On Wed, Sep 02, 2015 at 01:59:58PM -0600, Jeff Law wrote:
> >(set (reg:CC 66 cc)
> > (compare:CC (and:DI (lshiftrt:DI (subreg:DI (reg/v:SI 76 [ xD.2641 ])
> > 0)
> > (const_int 1 [0x1]))
> > (const_int 1 [0x1]))
> > (const_int 0 [0])))
> Yea, this is an alternative form. I don't offhand remember how/why
> this form appears, but it certainly does. I don't think any ports
> handle this form (but I certainly have done any checks), but I believe
> combine creates it primarily for internal purposes.
Combine replaces zero_ext* with equivalent shift/and patterns and tries
again, if things don't match. Targets with more generic masking insns
do not want to describe the very many cases that can be described with
zero_ext* separately.
rs6000 handles this exact pattern, btw. And I'll be very happy if we can
just drop it :-)
> >I don't understand how ((x >> 1) & 1) != 0 could be a useful expansion (it
> >even uses shifts by 0 at
> >times which are unlikely to ever match anything). Why does combine not try
> >to match the obvious (x &
> >C) != 0 case? Single-bit and mask tests are very common, so this blocks
> >efficient code generation on
> >many targets.
> From md.texi:
>
> cindex @code{zero_extract}, canonicalization of
> @cindex @code{sign_extract}, canonicalization of
> @item
> Equality comparisons of a group of bits (usually a single bit) with zero
> will be written using @code{zero_extract} rather than the equivalent
> @code{and} or @code{sign_extract} operations.
Oh it's even documented, thanks. I do still think we should think of
changing this.
Segher
