llvm dev - Feb 2017 - LLVM Pass - Backend Instrumentation

Hello,

I would like to instrument backend generated code to recover all load and
store instructions' operands. What would be the best way to implement this
instrumentation.

I was thinking of creating a MachineFunctionPass, get all load and store
instructions and add an instruction that writes the operands of Load/Store
instructions to an address. How can I control the address of
instrumentation ?

I think getting all load and store instructions will be easy (I will do
something similar to ARMLoadStoreOptimizer.cpp). However, I don't know how
to control the instrumentation address. Can anybody give me pointer on this
? Or any other tips/recommendations are appreciated as well.

Thank you very much for your help and time.

Best Regards,
MAW
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170228/03d4f645/attachment.html>

Hi Abdul,

On 28 February 2017 at 03:22, Abdul Wahab via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> However, I don't know how
> to control the instrumentation address. Can anybody give me pointer on
this?
A couple of options spring to mind.

You could allocate a buffer somewhere and store its address into a
chosen variable. Then your instrumentation would consist of loading
the buffer's address from this global into a vreg; storing your data
there; incrementing the buffer's address; and finally storing the
buffer back to the global.

Converting that whole sequence to a call might be better for
performance, and certainly more versatile. Then you'd put your data
into argument registers, emit a "BL __handle_store" or whatever, and
that function (which could be written in C++) would log the store.

A completely different approach would be to reserve some non-essential
register in LLVM (r9 is traditional) so the compiler doesn't use it.
Then if you arrange for startup code to set it to a buffer's address
you can simply store to r9 and increment it during your
instrumentation.

The tricky bit will be that this all has to be done after register
allocation (otherwise you miss spills & fills). You might have to
surround your entire instrumentation block with push/pop instructions
to give you some free registers to use.

Cheers.

Tim.

Hi Tim,
Thank you so much for your answer.
I like the approach in which a register can be reserved so the compiler
don't use it. How can I do that easily at the backend ?
Besides, do you have any reference for instrumentation based on this or any
other approach you mentioned.
Thank you very much for your help and time.
Best Regards,
MAW


Le mar. 28 févr. 2017 à 15:57, Tim Northover <t.p.northover at gmail.com>
a
écrit :
> Hi Abdul,
>
> On 28 February 2017 at 03:22, Abdul Wahab via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > However, I don't know how
> > to control the instrumentation address. Can anybody give me pointer on
> this?
>
> A couple of options spring to mind.
>
> You could allocate a buffer somewhere and store its address into a
> chosen variable. Then your instrumentation would consist of loading
> the buffer's address from this global into a vreg; storing your data
> there; incrementing the buffer's address; and finally storing the
> buffer back to the global.
>
> Converting that whole sequence to a call might be better for
> performance, and certainly more versatile. Then you'd put your data
> into argument registers, emit a "BL __handle_store" or whatever,
and
> that function (which could be written in C++) would log the store.
>
> A completely different approach would be to reserve some non-essential
> register in LLVM (r9 is traditional) so the compiler doesn't use it.
> Then if you arrange for startup code to set it to a buffer's address
> you can simply store to r9 and increment it during your
> instrumentation.
>
> The tricky bit will be that this all has to be done after register
> allocation (otherwise you miss spills & fills). You might have to
> surround your entire instrumentation block with push/pop instructions
> to give you some free registers to use.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170303/1869cf11/attachment.html>