search for: resolvereferences

Jakob, I think this exactly what's happening. I debugged the resolveReferences for the ADD down into the resolve of TSFlags. It calls VarInit::getFieldInit for the "Val" field of "foo". The code is: Init *VarInit::getFieldInit(Record &R, const RecordVal *RV, const std::string &FieldName) const { if (isa<RecordRecTy...

An extra call to resolveReferences after setting the value in the `let` does fix this, but I'm not sure that it is the right fix. The attached hackish patch seems to fix up a reduced version of the test case you gave here (I haven't run a full battery of tests on it, so it might cause other failures). Jakob, any idea about...

On Tuesday 24 March 2009 10:43, Chris Lattner wrote: > On Mar 23, 2009, at 5:56 PM, David Greene wrote: > > Is it legal to do something like a !strconcat on a non-string > > entity? That > > is, is there some operation that will let me do this (replace > > SOME_CONCAT with > > an appropriate operator): > > I don't get it, can you try a simpler example on

On Jan 31, 2013, at 9:27 AM, Sean Silva <silvas at purdue.edu> wrote: > An extra call to resolveReferences after setting the value in the > `let` does fix this, but I'm not sure that it is the right fix. The > attached hackish patch seems to fix up a reduced version of the test > case you gave here (I haven't run a full battery of tests on it, so it > might cause other failures). &gt...

...rgument to Fold for TGParser use is not an issue as it has a RecordKeeper instance, the other Record classes have a problem because they lack this type of instance. See for example the implementation of Record.cpp:OpInit::resolveBitReference(...). These methods (such as resolveBitReference(...) and resolveReferences(...) need a context containing a RecordKeeper for their evaluation. A cursory glance for the uses of Record::setName(...) seems to imply that adding a RecordKeeper& argument would not be an issue. I'll keep on looking for other mechanisms. > > Another random question: why is create...

It seems like this code should work with Tablegen, but it generates the error: "error:Invalid TSFlags bit in ADD" Here's the code: =================================== include "llvm/Target/Target.td" def MyInstrInfo : InstrInfo; def MyTarget : Target { // Information about the instructions... let InstructionSet = MyInstrInfo; } def r1 :

My brief investigation seems to point at this having to do with the let altering the base class, which prevents the usual resolution from occurring (presumably the resolution has already happened for the base). I'll dig into this tomorrow. -- Sean Silva

...itself. When it comes to variable resolving, I propose a simple resolver interface, see https://reviews.llvm.org/D43564. This allows multiple template arguments to be resolved simultaneously, which should be a small performance improvements aside from the more subjective cleanup of the IMO odd resolveReferences interface. At the same time, this allows proper variable hiding when resolving inside nested !foreachs. The type system stuff is more vague, and is mostly about making sure that we actually get the right types everywhere. For example, list types end up being incorrect all over the place at the...

...s to variable resolving, I propose a simple resolver > interface, see https://reviews.llvm.org/D43564. > > This allows multiple template arguments to be resolved simultaneously, > which should be a small performance improvements aside from the more > subjective cleanup of the IMO odd resolveReferences interface. At the > same time, this allows proper variable hiding when resolving inside > nested !foreachs. > > The type system stuff is more vague, and is mostly about making sure > that we actually get the right types everywhere. For example, list types > end up being incorrect...

On Dec 12, 2010, at 10:54 AM, Garrison Venn wrote: > > Hey Chris, > > The following patch removes all global references to a RecordKeeper instance for the tblgen > utility. This effort was motivated by the FIXME remark, in TableGen.cpp. Although a few files > were touched, the main change was to Record.h. > > The patch takes the simple approach of adding a RecordKeeper

...for TGParser use is not an issue as it has a RecordKeeper instance, the other Record > classes have a problem because they lack this type of instance. See for example the > implementation of Record.cpp:OpInit::resolveBitReference(...). These methods (such as > resolveBitReference(...) and resolveReferences(...) need a context containing a RecordKeeper > for their evaluation. A cursory glance for the uses of Record::setName(...) seems to imply that adding a > RecordKeeper& argument would not be an issue. I'll keep on looking for other mechanisms. > >> >> Another random...

Hey Chris, The following patch removes all global references to a RecordKeeper instance for the tblgen utility. This effort was motivated by the FIXME remark, in TableGen.cpp. Although a few files were touched, the main change was to Record.h. The patch takes the simple approach of adding a RecordKeeper reference to TGParser, and any needed emitter helper classes. In addition, since some of

On Mon, Feb 19, 2018 at 11:26 AM Nicolai Hähnle <nhaehnle at gmail.com> wrote: > Hi all, > > While working on some features for the AMDGPU backend -- specifically, > explicit address components for image intrinsics, which involves > generating both > > (a) a lot of intrinsics with different but somewhat regular parameter > types, and > > (b) the patterns to

Hi all, While working on some features for the AMDGPU backend -- specifically, explicit address components for image intrinsics, which involves generating both (a) a lot of intrinsics with different but somewhat regular parameter types, and (b) the patterns to select instructions for those intrinsics -- I got fed up with a lot of the TableGen bugs and limitations and set out to fix things.