search for: recordkeeping

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

Hi Chris, Thanks for the review! I believe I caught most of the syntax 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

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 to be manifested as a message to this

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

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 static pointer, make RecordKeeper a friend of Record, and add

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 >

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 which in turn

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

The attached patch removes Record::createRecord(...) and its uses from trunk, and includes previous code style fixes. On Dec 12, 2010, at 21:52, Garrison Venn wrote: > ... > >> >> Another random question: why is createRecord better than using "new Record"? If createRecord is better, it would be good to make the Record ctor private so the code doesn't evolve

Hey Chris, Ok, so I'm working on creating this trivial patch, for starters, but I'm trying to identify a controlled unit test for tblgen. So all of the following test tblgen to various extents: 1) make 2) make unittests 3) make // with clang and 4) make check // which I'm avoiding Since I'm just starting to understand tblgen, I'm not comfortable with any of these

There is a second issue with the new TableGenBackendSkeleton.cpp file. It 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;

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

I’m hitting TableGen errors trying to match the smullohi <lhs> <rhs> node in TableGen. smullohi returns two results, which is the problem. I am not sure how to match against multiple results. The only other nodes to return two operands are umullohi, udivrem, and sdivrem. There are no examples of these in TableGen in tree. The closest I can get is this: set (R1, R0, (umullohi

On Oct 3, 2012, at 7:07 PM, Sean Silva <silvas at purdue.edu> wrote: > Hi all, I'm sure that the last thing that you want to think about is > TableGen's guts, but I'm pursuing a course in bringing TableGen up to > snuff with the rest of LLVM. > > Basically, I would like to introduce a "TGContext" class (by analogy > with LLVMContext) to harbor a

It won't cause a negative effect, go for it! Dynamic_cast is realllly slow compared to dyn_cast, it is worth the memory. -Chris On Oct 3, 2012, at 9:39 PM, Sean Silva <silvas at purdue.edu> wrote: > Thanks for the feedback! > >>> Does anybody have anything else they think should go into TGContext or >>> any other responsibilities it should have? Or any

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

...ation unit, MCDwarfLineTable has a *vector* called MCDwarfFiles (so each MCDwarfLineTable can have multiple files). Although you can have references to multiple files in the same MCDwarfLineTable, it appears that the only one which is ever used is the first one! MCDwarfLineTable doesn't do any recordkeeping to remember which line number data belongs to which file, either. ------------------------ I can go through the code and clean up some of these inconsistencies, but I need to know how it is *intended* to work. Can someone explain? Thanks, Alex Dowad -------------- next part -------------- An HTM...

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.

Hi I'm returning to my MC6809 back-end from a health-related hiatus. The assembler is tantalisingly close, but I've got some parsing and matching problems. The register set; these overlap in annoying ways, for instance, two instructions TFR and EXG each have a single opcode, and the post-byte specifies which registers are to be involved, but the registers can be 8- or 16-bit, and 2 of

On Aug 17, 2012, at 10:02 AM, "Jyotsna Verma" <jverma at codeaurora.org> wrote: > > 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 >>