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

[Argiris Kirtzidis]

(CC'ed llvm-commits)

Evan Phoenix wrote:
>
> On May 12, 2009, at 11:45 PM, Argiris Kirtzidis wrote:
>
>> Hi Evan,
>>
>> Evan Phoenix wrote:
>>>> Wow another Evan. :-)
>>>>
>>> Doin' my part to raise the quota!
>>>
>>>> This looks fine but is it necessary? Can we just use  
>>>> MachineCodeEmitter to report these? Should it be under  
>>>> ExecutionEngine or CodeGen? Are you expecting to extend it to 
>>>> track  more information?
>>>>
>>> After talking with a number of people in #llvm, this was the 
>>> solution  we came up with.  We couldn't come up with a solution for 
>>> reporting  the info from MachineCodeEmitter that didn't require 
>>> restructuring  things a lot, so this was the idea we came up with.
>>>
>>> One upside is that because it's isolated, we have the ability to  
>>> easily extend it to track more information. One thing I eventually  
>>> want to report is the Relocation information, so that the machine 
>>> code  can be manipulated outside of LLVMs control.
>>>
>>> I consider it to be a phase 1 of 
>>> http://wiki.llvm.org/Provide_more_control_over_and_access_to_JIT%27s_output , 
>>> which Jeffrey Yasskin and I have been discussing.
>>>
>>> So I guess my point is that I'm open to reporting this data a  
>>> different way, but we haven't yet seen one that is as simple. :)
>>>
>>> Additionally, I'm happy to craft this patch externally, but I think 
>>> it  would make everyones life easier to get it into the repo, so 
>>> that  others can work on adding things to the API.
>>>
>>
>> I'm interested in this as well. How about passing an abstract class 
>> object to JIT (JITListener ?), essentially passing hooks that the JIT 
>> calls to pass information during JIT compilation process; the 
>> application will have full flexibility about what it will do with 
>> this information. The LLVM side can be "oblivious" about how to 
>> represent the information, it only needs to call the abstract hooks.
>> (I have something like this in a local patch which gathers debug info 
>> from JITed code.)
>
> 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.

Any thoughts on the above ?

-Argiris