[llvm-dev] LLVM Pass - Backend Instrumentation

[Abdul Wahab via llvm-dev]

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>