search for: recti

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 proper unique'd type system and BumpPtr allocate all of TableGen's data (RecTy's, Record's,

>> Ok, here's the first batch. It converts the RecTy hierarchy over to >> use LLVM-style RTTI. Along the way, I also wrote up a new doc "How to >> set up LLVM-style RTTI for your class hierarchy", which covers the >> previously undocumented (albeit not that complicated) process for >> hooking into Support/Casting.h. > > Cool. Please pull this

> It won't cause a negative effect, go for it! Dynamic_cast is realllly slow compared to dyn_cast, it is worth the memory. Ok, here's the first batch. It converts the RecTy hierarchy over to use LLVM-style RTTI. Along the way, I also wrote up a new doc "How to set up LLVM-style RTTI for your class hierarchy", which covers the previously undocumented (albeit not that

On Oct 4, 2012, at 5:15 PM, Sean Silva <silvas at purdue.edu> wrote: >> It won't cause a negative effect, go for it! Dynamic_cast is realllly slow compared to dyn_cast, it is worth the memory. > > Ok, here's the first batch. It converts the RecTy hierarchy over to > use LLVM-style RTTI. Along the way, I also wrote up a new doc "How to > set up LLVM-style

I've been trying to get llvm to compile under windows with the Intel C+ + 11.0.066 compiler without killing the compiler. I filed a bug report with Intel, and Intel says that their compiler has a problem with RecTy and Init being declared with "class" in utils \TableGen\TGParser.h but defined with "struct" in utils\TableGen \Record.h. The attached patch changes

I'm adding some new operators to TableGen and I've run into a memory ownership issue. We have all of these Inits and RecTys flying around but I don't see any scheme to assign ownership. It looks like we're leaking memory all over. This is getting worse as I'm adding operators because I need to create new objects on-the-fly and/or return operands of operators as the result

Hi, I'm new to Clang / LLVM, and trying to build so that it will run natively on Windows. Used the CMake approach (thanks to whoever created the configs for this). Had to comment out "DbgInfoRemover.cpp" in one of the make files (didn't spend time to figure out why), following which CMake produced a nice working Visual Studio 2008 solution file. I opened this up in VS

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

Hello, I was fiddling with TableGen (for a use that has nothing to do with a compiler but it's doesn't matter) and TableGen triggers an assertion failure on this code (I reduced the case to the minimum, it's a parsing bug): class Bli<string _t> { string t = _t; } class Bla<list<Bli> _bli> : Bli<!car(_bli).t> { } #0 0x00007ffff6ebda75 in *__GI_raise

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

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

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

On Sep 1, 2010, at 4:35 AM, Amaury Pouly wrote: > Hello, > I was fiddling with TableGen (for a use that has nothing to do with a compiler but it's doesn't matter) and TableGen triggers an assertion failure on this code (I reduced the case to the minimum, it's a parsing bug): David, can you take a look? This is related to your lisp interpreter :) -Chris > > class

Why do you want to eliminate dynamic_cast and exceptions from tablegen? This is just a tool run over a few thousand lines of td files. You can't measure the difference in performance if you eliminate dynamic_cast and exceptions. I think it was a huge mistake to not use RTTI and exceptions in the compiler itself but I'm sure that old horse has been beaten to death long ago. But for

In the midst of making TableGen Inits unique, I've run into some very odd DenseMap behavior. I converted the TernOpInit to use a factory method that uses a DenseMap to unique objects. I have defined a DenseMapInfo for std::string that uses HashString from StringExtras.h. const TernOpInit *TernOpInit::get(TernaryOp opc, const Init *lhs, const Init *mhs,

While I'm at it, I noticed a behaviour which is not exactly related but similar. To put it simply, you can 't do T.V.W, you need to do !cast<Bla>(T.V).W Example: class Bla<string t> { string blu = t; } class Bli<Bla t> { Bla bla = t; } def a : Bli<Bla<"">>; def b : Bla<!cast<Bla>(a.bla).blu>; // works def b :

...not by me, nor by anybody else AFAICT). Most of the changes that I am proposing are primarily to make it more self-contained and maintainable. Also, once TableGen is up to snuff with the rest of the codebase and its current de facto behavior is documented, it will be possible to coherently take directions on improving the language, which could have significant positive benefits across the codebase by e.g. making target descriptions easier to write and maintain. > Algorithm complexity and choice is what usually dominates efficiency unless > you are talking about some tight loop in the kerne...