[LLVMdev] VEX prefixes for JIT in llvm 3.5

Philip Reames listmail at philipreames.com
Thu Sep 18 11:01:26 PDT 2014


On 09/18/2014 10:17 AM, Lang Hames wrote:
> Hi Matt, Philip,
>
> You could get the data you want by recording the addresses returned by 
> the allocateCodeSection and allocateDataSection methods on your 
> RTDyldMemoryManager, then disassembling those sections after you've 
> called resolveRelocations. That's a little unsatisfying though. For 
> one thing, unless you very carefully maintain the association with the 
> original object via back-channels there will be no way of knowing 
> which section belongs to which object file.
I know.  This is what I'm actually doing today.  :)
>
> With a bit of cleanup though, we could do something more like this:
>
> const RuntimeDyld::JITObject& JO = RTDyld.loadObject(Object);
> // ...
> RTDyld.resolveRelocations();
>
> DEBUG(
>   for (const RuntimeDyld::JITObject::Section& S : JO.sections())
>     if (S.isText())
> Disassemble(S.getAddr(), S.getSize());
> );
>
> How does that look?
I'm not using the loadObject interface today.  On the surface, this 
looks ideal, but I don't have any practical experience to confirm. I'm 
currently using the interfaces on ExecutionEngine (i.e. 
generateCodeForModule, mapSectionAddress, finalizeObject, then 
getPointerToFunction)
>
> Cheers,
> Lang.
>
>
> On Wed, Sep 17, 2014 at 3:08 PM, Philip Reames 
> <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote:
>
>
>     On 09/17/2014 12:45 PM, Matt Godbolt wrote:
>
>         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?
>
>     my 2 cents: It seems like we need a different event type. Having
>     access to the object before linking (and relocation?) seems
>     useful, but I suspect most users (myself included) want the final
>     object after everything is done.
>
>     Philip
>
>
>     On Wed, Sep 17, 2014 at 2:35 PM, Yaron Keren
>     <yaron.keren at gmail.com <mailto: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
>             <mailto: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 <mailto: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 <mailto: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
>                         <mailto: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 <mailto:LLVMdev at cs.uiuc.edu>
>                 http://llvm.cs.uiuc.edu
>                 http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
>
>
>     _______________________________________________
>     LLVM Developers mailing list
>     LLVMdev at cs.uiuc.edu <mailto: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/20140918/42eeddbe/attachment.html>


More information about the llvm-dev mailing list