search for: recordv

A question for all you TableGen aficionados: Does anyone know why the collection of RecordVal field values stored in a Record are represented by a SmallVector rather than some sort of map? This means that every time a record field is looked up by name, a linear search is performed. Is it a question of RAM usage?

I spent some time playing with TableGen in order to improve the ability of backends to generate error messages with more precise source locations. The main requirement was to add a slot to the RecordVal class to hold the source location of the statement that defined the field. To make that easier to use, I added a third PrintFatalError() method that accepts a RecordVal and grabs the source location from it. To test these ideas, I worked on the SearchableTable backend. It now includes in every m...

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>(getType())) if (const RecordVal *Val = R.getValue(VarName)) { if (RV != Val && (RV || isa<UnsetInit>(Val->getValue()))) return 0; Init *TheInit = Val-&g...

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

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 what the "right" fix is here? -- Sean Silva

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

...cherPredicate's value is 1 or 0. class "Predicate" in Target.td has a field AssemblerMatcherPredicate, so this will always return a non-null value. I think this line should be: if (!Pred->getValue("AssemblerMatcherPredicate")->getValue()) Pred->getValue returns a RecordVal object. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121127/55c08be4/attachment.html>