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

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

On Tue, 2004-11-30 at 16:07 +0000, Andrew Haley wrote:
> One of the Java test cases is failing because of an incorrect
> optimization.
> 
> 
> Here's the function in the t18.copyrename1 dump:
> 
> ;; Function Array_3.baz() (_ZN7Array_33bazEv)
> 
> Array_3.baz() ()
> {
>   int <tmp>;
>   int nn;
>   struct int[] * x;
>   int D.631;
>   int D.630;
>   int retval.0;
> 
> <bb 0>:
>   _Jv_InitClass (&Array_3.class);
>   x_3 = 0B;
>   <tmp>_4 = x_3->length;
>   <tmp>_5 = <tmp>_4;
>   <tmp>_6 = <tmp>_5;
>   nn_7 = <tmp>_6;
>   D.631_8 = 5;
>   return D.631_8;
> 
> }
> 
> 
> And here it is in the t19.dce1 dump:
> 
> ;; Function Array_3.baz() (_ZN7Array_33bazEv)
> 
> Array_3.baz() ()
> {
>   int <tmp>;
>   int nn;
>   struct int[] * x;
>   int D.631;
>   int D.630;
>   int retval.0;
> 
> <bb 0>:
>   _Jv_InitClass (&Array_3.class);
>   D.631_8 = 5;
>   return D.631_8;
> 
> }
> 
> 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?

jeff