[llvm-dev] thread safety ExecutionEngine::getFunctionAddress

[koffie drinker via llvm-dev]

Actually, The object cache holds the optimized IR (It's precompiled with
optimizations and persist it). There's around of 10% of "on-the-fly"
generated code that would go without the optimization. I Did test with
optimization, and it was slower. For that 10% I'm okay with optimization
being turned off.

I also only generate the function prototype for cached modules to reduce IR
generation.

On Tue, Dec 20, 2016 at 6:20 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:

>
> On Dec 20, 2016, at 9:13 AM, koffie drinker via llvm-dev <
> llvm-dev at lists.llvm.org> 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.
>
>
> I can’t help with the rest, but just wanted to mention that totally
> disabling the IR optimizations is not necessarily a good idea depending on
> what does the input IR looks like: some of the optimizations can be
> “lightweight” and simplify the IR / delete dead core, making the
> compile-time actually faster.
>
> —
> Mehdi
>
>
> 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,
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161221/cb4b68be/attachment.html>