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

[Lang Hames]

Sorry, that should have read "CompileCallbackManager factory functor which
*OrcLazyJIT* can run during construction".

- Lang.

On Mon, Mar 30, 2015 at 12:53 PM, Lang Hames <lhames at gmail.com> wrote:

> 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/aaf3bb91/attachment.html>