Re: [RFC] New SSA variable mapping infrastructure

[Alexandre Oliva <aoliva@redhat.com>]

On Nov  8, 2007, "Richard Guenther" <richard.guenther@gmail.com> wrote:

>> And what happened to l?

> l is no longer a value that is computed (we do not compute D.1545 +
> j, but only D.1545 + D.1545 and the final sum.  This is what I mean
> with "preserving values" - values that are no longer computed do not
> have their values retained)

So, you intentionally let it go, even though debug information could
encode it.  And, worse, you leave no note behind that the value of l
is no longer known at that point, so if l is retained elsewhere, debug
information will be emitted for it, but it will point at a location
that does not hold the value of l at all in the region where it was
optimized away.  That's bad.

> Now onto the above case.  What we end up with after tree optimizations in
> the moment is

Looks like you threw away the function calls.  That's cheating! :-)

Seriously, the whole point of my introducing those calls were to
expose additional obvious weaknesses in your design.

> foo (i, j)
> {
>   int k.5;
>   int k;

> <bb 2>:
>   k.5 = i * 10 E{ k };
>   if (i < j)
>     goto <bb 3>;
>   else
>     goto <bb 4>;

> <bb 3>:
>   k = k.5;
>   goto <bb 5>;

> <bb 4>:
>   k = 0;

> <bb 5>:
>   return (j + k.5 E{ l }) + k;

> }

> That is, i * 10 has the name 'k' (yes, computed unconditionally -
> but it is also life in the relevant block)

I don't care that it's live or that it's computed.  The question is
whether it makes any sense whatsoever to indicate, in debug
information, that the value of k in bb4 is in k.5, rather than zero.
That's an obvious bug to me.

> we still compute 'l' in this case,

I understood you were adding annotations only to SSA assignments.  The
presence of E{l} seems to contradict this.  So, what's missing from
your design description?

> I believe you cannot do better here unless you limit optimization.

> With VTA I see (final_cleanup again):

The VTA branch is work in progress.  We're discussing design, not
incomplete implementations.  It's just silly to point at raw food and
say "hey, your cooking recipe sucks!" ;-)

In my design, what I envision for the optimized foo() is:

foo (i, j)
{
  int T.1;
  int k;

<bb 2>:
  T.1 = i * 10;
  # DEBUG l = T.1;
  # DEBUG k = 0;
  if (i < j)
    goto <bb 3>;
  else
    goto <bb 4>;

<bb 3>:
  # DEBUG k = T.1;
  breakpoint1 ();
  k = T.1;
  goto <bb 5>;

<bb 4>:
  breakpoint2 ();

<bb 5>:
  # DEBUG k = k;
  breakpoint3 ();
  return (j + T.1) + k;
}

> so you lost 'l' (I didn't ;))

See?, it's there.  It's at least present in the debug stmts design,
and you haven't explained how you get it into the
bitmap-aside-to-SSA-assignments one.

> and from what I see you might in this case avoid making the value i
> * 10 globally associated to 'k' because you track constants in debug
> expressions?

The fact that it's constant is just a distraction.  See in the debug
annotation that 'k = 0' could be anything else, any other expression
live at that point.  And the value of k would be tracked starting from
that location, and any other locations holding that value, as long as
it remained available or k was assigned another value.

> which is basically the same situation as before.  With VTA we get

When the implementation in the VTA branch is complete such that it
matches the design, I expect to get something like this (starting from
your call-less foo(int,int)):

foo (i, j)
{
  int T.1;
  int k;

<bb 2>:
  T.1 = i * 10;
  # DEBUG l = j + T.1;
  # DEBUG k = j + i;
  if (i < j)
    goto <bb 3>;
  else
    goto <bb 4>;

<bb 3>:
  # DEBUG k = T.1;
  k = T.1;
  goto <bb 5>;

<bb 4>:
  k = j + i;

<bb 5>:
  # DEBUG k = k;
  return (j + T.1) + k;
}

>   # DEBUG k optimized away;

should have been 'k = j + i';

>   # DEBUG k = k;

> which looks confusing somehow (it looks to me that some of the 'k' in DEBUG
> exprs should be 'k.5'?)

Why?  k.5 doesn't model anything in the source level.  DEBUG_STMTS are
supposed to indicate that the value of a source-level concept (the
left-hand k) can be determined by computing a certain expression,
e.g., by adding the implementation arguments j and i in one case, or
by taking the value of the implementation variable k in the other.

> But maybe you can explain what happens to what names here?

See above.  Also, see the debug stmt in bb3 above, that refers to T.1
(which the compiler happens to name k.5).  Does it make sense to you
now?

If not, maybe you can explain why/where you think k.5 should be
mentioned.  Is that what you were expecting?  If not, perhaps there's
some misunderstanding as to what the debug stmts stand for.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}