[LLVMdev] VEX prefixes for JIT in llvm 3.5

Thu Sep 18 11:42:55 PDT 2014

Hi Philip,

Ahh. Sorry to hear. The good news is that I have a plan to make it better.
The bad news is that I don't have a timeline. I'm trying to squash a few
critical bugs in the infrastructure at the moment and then I'll start
putting out proposals and asking for volunteers. :)

- Lang.

On Thu, Sep 18, 2014 at 11:01 AM, Philip Reames <listmail at philipreames.com>
wrote:

>
> On 09/18/2014 10:17 AM, Lang Hames wrote:
>
> 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.
>
> I know.  This is what I'm actually doing today.  :)
>
>
>  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?
>
> I'm not using the loadObject interface today.  On the surface, this looks
> ideal, but I don't have any practical experience to confirm.  I'm currently
> using the interfaces on ExecutionEngine (i.e. generateCodeForModule,
> mapSectionAddress, finalizeObject, then getPointerToFunction)
>
>
>  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/7db12bd4/attachment.html>