RFC: Combine of compare & and oddity

["Wilco Dijkstra" <wdijkstr@arm.com>]

Hi,

Combine canonicalizes certain AND masks in a comparison with zero into extracts of the widest
register type. During matching these are expanded into a very inefficient sequence that fails to
match. For example (x & 2) == 0 is matched in combine like this:

Failed to match this instruction:
(set (reg:CC 66 cc)
    (compare:CC (zero_extract:DI (subreg:DI (reg/v:SI 76 [ xD.2641 ]) 0)
            (const_int 1 [0x1])
            (const_int 1 [0x1]))
        (const_int 0 [0])))
Failed to match this instruction:
(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])))

Neither matches the AArch64 patterns for ANDS/TST (which is just compare and AND). If the immediate
is not a power of 2 or a power of 2 -1 then it matches correctly as expected.

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.

It's trivial to change change_zero_ext to expand extracts always into AND and remove the redundant
subreg. However wouldn't it make more sense to never special case certain AND immediate in the first
place?

Wilco