search for: getallderiveddefinit

Is there a reason that RecordKeeper:: getAllDerivedDefinitions(...) implementation accesses the global Records instance instead of just referencing itself? As far as I can tell from the usage: 1) Records has the linkage as extern RecordKeeper Records in Record.h 2) Is instantiated as a global in TableGen 3) All llvm uses of getAllDerivedDefinitions SEEM...

On Dec 9, 2010, at 4:50 AM, Garrison Venn wrote: > Is there a reason that RecordKeeper:: getAllDerivedDefinitions(...) implementation > accesses the global Records instance instead of just referencing itself? > > As far as I can tell from the usage: > > 1) Records has the linkage as extern RecordKeeper Records in Record.h > 2) Is instantiated as a global in TableGen > 3) All llvm us...

Attached patch for removing for the first trivial RecordKeeper:: getAllDerivedDefinitions(...) dependency on the global RecordKeeper Records instance. The real work will be removing this dependency from the other Record.h classes/structs, and from TGParser. Thinking this would be implemented as some sort of context structure/class holding a RecordKeeper instance passed to TGParser...

...List) can be modified after the fact. I'll check further when I get there. Now if only work would get out of the way. ;-) Garrison On Dec 9, 2010, at 18:32, Chris Lattner wrote: > > On Dec 9, 2010, at 4:50 AM, Garrison Venn wrote: > >> Is there a reason that RecordKeeper:: getAllDerivedDefinitions(...) implementation >> accesses the global Records instance instead of just referencing itself? >> >> As far as I can tell from the usage: >> >> 1) Records has the linkage as extern RecordKeeper Records in Record.h >> 2) Is instantiated as a global in Tabl...

...of the column fields in your key column. ValueCols identifies the other columns in the table. It should be an error if there are multiple instructions that fit a table entry because both row and column fields are identical. You don't need to change the parser. Simply start from RecordKeeper::getAllDerivedDefinitions(FilterClass). Identify the row and column (if any) of each instruction, and build your table from that. /jakob

Hi Jacob, Thanks for the suggestions. I have a few questions here. > You are on to something here, but you don't need to define a 'Relations' class > on top of the tablegen records. They are already relations, you just need the > proper query language to match the instructions you want. Are you saying that the mechanism is already present which allows us to relate

...vadve/shared/PublicCVS/llvm/utils/TableGen/CodeEmitterGen.cpp,v retrieving revision 1.41 diff -u -r1.41 CodeEmitterGen.cpp --- CodeEmitterGen.cpp 19 Aug 2005 01:04:33 -0000 1.41 +++ CodeEmitterGen.cpp 24 Oct 2005 06:40:56 -0000 @@ -76,7 +76,7 @@ std::vector<Record*> Insts = Records.getAllDerivedDefinitions("Instruction"); EmitSourceFileHeader("Machine Code Emitter", o); - o << "namespace llvm {\n\n"; + //o << "namespace llvm {\n\n"; std::string Namespace = Insts[0]->getValueAsString("Namespace") + "::"; //...

>> 2) Same error but some diff. problem with AlphaCodeEmitter.cpp and >> PPCCodeEmitter.cpp: >> >> GCC don't like definition member-functions in global namespace with >> declaration in llvm::<unnamed> : Sorry for wrong comment. Must be: GCC 4.1.0 don't like definition member-functions in llvm namespace with declaration in

...olumn. ValueCols > identifies the other columns in the table. > > It should be an error if there are multiple instructions that fit a table entry > because both row and column fields are identical. > > You don't need to change the parser. Simply start from > RecordKeeper::getAllDerivedDefinitions(FilterClass). Identify the row and > column (if any) of each instruction, and build your table from that. > > /jakob