Re: tree-ssa: a weird (mis)optimization

[Andrew Haley <aph at redhat dot com>]

Jeffrey A Law writes:
 > On Wed, 2004-12-01 at 13:05 +0000, Andrew Haley wrote:
 > 
 > >   # PRED: ENTRY (fallthru)
 > > bb_0:;
 > >   Array_3.0 = Array_3;
 > >   _Jv_InitClass (Array_3.0);
 > >   x_3 = 0B;
 > >   D.1580 = x_3->length;
 > >   tmp_4 = D.1580;
 > >   tmp_5 = tmp_4;
 > >   tmp_6 = tmp_5;
 > >   nn_7 = tmp_6;
 > >   D_631 = 5;
 > >   D.1581 = D_631;
 > >   return D.1581;
 > >   # SUCC: EXIT
 > > 
 > > }
 > > 
 > > It seems to me that even with -fnon-call-exceptions, gcc doesn't mark
 > > x_3->length as potentially throwing.
 > Is it marked as potentially throwing if x_3 doesn't have an invariant
 > value?  ie, if you pass in x_3 or something like that does the right
 > thing happen?
 > 
 > I'm guessing that we see the invariant address and assume that
 > dereferencing the invariant address can't fault.  I seem to
 > recall some truly horrific hacks in the past related to how
 > we handle dereferences of address 0.

int
baz1(  struct  intArray * x_3)
{
  int tmp_4, tmp_5, tmp_6;
  int nn_7;
  int D_631;
  int D_630;
  int retval;

bb_0:
  _Jv_InitClass (Array_3);
  tmp_4 = x_3->length;
  tmp_5 = tmp_4;
  tmp_6 = tmp_5;
  nn_7 = tmp_6;
  D_631 = nn_7;
  return D_631;
}

becomes:

Merging blocks 0 and 1
int baz1(intArray*) (x_3)
{
  int retval;
  int D_630;
  int D_631;
  int nn_7;
  int tmp_6;
  int tmp_5;
  int tmp_4;
  int D.1595;
  int D.1594;
  void * Array_3.1;

  # BLOCK 0
  # PRED: ENTRY (fallthru)
bb_0:;
  Array_3.1 = Array_3;
  _Jv_InitClass (Array_3.1);
  D.1594 = x_3->length;
  tmp_4 = D.1594;
  tmp_5 = tmp_4;
  tmp_6 = tmp_5;
  nn_7 = tmp_6;
  D_631 = nn_7;
  D.1595 = D_631;
  return D.1595;
  # SUCC: EXIT

}