[llvm-dev] More function signatures for LLVMRunFunction?

[Evan Miller via llvm-dev]

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>