[LLVMdev] Is ExecutionEngine always meant to be a singleton?

[Kenneth Uildriks]

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.