[Lldb-commits] [PATCH] Initial Assembly profiler for mips64

[Vince Harron]

So here are my unsolicited thoughts on an issue I have a tenuous grasp of.
 =)

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.

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.

Am I missing something?

Vince





On Sat, Feb 21, 2015 at 2:36 AM, Jason Molenda <jmolenda at apple.com> wrote:

> 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.
>
> A simple example for x86_64, you can save a register to the stack with
> either
>
>   push %rbx
>
> or
>
>   movq %rax, -0x10(%rbp)
>
> (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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> For that matter, you could argue that UnwindAssembly-x86 could be
> rewritten in the same way.
>
> 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.
>
>
> REPOSITORY
>   rL LLVM
>
> http://reviews.llvm.org/D7696
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>
>


-- 

Vince Harron | Technical Lead Manager | vharron at google.com | 858-442-0868
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20150221/5ac4df33/attachment.html>