[llvm-commits] [PATCH] Generate info about the JIT process

[Evan Phoenix]

I haven't heard anything from Argiris, or any other thoughts on what  
the JITListener would look like. I hesitate to write such a thing  
without an idea of what people want, so I'm hoping we can commit my  
patch as is.

When there is more discussion about the JITListener, it will be easy  
to make MachineCodeInfo sit on top of it without any external API  
changes.

I've attached an updated version of the patch against SVN HEAD.

  - Evan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: jit-info.diff
Type: application/octet-stream
Size: 6510 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20090518/36f9b50d/attachment.obj>
-------------- next part --------------


On May 13, 2009, at 10:21 AM, Chris Lattner wrote:

> On May 13, 2009, at 2:20 AM, Argiris Kirtzidis wrote:
>>> Thats basically what MachineCodeInfo enables. ATM, there are only 2
>>> things it publishes directly to the MCI, but future APIs can  
>>> easily be
>>> added using virtual methods to allow for subclasses of  
>>> MachineCodeInfo
>>> to do new things.
>>>
>>> This is far from a final set of things MCI will do, it's primarily a
>>> way of introduce an API that we can add future things to.
>>
>> Ok, that sounds great. It's just that MachineCodeInfo is restricted  
>> to
>> the "function level", how about "module level" info, specifically
>> getting notifications during code execution like:
>> -"I lazy JITed this function"
>> -"I allocated this memory chunk for this global variable"
>>
>> Of course, MachineCodeInfo could be the one for the "function  
>> level" and
>> something like "JITListener" at the module level. The JITListener  
>> could
>> have a method that passes a MachineCodeInfo before function JITing.  
>> IMO
>> this is flexible and clean.
>
> I agree with Argiris: there should be a simple abstract interface  
> with methods like the above.  The JIT should have an optional  
> pointer to it.  If non-null, it would invoke the methods on the  
> JITListener.  This would allow lots of detailed instrumentation, but  
> would introduce no overhead if it's not being used.
>
> -Chris