search for: disablelazycompilation

...one of the BBs of foo(), so it doesn't have a terminating instruction and I assert with: Assertion failed: (T && "getTerminator returned null!"), function SuccIterator, file /Users/ddd/Development/llvm/include/llvm/Support/CFG.h, line 99. I have checked that ExecutionEnding::DisableLazyCompilation() fixes it. Am I supposed to enable lazy JIT in that case? That's not really what i want, what I really would like is to be able to state that a function is "in progress" to make sure it doesn't get added to the pending list. Much like a forward reference in C. Thanks in advance...

...t;); EE->runFunction(mf, args); This is done for establishing a clear distinction between compile time and execution time (for benchmarking purposes) and for speeding up the whole process, as it is quite faster to generate all code in advance than to JIT it as it is found (ExecutionEngine::DisableLazyCompilation does not the same thing, as a large part of the code on the real-life applications where this compiler works is reachable only through pointers.)

Hello Eli. Eli Friedman <eli.friedman at gmail.com> writes: >> If I activate the Inliner pass: >> >>    Builder.Inliner = createFunctionInliningPass(Threshold); >> >> this is the result: >> >> LLVM ERROR: Program used external function 'llvm.lifetime.start' which could not be resolved! >> >> It happens on almost all my test

...was about changing the sense of a magic bool, why not > change the argument to be an enum instead?  That should make it extremely > clear in the source what behavior is desired. No, the magic bools all keep the same sense. The change affects the behavior of programs without a call to JIT->DisableLazyCompilation(bool). Anyone who's already calling it with any parameter keeps their current behavior. I'd be reasonably happy making that call required (so no default) if people want that instead.

...seems that r88984 does break fastcc and/or tail calls in the JIT. Maybe you don't see this in UnladenSwallow because it doesn't do tail calls? There's also some minor breakage which isn't TCO-related (four failed checks in the Pure interpreter) when reenabling lazy compilation with DisableLazyCompilation(false). These seem to go all the way back to your commit of Nick's patch (r84032 = "Keep track of stubs that are created" fails exactly the same checks, while r84031 is fine). Those four Pure checks all involve anonymous closures (lambdas); I still need to look at Nick's patch to...

...ionEngine created as follows: EE = llvm::EngineBuilder(globalModule) .setEngineKind(llvm::EngineKind::JIT) .setErrorStr(&err) .setOptLevel(llvm::CodeGenOpt::Default) .setAllocateGVsWithCode(false) //.setMAttrs("-avx") .setMCPU("core2") .create(); EE->DisableLazyCompilation(); After passing in the compiled module, I call: EE->runStaticConstructorsDestructors(module, false); Then to test the tear-down of the module, I call: EE->runStaticConstructorsDestructors(mImpl->module, true); EE->clearGlobalMappingsFromModule(mImpl->module); EE->removeModule...

...p;err) >                        .setOptLevel(llvm::CodeGenOpt::Default) >                        .setAllocateGVsWithCode(false) >                        //.setMAttrs("-avx") >                        .setMCPU("core2") >                        .create(); > EE->DisableLazyCompilation(); > > After passing in the compiled module, I call: > > EE->runStaticConstructorsDestructors(module, false); > > Then to test the tear-down of the module, I call: > > EE->runStaticConstructorsDestructors(mImpl->module, true); > EE->clearGlobalMappingsFromModu...

...e of a magic bool, why not >> change the argument to be an enum instead?  That should make it extremely >> clear in the source what behavior is desired. > > No, the magic bools all keep the same sense. The change affects the > behavior of programs without a call to > JIT->DisableLazyCompilation(bool). Anyone who's already calling it > with any parameter keeps their current behavior. ... but I'd be perfectly happy to rename that function and have it take an enum instead.

Hi Yuri, > I am debugging the memory issue that manifests itself like this: > > *** glibc detected *** ../app/app.OWS: free(): invalid pointer: 0x0ad391fc *** try running under valgrind. Note that if the program being JIT'd corrupts memory then this can cause the JIT itself to blow up. Ciao, Duncan.

(I have verified that just going through all the Functions in the Module and calling getPointerToFunction for each in turn actually seems to work -- I just wanted to make sure that this is sensible) Sarah

Fellow developers, I'm parallelizing loops to be called by pthread. The thread body that I pass to pthread_create looks like define i8* @loop1({ i32*, i32* }* nest %parent_frame, i8* %arg) parent_frame is pointer to shared variables in original function 0x00007f0de11c41f0: mov (%r10),%rax 0x00007f0de11c41f3: cmpl $0x63,(%rax) 0x00007f0de11c41f6: jg 0x7f0de11c420c

...reak fastcc and/or tail calls in the JIT. > Maybe you don't see this in UnladenSwallow because it doesn't do tail calls? > > There's also some minor breakage which isn't TCO-related (four failed > checks in the Pure interpreter) when reenabling lazy compilation with > DisableLazyCompilation(false). These seem to go all the way back to your > commit of Nick's patch (r84032 = "Keep track of stubs that are created" > fails exactly the same checks, while r84031 is fine). Those four Pure > checks all involve anonymous closures (lambdas); I still need to look at >...

...tion(mf, args); > > This is done for establishing a clear distinction between compile time > and execution time (for benchmarking purposes) and for speeding up the > whole process, as it is quite faster to generate all code in advance > than to JIT it as it is found (ExecutionEngine::DisableLazyCompilation > does not the same thing, as a large part of the code on the real-life > applications where this compiler works is reachable only through > pointers.) > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llv...

...error! " << llvm_linker.getLastError()<< "\n"; return 3; } } Module *m = llvm_linker.releaseModule(); string err; ExecutionEngine *ee = EngineBuilder(m).setEngineKind(EngineKind::JIT).setErrorStr(&err).create(); ee->DisableGVCompilation(false); ee->DisableLazyCompilation(true); Function* func = ee->FindFunctionNamed(argv[1]); if(!func){ cout<<"cannot find entry point\n"; return -1; } typedef void (*PFN)(); PFN pfn = reinterpret_cast<PFN>(ee->getPointerToFunction(func)); pfn(); ee->freeMachineCodeForFunction(func); de...

On Oct 28, 2009, at 9:41 AM, Jeffrey Yasskin wrote: > In r85295, in response to the discussion at http://llvm.org/PR5184 > (Lazy JIT ain't thread-safe), I changed the default JIT from lazy to > non-lazy. It has since come to my attention that this may have been > the wrong change, so I wanted to ask you guys. > > A couple reasons to make the default non-lazy compilation:

Hello, I now have a working installation of LLVM under Vista/Cygwin and I can play with it. First of all, I'd like to say that I'm impressed by the elegance of the APIs and the overall quality of the project. What we'd like to do is to compile textual LLVM code in memory and execute it immediately. The code would take some time to run, and so we'd like to fully optimize it.

Chris Lattner wrote: > Check out http://nondot.org/sabre/LLVMNotes > > %Size = getelementptr %T* null, int 1 %SizeI = cast %T* %Size to uint How incredibly cunning. :-) Thanks for that. Next stupid question. I've put together a simple coroutine/fibre style threading system on top of the Linux setcontext/getcontext stuff, which surprisingly enough seems to work *almost*

On Sun, Nov 29, 2009 at 2:19 AM, Albert Graef <Dr.Graef at t-online.de> wrote: > Jon Harrop wrote: >> I've come up with the following minimal repro that segfaults on my machine: > > Jon, were you able to resolve this? > > FWIW, TOT is causing all kinds of weird segfaults related to tail calls > in my Pure interpreter, too (at least on x86-64). In my case these

I am debugging the memory issue that manifests itself like this: *** glibc detected *** ../app/app.OWS: free(): invalid pointer: 0x0ad391fc *** ======= Backtrace: ========= /lib/libc.so.6(+0x6c501)[0x4f6501] /lib/libc.so.6(+0x6dd70)[0x4f7d70] /lib/libc.so.6(cfree+0x6d)[0x4fae5d] ../app/app.OWS(_ZNSt8_Rb_treeIjjSt9_IdentityIjESt4lessIjESaIjEE5eraseESt17_Rb_tree_iteratorIjES7_+0x4b)[0x83de6eb]

...t this patch seems like the wrong thing to do. Evan, you wrote, "there are existing customers out there that are using previous llvm release who will not appreciate the API change." Who are they? Recall that after my original change they can get back to lazy compilation by adding jit->DisableLazyCompilation(false) to their code. They have no need for #ifdefs. I still think that having a default that's right in nearly all cases is the best option (the only concrete counter-example I've seen is lli), but I'm happy to write another patch with a global forced choice or commit this one if tha...