search for: howtosetupllvmstylertti

This [1] might worth reading, Malhar. [1] http://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html 2017-06-10 4:12 GMT+08:00 Tim Northover via llvm-dev < llvm-dev at lists.llvm.org>: > On 9 June 2017 at 12:03, Jajoo, Malhar via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Is there some way around this ( without suggesting a change to my entire > AST ) ? &g...

..._cast<>'s (e.g. `if (dyn_cast<>) { /* ... */ }`). 0003-tblgen-Use-appropriate-LLVM-style-RTTI-functions.patch: Fix up "semantically inappropriate" dyn_cast<>'s to isa<> or cast<> as appropriate. If you want I can squash this with 0002. 0004-docs-Add-HowToSetUpLLVMStyleRTTI.rst.patch: Add docs for setting up LLVM-style RTTI for a class hierarchy. The attached PDF is the rendered version of this document. Please give feedback on inaccuracies or suggested improvements for this document. One question regarding `classof()`s of the form: static bool classof(const Foo...

...(dyn_cast<>) { /* ... */ }`). > > 0003-tblgen-Use-appropriate-LLVM-style-RTTI-functions.patch: > Fix up "semantically inappropriate" dyn_cast<>'s to isa<> or cast<> as > appropriate. If you want I can squash this with 0002. > > 0004-docs-Add-HowToSetUpLLVMStyleRTTI.rst.patch: > Add docs for setting up LLVM-style RTTI for a class hierarchy. The > attached PDF is the rendered version of this document. Please give > feedback on inaccuracies or suggested improvements for this document. These all look great, please apply. > One question regarding `cl...

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

Hello. I'm new to this list (but I've been already following cfe-dev), so hello everybody. Is there some piece of documentation on how the custom dyn_cast<> work? I'm using LLVM as the backend for an experimental compiler and I want to make it work for my own classes in the front-end (clang also does this afaik). Thank you, Nicola

Hi, I was wondering if it was possible to create a Dummy Type by subclassing LLVM Type. I do not want to create a new type or even do much with this dummy type , all I need is a placeholder type until I generate IR. I want to use this approach as most of my AST is already configured to accept a Type* and not a DummyType* ( which is my own class ) I explored this a bit and did manage to

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

...* ... */ }`). >> >> 0003-tblgen-Use-appropriate-LLVM-style-RTTI-functions.patch: >> Fix up "semantically inappropriate" dyn_cast<>'s to isa<> or cast<> as >> appropriate. If you want I can squash this with 0002. >> >> 0004-docs-Add-HowToSetUpLLVMStyleRTTI.rst.patch: >> Add docs for setting up LLVM-style RTTI for a class hierarchy. The >> attached PDF is the rendered version of this document. Please give >> feedback on inaccuracies or suggested improvements for this document. > > These all look great, please apply. > >&g...

...p-front. > > It looks like I’m missing a piece of something as it is not clear why is > this strictly needed. I may have to actually look closer at the code itself. > > LLVM's RTTI requires you to define an enum value for each type in your > hierarchy (see http://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html), which > means you need to know about all your potential subclasses up-front. That's > not an option for a generic error class that might be subclassed in > arbitrary ways. > > > For a generic error class it is not an option indeed, but I was looking at > it in the co...

...ks like I’m missing a piece of something as it is not clear why >> is this strictly needed. I may have to actually look closer at the code >> itself. >> >> LLVM's RTTI requires you to define an enum value for each type in your >> hierarchy (see http://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html), which >> means you need to know about all your potential subclasses up-front. That's >> not an option for a generic error class that might be subclassed in >> arbitrary ways. >> >> >> For a generic error class it is not an option indeed, but I was look...

...to enumerate the types up-front. > It looks like I’m missing a piece of something as it is not clear why is this strictly needed. I may have to actually look closer at the code itself. LLVM's RTTI requires you to define an enum value for each type in your hierarchy (see http://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html), which means you need to know about all your potential subclasses up-front. That's not an option for a generic error class that might be subclassed in arbitrary ways. The new RTTI system uses something closer to LLVM's Pass IDs: TypedErrorInfo (a utility which all errors must inherit...

Hi Mehdi, > I’m not sure to understand this claim? You are supposed to be able to extend and subclass the type of diagnostics? (I remember doing it for an out-of-tree LLVM-based project). You can subclass diagnostics, but subclassing (on its own) only lets you change the behaviour of the diagnostic/error itself. What we need, and what this patch supplies, is a way to choose a particular