[LLVMdev] [Proposal] Adding callback mechanism to Execution Engines

[Kaylor, Andrew]

That's definitely interesting, but I'm not sure it's a general enough use case to put into the LLVM classes.

As described earlier, you can call an arbitrary function in your program from the generated code.  If the execution engine did expose interesting information, you could call the EE interface from that function.

However, I'm not sure that the ExecutionEngine is likely to have the information you want.  The ExecutionEngine is primarily responsible for generating the binary code.  The current interfaces expose some helper functions to allow you to call the generated code directly.  However, these are likely to be moved out of the EE interface, at least for MCJIT.  The most the EE could reliably tell you is how often the address of a particular function was requested, and again I don't know that there is a general case for tracking such statistics in the EE itself.

In any event, once the EE has returned the address of a function, it will have no information about how many times the function is called.  Also, a function can be called from within the generated code without the EE knowing anything about it.

-Andy


From: usurper1990 at gmail.com [mailto:usurper1990 at gmail.com] On Behalf Of Amogh Akshintala
Sent: Friday, November 01, 2013 2:28 PM
To: Caldarale, Charles R
Cc: Kaylor, Andrew; sumeeth kc; LLVM Dev
Subject: Re: [LLVMdev] [Proposal] Adding callback mechanism to Execution Engines

Hey Everyone,

I understood this a little differently (well, I do have direct contact with Sumeeth given that we both work in the same lab). Allow me to try and explain his proposal.

We are trying to optimise out instructions from a program (JIT-compiled OS Kernels or JIT-compiled Web Server code) during run time and we have this hypothesis that some of the decisions are best taken by the programmer himself, e.g. if statistics shows that a particular subsystem of the program being run hasn't seen any action in quite a while, the programmer is in a position to decide whether that part of the code can be optimised out of the binary or not (if the code is some highly sensitive failure detection code then I guess he wouldn't want it removed no matter what).

For this, we wanted to some mechanism to call back into the execution engine to get stuff like stats or to tell the execution engine to recompile a particular module or function etc.

His proposal is to introduce a callback mechanism in the execution engine that allows the internal tools to expose functions like offering stats or the ability to toggle a recompile etc. to the user program.

Hope that clears some things up.

Cheers,
Amogh

On Fri, Nov 1, 2013 at 1:53 PM, Caldarale, Charles R <Chuck.Caldarale at unisys.com<mailto:Chuck.Caldarale at unisys.com>> wrote:
> From: llvmdev-bounces at cs.uiuc.edu<mailto:llvmdev-bounces at cs.uiuc.edu> [mailto:llvmdev-bounces at cs.uiuc.edu<mailto:llvmdev-bounces at cs.uiuc.edu>]
> On Behalf Of Kaylor, Andrew
> Subject: Re: [LLVMdev] [Proposal] Adding callback mechanism to Execution Engines

> If the function is in a statically linked module, you need to do something to explicitly expose it.  With
> the older JIT engine you can use addGlobalMapping as Yaron suggests, but I don't think that will work
> with MCJIT.

Seems to work fine for us with MCJIT.

- Chuck


_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu>         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



--
The Wheel of Time turns and Ages come and go, leaving memories that become legend. Legend fades to myth, and even myth is long forgotten when the Age that gave it birth returns again.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131101/a852a5ab/attachment.html>