[LLVMdev] Calling PassManager on previously JITed Modules

[Keppler, Dave]

Your step #2 will only execute Module level passes.  JIT::getPointerToFunction can trigger materialization and will invoke the JIT state's FunctionPassManager, both of which can alter the Module.  That's a likely the source of the synchronization problems you're encountering.

- Dave

>-----Original Message-----
>From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
>Behalf Of Stephen Kyle
>Sent: Tuesday, November 09, 2010 12:57 PM
>To: llvmdev at cs.uiuc.edu
>Subject: Re: [LLVMdev] Calling PassManager on previously JITed Modules
>
>Hi,
>
>I found the following wiki page in the Unladen Swallow project:
>
>http://code.google.com/p/unladen-swallow/wiki/CodeLifecycle
>
>This would appear to answer my question. Could someone confirm for me
>if it's definitely unsafe to attempt to optimise/JIT any Modules while
>a different thread is currently executing a JITed function which has
>been generated from them? Or am I just missing something here?
>
>I've tried using llvm::CloneModule() to copy the Module and then work
>on that instead to JIT a new function, but it seems that doesn't
>always work, or even the cloning process itself causes an assertion to
>be raised.
>
>Thanks in advance for any replies,
>Stephen
>
>On 8 November 2010 21:22, Stephen Kyle <stephenckyle at googlemail.com> wrote:
>> Hi,
>>
>> Has anyone had any success with running different PassManagers on
>> llvm::Modules they've already JITed and are executing?
>>
>> In detail:
>>
>> 1) getting the IR, in form of an llvm::Module
>> 2) calling PassManager->run() on the module
>> 3) calling getFunction() and getPointerToFunction() to JIT the module
>> 4) executing the JITed code using the function pointer received in step 3
>>
>> and then what I want to do is:
>>
>> 5) using a different PassManager with different (more time-consuming)
>> Passes, call run() on the module again
>> 6) call getFunction() and getPointerToFunction() again
>> 7) use the new function pointer to execute the JITed code instead.
>>
>> As an added complication, different threads may be performing the
>> initial compilation or reoptimisation, but before we consider this, is
>> there any reason why the above shouldn't work?
>>
>> When I do it, I occasionally get assertion errors such as:
>>
>> <more path...>/RELEASE_28/include/llvm/ADT/APInt.h:819: bool
>> llvm::APInt::operator==(const llvm::APInt&) const: Assertion `BitWidth
>> == RHS.BitWidth && "Comparison requires equal bit widths"' failed.
>> Stack dump:
>> 0.      Running pass 'Function Pass Manager' on module 'lib0000'.
>> 1.      Running pass 'Combine redundant instructions' on function '<func
>name>'
>> Aborted
>>
>> or
>>
>> RELEASE_28/lib/VMCore/LeaksContext.h:50: void
>> llvm::LeakDetectorImpl<T>::addGarbage(const T*) [with T =
>> llvm::Value]: Assertion `Ts.count(o) == 0 && "Object already in set!"'
>> failed.
>> Stack dump:
>> 0.      Running pass 'Function Pass Manager' on module 'lib000d'.
>> 1.      Running pass 'Combine redundant instructions' on function '<func
>name>'
>> Aborted
>>
>> It only happens sometimes, so this would imply some kind of race
>> condition between the compliation and reoptimisation threads, but I'm
>> definitely not trying to run a PassManager on a module which is
>> currently being JITed, so perhaps something about the module is being
>> corrupted by the call to the JIT? Hopefully the above assertion checks
>> indicate something obvious to someone...?
>>
>> Cheers,
>> Stephen
>>
>
>_______________________________________________
>LLVM Developers mailing list
>LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev