search for: llvmcontextimpl

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 gmail.com>: > What're the situation in which you need to clear it? If there are > outstanding users of it (given that you mention clients possibly > holding references to the p...

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 reason which I'm not aware of LLVMContextImpl is actually exposed as a public pointer in the LLVMContext interface,making it...

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

...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 gmail.com>: > > > >> What're the situation in which you need to clear it? If there are > >> outstanding users...

...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 found that the Int32Ty is defined in the LLVMContextImpl.h , but I can not find it in the llvm include directory. I installed llvm in "/usr/local/llvm" but there is no "LLVMContextImpl.h" in /usr/local/llvm/include/llvm/IR (LLVMContext.h exists) Does this mean that the llvm is not installed correctly? What should I do to fix it? T...

...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 I see this use anywhere else in BitcodeReader's implementation (.cpp file). Doesn't the context's NamedStructTypes (checking for a previously created StructType with the same name), have to be used before setName(…) is called so...

...s 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 I see this use anywhere else in BitcodeReader's implementation (.cpp file). The BitcodeReader has nothing to do with the issue in question; the relevant code is in lib/Linker. -Eli

> 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. Also, using llvm::IRBuilder<> is a whole lot easier and safer than trying to cr...

...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 I see this use anywhere else in BitcodeReader's implementation (.cpp file). > > Doesn't the context's NamedStructTypes (checking for a previously created StructType > with the same name), have to be used before set...

...< llvm-dev at lists.llvm.org> wrote: > Actually, looking at the destructors for LLVMContext and Module I do not > think the current ownership scheme makes sense, so this might be a good > opportunity to re-think it. > > Right now an LLVMContext owns a list of modules (see > LLVMContextImpl::OwnedModules) that it destroys when its destructor is > called. Modules remove themselves from this list if they are destructed > before the context: > > Module::~Module() { > Context.removeModule(this); > ... > > LLVMContextImpl::~LLVMContextImpl() { > // NOTE: W...

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 easy as deleting the LLVMContextImpl and creating a new one. > > The problem is that for some reason which I'm not aware of LLVMContextImpl > is actually exposed as a public pointer in the LLVMCo...

On Jul 26, 2011, at 4:03 AM, Garrison Venn wrote: >> Hi Garrison, >> >> Do the other two threads answer the question here? >> >> -Chris > > Yes I believe the other threads concerning the same issue answer why the system, because > of the lack of type linkage, is lenient in "unioning" types. What I'm still uncomfortable with is, I >

...>> Actually, looking at the destructors for LLVMContext and Module I do not >>> think the current ownership scheme makes sense, so this might be a good >>> opportunity to re-think it. >>> >>> Right now an LLVMContext owns a list of modules (see >>> LLVMContextImpl::OwnedModules) that it destroys when its destructor is >>> called. Modules remove themselves from this list if they are destructed >>> before the context: >>> >>> Module::~Module() { >>> Context.removeModule(this); >>> ... >>> >...

...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 I see this use anywhere else in BitcodeReader's implementation (.cpp file). >> >> Doesn't the context's NamedStructTypes (checking for a previously created StructType >> with the same name), have to be...

...b0 3 libc.so.6 0x00007f0396195425 gsignal + 53 4 libc.so.6 0x00007f0396198b8b abort + 379 5 libc.so.6 0x00007f039618e0ee 6 libc.so.6 0x00007f039618e192 7 opt 0x0000000000f7cd7d 8 opt 0x0000000000ee3c52 9 opt 0x0000000000f5bddf llvm::LLVMContextImpl::~LLVMContextImpl() + 1999 10 opt 0x0000000000f5ad1c 11 opt 0x0000000000fb9d69 llvm::llvm_shutdown() + 41 12 opt 0x00000000005285b3 main + 7251 13 libc.so.6 0x00007f039618076d __libc_start_main + 237 14 opt 0x0000000000521f91 Stack dump: 0. P...

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 accessed by my code(a subclass of ModulePass). So how can I iterate all the Types in a Module? Thanks. Regards, Thomas Yang --------...

Hi All, ORC's new concurrent compilation model generates some interesting lifetime and thread safety questions around LLVMContext: We need multiple LLVMContexts (one per module in the simplest case, but at least one per thread), and the lifetime of each context depends on the execution path of the JIT'd code. We would like to deallocate contexts once all modules associated with them have

...95425 gsignal + 53 > 4 libc.so.6 0x00007f0396198b8b abort + 379 > 5 libc.so.6 0x00007f039618e0ee > 6 libc.so.6 0x00007f039618e192 > 7 opt 0x0000000000f7cd7d > 8 opt 0x0000000000ee3c52 > 9 opt 0x0000000000f5bddf > llvm::LLVMContextImpl::~LLVMContextImpl() + 1999 > 10 opt 0x0000000000f5ad1c > 11 opt 0x0000000000fb9d69 llvm::llvm_shutdown() + 41 > 12 opt 0x00000000005285b3 main + 7251 > 13 libc.so.6 0x00007f039618076d __libc_start_main + 237 > 14 opt 0x00000000005...

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 scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120814/48575773/attachment.html>

...ll stack for this case: msvcr100d.dll!_purecall() Line 54 + 0x7 bytes C > llvm_test.exe!llvm::BumpPtrAllocator::DeallocateSlabs(llvm::MemSlab * Slab) Line 71 + 0x1b bytes C++ llvm_test.exe!llvm::BumpPtrAllocator::~BumpPtrAllocator() Line 30 C++ llvm_test.exe!llvm::LLVMContextImpl::~LLVMContextImpl() Line 128 + 0xf3 bytes C++ llvm_test.exe!llvm::LLVMContextImpl::`scalar deleting destructor'() + 0x16 bytes C++ llvm_test.exe!llvm::LLVMContext::~LLVMContext() Line 62 + 0x38 bytes C++ llvm_test.exe!llvm::LLVMContext::`scalar deleting destructo...