llvm dev - Oct 2012 - [LLVMdev] Dynamically loading native code generated from LLVM IR

Hi,

I'm building LLVM IR. I'd like to compile this IR to native code (I
don't want JIT) and immediately load it to execute. So far, I've the
following:

1) I can emit the IR to native assembly/object file doing the same thing llc
does (using TargetMachine::addPassesToEmitFile).
2) I can dynamically load a precompiled .so file (using
llvm::sys::DynamicLibrary::getPermanentLibrary), get a function pointer from
that file, and execute.

I can't dynamically load the .o file I produce in step 1 because it's a
static library. If I could produce a .so file in step 1, my problem would be
solved. llc has a "-relocation-model=pic" option, but the file
produced with that did not dynamically load. I got lost in clang's options
when trying to find where the "-shared" and "-fPIC" options
are used.

So, my question is: Which API should I look at to emit dynamically loadable
native code from LLVM IR?

I would also like to emit code to an in-memory stream instead of a file because
everything happens at runtime, but that's a secondary concern.

Thanks in advance.

-Baris Aktemur

Hi Baris,
> If I could produce a .so file in step 1, my problem would be solved. llc
has a "-relocation-model=pic" option, but the file produced with that
did not dynamically load.
That relocation-model=pic option usually necessary for a linker to be
able to produce a .so file (it changes how variables are addressed so
that more things can be decided when the .so is loaded), but it won't
produce a .so itself.
> So, my question is: Which API should I look at to emit dynamically loadable
native code from LLVM IR?
The JIT sounds like it does almost exactly what you want. LLVM's JIT
isn't a classical lightweight, dynamic one like you'd see for
JavaScript or Java. All it really does is produce a native .o file in
memory, take care of the relocations for you and then jump into it (or
provide you with a function-pointer). Is there any other reason you
want to avoid it?

Otherwise, only a full linker is capable of turning a .o into
something loadable with "dlopen" or its equivalents. That's a lot
of
work, though I suppose you could fork a process to the system's linker
if there is one.

Tim.

Tim Northover wrote:
> Hi Baris,
>
>> If I could produce a .so file in step 1, my problem would be solved.
llc has a "-relocation-model=pic" option, but the file produced with
that did not dynamically load.
> That relocation-model=pic option usually necessary for a linker to be
> able to produce a .so file (it changes how variables are addressed so
> that more things can be decided when the .so is loaded), but it won't
> produce a .so itself.
>
>> So, my question is: Which API should I look at to emit dynamically
loadable native code from LLVM IR?
> The JIT sounds like it does almost exactly what you want. LLVM's JIT
> isn't a classical lightweight, dynamic one like you'd see for
> JavaScript or Java. All it really does is produce a native .o file in
> memory, take care of the relocations for you and then jump into it (or
> provide you with a function-pointer).
OK ... I have a similar issue. What happens if the code located in the 
.o file has references to external libs ?
How can I link the inmemory .o file against the external libs ... just 
to get a fully executable code segment in memory.

Best Regards

Armin Steinhoff

http://www.steinhoff-automation.com
> Is there any other reason you
> want to avoid it?
>
> Otherwise, only a full linker is capable of turning a .o into
> something loadable with "dlopen" or its equivalents. That's a
lot of
> work, though I suppose you could fork a process to the system's linker
> if there is one.
>
> Tim.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

Dear Tim,
> 
> The JIT sounds like it does almost exactly what you want. LLVM's JIT
> isn't a classical lightweight, dynamic one like you'd see for
> JavaScript or Java. All it really does is produce a native .o file in
> memory, take care of the relocations for you and then jump into it (or
> provide you with a function-pointer). Is there any other reason you
> want to avoid it?
> 
Based on the experiments I ran, JIT version runs significantly slower than the
code compiled to native. But according to your explanation, this shouldn't
have happened. I wonder why I witnessed the performance difference.

Thank you.

-Baris Aktemur

I'm not sure I understand your use case, but MCJIT (as opposed to the legacy
JIT) does almost exactly what you're asking for.  It generates an in-memory
object file image (using addPassesToEmitMC) and then loads and links it for
execution.

If there's some particular detail you don't like in the way this is
happening, you might be able to generate a file as you have and then use the
RuntimeDyld interface to load it.  The llvm-rtdyld tool does something like
this.

-Andy

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Baris Aktemur
Sent: Thursday, October 11, 2012 11:58 PM
To: llvmdev at cs.uiuc.edu
Subject: [LLVMdev] Dynamically loading native code generated from LLVM IR

Hi,

I'm building LLVM IR. I'd like to compile this IR to native code (I
don't want JIT) and immediately load it to execute. So far, I've the
following:

1) I can emit the IR to native assembly/object file doing the same thing llc
does (using TargetMachine::addPassesToEmitFile).
2) I can dynamically load a precompiled .so file (using
llvm::sys::DynamicLibrary::getPermanentLibrary), get a function pointer from
that file, and execute.

I can't dynamically load the .o file I produce in step 1 because it's a
static library. If I could produce a .so file in step 1, my problem would be
solved. llc has a "-relocation-model=pic" option, but the file
produced with that did not dynamically load. I got lost in clang's options
when trying to find where the "-shared" and "-fPIC" options
are used.

So, my question is: Which API should I look at to emit dynamically loadable
native code from LLVM IR?

I would also like to emit code to an in-memory stream instead of a file because
everything happens at runtime, but that's a secondary concern.

Thanks in advance.

-Baris Aktemur




_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Kaylor,

do you have some good documented example code which shows the usage of 
the MCJIT ?
This would help a lot ... the sematic of lots of API calls are not 
intuitively understandable.

Best Regards

--Armin



Kaylor, Andrew wrote:
> I'm not sure I understand your use case, but MCJIT (as opposed to the
legacy JIT) does almost exactly what you're asking for.  It generates an
in-memory object file image (using addPassesToEmitMC) and then loads and links
it for execution.
>
> If there's some particular detail you don't like in the way this is
happening, you might be able to generate a file as you have and then use the
RuntimeDyld interface to load it.  The llvm-rtdyld tool does something like
this.
>
> -Andy
>
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu] On Behalf Of Baris Aktemur
> Sent: Thursday, October 11, 2012 11:58 PM
> To: llvmdev at cs.uiuc.edu
> Subject: [LLVMdev] Dynamically loading native code generated from LLVM IR
>
> Hi,
>
> I'm building LLVM IR. I'd like to compile this IR to native code (I
don't want JIT) and immediately load it to execute. So far, I've the
following:
>
> 1) I can emit the IR to native assembly/object file doing the same thing
llc does (using TargetMachine::addPassesToEmitFile).
> 2) I can dynamically load a precompiled .so file (using
llvm::sys::DynamicLibrary::getPermanentLibrary), get a function pointer from
that file, and execute.
>
> I can't dynamically load the .o file I produce in step 1 because
it's a static library. If I could produce a .so file in step 1, my problem
would be solved. llc has a "-relocation-model=pic" option, but the
file produced with that did not dynamically load. I got lost in clang's
options when trying to find where the "-shared" and "-fPIC"
options are used.
>
> So, my question is: Which API should I look at to emit dynamically loadable
native code from LLVM IR?
>
> I would also like to emit code to an in-memory stream instead of a file
because everything happens at runtime, but that's a secondary concern.
>
> Thanks in advance.
>
> -Baris Aktemur
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>