similar to: [LLVMdev] TableGen: Requesting feedback for "TGContext"

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

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

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

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

> 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

> 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. This isn't about performance. It's about bringing it up to snuff with the rest of the codebase. And btw it's not "a few

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

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

Hi Sanjoy, Any update on this? Are there plans to implement this proposal? Thanks, Pankaj -----Original Message----- Date: Fri, 23 Sep 2016 02:09:19 -0700 From: Sanjoy Das via llvm-dev <llvm-dev at lists.llvm.org> To: llvm-dev <llvm-dev at lists.llvm.org>, Andrew Trick <atrick at apple.com>, Dan Gohman <dan433584 at gmail.com>, Hal Finkel <hfinkel at anl.gov>,

> On Aug 8, 2017, at 5:34 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi Pankaj, > > IIRC there was pushback on this proposal so I did not proceed further. > Are you blocked on this? > > [+CC Andy, who I remember had some objections.] > > — Sanjoy Off the top of my head, my concern is that expression comparison is no longer constant time,

Hello, While working on lld code, I encountered a couple of memory management issues. If lld should be usable as a library, I assume it should not leaks any memory when performing a single link pass (UniversalDriver::link(arc, argv)). Actually, after calling that function, I got some major leaks. I may be wrong, but I think there is 3 major leaks. - One of the main leak is in FileArchive. When

Hi all, This is about a project I've been prototyping on-and-off for a while that has finally reached a point where I can claim it to be "potentially viable". I'd like to gather some input from the community before moving too far ahead. # The problem There is a representation issue within SCEV that prevents it from fully using information from nsw/nuw flags present in the

Hi all, I'm trying to convert our code base from GCC 4.0 to LLVM (on mac OS X), and ran into a problem. In the past we used mach_override and the dynamic_cast source to override the built-in dynamic_cast operator to detect shared library issues (http://gcc.gnu.org/faq.html#dso). Basically we'd assert at runtime when a duplicated RTTI is found, giving us a chance to backtrace the offending

HI Stefan, CC'ing Reid Kleckner, who might have some insight here, and llvm-dev as this may be of interest to other windows JIT users. I am facing the issue that C++ dynamic_cast doesn't work for types > loaded from object files with RuntimeDyLd. <snip> Do you think it is possible that RuntimeDyLd misses type info data in > the COFF file or doesn't wire it up

LLVM has a relatively large number of proprietary replacements for standard C++ functions and classes. One of these is dyn_cast to replace dynamic_cast. The two calls appear to be semantically equivalent; the only difference that I can see is that dyn_cast reportedly works on classes that have no v-table [1]. Could someone please explain why I should use dyn_cast instead of dynamic_cast?

Hi Akos, you should send this to the clang mailing list instead. Ciao, Duncan. > I'm trying to convert our code base from GCC 4.0 to LLVM (on mac OS X), and ran > into a problem. In the past we used mach_override and the dynamic_cast source to > override the built-in dynamic_cast operator to detect shared library issues > (http://gcc.gnu.org/faq.html#dso). Basically we'd

As far as I can tell, exceptions work just fine without RTTI when using gcc 3.4.2. dynamic_cast, on the hand, crashes without RTTI (no compilation error or warning is generated). Jeff Cohen wrote: > This may be the case with GCC, but VC++ allows exception handling to > be enabled while RTTI is disabled. According to VC++ documentation, > RTTI is needed only to support

I see a bunch of definitions scattered throughout LLVM, and I could not find good documentation on them. I don't understand why they exist when LLVM is being compiled with RTTI enabled. It seems to me that: isa<T>(x) is a substitute for (dynamic_cast<T>(x) != NULL) and there are some other similar casting tools defined in Casting.h. Why should I use these instead of C++'s

Trevor Harmon <Trevor.W.Harmon at nasa.gov> writes: [snip] > Could someone > please explain why I should use dyn_cast instead of dynamic_cast? (I > thought all classes have v-tables...) Thanks, For reducing executable size, LLVM builds with RTTI disabled where possible.