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

[Andrew Haley <aph at redhat dot com>]

Jeffrey A Law writes:
 > On Tue, 2004-11-30 at 16:07 +0000, Andrew Haley wrote:
 > > 
 > > }
 > > 
 > > The problem here is that the line
 > > 
 > >   <tmp>_4 = x_3->length;
 > > 
 > > has disappeared.  This should not have happened, because the operation
 > > should have may_trap_p() set -- we're deleting a trapping instruction.
 > I would hazard a guess that the statement in question is not considered
 > a trapping instruction because if it was I think we would have had a
 > different CFG.
 > 
 > What does the .cfg dump look like?

Here's a C++ version of the source, to avoid all the Java obfuscation:

extern void *Array_3;
extern void  _Jv_InitClass (void *);

struct intArray
{
  int length;
  int data[0];
};


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

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

And its CFG:

;; Function int baz() (_Z3bazv)

Merging blocks 0 and 1
int baz() ()
{
  int retval;
  int D_630;
  int D_631;
  struct intArray * x_3;
  int nn_7;
  int tmp_6;
  int tmp_5;
  int tmp_4;
  int D.1581;
  int D.1580;
  void * Array_3.0;

  # BLOCK 0
  # 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.

Andrew.