If we have an atomic integer x we're not depending on, then we can emit if statements such as
if (atomic_fetch_add(x, 1) < 0)
// or add >= 0, or sub > 0, or sub <= 0, etc
{
// liveness of this depends on x's known value
}
Why? There's a fairly obscure O3 optimisation in LLVM's X86ISelLowering (combineSetCCAtomicArith)
that seems to rewrite conditional execution based on these sorts of atomic increments-decrements so that they instead just add/sub 1 locked and take the flags from that (with the operator revised to handle the fact we're checking on the other side of the action).
These sorts of things should probably live in the generators for the if statements, and filter on known value according to intended truthiness, and also check for UB.
I'm assuming here that x86 S and NS (signed/not signed) can appear if we compare <0 and >=0 respectively, but this might not be true.
If we have an atomic integer
xwe're not depending on, then we can emit if statements such asWhy? There's a fairly obscure O3 optimisation in LLVM's
X86ISelLowering(combineSetCCAtomicArith) that seems to rewrite conditional execution based on these sorts of atomic increments-decrements so that they instead just add/sub1locked and take the flags from that (with the operator revised to handle the fact we're checking on the other side of the action).These sorts of things should probably live in the generators for the if statements, and filter on known value according to intended truthiness, and also check for UB.
I'm assuming here that x86
SandNS(signed/not signed) can appear if we compare<0and>=0respectively, but this might not be true.