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

[Andi Kleen]

On Thu, Nov 22, 2018 at 02:53:11PM +0100, Richard Biener wrote:
> > the optimizer moving it around over function calls etc.?
> > The instrumentation should still be useful when the program
> > crashes, so we don't want to delay logging too much.
> 
> You can't avoid moving it, yes.  But it can be even moved now, effectively
> detaching it from the "interesting" $pc ranges we have debug location lists for?
> 
> > > Maybe even instead pass it a number of bytes so it models how atomics work.
> >
> > How could that reject float?
> 
> Why does it need to reject floats?  Note you are already rejecting floats
> in the instrumentation pass.

The backend doesn't know how to generate the code for ptwrite %xmm0. 
So it would either need to learn about all these conversions, or reject
them in the hook so that the middle end eventually can generate
them. Or maybe hard code the knowledge in the middle end?

> > Mode seems better for now.
> >
> > Eventually might support float/double through memory, but not in the
> > first version.
> 
> Why does movq %xmm0, %rax; ptwrite %rax not work?

It works of course, the question is just who is in charge
of figuring out that the movq needs to be generated
(and that it's not a round, but a bit cast)

> Fair enough, the instrumentation would need to pad out smaller values
> and/or split larger values.  I think 1 and 2 byte values would be interesting
> so you can support char and shorts.  Eventually 16byte values for __int128
> or vectors.

Right. And for copies/clears too. But I was hoping to just get
the basics solid and then do these more advanced features later.

> > > btw, I wonder whether the vartrace attribute should have an argument like
> > > vartrace(locals,reads,...)?
> >
> > I was hoping this could be delayed until actually needed. It'll need
> > some changes because I don't want to do the full parsing for every decl
> > all the time, so would need to store a bitmap of options somewhere
> > in tree.
> 
> Hmm, indeed.  I wonder if you need the function attribute at all then?  Maybe

I really would like an opt-in per function. I think that's an important
use case. Just instrument a few functions that contribute to the bug
you're debugging to cut down the bandwidth.

The idea was that __attribute__((vartrace)) for a function would
log everything in that function, including locals.

I could see a use case to opt-in into a function without
locals (mainly because local tracking is more likely to cause
trace overflows if there is a lot of execution). But I think I can do
without that in v1 might add it later.

> That is, on types and decls you'd interpret it as if locals tracing is on
> then locals of type are traced but otherwise locals of type are not traced?

When the opt-in is on the type or the variable then the variable
should be tracked, even if it is an local (or maybe even a cast)

The locals check is mainly for the command line.

> That is, if I just want to trace variable i and do
> 
>  int i __attribute__((vartrace));
> 
> then what options do I enable to make that work and how can I avoid
> tracing anything else?  Similar for

Just enable -mptwrite (or nothing if it's implied with -mcpu=...) 

> 
>  typedef int traced_int __attribute_((vartrace));

Same.

> 
> ?  I guess we'd need -fvar-trace=locals to get the described effect for
> the type attribute and then -fvar-trace=locals,all to have _all_ locals
> traced?  Or -fvar-trace=locals,only-marked? ... or forgo with the idea
> of marking types?

You want a command line override to not trace if the attribute
is set?

-mno-ptwrite would work. Could also add something separate
in -fvartrace (perhaps implied in =off) but not sure if it's worth it.

I suppose it could make sense if someone wants to use the _ptwrite 
builtin separately still. I'll add it to =off.

> so there's no 'i' anymore.  If you enable debug-info you

Hmm I guess that's ok for now. I suppose it'll work with -Og.

> and instrumenting late.  (but ptwrite is only
> interesting for optimized code, no?)

It's very interesting for non optimized code too. In fact
that would be a common use case during debugging.


-Andi