diff mbox series

[5/7] RISC-V: Recognize bexti in negated if-conversion

Message ID 20221112212943.3068249-6-philipp.tomsich@vrull.eu
State Accepted
Headers
Series RISC-V: Backend support for XVentanaCondOps/ZiCondops |

Checks

Context Check Description
snail/gcc-patch-check success Github commit url

Commit Message

Philipp Tomsich Nov. 12, 2022, 9:29 p.m. UTC 
  While the positive case "if ((bits >> SHAMT) & 1)" for SHAMT 0..10 can
trigger conversion into efficient branchless sequences
  - with Zbs (bexti + neg + and)
  - with XVentanaCondOps (andi + vt.maskc)
the inverted/negated case results in
  andi a5,a0,1024
  seqz a5,a5
  neg a5,a5
  and a5,a5,a1
due to how the sequence presents to the combine pass.

This adds an additional splitter to reassociate the polarity reversed
case into bexti + addi, if Zbs is present.

Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu>

gcc/ChangeLog:

    * config/riscv/xventanacondops.md: Add split to reassociate
      "andi + seqz + neg" into "bexti + addi".

---

 gcc/config/riscv/xventanacondops.md | 9 +++++++++
 1 file changed, 9 insertions(+)

Comments

Jeff Law Nov. 17, 2022, 11:17 p.m. UTC | #1 
On 11/12/22 14:29, Philipp Tomsich wrote:
> While the positive case "if ((bits >> SHAMT) & 1)" for SHAMT 0..10 can
> trigger conversion into efficient branchless sequences
>    - with Zbs (bexti + neg + and)
>    - with XVentanaCondOps (andi + vt.maskc)
> the inverted/negated case results in
>    andi a5,a0,1024
>    seqz a5,a5
>    neg a5,a5
>    and a5,a5,a1
> due to how the sequence presents to the combine pass.
>
> This adds an additional splitter to reassociate the polarity reversed
> case into bexti + addi, if Zbs is present.
>
> Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu>
>
> gcc/ChangeLog:
>
>      * config/riscv/xventanacondops.md: Add split to reassociate
>        "andi + seqz + neg" into "bexti + addi".

OK once we've cleared the non-technical hurdles to committing vendor 
specific extensions.


Seeing the number of re association splitters that have been submitted 
and the fact that there's been a fair amount of commonality makes me 
wonder if we should instead be beefing up the generic split point code 
in combine.  Though IIRC that code may be strictly splitting without 
reassociation or rewriting..  Hmm, anyway, worth keeping in mind that we 
have some generic code to try and find good points to break down a 
complex insn into components that might be recognizable.


jeff
diff mbox series

Patch

diff --git a/gcc/config/riscv/xventanacondops.md b/gcc/config/riscv/xventanacondops.md
index 3e9d5833a4b..22b4b7d103a 100644
--- a/gcc/config/riscv/xventanacondops.md
+++ b/gcc/config/riscv/xventanacondops.md
@@ -119,3 +119,12 @@ 
   operands[2] = GEN_INT(1 << UINTVAL(operands[2]));
 })
 
+(define_split
+  [(set (match_operand:X 0 "register_operand")
+	(neg:X (eq:X (zero_extract:X (match_operand:X 1 "register_operand")
+				     (const_int 1)
+				     (match_operand 2 "immediate_operand"))
+		     (const_int 0))))]
+  "!TARGET_XVENTANACONDOPS && TARGET_ZBS"
+  [(set (match_dup 0) (zero_extract:X (match_dup 1) (const_int 1) (match_dup 2)))
+   (set (match_dup 0) (plus:X (match_dup 0) (const_int -1)))])