[tree-ssa] Mainline merge as of 2003-04-06

Diego Novillo dnovillo@redhat.com
Thu Apr 10 20:20:00 GMT 2003


If it's any consolation, I think I just reproduced the problem
with a COND_EXPR:

-----------------------------------------------------------------------------
void foo(int x)
{
  if (x > 3)
    {;}
  else
    bar();
  x = 9;
}

main()
{
  int j;

  foo(j);
  return j;
}
-----------------------------------------------------------------------------

At -O3 we inline the optimized foo() into main(), producing:

-----------------------------------------------------------------------------
{
  # BLOCK 0.  PRED: -1.  SUCC: 2 1.
  {
    int x;

    x = j;
    {
      extern  bar;

      if (x > 3)
        {

          # BLOCK 1 (a.c:4).  PRED: 0.  SUCC:.
          {
            (void)0
          }
        }
      else
        {

          # BLOCK 2 (a.c:6).  PRED: 0.  SUCC:.
          bar ()
        };
      (void)0
    }
  };

  # BLOCK 3 (a.c:15).  PRED:.  SUCC:.
  return j;
}
-----------------------------------------------------------------------------

We die as we try to create an edge out of BLOCK 1.


> 2-> _ZTISt8bad_cast.2 = &_ZTISt8bad_cast;
>     __cxa_throw (<UVcf50>, _ZTISt8bad_cast.2, 0B)
>   }
> }
> 
> 
> Should NEXT_BLOCK_LINK point to the statement at point #1 or point #2 in
> the above code?
> 
Well, there's no point for control to reach that empty statement
in #1.  I think making it go to #2 is sensible.

> If it should point to #2, then all these little fragments in tree-cfg.c
> must skip empty statements when trying to determine what NEXT_BLOCK_LINK
> ought to be to catch cases were a tree ends with one or more empty
> statement statements:
> 
>   /* Determine NEXT_BLOCK_LINK for statements inside the COND_EXPR body.  */
>   si = tsi_start (cond_p);
>   tsi_next (&si);
>   if (!tsi_end_p (si))
>     next_block_link = *(tsi_container (si));
> 
> Would skipping through empty statements in these loops potentially
> cause problems elsewhere?
> 
The interesting problem is what happens when we run out of
statements in the chain holding the COND_EXPR.  This means that
we should have every statement in the body know about
NEXT_BLOCK_LINK.

Oh, hell.  Now both our lives suck.  You happy now?  :)

Seriously, though.  I think we should be compacting the
instruction stream as we go out of SSA.  Having the flow graph
make all these contortions to accomodate empty_stmt_node is just
not worth it.


Thoughts?  Diego.



More information about the Gcc mailing list