[llvm-dev] More function signatures for LLVMRunFunction?

[Lang Hames via llvm-dev]

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>