[llvm-dev] ExecutionEngine::runFunction and libffi

[Mueller-Roemer, Johannes Sebastian via llvm-dev]

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.mu...@igd.fraunhofer.de  |  www.igd.fraunhofer.de

 

[Lang Hames via llvm-dev]

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.

_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

[Mueller-Roemer, Johannes Sebastian via llvm-dev]

Sure could, although that IR would have to be instanced/recompiled for every call to foo to avoid issues when foo is called from multiple threads (as otherwise the globals could be overwritten).

 

---