[llvm] r233182 - [Orc][lli] Add a very simple Orc-based lazy JIT to lli.
lhames at gmail.com
Mon Mar 30 12:53:20 PDT 2015
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.
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
>> ... // 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...
More information about the llvm-commits