search for: recordkeeper

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 addit...

...x style issues with the attached patch. It only contains these style changes. On Dec 12, 2010, at 19:30, Chris Lattner wrote: > > 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 looks like great progress to me, applied in r121659. > > That said, it is suboptimal for Record to have to have a RecordKeeper& in it. I haven't looked at the code in a long time, is it feasible to detangle that out of recor...

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 getAll...

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 reference to TGParser, and > any needed emitter...

Concerning the RecordKeeper reference in Record. Would you prefer to partially go back to a more limited constrained version of a global. Since we are not threaded anyway, we could turn the reference into a singleton for the duration of an initial parse and use session. The concept would be to instead make the reference a sta...

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 Table...

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 insta...

On Dec 12, 2010, at 8:12 PM, Garrison Venn wrote: >> I believe I caught most of the syntax style issues with the attached patch. It only contains >> these style changes. Thanks! I applied your followup patch in r121837. > Concerning the RecordKeeper reference in Record. Would you prefer to partially go > back to a more limited constrained version of a global. Since we are not threaded anyway, > we could turn the reference into a singleton for the duration of an initial parse and use session. > The concept would be to instead make the...

...d. I could push the Record > constructor to protected or private and make MultiClass a friend. This is ugly so I think I should > drop the factory method in favor of new Record. Like I said the factory method is mainly sugar > anyway. > > I'm assuming your ok with dropping the RecordKeeper::createRecord(...). I'll send that > patch tomorrow. > > ... >> Some minor coding style things: >> >> ... > >> -Chris >> > > <RecordKeeper.4.patch> I think you will be ok with this. Garrison PS: Standalone patch with respect to trunk...

...egisteredOptionList) 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 instantia...

...is a skeleton file for writing a new TableGen backend. /home/buildbots/docker-RHEL-buildbot/SetupBot/worker_env/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm/llvm/lib/TableGen/TableGenBackendSkeleton.cpp:38:17: error: private field 'Records' is not used [-Werror,-Wunused-private-field] RecordKeeper &Records; ^ There are two options: 1. Don't compile it at all. (I swear I compiled it locally.) 2. Add something to eliminate the error. I'm open to suggestions.

Thanks for the feedback! >> Does anybody have anything else they think should go into TGContext or >> any other responsibilities it should have? Or any feedback about the >> idea in general? > > All memory allocations should go into its bump pointer, RecordKeeper should as well. Any other global state that exist should also. Sounds good. >> I'm also hoping that this change should loosen up some of the >> calcification that has accumulated on TableGen and get the ball >> rolling for transitioning dynamic_cast<> to dyn_cast<&...

...atternToMatcher(llvm::PatternToMatch const&, unsigned int, llvm::CodeGenDAGPatterns const&) + 143 11 llvm-tblgen 0x0000000108927ca5 (anonymous namespace)::DAGISelEmitter::run(llvm::raw_ostream&) + 3205 12 llvm-tblgen 0x0000000108926fd6 llvm::EmitDAGISel(llvm::RecordKeeper&, llvm::raw_ostream&) + 54 13 llvm-tblgen 0x0000000108a6dfc8 (anonymous namespace)::LLVMTableGenMain(llvm::raw_ostream&, llvm::RecordKeeper&) + 328 14 libLLVMTableGen.dylib 0x0000000108fd7cb1 llvm::TableGenMain(char*, bool (*)(llvm::raw_ostream&, llvm::RecordKe...

...help move the "tblgen as a library" idea closer to reality. > Does anybody have anything else they think should go into TGContext or > any other responsibilities it should have? Or any feedback about the > idea in general? All memory allocations should go into its bump pointer, RecordKeeper should as well. Any other global state that exist should also. > I'm also hoping that this change should loosen up some of the > calcification that has accumulated on TableGen and get the ball > rolling for transitioning dynamic_cast<> to dyn_cast<> and eliminating > e...

...anks for the feedback! > >>> Does anybody have anything else they think should go into TGContext or >>> any other responsibilities it should have? Or any feedback about the >>> idea in general? >> >> All memory allocations should go into its bump pointer, RecordKeeper should as well. Any other global state that exist should also. > > Sounds good. > >>> I'm also hoping that this change should loosen up some of the >>> calcification that has accumulated on TableGen and get the ball >>> rolling for transitioning dynamic_ca...

tl;dr: is anyone opposed to making the interface to a TableGen backend be: void MyBackend(RecordKeeper &, raw_ostream & /* maybe some other args, per backend's needs */); ?? Currently, this is the "interface" for a TableGen backend: struct TableGenBackend { virtual void anchor(); virtual ~TableGenBackend() {} // run - All TableGen backends should implement the run met...

Dear LLVM devs, I'm just working on the LLVM assembler's handling of .file and .line directives. I've noticed some strange things and am wondering if there is a reason the code works the way it does. 1. MCContext keeps a map of number -> MCDwarfLineTable called MCDwarfLineTablesCUMap. However, as far as I can see, the only compilation unit number which is *ever* used is zero! If

Could we expose predicates defined in the target InstrInfo.td file to the MachineVerifier? We use BuildMI() to create many instructions after ISEL, but the predicates are not being checked at this point. Thus, I could forget to check the target and build an instruction that is illegal for a specific configuration. In such a case it would be nice if the MachineVerifier could detect this for me.

...runTargetDesc(llvm::raw_ostream&, llvm::CodeGenTarget&, llvm::CodeGenRegBank&) + 18402 10 llvm-tblgen 0x000000010ba25658 (anonymous namespace)::RegisterInfoEmitter::run(llvm::raw_ostream&) + 120 11 llvm-tblgen 0x000000010ba25596 llvm::EmitRegisterInfo(llvm::RecordKeeper&, llvm::raw_ostream&) + 54 12 llvm-tblgen 0x000000010bad6f28 (anonymous namespace)::LLVMTableGenMain(llvm::raw_ostream&, llvm::RecordKeeper&) + 184 13 llvm-tblgen 0x000000010bc3b54f llvm::TableGenMain(char*, bool (*)(llvm::raw_ostream&, llvm::RecordKeep...

...fies the value 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