<div dir="ltr">So here are my unsolicited thoughts on an issue I have a tenuous grasp of.  =)<div><br></div><div>I'm going to go out on a limb and say that there isn't a whole lot of hand written assembly written for MIPS in applications today.  If this gets MIPS on par with x86 support, maybe it's good enough for now?  It sounds like instruction emulation will give the best results but it sounds like it might be overkill right now, especially if they're just trying to bring it up.</div><div><br></div><div>That said, it they are closing on clean tests and they want the best results in all cases, I think instruction emulation is the way to go.</div><div><br></div><div>Am I missing something?</div><div><br></div><div>Vince</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 21, 2015 at 2:36 AM, Jason Molenda <span dir="ltr"><<a href="mailto:jmolenda@apple.com" target="_blank">jmolenda@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">When you're talking about compiler generated code, a hand written assembly parser is easy.  The complication comes when the compiler changes how it expresses prologues -- or hand written assembly routines.<br>
<br>
A simple example for x86_64, you can save a register to the stack with either<br>
<br>
  push %rbx<br>
<br>
or<br>
<br>
  movq %rax, -0x10(%rbp)<br>
<br>
(using at&t assembly syntax).  If your compiler only does the pushes and that's all you handle, your profiler will fail as soon as it sees the alternate instruction to do the same.<br>
<br>
You see the assembly profilers like UnwindAssembly-x86 fall over if you don't think up all the instructions that might occur in prologue/epilogues.  That's the risk of them.<br>
<br>
I just looked into the existing arm & arm64 emulation routines and I think I mis-stated what Greg suggested.  The arm instruction emulation (see source/Plugins/Instruction/ARM) is a full instruction emulation from the ARM xml instruction description files.  It could be a big undertaking.<br>
<br>
The arm64 instruction emulation (see source/Plugins/Instruction/ARM64) is a hand written emulation of only a dozen different instructions - I hadn't looked into it in detail until now.  I think Greg would prefer that the MIPS assembly profiler be written in a similar style to the ARM64 instruction emulation routine.<br>
<br>
The Instruction plugins are run by the UnwindAssembly/InstEmulation/UnwindAssemblyInstEmulation.cpp class.  This class uses the Instruction subclass to classify the instruction stream and it generates the UnwindPlan from there.<br>
<br>
For that matter, you could argue that UnwindAssembly-x86 could be rewritten in the same way.<br>
<br>
I'm less against Greg's suggestion given all of this.  It's separating the instruction recognition logic from the UnwindPlan creation logic and seems like a good direction to head in.  I haven't done this for the x86 profiler yet myself so I feel bad about asking someone else to jump in here.  The "full emulation of the entire ISA is more flexible" argument doesn't hold for something like the EmulateInstructionARM64 class but there is the separation of logic to argue in favor of it.<br>
<span class=""><br>
<br>
REPOSITORY<br>
  rL LLVM<br>
<br>
<a href="http://reviews.llvm.org/D7696" target="_blank">http://reviews.llvm.org/D7696</a><br>
<br>
</span>EMAIL PREFERENCES<br>
  <a href="http://reviews.llvm.org/settings/panel/emailpreferences/" target="_blank">http://reviews.llvm.org/settings/panel/emailpreferences/</a><br>
<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><br><table cellspacing="0" cellpadding="0" style="font-family:'Times New Roman'"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Vince Harron |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Technical Lead Manager |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:vharron@google.com" target="_blank">vharron@google.com</a> |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"> 858-442-0868</td></tr></tbody></table><br></div></div>
</div>