[Qemu-devel] ARM NEON function call tracing

[Qemu-devel] ARM NEON function call tracing

[Junaid Shuja]

[-- Attachment #1: Type: text/plain, Size: 498 bytes --]

Hi,
I am working on ARM/NEON instructions. I want to know which neon helper
function corresponds to the neon instructions. As a test case, I have a
source file with loads of vadd.i32 instructions. I want to trace which neon
helper functions is called. I used a very crude approach: printf in
neon_add_u16 funtion and compiled source again. But no printf showed on
program execution. I need help regarding tracing of neon helpers.

-- 
Junaid Shuja
WHA130039
PhD Student, FSKTM
University of Malaya

[-- Attachment #2: Type: text/html, Size: 684 bytes --]

Re: [Qemu-devel] ARM NEON function call tracing

[Peter Maydell]

On 11 November 2015 at 07:51, Junaid Shuja <junaidshuja@siswa.um.edu.my> wrote:
> Hi,
> I am working on ARM/NEON instructions. I want to know which neon helper
> function corresponds to the neon instructions. As a test case, I have a
> source file with loads of vadd.i32 instructions. I want to trace which neon
> helper functions is called. I used a very crude approach: printf in
> neon_add_u16 funtion and compiled source again. But no printf showed on
> program execution. I need help regarding tracing of neon helpers.

Integer addition is a simple operation so we can do it directly
in the generated code; we don't need a helper for it, even as a
Neon instruction. Generally we only have helper functions for
operations that are too complicated to do directly inline.
So there isn't a simple "one neon instruction, one helper function"
mapping. Where we do have a helper function, the helper
may work on one "lane" of Neon data (meaning it gets called
more than once for each instruction) or it may work on several
lanes at once.

To find out how we handle a particular Neon instruction, you need
to look at disas_neon_data_insn and see what it does with the
insn (it may be easiest to do this by putting a breakpoint on
it and stepping through with a debugger). Where this code calls
gen_helper_* functions, it is emitting generated code which will
later call the relevant helper at runtime.

thanks
-- PMM

Re: [Qemu-devel] ARM NEON function call tracing

[Alex Bennée]

Peter Maydell <peter.maydell@linaro.org> writes:

> On 11 November 2015 at 07:51, Junaid Shuja <junaidshuja@siswa.um.edu.my> wrote:
>> Hi,
>> I am working on ARM/NEON instructions. I want to know which neon helper
>> function corresponds to the neon instructions. As a test case, I have a
>> source file with loads of vadd.i32 instructions. I want to trace which neon
>> helper functions is called. I used a very crude approach: printf in
>> neon_add_u16 funtion and compiled source again. But no printf showed on
>> program execution. I need help regarding tracing of neon helpers.
>
> Integer addition is a simple operation so we can do it directly
> in the generated code; we don't need a helper for it, even as a
> Neon instruction. Generally we only have helper functions for
> operations that are too complicated to do directly inline.
> So there isn't a simple "one neon instruction, one helper function"
> mapping. Where we do have a helper function, the helper
> may work on one "lane" of Neon data (meaning it gets called
> more than once for each instruction) or it may work on several
> lanes at once.
>
> To find out how we handle a particular Neon instruction, you need
> to look at disas_neon_data_insn and see what it does with the
> insn (it may be easiest to do this by putting a breakpoint on
> it and stepping through with a debugger). Where this code calls
> gen_helper_* functions, it is emitting generated code which will
> later call the relevant helper at runtime.

Random musing: I wonder how easy it would be to emit the helper function
name in the out_asm dump?

>
> thanks
> -- PMM


-- 
Alex Bennée