From: Philipp Tomsich <philipp.tomsich@vrull.eu>
To: gcc-patches@gcc.gnu.org
Cc: Andrew Pinski <pinskia@gmail.com>,
Kito Cheng <kito.cheng@gmail.com>,
Palmer Dabbelt <palmer@rivosinc.com>,
Vineet Gupta <vineetg@rivosinc.com>,
Philipp Tomsich <philipp.tomsich@vrull.eu>
Subject: [PATCH v2] RISC-V: bitmanip: improve constant-loading for (1ULL << 31) in DImode
Date: Sun, 29 May 2022 23:51:27 +0200 [thread overview]
Message-ID: <20220529215127.482180-1-philipp.tomsich@vrull.eu> (raw)
The SINGLE_BIT_MASK_OPERAND() is overly restrictive, triggering for
bits above 31 only (to side-step any issues with the negative SImode
value 0x80000000/(-1ull << 31)/(1 << 31)). This moves the special
handling of this SImode value (i.e. the check for (-1ull << 31) to
riscv.cc and relaxes the SINGLE_BIT_MASK_OPERAND() test.
With this, the code-generation for loading (1ULL << 31) from:
li a0,1
slli a0,a0,31
to:
bseti a0,zero,31
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_build_integer_1): Rewrite value as
(-1 << 31) for the single-bit case, when operating on (1 << 31)
in SImode.
* gcc/config/riscv/riscv.h (SINGLE_BIT_MASK_OPERAND): Allow for
any single-bit value, moving the special case for (1 << 31) to
riscv_build_integer_1 (in riscv.c).
Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu>
---
Changes in v2:
- Use HOST_WIDE_INT_1U/HOST_WIDE_INT_M1U instead of constants.
- Fix some typos in the comment above the rewrite of the value.
- Update the comment to clarify that we expect a LUI to be emitted for
the SImode case (i.e. sign-extended for RV64) of (1 << 31).
gcc/config/riscv/riscv.cc | 9 +++++++++
gcc/config/riscv/riscv.h | 11 ++++-------
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index f83dc796d88..2e83ca07394 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -420,6 +420,15 @@ riscv_build_integer_1 (struct riscv_integer_op codes[RISCV_MAX_INTEGER_OPS],
/* Simply BSETI. */
codes[0].code = UNKNOWN;
codes[0].value = value;
+
+ /* RISC-V sign-extends all 32bit values that live in a 32bit
+ register. To avoid paradoxes, we thus need to use the
+ sign-extended (negative) representation (-1 << 31) for the
+ value, if we want to build (1 << 31) in SImode. This will
+ then expand to an LUI instruction. */
+ if (mode == SImode && value == (HOST_WIDE_INT_1U << 31))
+ codes[0].value = (HOST_WIDE_INT_M1U << 31);
+
return 1;
}
diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
index 5083a1c24b0..6f7f4d3fbdc 100644
--- a/gcc/config/riscv/riscv.h
+++ b/gcc/config/riscv/riscv.h
@@ -528,13 +528,10 @@ enum reg_class
(((VALUE) | ((1UL<<31) - IMM_REACH)) == ((1UL<<31) - IMM_REACH) \
|| ((VALUE) | ((1UL<<31) - IMM_REACH)) + IMM_REACH == 0)
-/* If this is a single bit mask, then we can load it with bseti. But this
- is not useful for any of the low 31 bits because we can use addi or lui
- to load them. It is wrong for loading SImode 0x80000000 on rv64 because it
- needs to be sign-extended. So we restrict this to the upper 32-bits
- only. */
-#define SINGLE_BIT_MASK_OPERAND(VALUE) \
- (pow2p_hwi (VALUE) && (ctz_hwi (VALUE) >= 32))
+/* If this is a single bit mask, then we can load it with bseti. Special
+ handling of SImode 0x80000000 on RV64 is done in riscv_build_integer_1. */
+#define SINGLE_BIT_MASK_OPERAND(VALUE) \
+ (pow2p_hwi (VALUE))
/* Stack layout; function entry, exit and calling. */
--
2.34.1
next reply other threads:[~2022-05-29 21:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-29 21:51 Philipp Tomsich [this message]
2022-06-02 13:17 ` Kito Cheng
2022-06-02 19:23 ` Philipp Tomsich
2022-06-02 19:24 ` Philipp Tomsich
2022-06-07 10:27 ` Kito Cheng
2022-06-14 11:18 ` Philipp Tomsich
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=20220529215127.482180-1-philipp.tomsich@vrull.eu \
--to=philipp.tomsich@vrull.eu \
--cc=gcc-patches@gcc.gnu.org \
--cc=kito.cheng@gmail.com \
--cc=palmer@rivosinc.com \
--cc=pinskia@gmail.com \
--cc=vineetg@rivosinc.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).