llvm dev - Jul 2016 - More function signatures for LLVMRunFunction?

Hi Lang,

Thanks for the reply. Responses below.

As far as I know nobody is actively working on MCJIT any more. I've
been
> working on the next generation of LLVM JIT APIs (ORC - see
> include/llvm/ExecutionEngine/Orc) for a while now, but they don't have
> functionality for running arbitrary functions yet.
>
Thanks for the pointer to ORC -- it looks like the runFunction there is a
copy-paste from MCJIT (minus the finalize() stuff).

Definitely. I'd be happy to see something like this in ORC, and I
think
> there would be other people who would appreciate it too.
>
The basic approach I am using is to add a function to TargetMachine called
runFunctionNatively:

  virtual GenericValue runFunctionNatively(Function *F, void *FPtr,
ArrayRef<GenericValue> ArgValues);

This houses most of the duplicated code currently in runFunction, and can
then be called from either MCJIT or OrcMCJITReplacement. I then have an
override for X86TargetMachine that uses the register trick.

I'd like to see a generic implementation that can handle all
architectures
> first, maybe with an specialized version for specific ABIs as an
> optimization.
>
I agree a generic implementation would be ideal, but I don't know how to do
a generic dynamic dispatch in C. Lacking that generic implementation, would
you be interested in seeing what I have so far?

Thanks!

Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160715/48b0f140/attachment.html>

Hi Evan,

Thanks for the pointer to ORC -- it looks like the runFunction there is
a
> copy-paste from MCJIT (minus the finalize() stuff).

The runFunction method in OrcMCJITReplacement is just a copy-paste, but
OrcMCJITReplacement only exists for direct backwards-compatibility with
MCJIT. In general ORC doesn't have any equivalent of runFunction. Instead,
it just has symbol lookup (via findSymbol) and leaves it to the user to
cast the resulting TargetAddress to an appropriate function pointer and
marshal arguments/returns.

The basic approach I am using is to add a function to TargetMachine
called
> runFunctionNatively:
>

  virtual GenericValue runFunctionNatively(Function *F, void
*FPtr,
> ArrayRef<GenericValue> ArgValues);
>

This houses most of the duplicated code currently in runFunction, and
can
> then be called from either MCJIT or
OrcMCJITReplacement. I then have an override for X86TargetMachine that
uses
> the register trick.

Very cool that you got this working. It's a good fit for MCJIT as it stands
(though I'd want to keep it in ExecutionEngine, rather than move it to
TargetMachine). For Orc it might make sense to put it in ORCABISupport and
drop the Function* argument (in favor of some sort of calling-convention
description), since we want to make sure users can free Modules after
compiling the code.


I agree a generic implementation would be ideal, but I don't know how to
do
> a generic dynamic dispatch in C. Lacking that generic implementation, would
> you be interested in seeing what I have so far?

I can think of one (rather heavyweight) answer: We depend on libClang. This
solution would preclude including the feature in LLVMCore (we'd need to
create some sort of LLVM JIT-extras project) and kill performance for the
initial call, but it would be generic and work on remote-JITs.

Out of interest: How dynamic are your function signatures? If you know them
ahead of time (even if they're very complex) you can handle this by just
casting to an appropriate function pointer type and calling. If the
function signatures are dynamic (as in a REPL) then the usual answer is to
use whatever fronted you used for the rest of the program to generate the
main-like expression function, then call that. I can imagine that there
might be use cases where neither of these are appropriate though.

- Lang.

On Fri, Jul 15, 2016 at 11:48 AM, Evan Miller <emmiller at gmail.com>
wrote:
> Hi Lang,
>
> Thanks for the reply. Responses below.
>
> As far as I know nobody is actively working on MCJIT any more. I've
been
>> working on the next generation of LLVM JIT APIs (ORC - see
>> include/llvm/ExecutionEngine/Orc) for a while now, but they don't
have
>> functionality for running arbitrary functions yet.
>>
>
> Thanks for the pointer to ORC -- it looks like the runFunction there is a
> copy-paste from MCJIT (minus the finalize() stuff).
>
> Definitely. I'd be happy to see something like this in ORC, and I think
>> there would be other people who would appreciate it too.
>>
>
> The basic approach I am using is to add a function to TargetMachine called
> runFunctionNatively:
>
>   virtual GenericValue runFunctionNatively(Function *F, void *FPtr,
> ArrayRef<GenericValue> ArgValues);
>
> This houses most of the duplicated code currently in runFunction, and can
> then be called from either MCJIT or OrcMCJITReplacement. I then have an
> override for X86TargetMachine that uses the register trick.
>
> I'd like to see a generic implementation that can handle all
architectures
>> first, maybe with an specialized version for specific ABIs as an
>> optimization.
>>
>
> I agree a generic implementation would be ideal, but I don't know how
to
> do a generic dynamic dispatch in C. Lacking that generic implementation,
> would you be interested in seeing what I have so far?
>
> Thanks!
>
> Evan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160715/b8b69282/attachment.html>

Hi Lang,

On Fri, Jul 15, 2016 at 5:48 PM, Lang Hames <lhames at gmail.com> wrote:
> Very cool that you got this working. It's a good fit for MCJIT as it
> stands (though I'd want to keep it in ExecutionEngine, rather than move
it
> to TargetMachine). For Orc it might make sense to put it in ORCABISupport
> and drop the Function* argument (in favor of some sort of
> calling-convention description), since we want to make sure users can free
> Modules after compiling the code.
>
If I keep the runFunction code in ExecutionEngine, what is the best way to
test for X86_64?

> I can think of one (rather heavyweight) answer: We depend on libClang.
> This solution would preclude including the feature in LLVMCore (we'd
need
> to create some sort of LLVM JIT-extras project) and kill performance for
> the initial call, but it would be generic and work on remote-JITs.
>
That does seem heavyweight to me, I wonder if there's a pure LLVM solution?

Out of interest: How dynamic are your function signatures? If you know
them
> ahead of time (even if they're very complex) you can handle this by
just
> casting to an appropriate function pointer type and calling. If the
> function signatures are dynamic (as in a REPL) then the usual answer is to
> use whatever fronted you used for the rest of the program to generate the
> main-like expression function, then call that. I can imagine that there
> might be use cases where neither of these are appropriate though.
>
To be honest I just started tinkering with this because I was getting an
error with some LLVM tutorials. So right now I don't have a "real"
use case
apart from playing around with the API. I just thought it'd be worth
smoothing out the experience a bit, and maybe it'd end up simplifying some
people's client code.

Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160716/0871cc0d/attachment.html>