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

[Jeffrey A Law <law at redhat dot com>]

On Wed, 2004-12-01 at 13:05 +0000, Andrew Haley wrote:

> 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.
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.

Jeff