similar to: [LLVMdev] tblgen internals

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

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

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

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

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

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

Ok thanks I'll try that. I was trying to avoid re-building llvm-gcc. Garrison On Dec 10, 2010, at 12:12, Bob Wilson wrote: > > On Dec 10, 2010, at 6:11 AM, Garrison Venn wrote: > >> 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

On Dec 10, 2010, at 10:17 AM, Garrison Venn wrote: > Ok thanks I'll try that. I was trying to avoid re-building llvm-gcc. You don't need llvm-gcc to run most of the "make check" tests. The FrontEnd tests use it, but that's all. If you run configure with "--without-llvmgcc --without-llvmgxx", then it shouldn't use llvm-gcc at all. > > Garrison >

On Dec 10, 2010, at 6:11 AM, Garrison Venn wrote: > 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

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

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

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

Hi LLVMers, I found a bug in TGParser that is causing llvm-tblgen to crash on bad input. The reduced testcase is attached. The output follows: $ ./llvm-tblgen --version Low Level Virtual Machine (http://llvm.org/): LLVM version 3.1svn DEBUG build with assertions. Built Jan 20 2012 (15:46:08). Default target: x86_64-apple-darwin11.2.0 Host CPU: penryn $ ./llvm-tblgen bug.td 0

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

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

I made a simple edit to TGlexer.h, which is part of TableGen. Then, in Visual Studio, I asked it to build Tablegen. I got the following output: 1>------ Build started: Project: LLVMTableGen, Configuration: Release x64 ------ 1>Main.cpp 1>TGLexer.cpp 1>TGParser.cpp 1>LLVMTableGen.vcxproj -> D:\LLVM\Build\Release\lib\LLVMTableGen.lib ========== Build: 1 succeeded, 0 failed, 3

Hi All, One thing I believe also bothers someone else. Say we have the following code snippet: bits<32> insnEncoding; let insnEncoding{15-12} = 0b0100; Can we write the let expression with range list like this, with the same meaning? let insnEncoding{12-15} = 0b0100; I take a look on TGParser::ParseRangePiece (lib/TableGen/TGParser.cpp), seems the answer is YES. Can anyone