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
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
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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140917/79fa26f7/attachment.html>
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