I think it's fair to describe RTL's representation of condition flags using MODE_CC as a little counter-intuitive. For example, the i386 backend represents the carry flag (in adc instructions) using RTL of the form "(ltu:SI (reg:CCC) (const_int 0))", where great care needs to be taken not to treat this like a normal RTX expression, after all LTU (less-than-unsigned) against const0_rtx would normally always be false. Hence, MODE_CC comparisons need to be treated with caution, and simplify_const_relational_operation returns early (to avoid problems) when GET_MODE_CLASS (GET_MODE (op0)) == MODE_CC.
However, consider the (currently) hypothetical situation, where the RTL optimizers determine that a previous instruction unconditionally sets or clears the carry flag, and this gets propagated by combine into the above expression, we'd end up with something that looks like (ltu:SI (const_int 1) (const_int 0)), which doesn't mean what it says. Fortunately, simplify_const_relational_operation is passed the original mode of the comparison (cmp_mode, the original mode of op0) which can be checked for MODE_CC, even when op0 is now VOIDmode (const_int) after the substitution. Defending against this is clearly the right thing to do. More controversially, rather than just abort simplification/optimization in this case, we can use the comparison operator to infer/select the semantics of the CC_MODE flag. Hopefully, whenever a backend uses LTU, it represents the (set) carry flag (and behaves like i386.md), in which case the result of the simplified expression is the first operand. [If there's no standardization of semantics across backends, then we should always just return 0; but then miss potential optimizations]. This patch has been tested on x86_64-pc-linux-gnu with make bootstrap and make -k check, both with and without --target_board=unix{-m32}, with no new failures, and in combination with a i386 backend patch (that introduces support for x86's stc and clc instructions) where it avoids failures. However, I'm submitting this middle-end piece independently, to confirm that maintainers/reviewers are happy with the approach, and also to check there are no issues on other platforms, before building upon this infrastructure. Thoughts? Ok for mainline? 2022-07-07 Roger Sayle <ro...@nextmovesoftware.com> gcc/ChangeLog * simplify-rtx.cc (simplify_const_relational_operation): Handle case where both operands of a MODE_CC comparison have been simplified to constant integers. Thanks in advance, Roger --
diff --git a/gcc/simplify-rtx.cc b/gcc/simplify-rtx.cc index fa20665..73ec5c7 100644 --- a/gcc/simplify-rtx.cc +++ b/gcc/simplify-rtx.cc @@ -6026,6 +6026,18 @@ simplify_const_relational_operation (enum rtx_code code, return 0; } + /* Handle MODE_CC comparisons that have been simplified to + constants. */ + if (GET_MODE_CLASS (mode) == MODE_CC + && op1 == const0_rtx + && CONST_INT_P (op0)) + { + /* LTU represents the carry flag. */ + if (code == LTU) + return op0 == const0_rtx ? const0_rtx : const_true_rtx; + return 0; + } + /* We can't simplify MODE_CC values since we don't know what the actual comparison is. */ if (GET_MODE_CLASS (GET_MODE (op0)) == MODE_CC)