From: "Roger Sayle" <roger@nextmovesoftware.com>
To: <gcc-patches@gcc.gnu.org>
Cc: "'Segher Boessenkool'" <segher@kernel.crashing.org>
Subject: [PATCH] Be careful with MODE_CC in simplify_const_relational_operation.
Date: Thu, 7 Jul 2022 22:08:04 +0100 [thread overview]
Message-ID: <003601d89245$a86f8830$f94e9890$@nextmovesoftware.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2567 bytes --]
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 <roger@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
--
[-- Attachment #2: patchcf.txt --]
[-- Type: text/plain, Size: 752 bytes --]
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)
next reply other threads:[~2022-07-07 21:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-07 21:08 Roger Sayle [this message]
2022-07-07 22:38 ` Segher Boessenkool
2022-07-26 12:13 ` [PATCH] Add new target hook: simplify_modecc_const Roger Sayle
2022-07-26 17:44 ` Segher Boessenkool
2022-07-26 21:04 ` Roger Sayle
2022-07-26 22:11 ` Segher Boessenkool
2022-07-27 7:51 ` Roger Sayle
2022-07-27 18:37 ` Segher Boessenkool
2022-07-28 12:39 ` Richard Sandiford
2022-10-10 15:50 ` H.J. Lu
2022-10-14 20:31 ` Jeff Law
2022-10-14 21:05 ` H.J. Lu
2022-10-14 20:26 ` Jeff Law
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='003601d89245$a86f8830$f94e9890$@nextmovesoftware.com' \
--to=roger@nextmovesoftware.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=segher@kernel.crashing.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).