Re: RFC: Combine of compare & and oddity

[Segher Boessenkool <segher at kernel dot crashing dot org>]

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