Re: IMA vs tree-ssa

[Dale Johannesen <dalej at apple dot com>]

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;

instead which is wrong.  Now we may be able to prevent the ICE by 
checking for
ARRAY_TYPE there, but surely what you want to do is get the B[0] case 
to be recognized...
Thanks, at least now I understand the intent.