similar to: [LLVMdev] Making it possible to clear the LLVMContext

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

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

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

In the most basic case, I'd imagine something like this: auto C = std::make_shared<LLVMContext>(); struct ModuleAndSharedContextDeleter { std::shared_ptr<LLVMContext> C; operator()(Module *M) { delete M; } /* ctor to init C */}; std::unique_ptr<Module, ModuleAndSharedDeleter> M(new Module(C.get()), ModuleAndSharedContextDeleter(C)); (or invert this and traffic in structs

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

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

Hi Duncan, I came across something like the following recently which I guess might be related to your recent work. Any ideas? $ clang++-tot -cc1 crash_on_invalid.cpp -g -emit-obj -fexceptions -fcxx-exceptions crash_on_invalid.cpp:13:1: error: C++ requires a type specifier for all declarations x; ^ 1 error generated. *** Error in `clang++-tot': corrupted double-linked list: 0x000000000754f340

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 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 Wed, Jan 14, 2015 at 9:05 AM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2015 Jan 14, at 07:58, Duncan P. N. Exon Smith <dexonsmith at apple.com> > wrote: > > > >> > >> On 2015 Jan 13, at 23:59, David Blaikie <dblaikie at gmail.com> wrote: > >> > >> > >> > >> On Tue, Jan 13, 2015

Thanks, I am now working on compiling up VMKit. When compiling VMKit in my up-to-date svn checkout I get several error messages on missing members of the class 'llvm::Type': PNetLib.cpp: In function ‘void decapsulePrimitive(n3::VMObject*, const llvm::Type*, std::vector<llvm::GenericValue, std::allocator<llvm::GenericValue> >&)’: PNetLib.cpp:694: error: ‘Int1Ty’ is not a

Hi, On 2018-03-26 16:44:05 -0700, Duncan P. N. Exon Smith wrote: > > The second approach is to *not* cache modules but re-read them from disk > > (or memory, but that's irrelevant here). That works without any sort of > > asserts, but "leaks" memory because everytime a module is re-read from > > disk it re-creates types (cf

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

> On 2015-Jan-19, at 12:38, Frédéric Riss <friss at apple.com> wrote: > > >> On Jan 19, 2015, at 12:04 PM, Christian Schafmeister <chris.schaf at verizon.net> wrote: >> >> >> I forgot to mention this in my initial email. >> >> The build of LLVM that I was using was commit a0d5d7aed8e177cea381b3d054d80c212ece9f2c >> The date on the

Hi, LLVM community, I found an issue in my using scenario. We deliberately parse a bitcode file twice. It contains a named struct type. eg. %struct.cmd = type { float, float, float, float, float, i32 }. In the second module->dump, %struct.cmd becomes %struct.cmd0. my code is simplified like this. int main() { llvm::LLVMContext &llvmCtx = llvm::getGlobalContext(); string ErrMsg;

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

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

Hi: I'm building a small tool on top of LLVM Core Library. ``` LLVMContext context; SMDiagnostic diag; Module *M = parseIRFile(InputIR, diag, context).get(); if (M == nullptr) { diag.print("LLVM", errs()); exit(-1); } assert(M->isMaterialized() && "Module not materialized!"); PointerType *ArrayPtrTy =