[llvm-dev] ExecutionEngine::runFunction and libffi

Lang Hames via llvm-dev llvm-dev at lists.llvm.org
Fri Sep 18 11:32:54 PDT 2015


Hi Johannes,

No, runFunction isn't particularly useable at the moment. So far we've been
encouraging people to use getSymbolAddress and call functions directly,
handling argument and return marshaling themselves.

Given that runFunction is calling in to LLVM generated code, I think it
makes sense to add some utilities to the execution engine library (rather
than rely on libffi) to make marshaling/un-marshaling easier.  Given a
function prototype T1 foo(T2, T3, ...), a utility could create new IR along
these lines:

declare T1 foo(T2, T3, ...);

T1 r;
T2 arg1;
T3 arg2;
...

void foo_helper() {
  x1 = load arg1;
  x2 = load arg2;
  ...
  x0 = call foo(x1, x2, ...);
  store x0, r;
}

For primitive types all that would be needed is to copy the values into the
globals, invoke the helper, then read the return value back out.

Would something like this satisfy your use case?

Cheers,
Lang.


On Fri, Sep 18, 2015 at 6:46 AM, Mueller-Roemer, Johannes Sebastian via
llvm-dev <llvm-dev at lists.llvm.org> wrote:

> I noticed that runFunction (for MCJIT) is very limited. At the same time
> the interpreter already has a fairly generic way of calling functions from
> a pointer and a Function * (for description) using libffi. Would it make
> sense to pull that functionality out into a small support library and using
> it in MCJIT? As is runFunction isn’t particularly usable.
>
>
>
> --
>
> Johannes S. Mueller-Roemer, MSc
>
> Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)
>
>
>
> Fraunhofer-Institut für Graphische Datenverarbeitung IGD
>
> Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
>
> Tel +49 6151 155-606  |  Fax +49 6151 155-139
>
> johannes.mueller-roemer at igd.fraunhofer.de  |  www.igd.fraunhofer.de
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150918/e07e9212/attachment.html>


More information about the llvm-dev mailing list