https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118360
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu.org
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
We expand from
_1 = a_3(D) & 1;
_7 = (long int) _1;
_2 = (signed short) _7;
_8 = _2 w* 8;
_9 = b_4(D) ^ _8;
but it's not the bit test that becomes a shift but the widening multiplication.
So the issue is that we if-converted this conditional XOR of 8 to
an unconditional XOR of (a&1) * 8. That's
/* (zero_one != 0) ? z <op> y : y -> ((typeof(y))zero_one * z) <op> y */
(for op (bit_xor bit_ior plus)
(simplify
(cond (ne zero_one_valued_p@0
integer_zerop)
(op:c @2 @1)
@1)
(if (INTEGRAL_TYPE_P (type)
&& TYPE_PRECISION (type) > 1
&& (INTEGRAL_TYPE_P (TREE_TYPE (@0))))
(op (mult (convert:type @0) @2) @1))))
which assumes that setcc plus a mutliplication is cheaper than a jump.
Similar to that other PR which shows aggressive if-conversion being bad
for modes > word_mode.
In this case it's even more difficult to argue that we can do the reverse
transform at RTL expansion time.
But sure, the user could have written b ^= (a&1) * 8; himself which would
have been equally bad for AVR and not unlikely for general code (but
probably unlikely for code targeting specifically AVR).
Possibly the late if-conversion which allows more complex replacements
should disable itself for modes a new target hook asks for (defaulting
to modes > word_mode eventually).
