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