[LLVMdev] VEX prefixes for JIT in llvm 3.5

[Lang Hames]

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>