RISC-V: Use binvi to cover more immediates than with xori alone
Checks
Commit Message
Sequences of the form "a ^ C" with C being the positive half of a
signed immediate's range with one extra bit set in addtion are mapped
to xori and one binvi to avoid using a temporary (and a multi-insn
sequence to load C into that temporary).
gcc/ChangeLog:
* config/riscv/bitmanip.md (*binvi<mode>_extrabit): New pattern.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/zbs-binvi.c: New test.
Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu>
---
- Depends on a predicate posted in "RISC-V: Optimize branches testing
a bit-range or a shifted immediate". Depending on the order of
applying these, I'll take care to pull that part out of the other
patch if needed.
gcc/config/riscv/bitmanip.md | 19 +++++++++++++++++++
gcc/testsuite/gcc.target/riscv/zbs-binvi.c | 22 ++++++++++++++++++++++
2 files changed, 41 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/riscv/zbs-binvi.c
Comments
On 11/10/22 14:35, Philipp Tomsich wrote:
> Sequences of the form "a ^ C" with C being the positive half of a
> signed immediate's range with one extra bit set in addtion are mapped
> to xori and one binvi to avoid using a temporary (and a multi-insn
> sequence to load C into that temporary).
>
> gcc/ChangeLog:
>
> * config/riscv/bitmanip.md (*binvi<mode>_extrabit): New pattern.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/zbs-binvi.c: New test.
Could this have been potentially done by extending the ior pattern with
a code iterator that covered IOR/XOR?
Not a big deal, but if it'd work, consider to avoid the pattern duplication.
OK.
jeff
On Wed, 16 Nov 2022 at 04:45, Jeff Law <jeffreyalaw@gmail.com> wrote:
>
>
> On 11/10/22 14:35, Philipp Tomsich wrote:
> > Sequences of the form "a ^ C" with C being the positive half of a
> > signed immediate's range with one extra bit set in addtion are mapped
> > to xori and one binvi to avoid using a temporary (and a multi-insn
> > sequence to load C into that temporary).
> >
> > gcc/ChangeLog:
> >
> > * config/riscv/bitmanip.md (*binvi<mode>_extrabit): New pattern.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/riscv/zbs-binvi.c: New test.
>
> Could this have been potentially done by extending the ior pattern with
> a code iterator that covered IOR/XOR?
>
>
> Not a big deal, but if it'd work, consider to avoid the pattern duplication.
We'll rework to using an iterator and a mapping in v2 for the
following cases, folding into a single patch:
- X | C => bseti
- X & ~C => bclri
- X ^ C => binvi
Thanks.
Philipp.
@@ -577,6 +577,25 @@
"binvi\t%0,%1,%S2"
[(set_attr "type" "bitmanip")])
+; Catch those cases where we can use a binvi + xori or binvi + binvi
+; instead of a lui + addi + xor sequence.
+(define_insn_and_split "*binvi<mode>_extrabit"
+ [(set (match_operand:X 0 "register_operand" "=r")
+ (xor:X (match_operand:X 1 "register_operand" "r")
+ (match_operand:X 2 "uimm_extra_bit_operand" "i")))]
+ "TARGET_ZBS"
+ "#"
+ "&& reload_completed"
+ [(set (match_dup 0) (xor:X (match_dup 1) (match_dup 3)))
+ (set (match_dup 0) (xor:X (match_dup 0) (match_dup 4)))]
+{
+ unsigned HOST_WIDE_INT bits = UINTVAL (operands[2]);
+ unsigned HOST_WIDE_INT topbit = HOST_WIDE_INT_1U << floor_log2 (bits);
+
+ operands[3] = GEN_INT (bits &~ topbit);
+ operands[4] = GEN_INT (topbit);
+})
+
(define_insn "*bext<mode>"
[(set (match_operand:X 0 "register_operand" "=r")
(zero_extract:X (match_operand:X 1 "register_operand" "r")
new file mode 100644
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gc_zbs -mabi=lp64" } */
+/* { dg-skip-if "" { *-*-* } { "-O0" "-Og" } } */
+
+long long f3(long long a)
+{
+ return a ^ 0x1100;
+}
+
+long long f4 (long long a)
+{
+ return a ^ 0x80000000000000ffull;
+}
+
+long long f5 (long long a)
+{
+ return a ^ 0x8000001000000000ull;
+}
+
+/* { dg-final { scan-assembler-times "binvi\t" 4 } } */
+/* { dg-final { scan-assembler-times "xori\t" 2 } } */
+