On Nov 8, 2007, Michael Matz <[EMAIL PROTECTED]> wrote:
> Hi,
> On Wed, 7 Nov 2007, Alexandre Oliva wrote:
>> > 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' .
>>
>> I.e., there will be two parallel locations throughout the entire
>> function that hold the value of 'c'.
> No. For some PC locations the location of 'c' will happen to be the same
> as the one holding 'x', and for a different set of PC locations it will be
> the one also holding 'y'.
So we're in agreement. What you say is how it ought to be done, what
I did was to point out that the representation proposed by richi will
be unable to do the right thing.
>> f(int x /* but also c */, int y /* but also c */) { /* other vars */
> "int x /* but also c */, int y /* but also c */" implies that x == y
> already
No, per the posted design (assuming I understood it correctly) it just
implies that, at some point in the program, an assignment 'c = x' was
optimized away, and that at some other point in the program, an
assignment 'c = y' was optimized away.
>> do_something_with(x, ...); // doesn't touch x or y
>> do_something_else_with(y, ...); // doesn't touch x or y
>>
>> Now, what will you get if you 'print c' in the debugger (or if any
>> other debug info evaluator needs to tell what the value of user
>> variable c is) at a point within do_something_with(c,...) or
>> do_something_else_with(c)?
> ... so the answer would be "whatever is in that common place for x,y and
> c".
And once we removed the incorrect assumption you made, that 'x == y',
what do you get?
> How come that f::c is actually set to p$x?
It was in the original source code, was it not? p$x was passed to f()
as x, and then x was copied to c.
> I don't see any assignment and in fact no declaration for c in f.
> If you had one _that_ would be the place were the connection between
> p$x and 'c' would have been made and everything would fall in place.
Since there is a declaration of c in the original source-level f (the
only one that matters, as far as debug information is concerned), can
you please expand on how you'd get everything to fall in place?
> It's not possible that p$x _and_ p$y are f()::c.1 at the same time,
Exactly
> so the above examples are all somehow invalid.
It's the bitmap debug info representation that makes them nonsensical.
> int f(int y) {
> int x = 2 * y;
> return x + 2;
> }
> If the compiler forward-props 2*y into the single use and simplifies:
> return (y+1)*2;
> then the value 2*y is never actually calculated anymore, not in any
> register, not in any local variable, nowhere. There's no way debug
> information could generally rectify this loss of information.
Actually, while y is live, debug information could encode that x is
2*y, even if the value is not computed at run time. So your statement
is quite an exaggeration.
> In case of more complicated expressions that's not possible anymore
> and you lose.
Yep. If the value is unavailable, debug information should say so,
rather than pointing at something else.
> Forcing some values life is possible,
But undesirable. I'm not trying to do that. Actually, I'm working
hard to make sure it doesn't happen.
> So, our mapping is as accurate as your's.
Not at all, and you made that point yourself, twice, in a single
e-mail.
> It seems in your branch you also force some values life IIUC.
Nope. Any values that are forced live by debug annotations are bugs
to be fixed.
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
