public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Jeff Law <law@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r14-4676] expr: don't clear SUBREG_PROMOTED_VAR_P flag for a promoted subreg [target/111466] Date: Tue, 17 Oct 2023 04:02:41 +0000 (GMT) [thread overview] Message-ID: <20231017040241.6EFC23858D33@sourceware.org> (raw) https://gcc.gnu.org/g:8eb9cdd142182aaa3ee39750924bc0a0491236c3 commit r14-4676-g8eb9cdd142182aaa3ee39750924bc0a0491236c3 Author: Vineet Gupta <vineetg@rivosinc.com> Date: Mon Oct 16 21:59:09 2023 -0600 expr: don't clear SUBREG_PROMOTED_VAR_P flag for a promoted subreg [target/111466] RISC-V suffers from extraneous sign extensions, despite/given the ABI guarantee that 32-bit quantities are sign-extended into 64-bit registers, meaning incoming SI function args need not be explicitly sign extended (so do SI return values as most ALU insns implicitly sign-extend too.) Existing REE doesn't seem to handle this well and there are various ideas floating around to smarten REE about it. RISC-V also seems to correctly implement middle-end hook PROMOTE_MODE etc. Another approach would be to prevent EXPAND from generating the sign_extend in the first place which this patch tries to do. The hunk being removed was introduced way back in 1994 as 5069803972 ("expand_expr, case CONVERT_EXPR .. clear the promotion flag") This survived full testsuite run for RISC-V rv64gc with surprisingly no fallouts: test results before/after are exactly same. | | # of unexpected case / # of unique unexpected case | | gcc | g++ | gfortran | | rv64imafdc_zba_zbb_zbs_zicond/| 264 / 87 | 5 / 2 | 72 / 12 | | lp64d/medlow Granted for something so old to have survived, there must be a valid reason. Unfortunately the original change didn't have additional commentary or a test case. That is not to say it can't/won't possibly break things on other arches/ABIs, hence the RFC for someone to scream that this is just bonkers, don't do this 🙂 I've explicitly CC'ed Jakub and Roger who have last touched subreg promoted notes in expr.cc for insight and/or screaming 😉 Thanks to Robin for narrowing this down in an amazing debugging session @ GNU Cauldron. ``` foo2: sext.w a6,a1 <-- this goes away beq a1,zero,.L4 li a5,0 li a0,0 .L3: addw a4,a2,a5 addw a5,a3,a5 addw a0,a4,a0 bltu a5,a6,.L3 ret .L4: li a0,0 ret ``` Signed-off-by: Vineet Gupta <vineetg@rivosinc.com> Co-developed-by: Robin Dapp <rdapp.gcc@gmail.com> PR target/111466 gcc/ * expr.cc (expand_expr_real_2): Do not clear SUBREG_PROMOTED_VAR_P. gcc/testsuite * gcc.target/riscv/pr111466.c: New test. Diff: --- gcc/expr.cc | 7 ------- gcc/testsuite/gcc.target/riscv/pr111466.c | 15 +++++++++++++++ 2 files changed, 15 insertions(+), 7 deletions(-) diff --git a/gcc/expr.cc b/gcc/expr.cc index 4220cbd9f8f0..8aed3fc6cbe9 100644 --- a/gcc/expr.cc +++ b/gcc/expr.cc @@ -9329,13 +9329,6 @@ expand_expr_real_2 (sepops ops, rtx target, machine_mode tmode, op0 = expand_expr (treeop0, target, VOIDmode, modifier); - /* If the signedness of the conversion differs and OP0 is - a promoted SUBREG, clear that indication since we now - have to do the proper extension. */ - if (TYPE_UNSIGNED (TREE_TYPE (treeop0)) != unsignedp - && GET_CODE (op0) == SUBREG) - SUBREG_PROMOTED_VAR_P (op0) = 0; - return REDUCE_BIT_FIELD (op0); } diff --git a/gcc/testsuite/gcc.target/riscv/pr111466.c b/gcc/testsuite/gcc.target/riscv/pr111466.c new file mode 100644 index 000000000000..007792466a51 --- /dev/null +++ b/gcc/testsuite/gcc.target/riscv/pr111466.c @@ -0,0 +1,15 @@ +/* Simplified varaint of gcc.target/riscv/zba-adduw.c. */ + +/* { dg-do compile } */ +/* { dg-options "-march=rv64gc_zba_zbs -mabi=lp64" } */ +/* { dg-skip-if "" { *-*-* } { "-O0" } } */ + +int foo2(int unused, int n, unsigned y, unsigned delta){ + int s = 0; + unsigned int x = 0; + for (;x<n;x +=delta) + s += x+y; + return s; +} + +/* { dg-final { scan-assembler "\msext\M" } } */
reply other threads:[~2023-10-17 4:02 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20231017040241.6EFC23858D33@sourceware.org \ --to=law@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.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: linkBe 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).