There are situations where knowledge about which bits
of a value are (not) set can be used for optimization.
For example in an insn combine pattern like:
(define_insn_and_split ""
[(set (match_operand:QI 0 "register_operand" "=d")
(ior:QI (ashift:QI (match_operand:QI 1 "register_operand" "r")
(match_operand:QI 2 "const_0_to_7_operand" "n"))
(match_operand:QI 3 "register_operand"
"0")))]
"optimize
&& !reload_completed
&& nonzero_bits (operands[1], VOIDmode) == 1"
...
This pattern is only correct when operands[1] is 0 or 1.
While such patterns seem to work, it's all quite wonky,
in particular since nonzero_bits() may forget about known
properties in later passes.
For the use case I have in mind, it is in order when the
pattern works until split1 which would transform it into
something else (and without nonzero_bits() in the insn
condition, asserting that the existence of the pattern
certifies the bit condition).
Is there a justification that such insn conditions may
be used and are supposed to work as expected?
Johann
