llvm dev - Nov 2013 - [LLVMdev] [Proposal] Adding callback mechanism to Execution Engines

> From: 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131101/6159fa5d/attachment.html>

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> wrote:
> > *From:* 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         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/2041d4ea/attachment.html>

Are you using the latest code from trunk?  I didn't think the latest code
used the address mapping in the ExecutionEngine base class.

Of course, if people are depending on this it might be something that should be
fixed if it isn't working.

-Andy

From: Caldarale, Charles R [mailto:Chuck.Caldarale at unisys.com]
Sent: Friday, November 01, 2013 10:54 AM
To: Kaylor, Andrew; sumeeth kc; LLVM Dev
Subject: RE: [LLVMdev] [Proposal] Adding callback mechanism to Execution Engines
> From: 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131101/a25e33af/attachment.html>

Hi Andrew,

I used the latest code from trunk. GlobalSymbolTable is being used in
MCJIT.

I guess it wasn't clear from the proposal that the user program will be
modified to indicate that the callback should happen at that point in the
code. The objective is to call some of the functions which belong to lli or
the ExecutionEngine.

Thanks,
Sumeeth


On Fri, Nov 1, 2013 at 5:40 PM, Kaylor, Andrew <andrew.kaylor at
intel.com>wrote:
>  Are you using the latest code from trunk?  I didn’t think the latest
> code used the address mapping in the ExecutionEngine base class.****
>
> ** **
>
> Of course, if people are depending on this it might be something that
> should be fixed if it isn’t working.****
>
> ** **
>
> -Andy****
>
> ** **
>
> *From:* Caldarale, Charles R [mailto:Chuck.Caldarale at unisys.com]
> *Sent:* Friday, November 01, 2013 10:54 AM
> *To:* Kaylor, Andrew; sumeeth kc; LLVM Dev
> *Subject:* RE: [LLVMdev] [Proposal] Adding callback mechanism to
> Execution Engines****
>
> ** **
>
> > *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu<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****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131101/7053b4df/attachment.html>

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>

> From: Kaylor, Andrew [mailto:andrew.kaylor at intel.com]
> Subject: RE: [LLVMdev] [Proposal] Adding callback mechanism to Execution
Engines
> Are you using the latest code from trunk?  I didn't think the latest
code used the address
> mapping in the ExecutionEngine base class.
No, I should have mentioned that we're on 3.3. I don't think we've
run anything other than small tests on recent trunk versions so far.
> Of course, if people are depending on this it might be something that
should be fixed if it isn't working.
It appears there are alternatives, so it's probably not a serious issue.

- Chuck

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131101/c9071a32/attachment.html>