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

Argiris Kirtzidis akyrtzi at gmail.com
Tue May 12 23:45:25 PDT 2009

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.)


More information about the llvm-commits mailing list