On Fri, May 29, 2015 at 10:00:04AM -0500, Segher Boessenkool wrote:
> On Fri, May 29, 2015 at 11:20:08PM +0930, Alan Modra wrote:
> > On Fri, May 29, 2015 at 07:58:38AM -0500, Segher Boessenkool wrote:
> > > On Fri, May 29, 2015 at 12:41:20PM +0930, Alan Modra wrote:
> > > > +/* Describe how rtl operations on registers behave on this target when
> > > > + operating on less than the entire register. */
> > > > +#define EXTEND_OP(OP) \
> > > > + (GET_MODE (OP) != SImode \
> > > > + || !TARGET_POWERPC64 \
> > > > + ? UNKNOWN \
> > > > + : (GET_CODE (OP) == AND \
> > > > + || GET_CODE (OP) == ZERO_EXTEND \
> > > > + || GET_CODE (OP) == ASHIFT \
> > > > + || GET_CODE (OP) == ROTATE \
> > > > + || GET_CODE (OP) == LSHIFTRT) \
> > > > + ? ZERO_EXTEND \
> > > > + : (GET_CODE (OP) == SIGN_EXTEND \
> > > > + || GET_CODE (OP) == ASHIFTRT) \
> > > > + ? SIGN_EXTEND \
> > > > + : UNKNOWN)
> > >
> > > I think this is too simplistic though. For example, AND with -7 is not
> > > zero-extended (rlwinm rD,rA,0,31,28 sets the high 32 bits of rD to the low
> > > 32 bits of rA).
> >
> > We take some pains in rs6000.md to ensure that the wrap-around case
> > for rlwinm does not occur for TARGET_POWERPC64.
>
> I consider that a bug; it pessimises code.
At the time I added the checks for wrap-around, I recall that gcc
generated wrong code without the fix.
> > You'll find that an
> > SImode AND with any value is in fact zero extending.
>
> int f(int x) { return x & 0xc0000000; }
>
> is a counter-example with current trunk (it does a rldicr).
Huh, that does look like you've destroyed my claim about SImode AND.
--
Alan Modra
Australia Development Lab, IBM
