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.
> 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).
Segher
