similar to: [LLVMdev] Iterate through a Module's StructTypes

Hello, I'm updating a legacy code using LLVM 2.5 where it has an iteration through a Module's TypeSymbolTable to process each StructType. In LLVM 3.4, TypeSymbolTable has been removed. I can only find the LLVMContextImpl instance of a Module's LLVMContext which has AnonStructTypes and NamedStructTypes two maps. However, LLVMContextImpl is an opaque class which cannot be directly

Dear Rafael, Thank you for your answer. The verbose mode -v shows that clang uses the old ld in /usr/bin while I install the gold in /usr/local/bin. Regards, Chunbai On Tue, Dec 3, 2013 at 9:23 PM, Rafael Espíndola <rafael.espindola at gmail.com > wrote: > > Could anyone tell me where my mistake is? > > Try running > > clang -flto a.o b.o -o main -v > > it should

On 5 December 2013 07:46, Chunbai YANG <chunbyang2 at gapps.cityu.edu.hk> wrote: > Dear Rafael, > > Thank you for your answer. The verbose mode -v shows that clang uses the old > ld in /usr/bin while I install the gold in /usr/local/bin. Clang should be searching the path. What does $ which ld print? Maybe all that you have to do is $ export PATH=/usr/local/bin:$PATH Cheers,

Hi all, I 'd like to fetch a list of structures, and found that it could be done via LLVMContextImpl *pImpl = Context.pImpl; pImpl->AnonStructTypes This however needs the inclusion of LLVMContextImpl.h, which is not contained in the includes dir, but in the lib/IR dir (next to the .cpp files) and is not installed under /usr/local/include... Whats the reason for this? Isn't it

Hi everyone, I want to perform whole-program analysis for apache httpd using httpd's original autoconf system so that I need to generate a single bitcode file. So I follow the instructions in LLVM document on gold plugin http://llvm.org/docs/GoldPlugin.html#lto-how-to-build. However, when running a simple program using LTO, clang fails to link the object file with the LLVM bitcode.

Several people on this list have reported issues with the linker regarding a named StructType instance with the same name in two different modules being resolved into two StructTypes with different names due to StructType:: setName(…) collision behavior. Looking at BitcodeReader::ParseTypeTableBody(…), I don't see use of LLVMContextImpl::NamedStructTypes or of Module::getTypeByName(…). Nor do

Is it possible to merge StructTypes with different names like: %"class.std::allocator.4" = type { i8 } %"class.__gnu_cxx::new_allocator.5" = type { i8 } %"class.std::allocator.0" = type { i8 } %"class.__gnu_cxx::new_allocator.1" = type { i8 } %"class.std::allocator.0.6" = type { i8 } merge into %"class.__gnu_cxx::new_allocator" = type

Hi Михаил, > Is it possible to merge StructTypes with different names like: > > %"class.std::allocator.4" = type { i8 } > %"class.__gnu_cxx::new_allocator.5" = type { i8 } > %"class.std::allocator.0" = type { i8 } > %"class.__gnu_cxx::new_allocator.1" = type { i8 } > %"class.std::allocator.0.6" = type { i8 } > > merge

I have such problem with linking represented files.... llvm-link 1.bc 2.bc -o 3.bc 2012/5/4 Duncan Sands <baldrick at free.fr> > Hi Михаил, > > > Is it possible to merge StructTypes with different names like: > > > > %"class.std::allocator.4" = type { i8 } > > %"class.__gnu_cxx::new_allocator.5" = type { i8 } > >

On Jul 25, 2011, at 10:50 AM, Garrison Venn wrote: > Several people on this list have reported issues with the linker regarding a > named StructType instance with the same name in two different modules > being resolved into two StructTypes with different names due to StructType:: > setName(…) collision behavior. Looking at BitcodeReader::ParseTypeTableBody(…), > I don't see

Quick question: how do I get a list of StructType* defined/used in a Module? I can't seem to find an appropriate iterator in the Module class... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110831/17715c85/attachment.html> -------------- next part -------------- A non-text attachment was

On Aug 31, 2011, at 10:23 AM, Carlo Alberto Ferraris wrote: > Quick question: how do I get a list of StructType* defined/used in a Module? I can't seem to find an appropriate iterator in the Module class... Module::findUsedStructTypes. Note that this requires scanning the entire module, it is not an efficient operation. -Chris

Nella citazione mercoledì 31 agosto 2011 20:35:46, Chris Lattner ha scritto: > On Aug 31, 2011, at 10:23 AM, Carlo Alberto Ferraris wrote: >> Quick question: how do I get a list of StructType* defined/used in a Module? I can't seem to find an appropriate iterator in the Module class... > Module::findUsedStructTypes. Note that this requires scanning the entire module, it is not an

On Mon, Jul 25, 2011 at 10:50 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Several people on this list have reported issues with the linker regarding a > named StructType instance with the same name in two different modules > being resolved into two StructTypes with different names due to StructType:: > setName(…) collision behavior. Looking at

> Could anyone tell me where my mistake is? Try running clang -flto a.o b.o -o main -v it should print how clang is running the linker. See if it is running the linker you expect and if it is passing -plugin to it. Cheers, Rafael

Thanks for the response Chris, On Jul 26, 2011, at 0:44, Chris Lattner wrote: > > On Jul 25, 2011, at 10:50 AM, Garrison Venn wrote: > >> Several people on this list have reported issues with the linker regarding a >> named StructType instance with the same name in two different modules >> being resolved into two StructTypes with different names due to StructType::

On 25 June 2011 13:00, Duncan Sands <baldrick at free.fr> wrote: >> 3. Clang/dragonegg need to adapt to the new API (help appreciated!) > > what needs to be done exactly? Background info: http://www.nondot.org/sabre/LLVMNotes/TypeSystemRewrite.txt As I understand it, PATypeHolder, OpaqueType and the Module's TypeSymbolTable are gone. Instead, StructTypes can optionally be

Hi Chris, > 3. Clang/dragonegg need to adapt to the new API (help appreciated!) what needs to be done exactly? Ciao, Duncan.

Hi Jay, > As I understand it, PATypeHolder, OpaqueType and the Module's > TypeSymbolTable are gone. Instead, StructTypes can optionally be > named, and if they are then: > > - they use name equivalence instead of structural equivalence. > - you can create them without any fields, and then add the fields > later when the struct is complete. I find this distinction between

On 30 June 2011 14:07, Duncan Sands <baldrick at free.fr> wrote: > Hi Jay, > >> As I understand it, PATypeHolder, OpaqueType and the Module's >> TypeSymbolTable are gone. Instead, StructTypes can optionally be >> named, and if they are then: >> >> - they use name equivalence instead of structural equivalence. >> - you can create them without any