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.
