Better info for combine results in worse code generated

Alan Modra amodra@gmail.com
Sat May 30 01:17:00 GMT 2015


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



More information about the Gcc mailing list