search for: recty

...s 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, Init's, etc). This change should have no effect on the TableGen backends, simply being a refactoring of the internals. One huge bonus in particular from centralizing all of the memory allocation is that I plan to hack in a custom memory allocator (in a local branch) which...

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

> 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 complicated) process for hooking into Support/Casting.h. Attached are 4 patches. I've al...

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 RTTI for your class hierarchy", which covers the > previously undocumented (albeit not that complicated) process for > hooking into Support/Casting.h. Cool. Please p...

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 TGParser.h to use struct. -------------- next part -------------- A non-text attachment was scrubbed... Name: intel-patch.dif...

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 of the folding of the operation....

...blegen\Record.h(38) : warning C4099: 'llvm::Init' : type name first seen using 'class' now seen using 'struct' 1> c:\llvm\utils\tablegen\TGParser.h(24) : see declaration of 'llvm::Init' 1>c:\llvm\utils\tablegen\Record.h(63) : warning C4099: 'llvm::RecTy' : type name first seen using 'class' now seen using 'struct' 1> c:\llvm\utils\tablegen\TGParser.h(23) : see declaration of 'llvm::RecTy' 1>c:\llvm\utils\tablegen\Record.h(425) : warning C4099: 'llvm::Init' : type name first seen using 'class...

...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, Init's, etc). This >> change should have no effect on the TableGen backends, simply being a >> refactoring of the internals. > > Makes sense to me. > >> One huge bonus in particular from centralizing all of the memory >> allocation is that I...

...nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff6ec15c0 in *__GI_abort () at abort.c:92 #2 0x00007ffff6eb6941 in *__GI___assert_fail (assertion=0x5aa663 "0 && \"Unknown unop\"", file=<value optimized out>, line=633, function=0x5abb20 "virtual llvm::RecTy* llvm::UnOpInit::getFieldType(const std::string&) const") at assert.c:81 #3 0x000000000050ddc8 in llvm::UnOpInit::getFieldType (this=0x850f00, FieldName=...) at Record.cpp:633 #4 0x0000000000543f64 in llvm::TGParser::ParseValue (this=0x7fffffffd480, CurRec=0x8511d0, ItemType=0x851540) at...

...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, Init's, etc). This >>> change should have no effect on the TableGen backends, simply being a >>> refactoring of the internals. >> >> Makes sense to me. >> >>> One huge bonus in particular from centralizing all of the memory &gt...

...t 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, Init's, etc). This > change should have no effect on the TableGen backends, simply being a > refactoring of the internals. > > One huge bonus in particular from centralizing all of the memory > allocation is that I plan to hack in a custom memory allocator (...

...t 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, Init's, etc). This > change should have no effect on the TableGen backends, simply being a > refactoring of the internals. Makes sense to me. > One huge bonus in particular from centralizing all of the memory > allocation is that I plan to hack in a custom mem...

...x/sysv/linux/raise.c:64 > #1 0x00007ffff6ec15c0 in *__GI_abort () at abort.c:92 > #2 0x00007ffff6eb6941 in *__GI___assert_fail (assertion=0x5aa663 "0 && \"Unknown unop\"", file=<value optimized out>, line=633, > function=0x5abb20 "virtual llvm::RecTy* llvm::UnOpInit::getFieldType(const std::string&) const") at assert.c:81 > #3 0x000000000050ddc8 in llvm::UnOpInit::getFieldType (this=0x850f00, FieldName=...) at Record.cpp:633 > #4 0x0000000000543f64 in llvm::TGParser::ParseValue (this=0x7fffffffd480, CurRec=0x8511d0, ItemType=0x...

...ut 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, Init's, etc). This > change should have no effect on the TableGen backends, simply being a > refactoring of the internals. > > One huge bonus in particular from centralizing all of the memory > allocation is that I plan to hack in a custom memory allocator (i...

...d 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, const Init *rhs, RecTy *Type) { #define WORKS #ifdef WORKS typedef std::pair< std::pair< std::pair<std::pair<unsigned, std::string>, const Init *>, const Init * >, const Init * > Key; #else typedef std::pair< std::pair< std::pair<std::pair<un...

...c:64 > > #1 0x00007ffff6ec15c0 in *__GI_abort () at abort.c:92 > > #2 0x00007ffff6eb6941 in *__GI___assert_fail (assertion=0x5aa663 "0 && > \"Unknown unop\"", file=<value optimized out>, line=633, > > function=0x5abb20 "virtual llvm::RecTy* > llvm::UnOpInit::getFieldType(const std::string&) const") at assert.c:81 > > #3 0x000000000050ddc8 in llvm::UnOpInit::getFieldType (this=0x850f00, > FieldName=...) at Record.cpp:633 > > #4 0x0000000000543f64 in llvm::TGParser::ParseValue > (this=0x7fffffffd480, Cur...

...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, Init's, etc). This >> change should have no effect on the TableGen backends, simply being a >> refactoring of the internals. >> >> One huge bonus in particular from centralizing all of the memory >> allocation is that I plan to hack in a custom...