Re: [PATCH 2/3] Add a pass to automatically add ptwrite instrumentation

[Richard Biener <richard.guenther@gmail.com>]

On November 13, 2018 7:09:15 PM GMT+01:00, Andi Kleen <andi@firstfloor.org> wrote:
>On Tue, Nov 13, 2018 at 09:03:52AM +0100, Richard Biener wrote:
>> > I even had an earlier version of this that instrumented
>> > assembler output of the compiler with PTWRITE in a separate script,
>> > and it worked fine too.
>> 
>> Apart from eventually messing up branch range restrictions I guess ;)
>
>You mean for LOOP? For everything else the assembler handles it I
>believe.
>
>> Did you gather any statistics on how many ptwrite instructions
>> that are generated by your patch are not covered by any
>> location range & expr?  
>
>Need to look into that. Any suggestions how to do it in the compiler?

I guess you need to do that in a dwarf decoder somehow. 

>I had some decode failures with the perf dwarf decoder,
>but I was usually blaming them on perf dwarf limitations. 
>
>> I assume ptwrite is writing from register
>> input only so you probably should avoid instrumenting writes
>> of constants (will require an extra register)?
>
>Hmm, I think those are needed unfortunately because someone
>might want to trace every update of of something. With branch
>tracing it could be recreated theoretically but would 
>be a lot more work for the decoder.
>
>> How does the .text size behave say for cc1 when you enable
>> the various granularities of instrumentation?  How many
>> ptwrite instructions are there per 100 regular instructions?
>
>With locals tracing (worst case) I see ~23% of all instructions
>in cc1 be PTWRITE. Binary is ~27% bigger.

OK, I suppose it will get better when addressing some of my review comments. 

>> Can we get an updated patch based on my review?
>
>Yes, working on it, also addressing Martin's comments. Hopefully soon.
>> 
>> I still think we should eventually move the pass later
>
>It's after pass_sanopt now.
>
>> avoid instrumenting places we'll not have any meaningful locations
>> in the debug info - if only to reduce required trace bandwith.
>
>Can you suggest how to check that?

I'd look at doing the instrumentation after var-tracking has run - that is what computes the locations in the end. That means instrumenting on late RTL after register allocation (and eventually with branch range restrictions in place). Basically you'd instrument at the same time as generating debug info.

Richard. 

>-Andi