Re: Designs for better debug info in GCC (was: Re: [vta] don't let debug insns get in the way of simple vect reduction)

[Michael Matz <matz at suse dot de>]

Hi,

On Wed, 7 Nov 2007, Alexandre Oliva wrote:

> > With the different approach I and Matz started (and to which we didn't 
> > yet spend enough time to get debug information actually output - but I 
> > hope we'll get there soon), on the tree level the extra information is 
> > stored in a bitmap per SSA_NAME (where necessary).
> 
> This will fail on a very fundamental level.  Consider code such as:
> 
> f(int x, int y) {
>   int c;
>   /* other vars */
> 
>   c = x;
>   do_something_with(c, ...); // doesn't touch x or y
> 
>   c = y;
>   do_something_else_with(c, ...); // doesn't touch x or y
> }
> 
> where do_something_*with are actually complex computations, be that
> explicit code, be it macros or inlined functions.
> 
> This can (and should) be trivially optimized to:
> 
> f(int x, int y) {
>   /* other vars */
> 
>   do_something_with(x, ...); // doesn't touch x or y
> 
>   do_something_else_with(y, ...); // doesn't touch x or y
> }
> 
> But now, if I 'print c' in a debugger in the middle of one of the
> do_something_*with expansions, what do I get?
> 
> With the approach I'm implementing, you should get x and y at the
> appropriate points, even though variable c doesn't really exist any
> more.
> 
> With your approach, what will you get?

x and y at the appropriate part.  Whatever holds 'x' at a point (SSA name, 
pseudo or mem) will also mention that it holds 'c'.  At a later point 
whichever holds 'y' will also mention in holds 'c' .

> There isn't any assignment to x or y you could hook your notes to.

But there are _places_ for x and y.  Those places can and are also 
associated with c.

> Even if you were to set up side representations to model the additional 
> variables that end up mapped to the incoming arguments, you'd have 'c' 
> in both, and at the entry point.  How would you tell?

I don't understand the question.


Ciao,
Michael.