[LLVMdev] VEX prefixes for JIT in llvm 3.5

[Matt Godbolt]

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