[llvm-dev] thread safety ExecutionEngine::getFunctionAddress

[koffie drinker via llvm-dev]

So I've made code to invoke the getfunctionaddress() in parallel. I did
verify that the code was good, by substituting getfunctionaddress() with a
bunch bogus computations.

It seems that the code with getfunctionaddress() is being serialized. Is
there a giant lock somewhere per executionengine?
I have one execution engine that holds all the modules. Going through the
llvm-dev list archives, it seems that I have to have a execution engine per
module. Is this still the case ? (the posting were quite old). Is there a
difference between mcjit and orc in this case?

I was hoping that by not modifying IR during getfunctionaddress() would
work :(

Cheers,

On Tue, Dec 20, 2016 at 6:13 PM, koffie drinker <gekkekoe at gmail.com> wrote:

> Hi,
>
> I'm trying to speed up the JIT time with llvm (3.9.1).
> So far i've implemented the object cache, used FastISel and disabled
> optimizations.
> Jit time is still too slow for my purpose (I do have a lot of code to Jit).
>
> http://llvm.org/docs/ProgrammersManual.html#threads-and-the-jit states
> that we can invoke ExecutionEngine::getPointerToFunction() concurrently.
> This function was replaced by ExecutionEngine::getFunctionAddress(). Is
> this function also thread safe?
>
> I want to speed up codegen by invoking parallel calls to
> getfunctionaddress(). Currently  due the the large amount of code that has
> to be Jitted, the getfunctionaddress() takes around 40% of my load time.
>
> What is meant with "he user must still ensure that only one thread
> accesses IR in a given LLVMContext while another thread might be
> modifying it" ?
>
> If I pre-generate all IR, and before execution, invoke the parallel
> getfunctionaddress() I should be fine right ? Since IR won't be modified
> anymore.
>
> Cheers,
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161222/820774c1/attachment.html>