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

[Roger Sayle]

Hi Richard,

> Roger Sayle wrote:
> > The second and third operands of ZERO_EXTRACT should always be
> > constant integers and therefore we only need to examine the
> > first operand.
>
> False.

Indeed.  David Anglin has already corrected me on my understanding.
Fortunately, it doesn't affect the validity of that change/hunk.  If
you were to support ZERO_EXTRACT in reg_overlap_mentioned_p, I'm sure
you'd do it the same way.  If not, you could consider David's patch:
http://gcc.gnu.org/ml/gcc-patches/2003-04/msg00625.html


> I'll look at the combine fragment later; my gut reaction is
> that it's overly pessimistic.

I won't argue that combine could be improved.  However the current
state of affairs is that code immediately following the combine
change in my patch looks like (line 1122 of combine.c):


  /* DEST must either be a REG or CC0.  */
  if (GET_CODE (dest) == REG)
    {
      ...
    }
  else if (GET_CODE (dest) != CC0)
    return 0;


Hence my patch only guards against the cases GCC already handles.


Whether you decide to approve this patch or fix the problem differently,
don't forget/overlook my proposed documentation change.  The fact that
that zero_extract isn't listed as a valid set destination may well have
contributed to this regression.
http://gcc.gnu.org/ml/gcc-patches/2003-04/msg00650.html


Sorry again for my misinterpretation of the zero_extract documentation.

Roger
--