Great stuff; thanks both! I'm also looking to turn my MCJIT conversion spike into our main use case. The only thing I'm missing is the ability to get a post-linked copy of the generated assembly. In JIT I used JITEventListener's NotifyFunctionEmitted and used a MCDisassembler to disassemble the stream (with my own custom annotators), and redirected the output to the relevant place for auditing of our app. With MCJIT I notice that NotifyFunctionEmitted is gone (understandably) and so I hook NotifyObjectEmitted. I then run through all the function symbols and dump them as before. Yay. Except that in MCJIT terms the linking hasn't happened, so all the globals and external functions are all zeros at this point. (If I hackily observe the same code later on I see the linker has appropriately populated these addresses). This makes my nicely annotated code a little unreadable, unfortunately. Does anyone have any suggestions as to how I might get to disassemble the post-linked code? Thanks once again! -matt On Wed, Sep 17, 2014 at 2:35 PM, Yaron Keren <yaron.keren at gmail.com> wrote:> Hi, > > You need to call llvm::sys::getHostCPUName() and pass the result to > createTargetMachine() passed to the JIT. This patch should be applied: > > http://llvm.org/bugs/show_bug.cgi?id=17422 > > Anyhow, the JIT was removed from current code and will not be in next LLVM > release. > > Yaron > > > 2014-09-17 22:27 GMT+03:00 Matt Godbolt <matt at godbolt.org>: >> >> Hi Jim, >> >> Thanks for a very quick reply! That indeed does the trick! >> >> Presumably the default has changed in 3.5 to be a "generic" CPU >> instead of the native one? If that's the case I wonder why: especially >> when JITting it really only makes sense to target the actual CPU - >> unless I'm missing something? :) >> >> Thanks again, >> >> Matt >> >> On Wed, Sep 17, 2014 at 2:16 PM, Jim Grosbach <grosbach at apple.com> wrote: >> > Hi Matt, >> > >> > I suspect you need to specify the target CPU when you create the JIT. >> > It’s just a method on the builder (e.g., builder.setMCPU(MCPU)). If you want >> > auto-detection based on the host CPU, sys::getHostCPUName() returns a value >> > suitable to be passed directly into the builder. >> > >> > -Jim >> > >> >> On Sep 17, 2014, at 11:44 AM, Matt Godbolt <matt at godbolt.org> wrote: >> >> >> >> Hi guys, >> >> >> >> I just upgraded our JIT system to use llvm 3.5 and noticed one big >> >> change in our generated code: we don't see any non-destructive VEX >> >> prefix instructions being emitted any more (vmulsd xmm0, xmm1, blah) >> >> etc. >> >> >> >> It's long been on my list of things to investigate anyway as I noticed >> >> llvm didn't emit VZEROUPPER calls either, so I supposed it might not >> >> be a bad thing to disable vex. >> >> >> >> That being said, try as I might I can't force avx on >> >> (builder.setMCPU("core-avx-i") and/or >> >> builder.setMAttrs(vector<string>{"+avx"});). We're still using the old >> >> JIT but I just spiked out a move to MCJIT and I still don't see the >> >> VEX instructions. >> >> >> >> Was there a deliberate change on the llvm-side to discourage VEX >> >> instructions unless they make a big enough difference (and/or is >> >> VZEROUPPER now emitted?). >> >> >> >> If not, how might I go about digging further into this? >> >> >> >> Many thanks in advance, Matt >> >> >> >> -- >> >> Matt >> >> _______________________________________________ >> >> LLVM Developers mailing list >> >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > >> >> >> >> -- >> Matt >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-- Matt
On 09/17/2014 12:45 PM, Matt Godbolt wrote:> Great stuff; thanks both! > > I'm also looking to turn my MCJIT conversion spike into our main use > case. The only thing I'm missing is the ability to get a post-linked > copy of the generated assembly. > > In JIT I used JITEventListener's NotifyFunctionEmitted and used a > MCDisassembler to disassemble the stream (with my own custom > annotators), and redirected the output to the relevant place for > auditing of our app. > > With MCJIT I notice that NotifyFunctionEmitted is gone > (understandably) and so I hook NotifyObjectEmitted. I then run through > all the function symbols and dump them as before. Yay. Except that in > MCJIT terms the linking hasn't happened, so all the globals and > external functions are all zeros at this point. (If I hackily observe > the same code later on I see the linker has appropriately populated > these addresses). This makes my nicely annotated code a little > unreadable, unfortunately. > > Does anyone have any suggestions as to how I might get to disassemble > the post-linked code?my 2 cents: It seems like we need a different event type. Having access to the object before linking (and relocation?) seems useful, but I suspect most users (myself included) want the final object after everything is done. Philip On Wed, Sep 17, 2014 at 2:35 PM, Yaron Keren <yaron.keren at gmail.com> wrote:>> Hi, >> >> You need to call llvm::sys::getHostCPUName() and pass the result to >> createTargetMachine() passed to the JIT. This patch should be applied: >> >> http://llvm.org/bugs/show_bug.cgi?id=17422 >> >> Anyhow, the JIT was removed from current code and will not be in next LLVM >> release. >> >> Yaron >> >> >> 2014-09-17 22:27 GMT+03:00 Matt Godbolt <matt at godbolt.org>: >>> Hi Jim, >>> >>> Thanks for a very quick reply! That indeed does the trick! >>> >>> Presumably the default has changed in 3.5 to be a "generic" CPU >>> instead of the native one? If that's the case I wonder why: especially >>> when JITting it really only makes sense to target the actual CPU - >>> unless I'm missing something? :) >>> >>> Thanks again, >>> >>> Matt >>> >>> On Wed, Sep 17, 2014 at 2:16 PM, Jim Grosbach <grosbach at apple.com> wrote: >>>> Hi Matt, >>>> >>>> I suspect you need to specify the target CPU when you create the JIT. >>>> It’s just a method on the builder (e.g., builder.setMCPU(MCPU)). If you want >>>> auto-detection based on the host CPU, sys::getHostCPUName() returns a value >>>> suitable to be passed directly into the builder. >>>> >>>> -Jim >>>> >>>>> On Sep 17, 2014, at 11:44 AM, Matt Godbolt <matt at godbolt.org> wrote: >>>>> >>>>> Hi guys, >>>>> >>>>> I just upgraded our JIT system to use llvm 3.5 and noticed one big >>>>> change in our generated code: we don't see any non-destructive VEX >>>>> prefix instructions being emitted any more (vmulsd xmm0, xmm1, blah) >>>>> etc. >>>>> >>>>> It's long been on my list of things to investigate anyway as I noticed >>>>> llvm didn't emit VZEROUPPER calls either, so I supposed it might not >>>>> be a bad thing to disable vex. >>>>> >>>>> That being said, try as I might I can't force avx on >>>>> (builder.setMCPU("core-avx-i") and/or >>>>> builder.setMAttrs(vector<string>{"+avx"});). We're still using the old >>>>> JIT but I just spiked out a move to MCJIT and I still don't see the >>>>> VEX instructions. >>>>> >>>>> Was there a deliberate change on the llvm-side to discourage VEX >>>>> instructions unless they make a big enough difference (and/or is >>>>> VZEROUPPER now emitted?). >>>>> >>>>> If not, how might I go about digging further into this? >>>>> >>>>> Many thanks in advance, Matt >>>>> >>>>> -- >>>>> Matt >>>>> _______________________________________________ >>>>> LLVM Developers mailing list >>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> >>> -- >>> Matt >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > >
Hi Matt, Philip,
You could get the data you want by recording the addresses returned by the
allocateCodeSection and allocateDataSection methods on your
RTDyldMemoryManager, then disassembling those sections after you've called
resolveRelocations. That's a little unsatisfying though. For one thing,
unless you very carefully maintain the association with the original object
via back-channels there will be no way of knowing which section belongs to
which object file.
With a bit of cleanup though, we could do something more like this:
const RuntimeDyld::JITObject& JO = RTDyld.loadObject(Object);
// ...
RTDyld.resolveRelocations();
DEBUG(
for (const RuntimeDyld::JITObject::Section& S : JO.sections())
if (S.isText())
Disassemble(S.getAddr(), S.getSize());
);
How does that look?
Cheers,
Lang.
On Wed, Sep 17, 2014 at 3:08 PM, Philip Reames <listmail at
philipreames.com>
wrote:
>
> On 09/17/2014 12:45 PM, Matt Godbolt wrote:
>
>> Great stuff; thanks both!
>>
>> I'm also looking to turn my MCJIT conversion spike into our main
use
>> case. The only thing I'm missing is the ability to get a
post-linked
>> copy of the generated assembly.
>>
>> In JIT I used JITEventListener's NotifyFunctionEmitted and used a
>> MCDisassembler to disassemble the stream (with my own custom
>> annotators), and redirected the output to the relevant place for
>> auditing of our app.
>>
>> With MCJIT I notice that NotifyFunctionEmitted is gone
>> (understandably) and so I hook NotifyObjectEmitted. I then run through
>> all the function symbols and dump them as before. Yay. Except that in
>> MCJIT terms the linking hasn't happened, so all the globals and
>> external functions are all zeros at this point. (If I hackily observe
>> the same code later on I see the linker has appropriately populated
>> these addresses). This makes my nicely annotated code a little
>> unreadable, unfortunately.
>>
>> Does anyone have any suggestions as to how I might get to disassemble
>> the post-linked code?
>>
> my 2 cents: It seems like we need a different event type. Having access
> to the object before linking (and relocation?) seems useful, but I suspect
> most users (myself included) want the final object after everything is
done.
>
> Philip
>
>
> On Wed, Sep 17, 2014 at 2:35 PM, Yaron Keren <yaron.keren at
gmail.com>
> wrote:
>
>> Hi,
>>>
>>> You need to call llvm::sys::getHostCPUName() and pass the result to
>>> createTargetMachine() passed to the JIT. This patch should be
applied:
>>>
>>> http://llvm.org/bugs/show_bug.cgi?id=17422
>>>
>>> Anyhow, the JIT was removed from current code and will not be in
next
>>> LLVM
>>> release.
>>>
>>> Yaron
>>>
>>>
>>> 2014-09-17 22:27 GMT+03:00 Matt Godbolt <matt at
godbolt.org>:
>>>
>>>> Hi Jim,
>>>>
>>>> Thanks for a very quick reply! That indeed does the trick!
>>>>
>>>> Presumably the default has changed in 3.5 to be a
"generic" CPU
>>>> instead of the native one? If that's the case I wonder why:
especially
>>>> when JITting it really only makes sense to target the actual
CPU -
>>>> unless I'm missing something? :)
>>>>
>>>> Thanks again,
>>>>
>>>> Matt
>>>>
>>>> On Wed, Sep 17, 2014 at 2:16 PM, Jim Grosbach <grosbach at
apple.com>
>>>> wrote:
>>>>
>>>>> Hi Matt,
>>>>>
>>>>> I suspect you need to specify the target CPU when you
create the JIT.
>>>>> It’s just a method on the builder (e.g.,
builder.setMCPU(MCPU)). If
>>>>> you want
>>>>> auto-detection based on the host CPU, sys::getHostCPUName()
returns a
>>>>> value
>>>>> suitable to be passed directly into the builder.
>>>>>
>>>>> -Jim
>>>>>
>>>>> On Sep 17, 2014, at 11:44 AM, Matt Godbolt <matt at
godbolt.org> wrote:
>>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> I just upgraded our JIT system to use llvm 3.5 and
noticed one big
>>>>>> change in our generated code: we don't see any
non-destructive VEX
>>>>>> prefix instructions being emitted any more (vmulsd
xmm0, xmm1, blah)
>>>>>> etc.
>>>>>>
>>>>>> It's long been on my list of things to investigate
anyway as I noticed
>>>>>> llvm didn't emit VZEROUPPER calls either, so I
supposed it might not
>>>>>> be a bad thing to disable vex.
>>>>>>
>>>>>> That being said, try as I might I can't force avx
on
>>>>>> (builder.setMCPU("core-avx-i") and/or
>>>>>>
builder.setMAttrs(vector<string>{"+avx"});). We're still
using the
>>>>>> old
>>>>>> JIT but I just spiked out a move to MCJIT and I still
don't see the
>>>>>> VEX instructions.
>>>>>>
>>>>>> Was there a deliberate change on the llvm-side to
discourage VEX
>>>>>> instructions unless they make a big enough difference
(and/or is
>>>>>> VZEROUPPER now emitted?).
>>>>>>
>>>>>> If not, how might I go about digging further into this?
>>>>>>
>>>>>> Many thanks in advance, Matt
>>>>>>
>>>>>> --
>>>>>> Matt
>>>>>> _______________________________________________
>>>>>> LLVM Developers mailing list
>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Matt
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>
>>>
>>>
>>
>>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140918/82175fd4/attachment.html>