Re: IMA vs tree-ssa

[law at redhat dot com]

In message <3F7FB8C0-68B0-11D8-8C0E-000A95D7CD40@apple.com>, Dale Johannesen wr
ites:
 >On Feb 26, 2004, at 2:42 PM, law@redhat.com wrote:
 >> In message <F0209661-68A9-11D8-8C0E-000A95D7CD40@apple.com>, Dale 
 >> Johannesen wr
 >> ites:
 >>> There are several places where tree-ssa does type comparison by
 >>> comparing TYPE_MAIN_VARIANT() for equality.
 >> Yup.
 >>
 >>> This doesn't work with IMA, and leads to several different ICEs in
 >>> various SPECmarks (you can probably figure out which one the example
 >>> came from :)
 >> When the tree-ssa optimizers look at TYPE_MAIN_VARIANT, they are 
 >> trying to
 >> determine if they can either eliminate an expression or eliminate a 
 >> copy.
 >> If the main variants are not equal, then all that ought to happen is a
 >> optimization opportunity is missed.
 >>
 >> If we're getting aborts and such, then I'd be very curious to know 
 >> precisely
 >> how the TYPE_MAIN_VARIANTs are being used and how the mis-matched types
 >> lead to failures.
 >
 >Hmm, I may have been too optimistic in thinking these were all the same 
 >bug then,
 >although everything passes without IMA...the one I analyzed in detail 
 >is 176.gcc.
 >Source looks like this:
 >
 >rtx recog_operand[MAX_RECOG_OPERANDS];
 >   register rtx *ro = &recog_operand[0];
 >   rtx x2;
 >       ro[0] = x2;
 >
 >It propagates &recog_operand into *r0, then tries to simplify 
 >*&recog_operand
 >in maybe_fold_stmt_indirect().  It ought to trigger this case:
 >
 >       /* Try folding *(&B+O) to B[X].  */
 >       t = maybe_fold_offset_to_array_ref (base, offset, TREE_TYPE 
 >(expr));
 >
 >but the node for struct rtx_def under the array type is not 
 >pointer-equivalent to the one
 >on the indirect node,  so that fails, and it falls through into
 >
 >       /* Fold *&B to B.  */
 >       if (integer_zerop (offset))
 >         return base;
I must still be missing something.  If OFFSET is zero, then why is returning
BASE wrong?

If OFFSET is nonzero, then we'll fall out returning NULL_TREE which 
indicates that we couldn't simplify -- which ought to just inhibit
an optimization.

jeff