[LLVMdev] LLVM optimization passes crash when running on second thread

[Peter Zion]

That was exactly the problem, thank you!

pz

On 2011-03-22, at 3:27 PM, Eli Friedman wrote:

> On Tue, Mar 22, 2011 at 11:51 AM, Peter Zion
> <peter.zion at fabric-engine.com> wrote:
>> Hello,
>> 
>> I am trying to modify my LLVM-based compiler to perform an initial, no-optimization compilation synchronously on startup and then perform an asynchronous, optimized recompilation in the background, and I am getting in one of the optimization passes.
>> 
>> - I am using the official release of LLVM 2.8
>> - I have compiled LLVM with threading enabled; I am running llvm::llvm_start_multithreaded() on application startup and checking that that result is true.
>> - The foreground compilation works fine.
>> - The background compilation also works fine if I comment out the addition of the optimization passes.
>> - The optimization passes are being added as follows:
>>        llvm::OwningPtr<llvm::PassManager> passManager( new llvm::PassManager );
>>        if ( optimize )
>>        {
>>          llvm::createStandardFunctionPasses( passManager.get(), 2 );
>>          llvm::createStandardModulePasses( passManager.get(), 2, false, true, true, true, false, llvm::createFunctionInliningPass() );
>>          llvm::createStandardLTOPasses( passManager.get(), true, true, false );
>>        }
>>        passManager->run( *module );
>> - If I *don't* comment out the optimization passes (inside the if statement above) LLVM crashes with what appears to be a stack overflow; I've attached the stack trace below.
>> - The code above is in the Fabric::DG::Code::compileAST() function shown in the stack trace below; its child in the stack is the passManager->run() call.
>> - I have added a global mutex lock around all my accesses to LLVM, just to try to debug the problem, and it doesn't make any difference.
>> - Both compilations are using the same LLVMContext.  It is unclear from the LLVM docs whether this is allowed.  I would be surprised, however, if the global lock I added wouldn't have sorted out that issue if it was the problem.
>> - In case it makes any difference, I am running on OS X and using Grand Central Dispatch to execute the background compilation using dispatch_group_async_f()
>> 
>> Is this a known problem?  Can anyone suggest anything I can do to fix or further debug this problem?
> 
> My best guess is that your background thread has less stack space than
> the main thread.  The version of LazyValueInfo which is in 2.8 was
> recursive, and can use a lot of stack space in extreme cases (this was
> fixed for 2.9, which should be released soon).  If you need to use
> 2.8, I would suggest either allocating more stack space, or
> customizing the passes you use not to include -jump-threading and
> -correlated-propagation.
> 
> -Eli