You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As noted, InstCombine currently transforms icmp of bools to logic ops.
I don't know the history of that decision, but it seems like a reasonable choice for IR because it is more natural to analyze boolean logic rather than comparisons of bools. This is despite the fact that the logic sequence may be 2 instructions instead of 1 compare.
If this is better inverted in x86 asm, then you have backend options:
Show that the icmp form is better for all targets and add a transform to DAGCombiner.
Show that the icmp form is better for >1 targets and add a transform using a TLI hook in DAGCombiner.
Show that the transform is always good for x86 and add a target-specific transform in X86ISelLowering.
There may be some complications here to deal with branches on merged conditions (see the TLI hook isJumpExpensive()).
Extended Description
The ABI dictates that bool be strictly 0 or 1. A bool value outside of 0 or 1 is UB
The compiler can optimize
A && !B1 then as
A > B`, which say under x86 becomes the macro fused op:AAndNotBAlt(bool, bool):
cmp dil, sil
jbe .LBB1_1
instead, the compiler generates:
https://gcc.godbolt.org/z/EWx63b4nz
AAndNotB(bool, bool):
test edi, edi
je .LBB0_2
test sil, sil
jne .LBB0_2
jmp True()
The text was updated successfully, but these errors were encountered: