Mueller-Roemer, Johannes Sebastian via llvm-dev
2015-Sep-18 13:46 UTC
[llvm-dev] ExecutionEngine::runFunction and libffi
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150918/cf0d208e/attachment.html>
Lang Hames via llvm-dev
2015-Sep-18 18:32 UTC
[llvm-dev] ExecutionEngine::runFunction and libffi
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>
Mueller-Roemer, Johannes Sebastian via llvm-dev
2015-Sep-21 08:08 UTC
[llvm-dev] ExecutionEngine::runFunction and libffi
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). ________________________________ From: Lang Hames [lhames at gmail.com] Sent: Friday, September 18, 2015 8:32 PM To: Mueller-Roemer, Johannes Sebastian Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] ExecutionEngine::runFunction and libffi 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<mailto: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<tel:%2B49%206151%20155-606> | Fax +49 6151 155-139<tel:%2B49%206151%20155-139> johannes.mueller-roemer at igd.fraunhofer.de<mailto:johannes.mueller-roemer at igd.fraunhofer.de> | www.igd.fraunhofer.de<http://www.igd.fraunhofer.de> _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto: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/20150921/5b280404/attachment.html>
Maybe Matching Threads
- change in CMake variable names breaks existing uses and does not conform to CMake conventions
- [LLVMdev] [PATCH][RFC]: Add fmin/fmax intrinsics
- Extra space in LLVM_DEFINITIONS causes CMake 3.1 to fail
- Extra space in LLVM_DEFINITIONS causes CMake 3.1 to fail
- [LLVMdev] Set up ExecutionEngine according to actual machine capabilities