llvm dev - Oct 2009 - [LLVMdev] Is ExecutionEngine always meant to be a singleton?

Right now, on X86, creating multiple ExecutionEngines in the same
process causes an assertion.

If it's supposed to always be a singleton, should there be a way to
get the process's ExecutionEngine instance?

This would, among other things, allow "lli" to execute bitcode that
itself uses the ExecutionEngine.

On Oct 8, 2009, at 9:19 AM, Kenneth Uildriks wrote:
> Right now, on X86, creating multiple ExecutionEngines in the same
> process causes an assertion.
>
Yes. This is by design.
> If it's supposed to always be a singleton, should there be a way to
> get the process's ExecutionEngine instance?
>
I can't see why. You could make a server to process llvm code.
> This would, among other things, allow "lli" to execute bitcode
that
> itself uses the ExecutionEngine.
I think you're doing something a bit fishy here. I'm not sure how  
you're generating code, but you may want to look at Unladen Swallow or  
Rubinius or the Kaleidoscope tutorial for how ExecutionEngine is  
generally used for jitting, and jitting in general.

-eric

>> This would, among other things, allow "lli" to execute
bitcode that
>> itself uses the ExecutionEngine.
>
> I think you're doing something a bit fishy here. I'm not sure how
> you're generating code, but you may want to look at Unladen Swallow or
> Rubinius or the Kaleidoscope tutorial for how ExecutionEngine is
> generally used for jitting, and jitting in general.
Really?  This seems like a perfectly reasonable thing to want to do.
Why shouldn't I be able to JIT a JIT?  Run lli inside lli.  If you
read his other mail, Kenneth is trying to support code that can
execute at compile time that might generate more code.  So the code
needs a way to interact with the compiler, ie the EE, and invoke it on
more bitcode.

Currently there is a JIT *TheJIT static global inside JITEmitter.cpp
which you could expose, if you wanted to.  Alternatively, if LLVM
doesn't want to expose the singleton-ness of the JIT as part of the
API, you can have a single global on your side.

Reid

On Fri, Oct 9, 2009 at 5:30 PM, Eric Christopher <echristo at apple.com>
wrote:
>
>> If it's supposed to always be a singleton, should there be a way to
>> get the process's ExecutionEngine instance?
>>
>
> I can't see why. You could make a server to process llvm code.
Do you mean create a separate server process to which you send llvm
code and receive back native machine code?

The reason why it would make sense to expose the process's singleton
ExecutionEngine instance is the same as the reason for exposing any
other singleton: to make it easier for a client to use it properly.
The way it is now, if you have two different modules that want to use
the ExecutionEngine, you have to arrange for one to create it and the
other to get it passed in, or for each to check a common global
variable that they're both linked to before trying to create it.  This
tends to couple the modules more tightly together than you might want,
and throws a big wrench into any effort to mix-and-match modules
(especially modules that you didn't write) that might have a use for
the ExecutionEngine.  To say nothing of the case where one module
*creates* the other one, and they both want to use the
ExecutionEngine.... and also allow the created module to use it later
after it's been llc'd.

Exposing it as a singleton allows all of these use cases, and many
others that I haven't thought of, to work cleanly.  And it makes it
more obvious how to implement the more usual use cases.  And it makes
explicit the fact that only a single ExecutionEngine is allowed to
exist.

On Fri, Oct 9, 2009 at 3:30 PM, Eric Christopher <echristo at apple.com>
wrote:
>
> On Oct 8, 2009, at 9:19 AM, Kenneth Uildriks wrote:
>
>> Right now, on X86, creating multiple ExecutionEngines in the same
>> process causes an assertion.
>>
>
> Yes. This is by design.
Why? By default, I'd rather get rid of singleton requirements than
expose them to users.
>> If it's supposed to always be a singleton, should there be a way to
>> get the process's ExecutionEngine instance?
>>
>
> I can't see why. You could make a server to process llvm code.
>
>> This would, among other things, allow "lli" to execute
bitcode that
>> itself uses the ExecutionEngine.
>
> I think you're doing something a bit fishy here. I'm not sure how
> you're generating code, but you may want to look at Unladen Swallow or
> Rubinius or the Kaleidoscope tutorial for how ExecutionEngine is
> generally used for jitting, and jitting in general.
>
> -eric
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>