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 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. > 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? -Andi