From: Greg McGary <gkm@rivosinc.com>
To: Jeff Law <jeffreyalaw@gmail.com>,
Richard Biener <richard.guenther@gmail.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] combine: Don't optimize SIGN_EXTEND of MEM on WORD_REGISTER_OPERATIONS targets [PR113010]
Date: Wed, 7 Feb 2024 22:36:00 -0700 [thread overview]
Message-ID: <96135e2f-c6c2-4504-932c-ca64af966fa8@rivosinc.com> (raw)
In-Reply-To: <5c564b6d-b74e-4648-a4bd-cc70724863d2@gmail.com>
On 2/4/24 9:58 PM, Jeff Law wrote:
>
> On 2/2/24 15:48, Greg McGary wrote:
>>
>> input: (sign_extend:DI (mem/c:SI (symbol_ref:DI ("minus_1") [flags
>> 0x86] <var_decl 0x7ffff761cb40 minus_1>) [1 minus_1+0 S4 A32]))
>>
>> result: (subreg:DI (mem/c:SI (symbol_ref:DI ("minus_1") [flags 0x86]
>> <var_decl 0x7ffff761cb40 minus_1>) [1 minus_1+0 S4 A32]) 0)
>>
>> Later, the high part of the PSoM statically evaluates to 0, the code
>> to load and test is elided, and the incorrect alternative is emitted
>> unconditionally.
> So I think we need to know where that high part gets statically turned
> into a zero.
>
> I'm not happy with the sign_extend->subreg transformation as we
> generally want to avoid (subreg (mem)) for various reasons. So we'll
> probably want to do something like your patch as well. But let's
> chase down the static evaluation of the high part to zero first --
> that's clearly wrong given the defined semantics of (subreg (mem)) in
> the presence of LOAD_EXTEND_OP.
This prevents the buggy evaluation. What think ye?
diff --git a/gcc/combine.cc b/gcc/combine.cc
index 812553c091e..736206242e1 100644
--- a/gcc/combine.cc
+++ b/gcc/combine.cc
@@ -12550,9 +12550,15 @@ simplify_comparison (enum rtx_code code, rtx
*pop0, rtx *pop1)
}
/* If the inner mode is narrower and we are extracting the
low part,
- we can treat the SUBREG as if it were a ZERO_EXTEND. */
+ we can treat the SUBREG as if it were a ZERO_EXTEND ... */
if (paradoxical_subreg_p (op0))
- ;
+ {
+ /* ... except we can't treat as ZERO_EXTEND when a machine
+ automatically sign-extends loads. */
+ if (MEM_P (SUBREG_REG (op0)) && WORD_REGISTER_OPERATIONS
+ && load_extend_op (inner_mode) == SIGN_EXTEND)
+ break;
+ }
else if (subreg_lowpart_p (op0)
&& GET_MODE_CLASS (mode) == MODE_INT
&& is_int_mode (GET_MODE (SUBREG_REG (op0)),
&inner_mode)
next prev parent reply other threads:[~2024-02-08 5:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-16 22:19 Greg McGary
2024-01-17 6:44 ` Richard Biener
2024-01-18 3:53 ` Greg McGary
2024-01-18 16:24 ` Jeff Law
2024-02-02 1:24 ` Greg McGary
2024-02-02 5:24 ` Jeff Law
2024-02-02 22:48 ` Greg McGary
2024-02-05 4:58 ` Jeff Law
2024-02-08 5:36 ` Greg McGary [this message]
2024-01-17 7:56 ` YunQiang Su
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=96135e2f-c6c2-4504-932c-ca64af966fa8@rivosinc.com \
--to=gkm@rivosinc.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jeffreyalaw@gmail.com \
--cc=richard.guenther@gmail.com \
/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).