[LLVMdev] VEX prefixes for JIT in llvm 3.5

Matt Godbolt matt at godbolt.org
Wed Sep 17 12:27:08 PDT 2014


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




More information about the llvm-dev mailing list