[LLVMdev] VEX prefixes for JIT in llvm 3.5

[Philip Reames]

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