[llvm] r233182 - [Orc][lli] Add a very simple Orc-based lazy JIT to lli.

[Lang Hames]

Hi Pawel,

Yes - CallbackManagerBuilder is polymorphic*, but it also requires
references to the stack that it is a part of, so it cannot be constructed
outside an OrcLazyJIT instance. That's why createCallbackManagerBuilder is
the way it is: It can't return a CompileCallbackManager value, so instead
it returns a CompileCallbackManager factory functor which the compiler can
run during construction. It indicates failure by returning a null factory
functor, which the user can detect before the try to construct the JIT.

* The overhead of the polymorphism disappears if you can template your
CompileOnDemand layer on a target specific subclass of
CompileCallbackManager, but lli is cross-target, so we can't do that here.

Cheers,
Lang.

On Mon, Mar 30, 2015 at 12:43 PM, Paweł Bylica <chfast at gmail.com> wrote:

>
>
> On Mon, Mar 30, 2015 at 8:46 PM Lang Hames <lhames at gmail.com> wrote:
>
>> Hi Dave,
>>
>> > More or less - it's an implementation detail, but I'd consider pulling
>> out the logic of the JIT instance's ctor into the factory function so that
>> it doesn't have to have a !ok state, it just returns from the factory
>> directly on the failure cases, then if it doesn't fail initializing the
>> structures - it passes them to the JIT instance's ctor which can't fail at
>> this point because all the failures have been dealt with.
>>
>> There's a problem with that, at least the way things are written at the
>> moment: The CompileOnDemand layer needs a reference to a
>> CompileCallbackManager (so that it can inject JIT callbacks), and the
>> CompileCallbackManager needs a reference to a lower JIT layer so that it
>> can output callback code. These are all class members, so they have to be
>> initialised in the constructor. The potential failure point is the
>> CompileCallbackManager: There may not be one for the target.
>>
>> In r233579 I've solved this by separating the selection of callback
>> managers (which can fail if there isn't one for the target) from the
>> construction of the callback manager (which should always work, assuming
>> you get that far). Now runOrcLazyJIT looks like:
>>
>>
>> auto CallbackManagerBuilder = createCallbackManagerBuilder(Target);
>> if (!CallbackManagerBuilder)
>>   return 1; // No callback manager for target.
>> OrcLazyJIT J(..., CallbackManagerBuilder); // <- Construction is now
>> guaranteed.
>> ... // Do stuff with the JIT
>>
>> What do you think?
>>
>> - Lang
>>
>
> If OrcLazyJIT requires CallbackManagerBuilder pass it by reference.
>
> Is CallbackManagerBuilder polymorphic?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150330/e1be637a/attachment.html>