[LLVMdev] VEX prefixes for JIT in llvm 3.5

Jim Grosbach grosbach at apple.com
Wed Sep 17 12:34:10 PDT 2014


Hi Matt,

Yep, that’s exactly what happened. There’s two things that motivated the change. First, the MCJIT supports JITing for a non-host CPU(*), so assuming the host isn’t safe. Second, the auto-detection was being done in a non-JIT-specific code path, so tools like llc were also getting the auto detection, which made writing good tests problematic. The plan is to re-introduce the auto detection for the MCJIT but to do it in a more well-contained manner.

-Jim

(*) That was the first use-case for MCJIT, actually. LLDB expression evaluation for remote targets (debugging iOS from OS X).

> On Sep 17, 2014, at 12:27 PM, Matt Godbolt <matt at godbolt.org> wrote:
> 
> 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