[PATCH] Fix simd-2.c failure on powerpc

[Roger Sayle]

Hi Michael,
> > The second and third operands of ZERO_EXTRACT should always be
> > constant integers and therefore we only need to examine the
> > first operand.
>
> This is not true.  It's not documented this way, and there are
> counter-examples in GCC.


Thanks for the correction.  Indeed, the documentation of zero_extract
and sign_extract don't require the second and third operands to be
constant integers, however neither does it state which RTXs are valid
or even which (non-floating point?) machine modes they must have.
My misunderstanding.

Not that I have total faith in the documentation:  The description
of "set" lists the valid RTXs for its "lval", SET_DEST, which
unfortunately omits to mention "zero_extract" or "sign_extract",
i.e. the cause of the current failure.  Doh!

How about:

Index: rtl.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/rtl.texi,v
retrieving revision 1.50
diff -c -3 -p -r1.50 rtl.texi
*** rtl.texi	7 Apr 2003 20:13:29 -0000	1.50
--- rtl.texi	10 Apr 2003 14:26:44 -0000
*************** the operands of these.
*** 2225,2232 ****
  Represents the action of storing the value of @var{x} into the place
  represented by @var{lval}.  @var{lval} must be an expression
  representing a place that can be stored in: @code{reg} (or @code{subreg}
! or @code{strict_low_part}), @code{mem}, @code{pc}, @code{parallel}, or
! @code{cc0}.

  If @var{lval} is a @code{reg}, @code{subreg} or @code{mem}, it has a
  machine mode; then @var{x} must be valid for that mode.
--- 2225,2232 ----
  Represents the action of storing the value of @var{x} into the place
  represented by @var{lval}.  @var{lval} must be an expression
  representing a place that can be stored in: @code{reg} (or @code{subreg}
! or @code{strict_low_part} or @code{zero_extract} or @code{sign_extract}),
! @code{mem}, @code{pc}, @code{parallel}, or @code{cc0}.

  If @var{lval} is a @code{reg}, @code{subreg} or @code{mem}, it has a
  machine mode; then @var{x} must be valid for that mode.
*************** rest of the register receives an undefin
*** 2239,2248 ****
  the mode of the register, the rest of the register can be changed in
  an undefined way.

! If @var{lval} is a @code{strict_low_part} of a @code{subreg}, then the
! part of the register specified by the machine mode of the
! @code{subreg} is given the value @var{x} and the rest of the register
! is not changed.

  If @var{lval} is @code{(cc0)}, it has no machine mode, and @var{x} may
  be either a @code{compare} expression or a value that may have any mode.
--- 2239,2248 ----
  the mode of the register, the rest of the register can be changed in
  an undefined way.

! If @var{lval} is a @code{strict_low_part}, @code{zero_extract} or
! @code{sign_extract} of a @code{subreg}, then the part of the register
! specified by the machine mode of the @code{subreg} is given the value
! @var{x} and the rest of the register is not changed.

  If @var{lval} is @code{(cc0)}, it has no machine mode, and @var{x} may
  be either a @code{compare} expression or a value that may have any mode.


> > The idiom of testing for ZERO_EXTRACT, SIGN_EXTRACT and
> > STRICT_LOW_PART appears elsewhere in rtlanal.c,
>
> If it checks only op0 of a ZERO_EXTRACT it usually is in functions which
> only need to know if something is changed.  Because op1 and op2 are
> read-only there's no need to look at them.

Indeed.  Fortunately, my tweak to reg_overlap_mentioned_p falls under
precisely this category, so the patch itself is still correct.

Thanks again for putting me straight.

Roger
--