similar to: [LLVMdev] LLVMContextImpl.h not installed?

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

Hello, the need here is to have a single LLVMContext used for multiple compilations. You make a good point about that by the way. If there are outstanding users cleaning the context under their seats might still pose a risk to them, and in that case deleting + newing a new LLVMContextImpl might actually not be very different. Marcello 2014-06-24 17:14 GMT+01:00 David Blaikie <dblaikie at

Something like, keeping the compiler alive for a many compilation sessions, using the same LLVMContext, but without the problem of accumulating data in the LLVMContext that would slowly fill up the memory. This as much I can enter into details that I can :/ Probably this is also a quite common use case scenario too. Marcello 2014-06-24 18:52 GMT+01:00 Eric Christopher <echristo at

Hello, I'm trying to develop a way to reliably clean the LLVMContext in order to make it possible to use it multiple times. LLVMContext itself is an almost empty object delegating almost all its content to LLVMContextImpl. This makes it very clean ideally, because clearing the LLVMContext would be as easy as deleting the LLVMContextImpl and creating a new one. The problem is that for some

Hi, I am trying to write a module pass that traverses through named structure types defined and modifies the type of certain fields in these named types. Is there any simple way of doing this? I am not quite sure how to get the LLVMContext's pImpl working from a pass since LLVMContextImpl is forward-declared. Thanks, Joe -------------- next part -------------- An HTML attachment was

On Tue, Aug 14, 2012 at 1:23 PM, Joe Yan <jyan2 at umd.edu> wrote: > Hi, > > I am trying to write a module pass that traverses through named structure > types defined and modifies the type of certain fields in these named types. > Is there any simple way of doing this? I am not quite sure how to get the > LLVMContext's pImpl working from a pass since LLVMContextImpl is

Hello! I'm newer to LLVM development . I'm trying to use AllocaInst class to construct an instruction , I wrote like this: AllocaInst *alloc = new AllocaInst(llvm::Int32Ty, 0, "indexLoc",i); but it return the error: error: use of undeclared identifier 'llvm::Int32Ty' AllocaInst *alloc = new AllocaInst(Int32Ty, 0, "indexLoc",i); I

Hi, On Tuesday, June 24, 2014 15:18:51 Marcello Maggioni wrote: > I'm trying to develop a way to reliably clean the LLVMContext in order to > make it possible to use it multiple times. > > LLVMContext itself is an almost empty object delegating almost all its > content to LLVMContextImpl. > This makes it very clean ideally, because clearing the LLVMContext would be > as

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

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

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Jin Huang > Subject: [LLVMdev] LLVM Type Int32Ty Problems & LLVMContextImpl.h Problems >    AllocaInst *alloc = new AllocaInst(llvm::Int32Ty, 0, "indexLoc",i); I think you should be using llvm::Type::getInt32Ty(Context), not llvm::Int32Ty, which is for internal LLVM usage.

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

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

On 18 Aug 2016, at 23:59, Richhiey Thomas <richhiey.thomas at gmail.com> wrote: > I've currently added a few classes which don't really belong to the public API (currently) into private headers and used PIMPL with the Cluster class. I'm having difficulty reading your changes, because you aren't keeping to one complete change per commit. So for instance you've added a

Agreed, the existing ownership seems sub-optimal. I wouldn't say broken, but subtle at least - looks like you get the choice to either manage the ownership of the Module object yourself, or let the context handle it (eg: currently it'd be valid to just do "{ LLVMContext C; new Module(C); new Module(C); }" - Modules end up owned by the context and cleaned up there). Might be hard

Hi Mehdi, Thanks for your reply. It seems caused by random rename because I saw %struct.StructTyName.692.475*, which might be twice renaming. Does this collision occur because this type is declared more than once? I encountered this problem when used clang to compile transmission 1.42 (http://download.transmissionbt.com/files/) with configuration: "./configure --disable-gtk". Then

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 Mon, Mar 29, 2010 at 01:15:30PM +0100, Renato Golin wrote: > Hi All, > > Which implies no one was expecting a UnionType there... > > Also, if I generate the object code directly, llc fails too... > > Is there any plan to implement the union type? The work-around is quite ugly... Sorry to Renato for getting two copeis of this, I cocked up the reply first time. Anyway,

> How long does 200?300 documents take to cluster? How does it grow as more > documents are included in the MSet? We'd expect an MSet of 1000 documents > to take longer to cluster than one with 100, but the important thing is > _how_ the time increases as the number of documents grows. > > Currently, the number of seconds taken for clustering a set of documents for varying

I tried to compare two types. Because of renaming, the comparison result is not as expected. How to deal with renaming while comparing types? Best, Haopeng On 6/2/15 4:09 PM, Mehdi Amini wrote: > Hi Haopeng, > > One more element, I just noticed you are using LTO, I am not sure how it is implemented but my guess is that there is a shared LLVMContext. If multiple files include this