[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