[Bug rtl-optimization/92656] The zero_extend insn can't be eliminated in the combine pass

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92656

--- Comment #2 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Trying 104 -> 105:
  104: r125:SI=zero_extend(r101:SI#0)
      REG_DEAD r101:SI
  105: r127:SI={(r100:SI!=0)?r125:SI:r79:SI}
      REG_DEAD r125:SI
      REG_DEAD r100:SI
      REG_DEAD r79:SI
Failed to match this instruction:
(set (reg/v:SI 127 [ result ])
    (if_then_else:SI (ne (reg:SI 100)
            (const_int 0 [0]))
        (zero_extend:SI (subreg:HI (reg:SI 101) 0))
        (reg/v:SI 79 [ result ])))
Failed to match this instruction:
(set (reg/v:SI 127 [ result ])
    (if_then_else:SI (ne (reg:SI 100)
            (const_int 0 [0]))
        (and:SI (reg:SI 101)
            (const_int 65535 [0xffff]))
        (reg/v:SI 79 [ result ])))


Combine does not know r101 has all the high bits clear, apparently.  r101 is
formed via

insn_cost 4 for    77: r94:SI=0x4000
insn_cost 4 for    78: r93:SI=r94:SI+0x2
      REG_DEAD r94:SI
      REG_EQUAL 0x4002
insn_cost 8 for    24: r79:SI=zero_extend(r95:SI#0)
      REG_DEAD r95:SI
insn_cost 4 for   103: r101:SI=r79:SI^r93:SI

(insn 24 is a HImode subreg), so it could have seen that.  But the way nonzero
bits are tracked is not very predictable or dependable (it depends on the order
that combine looks at insns, which changes if insns combine where they didn't
before, etc.)

This whole nonzero_bits thing should be handled by dataflow.