Re: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

[钟居哲]

Sure. 

We can come back to see in the future which doesn't change this codegen quality:
https://godbolt.org/z/d6rWPTWeW 



juzhe.zh...@rivai.ai
 
From: Jeff Law
Date: 2023-07-08 05:11
To: juzhe.zh...@rivai.ai; Robin Dapp
CC: gcc-patches; kito.cheng; Kito.cheng; palmer; palmer
Subject: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering
 
 
On 7/3/23 02:42, juzhe.zh...@rivai.ai wrote:
> We failed to merge it since it's been rejected.
> https://patchwork.sourceware.org/project/gcc/patch/20230628041512.188243-1-juzhe.zh...@rivai.ai/
>  
> <https://patchwork.sourceware.org/project/gcc/patch/20230628041512.188243-1-juzhe.zh...@rivai.ai/>
That was based on the belief that the bridging patterns should not be 
needed.  With the decision to move forward with those patterns this 
patch should be reconsidered.
 
jeff
 

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

[Jeff Law via Gcc-patches]

On 7/3/23 02:42, juzhe.zh...@rivai.ai wrote:

We failed to merge it since it's been rejected.
https://patchwork.sourceware.org/project/gcc/patch/20230628041512.188243-1-juzhe.zh...@rivai.ai/
 

That was based on the belief that the bridging patterns should not be 
needed.  With the decision to move forward with those patterns this 
patch should be reconsidered.


jeff

Re: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

[Lehua Ding]

Commited, thanks Robin and Jeff.


-- Original --
From:   
 "juzhe.zh...@rivai.ai" 
   

Re: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

[juzhe.zh...@rivai.ai]

OK. Thanks. Will commit with your cleanup patch.



juzhe.zh...@rivai.ai
 
From: Robin Dapp
Date: 2023-07-03 16:49
To: juzhe.zh...@rivai.ai
CC: rdapp.gcc; jeffreyalaw; gcc-patches; kito.cheng; Kito.cheng; palmer; palmer
Subject: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering
On 7/3/23 10:45, juzhe.zh...@rivai.ai wrote:
> We can apply it but not sure why the patchwork shows it's rejected.
 
I believe it also failed for me locally because the order of
patterns in autovec-opt.md was somehow different.  The one attached
worked for me though after some minor merge adjustments on my branch.
 
Regards
Robin
 
From 29b12a473a31b2caa64fa2d1d97920a460ced0a2 Mon Sep 17 00:00:00 2001
From: Juzhe-Zhong 
Date: Wed, 28 Jun 2023 12:15:12 +0800
Subject: [PATCH] RISC-V: Support vfwmul.vv combine lowering
 
Consider the following complicate case:
#define TEST_TYPE(TYPE1, TYPE2)\
  __attribute__ ((noipa)) void vwadd_##TYPE1_##TYPE2 ( \
TYPE1 *__restrict dst, TYPE1 *__restrict dst2, TYPE1 *__restrict dst3, \
TYPE1 *__restrict dst4, TYPE2 *__restrict a, TYPE2 *__restrict b,  \
TYPE2 *__restrict a2, TYPE2 *__restrict b2, int n) \
  {\
for (int i = 0; i < n; i++)\
  {\
dst[i] = (TYPE1) a[i] * (TYPE1) b[i];  \
dst2[i] = (TYPE1) a2[i] * (TYPE1) b[i];\
dst3[i] = (TYPE1) a2[i] * (TYPE1) a[i];\
dst4[i] = (TYPE1) a[i] * (TYPE1) b2[i];\
  }\
  }
 
TEST_TYPE (double, float)
 
Such complicate situation, Combine PASS can not combine extension of both 
operands on the fly.
So the combine PASS will first try to combine one of the combine extension, and 
then combine
the other. The combine flow is as follows:
 
Original IR:
(set (reg 0) (float_extend: (reg 1))
(set (reg 3) (float_extend: (reg 2))
(set (reg 4) (mult: (reg 0) (reg 3))
 
First step of combine:
(set (reg 3) (float_extend: (reg 2))
(set (reg 4) (mult: (float_extend: (reg 1) (reg 3))
 
Second step of combine:
(set (reg 4) (mult: (float_extend: (reg 1) (float_extend: (reg 2))
 
So, to enhance the combine optimization, we add a "pseudo vwfmul.wv" RTL 
pattern in autovec-opt.md
which is (set (reg 0) (mult (float_extend (reg 1) (reg 2.
 
gcc/ChangeLog:
 
* config/riscv/autovec-opt.md 
(@pred_single_widen_mul): Change "@" into "*" in pattern 
name which simplifies build files.
(*pred_single_widen_mul): Ditto.
(*pred_single_widen_mul): New pattern.
 
gcc/testsuite/ChangeLog:
 
* gcc.target/riscv/rvv/autovec/widen/widen-3.c: Add floating-point.
* gcc.target/riscv/rvv/autovec/widen/widen-7.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen-complicate-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen_run-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen_run-7.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-3.c: New test.
* gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-7.c: New test.
---
gcc/config/riscv/autovec-opt.md   | 39 +++
.../riscv/rvv/autovec/widen/widen-3.c |  7 +++-
.../riscv/rvv/autovec/widen/widen-7.c |  7 +++-
.../rvv/autovec/widen/widen-complicate-3.c|  7 +++-
.../riscv/rvv/autovec/widen/widen_run-3.c |  5 ++-
.../riscv/rvv/autovec/widen/widen_run-7.c |  5 ++-
.../rvv/autovec/widen/widen_run_zvfh-3.c  | 28 +
.../rvv/autovec/widen/widen_run_zvfh-7.c  | 28 +
8 files changed, 116 insertions(+), 10 deletions(-)
create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-3.c
create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-7.c
 
diff --git a/gcc/config/riscv/autovec-opt.md b/gcc/config/riscv/autovec-opt.md
index fd9cd27f50a..99b609a99d9 100644
--- a/gcc/config/riscv/autovec-opt.md
+++ b/gcc/config/riscv/autovec-opt.md
@@ -406,6 +406,45 @@ (define_insn "*pred_extract_first_sextsi"
   [(set_attr "type" "vimovvx")
(set_attr "mode" "")])
+;; We don't have vfwmul.wv instruction like vfwadd.wv in RVV.
+;; This pattern is an intermediate RTL IR as a pseudo vfwmul.wv to enhance
+;; optimization of instructions combine.
+(define_insn_and_split "*pred_single_widen_mul"
+  [(set (match_operand:VWEXTF 0 "register_operand"  "=,  
")
+   (if_then_else:VWEXTF
+ (unspec:
+   [(match_operand: 1 "vector_mask_operand"   
"vmWc1,vmWc1&qu

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

[Robin Dapp via Gcc-patches]

On 7/3/23 10:45, juzhe.zh...@rivai.ai wrote:
> We can apply it but not sure why the patchwork shows it's rejected.

I believe it also failed for me locally because the order of
patterns in autovec-opt.md was somehow different.  The one attached
worked for me though after some minor merge adjustments on my branch.

Regards
 Robin

>From 29b12a473a31b2caa64fa2d1d97920a460ced0a2 Mon Sep 17 00:00:00 2001
From: Juzhe-Zhong 
Date: Wed, 28 Jun 2023 12:15:12 +0800
Subject: [PATCH] RISC-V: Support vfwmul.vv combine lowering

Consider the following complicate case:
#define TEST_TYPE(TYPE1, TYPE2)\
  __attribute__ ((noipa)) void vwadd_##TYPE1_##TYPE2 ( \
TYPE1 *__restrict dst, TYPE1 *__restrict dst2, TYPE1 *__restrict dst3, \
TYPE1 *__restrict dst4, TYPE2 *__restrict a, TYPE2 *__restrict b,  \
TYPE2 *__restrict a2, TYPE2 *__restrict b2, int n) \
  {\
for (int i = 0; i < n; i++)\
  {\
dst[i] = (TYPE1) a[i] * (TYPE1) b[i];  \
dst2[i] = (TYPE1) a2[i] * (TYPE1) b[i];\
dst3[i] = (TYPE1) a2[i] * (TYPE1) a[i];\
dst4[i] = (TYPE1) a[i] * (TYPE1) b2[i];\
  }\
  }

TEST_TYPE (double, float)

Such complicate situation, Combine PASS can not combine extension of both 
operands on the fly.
So the combine PASS will first try to combine one of the combine extension, and 
then combine
the other. The combine flow is as follows:

Original IR:
(set (reg 0) (float_extend: (reg 1))
(set (reg 3) (float_extend: (reg 2))
(set (reg 4) (mult: (reg 0) (reg 3))

First step of combine:
(set (reg 3) (float_extend: (reg 2))
(set (reg 4) (mult: (float_extend: (reg 1) (reg 3))

Second step of combine:
(set (reg 4) (mult: (float_extend: (reg 1) (float_extend: (reg 2))

So, to enhance the combine optimization, we add a "pseudo vwfmul.wv" RTL 
pattern in autovec-opt.md
which is (set (reg 0) (mult (float_extend (reg 1) (reg 2.

gcc/ChangeLog:

* config/riscv/autovec-opt.md 
(@pred_single_widen_mul): Change "@" into "*" in pattern 
name which simplifies build files.
(*pred_single_widen_mul): Ditto.
(*pred_single_widen_mul): New pattern.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/widen/widen-3.c: Add floating-point.
* gcc.target/riscv/rvv/autovec/widen/widen-7.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen-complicate-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen_run-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen_run-7.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-3.c: New test.
* gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-7.c: New test.
---
 gcc/config/riscv/autovec-opt.md   | 39 +++
 .../riscv/rvv/autovec/widen/widen-3.c |  7 +++-
 .../riscv/rvv/autovec/widen/widen-7.c |  7 +++-
 .../rvv/autovec/widen/widen-complicate-3.c|  7 +++-
 .../riscv/rvv/autovec/widen/widen_run-3.c |  5 ++-
 .../riscv/rvv/autovec/widen/widen_run-7.c |  5 ++-
 .../rvv/autovec/widen/widen_run_zvfh-3.c  | 28 +
 .../rvv/autovec/widen/widen_run_zvfh-7.c  | 28 +
 8 files changed, 116 insertions(+), 10 deletions(-)
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-3.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-7.c

diff --git a/gcc/config/riscv/autovec-opt.md b/gcc/config/riscv/autovec-opt.md
index fd9cd27f50a..99b609a99d9 100644
--- a/gcc/config/riscv/autovec-opt.md
+++ b/gcc/config/riscv/autovec-opt.md
@@ -406,6 +406,45 @@ (define_insn "*pred_extract_first_sextsi"
   [(set_attr "type" "vimovvx")
(set_attr "mode" "")])
 
+;; We don't have vfwmul.wv instruction like vfwadd.wv in RVV.
+;; This pattern is an intermediate RTL IR as a pseudo vfwmul.wv to enhance
+;; optimization of instructions combine.
+(define_insn_and_split "*pred_single_widen_mul"
+  [(set (match_operand:VWEXTF 0 "register_operand"  "=,  
")
+   (if_then_else:VWEXTF
+ (unspec:
+   [(match_operand: 1 "vector_mask_operand"   
"vmWc1,vmWc1")
+(match_operand 5 "vector_length_operand"  "   rK,   
rK")
+(match_operand 6 "const_int_operand"  "i,
i")
+(match_operand 7 "const_int_operand"  "i,
i")
+(match_operand 8 "const_int_operand"  "i,
i")
+(match_operand 9 "const_int_operand" 

Re: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

[juzhe.zh...@rivai.ai]

We can apply it but not sure why the patchwork shows it's rejected.



juzhe.zh...@rivai.ai
 
From: Robin Dapp
Date: 2023-07-03 16:44
To: juzhe.zh...@rivai.ai
CC: rdapp.gcc; jeffreyalaw; gcc-patches; kito.cheng; Kito.cheng; palmer; palmer
Subject: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering
> We failed to merge it since it's been rejected.
> https://patchwork.sourceware.org/project/gcc/patch/20230628041512.188243-1-juzhe.zh...@rivai.ai/
>  
> <https://patchwork.sourceware.org/project/gcc/patch/20230628041512.188243-1-juzhe.zh...@rivai.ai/>
>  
 
Err, who rejected?  Or is this about the patch itself
that doesn't apply cleanly anymore?
 
Regards
Robin
 
 

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

[Robin Dapp via Gcc-patches]

> We failed to merge it since it's been rejected.
> https://patchwork.sourceware.org/project/gcc/patch/20230628041512.188243-1-juzhe.zh...@rivai.ai/
>  
> 
>  

Err, who rejected?  Or is this about the patch itself
that doesn't apply cleanly anymore?

Regards
 Robin

Re: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

[juzhe.zh...@rivai.ai]

We failed to merge it since it's been rejected.
https://patchwork.sourceware.org/project/gcc/patch/20230628041512.188243-1-juzhe.zh...@rivai.ai/
 




juzhe.zh...@rivai.ai
 
From: Robin Dapp
Date: 2023-07-03 15:49
To: juzhe.zhong
CC: rdapp.gcc; Jeff Law; gcc-patches; kito.cheng; kito.cheng; palmer; palmer
Subject: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering
> Thanks. Ok for trunk？
 
OK from my side.  As agreed with Jeff, I'm going to get back to this
and revisit/change if needed in the future.
 
Regards
Robin
 

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

[Robin Dapp via Gcc-patches]

> Thanks. Ok for trunk？

OK from my side.  As agreed with Jeff, I'm going to get back to this
and revisit/change if needed in the future.

Regards
 Robin

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

[Robin Dapp via Gcc-patches]

> There has to be some kind of mismatch between the patch or testcase
> or what we're looking at to judge success.

Yeah I think the initially posted example was misleading because it
contained an already working example.

> While I really don't see the need to have the bridge pattern, I'm
> still willing to believe that I've missed something, which is why I
> wanted to dive into it myself.  For example, we have heuristics to
> avoid trying too many 4->n combine patterns and we might be tripping
> over that or who knows what.
> 
> So my suggestion is that if both of you are getting the desired code,
> then Robin handle the review side of the two patches that introduce
> the helper patterns.

I went over both patches again and given the context they seem
reasonable to me.  I'd propose go with both of them for now and - in
the meanwhile - I'm going to  brush up on my combine knowledge some
time in the next weeks and get back to this then, hopefully with a
better explanation than my last one.

Regards
 Robin

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

[Jeff Law via Gcc-patches]

On 6/30/23 04:14, Robin Dapp wrote:

The explicit conversions I see are because we need the output of the
conversion in multiple vfmul instructions.  That won't be helped by
the patch you've proposed.


FWIW on my local branch and the patch applied I see that the vfwmuls
are being generated (all of the vfmuls are replaced).


It'll need to be a define_insn_and_split as its a 3->3 splitter.  The
split will emit the two extensions and the widening multiply as 3
distinct insns.


I tried this and while it worked for the first vfwmul the subsequent
ones are not being combined/optimized.  Now I'm not a combine expert
at all but it looks as if the source float_extends are being deleted

  deferring deletion of insn with uid = 39.
  deferring deletion of insn with uid = 37.

with that pattern successfully matched, while they are only "rescanned"
with the synthetic "single widen" one.  Them being deleted (or rather
absorbed by the vfwmul) no further combination is possible (until after
split?)

This seems to be a fundamental difference between the two approaches.
Maybe the "double widen" pattern can be adjusted to also handle this
or I did something wrong when writing the splitter?

With the "single widen" pattern, however, it works more or less
naturally therefore I'd still suggest going for it.
I'd hoped to have time to revisit all of this today, but I'm quickly 
running out of time.


There has to be some kind of mismatch between the patch or testcase or 
what we're looking at to judge success.


Monday and Tuesday are holidays in the US.  Naturally that means the 
rest of my work week is going to be busier than normal.  I don't want to 
hold things up unnecessarily.


While I really don't see the need to have the bridge pattern, I'm still 
willing to believe that I've missed something, which is why I wanted to 
dive into it myself.  For example, we have heuristics to avoid trying 
too many 4->n combine patterns and we might be tripping over that or who 
knows what.


So my suggestion is that if both of you are getting the desired code, 
then Robin handle the review side of the two patches that introduce the 
helper patterns.


Jeff

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

[Robin Dapp via Gcc-patches]

> The explicit conversions I see are because we need the output of the
> conversion in multiple vfmul instructions.  That won't be helped by
> the patch you've proposed.

FWIW on my local branch and the patch applied I see that the vfwmuls
are being generated (all of the vfmuls are replaced).

> It'll need to be a define_insn_and_split as its a 3->3 splitter.  The
> split will emit the two extensions and the widening multiply as 3
> distinct insns.

I tried this and while it worked for the first vfwmul the subsequent
ones are not being combined/optimized.  Now I'm not a combine expert
at all but it looks as if the source float_extends are being deleted

 deferring deletion of insn with uid = 39.
 deferring deletion of insn with uid = 37.

with that pattern successfully matched, while they are only "rescanned"
with the synthetic "single widen" one.  Them being deleted (or rather
absorbed by the vfwmul) no further combination is possible (until after
split?)

This seems to be a fundamental difference between the two approaches.
Maybe the "double widen" pattern can be adjusted to also handle this
or I did something wrong when writing the splitter?

With the "single widen" pattern, however, it works more or less
naturally therefore I'd still suggest going for it.

Regards
 Robin

Re: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

[juzhe.zh...@rivai.ai]

Hi, Jeff.

That's odd. I think maybe you should first clean up your environment ?
Or you didn't build up the toolchain correctly with this patch?

Compile option: --param=riscv-autovec-preference=scalable -O3 -ffast-math
Before this patch:
https://godbolt.org/z/Y5d44WMqs 

fail.s:

lw t5,0(sp)
ble t5,zero,.L5
.L3:
vsetvli t1,t5,e32,mf2,ta,ma
vle32.v v2,0(a4)
vle32.v v1,0(a5)
vsetvli t0,zero,e32,mf2,ta,ma
vfwcvt.f.f.v v3,v2
vfwcvt.f.f.v v2,v1
vsetvli zero,t1,e32,mf2,ta,ma
vle32.v v5,0(a6)
vle32.v v4,0(a7)
vsetvli t0,zero,e32,mf2,ta,ma
vfwcvt.f.f.v v1,v5
vsetvli zero,zero,e64,m1,ta,ma
vfmul.vv v5,v2,v3
vfmul.vv v2,v1,v2
vsetvli zero,t1,e64,m1,ta,ma
vse64.v v2,0(a1)
vse64.v v5,0(a0)
vsetvli t6,zero,e64,m1,ta,ma
vfmul.vv v1,v1,v3
vsetvli zero,zero,e32,mf2,ta,ma
vfwcvt.f.f.v v2,v4
vsetvli zero,t1,e64,m1,ta,ma
vse64.v v1,0(a2)
vsetvli t6,zero,e64,m1,ta,ma
slli t4,t1,2
slli t3,t1,3
vfmul.vv v1,v2,v3
sub t5,t5,t1
vsetvli zero,t1,e64,m1,ta,ma
vse64.v v1,0(a3)
add a4,a4,t4
add a5,a5,t4
add a0,a0,t3
add a6,a6,t4
add a1,a1,t3
add a2,a2,t3
add a7,a7,t4
add a3,a3,t3
bne t5,zero,.L3
.L5:
ret

After this patch:
pass.s:

lw t5,0(sp)
ble t5,zero,.L5
.L3:
vsetvli t1,t5,e32,mf2,ta,ma
vle32.v v1,0(a4)
vle32.v v3,0(a5)
vle32.v v2,0(a6)
vle32.v v4,0(a7)
vsetvli t6,zero,e32,mf2,ta,ma
vfwmul.vv v5,v3,v2
vfwmul.vv v6,v1,v3
vsetvli zero,t1,e64,m1,ta,ma
vse64.v v6,0(a0)
vse64.v v5,0(a1)
vsetvli t6,zero,e32,mf2,ta,ma
slli t4,t1,2
slli t3,t1,3
vfwmul.vv v3,v2,v1
sub t5,t5,t1
vfwmul.vv v2,v1,v4
vsetvli zero,t1,e64,m1,ta,ma
vse64.v v3,0(a2)
vse64.v v2,0(a3)
add a4,a4,t4
add a5,a5,t4
add a0,a0,t3
add a6,a6,t4
add a1,a1,t3
add a2,a2,t3
add a7,a7,t4
add a3,a3,t3
bne t5,zero,.L3
.L5:
ret

It's very obvious the codegen with this patch is perfect.

I have attached the .S in this patch.

I am not claiming that this patch solution is the only solution.

I am welcome you can provide another solution as long as you can make this 
codegen become the perfect codegen that this patch achieved.

I think maybe you should make sure you are using the correct toolchain that 
built with patch.

Thanks.


juzhe.zh...@rivai.ai
 
From: Jeff Law
Date: 2023-06-30 07:48
To: juzhe.zhong
CC: gcc-patches; kito.cheng; kito.cheng; palmer; palmer; rdapp.gcc
Subject: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering
 
 
On 6/29/23 17:46, juzhe.zhong wrote:
> You should try the example check the codegen before and after the patch. 
> You will understand it.
I've already done that.  It makes _no_ difference on the godbold example.
 
Jeff
 


fail.s
Description: Binary data


pass.s
Description: Binary data

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

[Jeff Law via Gcc-patches]

On 6/29/23 17:46, juzhe.zhong wrote:
You should try the example check the codegen before and after the patch. 
You will understand it.

I've already done that.  It makes _no_ difference on the godbold example.

Jeff

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

[Jeff Law via Gcc-patches]

On 6/28/23 16:00, 钟居哲 wrote:

You can see here:

https://godbolt.org/z/d78646hWb 
You patch doesn't help that code and your patch is a result of 
fundamentally misunderstanding combine's capabilities AFAICT.


Jeff

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

[Jeff Law via Gcc-patches]

On 6/28/23 16:00, 钟居哲 wrote:

You can see here:

https://godbolt.org/z/d78646hWb 
So just to be explicit, I see no difference with that test before/after 
your proposed change.  Nor would I expect one based on my understanding 
of the patch.


The explicit conversions I see are because we need the output of the 
conversion in multiple vfmul instructions.  That won't be helped by the 
patch you've proposed.


To be more concrete:


   vsetvli t1,t5,e32,mf2,ta,ma # 99[c=0 l=4]  vsetvldi
vle32.v v2,0(a4)# 23[c=4 l=4]  pred_movvnx2sf/1
vle32.v v1,0(a5)# 25[c=4 l=4]  pred_movvnx2sf/1
vsetvli t0,zero,e32,mf2,ta,ma   # 101   [c=0 l=4]  vsetvldi
vfwcvt.f.f.vv3,v2   # 77[c=4 l=4]  pred_extendvnx2df/0
vfwcvt.f.f.vv2,v1   # 79[c=4 l=4]  pred_extendvnx2df/0
vsetvli zero,t1,e32,mf2,ta,ma   # 102   [c=0 l=4]  
vsetvl_discard_resultdi
vle32.v v5,0(a6)# 31[c=4 l=4]  pred_movvnx2sf/1
vle32.v v4,0(a7)# 39[c=4 l=4]  pred_movvnx2sf/1
vsetvli t0,zero,e32,mf2,ta,ma   # 103   [c=0 l=4]  vsetvldi
vfwcvt.f.f.vv1,v5   # 81[c=4 l=4]  pred_extendvnx2df/0
vsetvli zero,zero,e64,m1,ta,ma  # 104   [c=16 l=4]  
vsetvl_vtype_change_only
vfmul.vvv5,v2,v3# 29[c=4 l=4]  pred_mulvnx2df/2
vfmul.vvv2,v1,v2# 34[c=4 l=4]  pred_mulvnx2df/2
vsetvli zero,t1,e64,m1,ta,ma# 105   [c=0 l=4]  
vsetvl_discard_resultdi
vse64.v v2,0(a1)# 35[c=4 l=4]  pred_storevnx2df
vse64.v v5,0(a0)# 30[c=4 l=4]  pred_storevnx2df
vsetvli t6,zero,e64,m1,ta,ma# 106   [c=0 l=4]  vsetvldi
vfmul.vvv1,v1,v3# 37[c=4 l=4]  pred_mulvnx2df/2
vsetvli zero,zero,e32,mf2,ta,ma # 107   [c=20 l=4]  
vsetvl_vtype_change_only
vfwcvt.f.f.vv2,v4   # 83[c=4 l=4]  pred_extendvnx2df/0
vsetvli zero,t1,e64,m1,ta,ma# 108   [c=0 l=4]  
vsetvl_discard_resultdi
vse64.v v1,0(a2)# 38[c=4 l=4]  pred_storevnx2df
vsetvli t6,zero,e64,m1,ta,ma# 109   [c=0 l=4]  vsetvldi
sllit4,t1,2 # 22[c=4 l=4]  ashldi3
sllit3,t1,3 # 27[c=4 l=4]  ashldi3
vfmul.vvv1,v2,v3# 42[c=4 l=4]  pred_mulvnx2df/2



Note how the output of the explicit conversion done in insn 77 is used 
by the vfmul in insns 29, 37 and 42.  Similarly for the other explcit 
conversions.


Your pattern isn't going to help that problem.

You could model this as a dependency height reduction.  I think that 
will get you were you want to go.


You'll need a pattern that matches this:

(parallel [ 
(set (reg:VNx2DF 160 [ vect__11.15 ])

(if_then_else:VNx2DF (unspec:VNx2BI [
(const_vector:VNx2BI repeat [
(const_int 1 [0x1])
])  
(reg:DI 169)

(const_int 2 [0x2]) repeated x2
(const_int 1 [0x1]) 
(const_int 7 [0x7])

(reg:SI 66 vl)
(reg:SI 67 vtype)
(reg:SI 69 frm)
] UNSPEC_VPREDICATE)
(mult:VNx2DF (float_extend:VNx2DF (reg:VNx2SF 144 [ vect__7.13 
]))
(float_extend:VNx2DF (reg:VNx2SF 146 [ vect__4.9 ])))
(unspec:VNx2DF [
(reg:SI 0 zero)
] UNSPEC_VUNDEF)))
(set (reg:VNx2DF 143 [ vect__8.14 ])
(float_extend:VNx2DF (reg:VNx2SF 144 [ vect__7.13 ])))
(set (reg:VNx2DF 145 [ vect__5.10 ])
(float_extend:VNx2DF (reg:VNx2SF 146 [ vect__4.9 ])))
])


It'll need to be a define_insn_and_split as its a 3->3 splitter.  The 
split will emit the two extensions and the widening multiply as 3 
distinct insns.


This has two positive effects.  First the widening multiply is no longer 
data dependent on the float_extend and so it can issue when ever r144 
and r146 are ready rather than when r143 and r145 are ready.


The second effect is I think this pattern will end up matching all the 
multiplies in this sample code.  As a result all the float_extend insns 
you generated when splitting become dead and should be removed by DCE.



Jeff

Re: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

[钟居哲]

Or do you have better solution to make the case succeed to combine into vfwmul?
I am ok with any solution.



juzhe.zh...@rivai.ai
 
From: Jeff Law
Date: 2023-06-30 06:59
To: 钟居哲; gcc-patches
CC: kito.cheng; kito.cheng; palmer; palmer; rdapp.gcc
Subject: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering
 
 
On 6/28/23 16:00, 钟居哲 wrote:
> You can see here:
> 
> https://godbolt.org/z/d78646hWb <https://godbolt.org/z/d78646hWb>
> 
> The first case can't genreate vfwmul.vv but second case succeed.
> 
> Failed to match this instruction:
> (set (reg:VNx2DF 150 [ vect__11.50 ])
>  (if_then_else:VNx2DF (unspec:VNx2BI [
>  (const_vector:VNx2BI repeat [
>  (const_int 1 [0x1])
>  ])
>  (reg:DI 153)
>  (const_int 2 [0x2]) repeated x2
>  (const_int 1 [0x1])
>  (const_int 7 [0x7])
>  (reg:SI 66 vl)
>  (reg:SI 67 vtype)
>  (reg:SI 69 N/A)
>  ] UNSPEC_VPREDICATE)
>  (mult:VNx2DF (float_extend:VNx2DF (reg:VNx2SF 149 [ vect__5.45 ]))
>  (reg:VNx2DF 148 [ vect__8.49 ]))
>  (unspec:VNx2DF [
>  (reg:SI 0 zero)
>  ] UNSPEC_VUNDEF)))
Right.  We try combining:
   24 -> 27
   25 -> 27
   23, 24 -> 27
   22, 25 -> 27
 
All of which fail, as expected.  24 -> 27 and 25-> 27 only put an 
extension on one operand of the mult.  The other two try to substitute a 
float extend of an if-then-else which I fully expect to fail.  All as 
expected.
 
The next one that gets tried is:
 
> Trying 25, 24 -> 27:
>25: r149:VNx2DF=float_extend(r141:VNx2SF)
>   REG_DEAD r141:VNx2SF
>24: r148:VNx2DF=float_extend(r139:VNx2SF)
>   REG_DEAD r139:VNx2SF
>27: 
> r150:VNx2DF={(unspec[const_vector,r153:DI,0x2,0x2,0x1,0x7,vl:SI,vtype:SI,N/A:SI]
>  69)?r148:VNx2DF*r149:VNx2DF:unspec[zero:SI] 68}
>   REG_DEAD r149:VNx2DF
>   REG_DEAD r148:VNx2DF
>   REG_DEAD N/A:SI
>   REG_DEAD zero:SI
>   REG_EQUAL r148:VNx2DF*r149:VNx2DF
> Successfully matched this instruction:
> (set (reg:VNx2DF 150 [ vect__11.50 ])
> (if_then_else:VNx2DF (unspec:VNx2BI [
> (const_vector:VNx2BI repeat [
> (const_int 1 [0x1])
> ])
> (reg:DI 153)
> (const_int 2 [0x2]) repeated x2
> (const_int 1 [0x1])
> (const_int 7 [0x7])
> (reg:SI 66 vl)
> (reg:SI 67 vtype)
> (reg:SI 69 N/A)
> ] UNSPEC_VPREDICATE)
> (mult:VNx2DF (float_extend:VNx2DF (reg:VNx2SF 141 [ vect__4.44 ]))
> (float_extend:VNx2DF (reg:VNx2SF 139 [ vect__7.48 ])))
> (unspec:VNx2DF [
> (reg:SI 0 zero)
> ] UNSPEC_VUNDEF)))
> allowing combination of insns 24, 25 and 27
> original costs 4 + 4 + 4 = 12
> replacement cost 4
 
Note how it replaced both operands of the mult with extended versions 
and the pattern matches, as expected.
 
The point being that I don't think those helper patterns are needed to 
handle the problem you suggested they were there to handle.  Combine 
knows how to handle multiple substitutions just fine.
 
Right now I don't see a need for this patch.
 
 
 
Jeff
 

Re: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

[钟居哲]

>> Right now I don't see a need for this patch.
No, we need this patch.

With this patch,  this following case can be combine into vfwmul.vv:
#define TEST_TYPE(TYPE1, TYPE2)\
  __attribute__ ((noipa)) void vwadd_##TYPE1_##TYPE2 ( \
TYPE1 *__restrict dst, TYPE1 *__restrict dst2, TYPE1 *__restrict dst3, \
TYPE1 *__restrict dst4, TYPE2 *__restrict a, TYPE2 *__restrict b,  \
TYPE2 *__restrict a2, TYPE2 *__restrict b2, int n) \
  {\
for (int i = 0; i < n; i++)\
  {\
dst[i] = (TYPE1) a[i] * (TYPE1) b[i];  \
dst2[i] = (TYPE1) a2[i] * (TYPE1) b[i];\
dst3[i] = (TYPE1) a2[i] * (TYPE1) a[i];\
dst4[i] = (TYPE1) a[i] * (TYPE1) b2[i];\
  }\
  }
TEST_TYPE (double, float)
You should try this, then you will know I am saying.


juzhe.zh...@rivai.ai
 
From: Jeff Law
Date: 2023-06-30 06:59
To: 钟居哲; gcc-patches
CC: kito.cheng; kito.cheng; palmer; palmer; rdapp.gcc
Subject: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering
 
 
On 6/28/23 16:00, 钟居哲 wrote:
> You can see here:
> 
> https://godbolt.org/z/d78646hWb <https://godbolt.org/z/d78646hWb>
> 
> The first case can't genreate vfwmul.vv but second case succeed.
> 
> Failed to match this instruction:
> (set (reg:VNx2DF 150 [ vect__11.50 ])
>  (if_then_else:VNx2DF (unspec:VNx2BI [
>  (const_vector:VNx2BI repeat [
>  (const_int 1 [0x1])
>  ])
>  (reg:DI 153)
>  (const_int 2 [0x2]) repeated x2
>  (const_int 1 [0x1])
>  (const_int 7 [0x7])
>  (reg:SI 66 vl)
>  (reg:SI 67 vtype)
>  (reg:SI 69 N/A)
>  ] UNSPEC_VPREDICATE)
>  (mult:VNx2DF (float_extend:VNx2DF (reg:VNx2SF 149 [ vect__5.45 ]))
>  (reg:VNx2DF 148 [ vect__8.49 ]))
>  (unspec:VNx2DF [
>  (reg:SI 0 zero)
>  ] UNSPEC_VUNDEF)))
Right.  We try combining:
   24 -> 27
   25 -> 27
   23, 24 -> 27
   22, 25 -> 27
 
All of which fail, as expected.  24 -> 27 and 25-> 27 only put an 
extension on one operand of the mult.  The other two try to substitute a 
float extend of an if-then-else which I fully expect to fail.  All as 
expected.
 
The next one that gets tried is:
 
> Trying 25, 24 -> 27:
>25: r149:VNx2DF=float_extend(r141:VNx2SF)
>   REG_DEAD r141:VNx2SF
>24: r148:VNx2DF=float_extend(r139:VNx2SF)
>   REG_DEAD r139:VNx2SF
>27: 
> r150:VNx2DF={(unspec[const_vector,r153:DI,0x2,0x2,0x1,0x7,vl:SI,vtype:SI,N/A:SI]
>  69)?r148:VNx2DF*r149:VNx2DF:unspec[zero:SI] 68}
>   REG_DEAD r149:VNx2DF
>   REG_DEAD r148:VNx2DF
>   REG_DEAD N/A:SI
>   REG_DEAD zero:SI
>   REG_EQUAL r148:VNx2DF*r149:VNx2DF
> Successfully matched this instruction:
> (set (reg:VNx2DF 150 [ vect__11.50 ])
> (if_then_else:VNx2DF (unspec:VNx2BI [
> (const_vector:VNx2BI repeat [
> (const_int 1 [0x1])
> ])
> (reg:DI 153)
> (const_int 2 [0x2]) repeated x2
> (const_int 1 [0x1])
> (const_int 7 [0x7])
> (reg:SI 66 vl)
> (reg:SI 67 vtype)
> (reg:SI 69 N/A)
> ] UNSPEC_VPREDICATE)
> (mult:VNx2DF (float_extend:VNx2DF (reg:VNx2SF 141 [ vect__4.44 ]))
> (float_extend:VNx2DF (reg:VNx2SF 139 [ vect__7.48 ])))
> (unspec:VNx2DF [
> (reg:SI 0 zero)
> ] UNSPEC_VUNDEF)))
> allowing combination of insns 24, 25 and 27
> original costs 4 + 4 + 4 = 12
> replacement cost 4
 
Note how it replaced both operands of the mult with extended versions 
and the pattern matches, as expected.
 
The point being that I don't think those helper patterns are needed to 
handle the problem you suggested they were there to handle.  Combine 
knows how to handle multiple substitutions just fine.
 
Right now I don't see a need for this patch.
 
 
 
Jeff
 

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

[Jeff Law via Gcc-patches]

On 6/28/23 16:00, 钟居哲 wrote:

You can see here:

https://godbolt.org/z/d78646hWb 

The first case can't genreate vfwmul.vv but second case succeed.

Failed to match this instruction:
(set (reg:VNx2DF 150 [ vect__11.50 ])
     (if_then_else:VNx2DF (unspec:VNx2BI [
                 (const_vector:VNx2BI repeat [
                         (const_int 1 [0x1])
                     ])
                 (reg:DI 153)
                 (const_int 2 [0x2]) repeated x2
                 (const_int 1 [0x1])
                 (const_int 7 [0x7])
                 (reg:SI 66 vl)
                 (reg:SI 67 vtype)
                 (reg:SI 69 N/A)
             ] UNSPEC_VPREDICATE)
         (mult:VNx2DF (float_extend:VNx2DF (reg:VNx2SF 149 [ vect__5.45 ]))
             (reg:VNx2DF 148 [ vect__8.49 ]))
         (unspec:VNx2DF [
                 (reg:SI 0 zero)
             ] UNSPEC_VUNDEF)))

Right.  We try combining:
  24 -> 27
  25 -> 27
  23, 24 -> 27
  22, 25 -> 27

All of which fail, as expected.  24 -> 27 and 25-> 27 only put an 
extension on one operand of the mult.  The other two try to substitute a 
float extend of an if-then-else which I fully expect to fail.  All as 
expected.


The next one that gets tried is:


Trying 25, 24 -> 27:
   25: r149:VNx2DF=float_extend(r141:VNx2SF)
  REG_DEAD r141:VNx2SF
   24: r148:VNx2DF=float_extend(r139:VNx2SF)
  REG_DEAD r139:VNx2SF
   27: 
r150:VNx2DF={(unspec[const_vector,r153:DI,0x2,0x2,0x1,0x7,vl:SI,vtype:SI,N/A:SI]
 69)?r148:VNx2DF*r149:VNx2DF:unspec[zero:SI] 68}
  REG_DEAD r149:VNx2DF
  REG_DEAD r148:VNx2DF
  REG_DEAD N/A:SI
  REG_DEAD zero:SI
  REG_EQUAL r148:VNx2DF*r149:VNx2DF
Successfully matched this instruction:
(set (reg:VNx2DF 150 [ vect__11.50 ])
(if_then_else:VNx2DF (unspec:VNx2BI [
(const_vector:VNx2BI repeat [
(const_int 1 [0x1])
])
(reg:DI 153)
(const_int 2 [0x2]) repeated x2
(const_int 1 [0x1])
(const_int 7 [0x7])
(reg:SI 66 vl)
(reg:SI 67 vtype)
(reg:SI 69 N/A)
] UNSPEC_VPREDICATE)
(mult:VNx2DF (float_extend:VNx2DF (reg:VNx2SF 141 [ vect__4.44 ]))
(float_extend:VNx2DF (reg:VNx2SF 139 [ vect__7.48 ])))
(unspec:VNx2DF [
(reg:SI 0 zero)
] UNSPEC_VUNDEF)))
allowing combination of insns 24, 25 and 27
original costs 4 + 4 + 4 = 12
replacement cost 4


Note how it replaced both operands of the mult with extended versions 
and the pattern matches, as expected.


The point being that I don't think those helper patterns are needed to 
handle the problem you suggested they were there to handle.  Combine 
knows how to handle multiple substitutions just fine.


Right now I don't see a need for this patch.



Jeff

Re: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

[钟居哲]

You can see here:

https://godbolt.org/z/d78646hWb 

The first case can't genreate vfwmul.vv but second case succeed.

Failed to match this instruction:
(set (reg:VNx2DF 150 [ vect__11.50 ])
(if_then_else:VNx2DF (unspec:VNx2BI [
(const_vector:VNx2BI repeat [
(const_int 1 [0x1])
])
(reg:DI 153)
(const_int 2 [0x2]) repeated x2
(const_int 1 [0x1])
(const_int 7 [0x7])
(reg:SI 66 vl)
(reg:SI 67 vtype)
(reg:SI 69 N/A)
] UNSPEC_VPREDICATE)
(mult:VNx2DF (float_extend:VNx2DF (reg:VNx2SF 149 [ vect__5.45 ]))
(reg:VNx2DF 148 [ vect__8.49 ]))
(unspec:VNx2DF [
(reg:SI 0 zero)
] UNSPEC_VUNDEF)))


This patch is adding this combine pattern.


juzhe.zh...@rivai.ai
 
From: Jeff Law
Date: 2023-06-29 00:24
To: Juzhe-Zhong; gcc-patches
CC: kito.cheng; kito.cheng; palmer; palmer; rdapp.gcc
Subject: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering
 
 
On 6/27/23 22:15, Juzhe-Zhong wrote:
> Consider the following complicate case:
> #define TEST_TYPE(TYPE1, TYPE2)   
>  \
>__attribute__ ((noipa)) void vwadd_##TYPE1_##TYPE2 (   
>   \
>  TYPE1 *__restrict dst, TYPE1 *__restrict dst2, TYPE1 *__restrict dst3,   
>   \
>  TYPE1 *__restrict dst4, TYPE2 *__restrict a, TYPE2 *__restrict b,
>   \
>  TYPE2 *__restrict a2, TYPE2 *__restrict b2, int n)   
>   \
>{  
>   \
>  for (int i = 0; i < n; i++)  
>   \
>{  
>   \
> dst[i] = (TYPE1) a[i] * (TYPE1) b[i];  \
> dst2[i] = (TYPE1) a2[i] * (TYPE1) b[i];\
> dst3[i] = (TYPE1) a2[i] * (TYPE1) a[i];\
> dst4[i] = (TYPE1) a[i] * (TYPE1) b2[i];\
>}  
>   \
>}
> 
> TEST_TYPE (double, float)
> 
> Such complicate situation, Combine PASS can not combine extension of both 
> operands on the fly.
> So the combine PASS will first try to combine one of the combine extension, 
> and then combine
> the other. The combine flow is as follows:
> 
> Original IR:
> (set (reg 0) (float_extend: (reg 1))
> (set (reg 3) (float_extend: (reg 2))
> (set (reg 4) (mult: (reg 0) (reg 3))
> 
> First step of combine:
> (set (reg 3) (float_extend: (reg 2))
> (set (reg 4) (mult: (float_extend: (reg 1) (reg 3))
> 
> Second step of combine:
> (set (reg 4) (mult: (float_extend: (reg 1) (float_extend: (reg 2))
> 
> So, to enhance the combine optimization, we add a "pseudo vwfmul.wv" RTL 
> pattern in autovec-opt.md
> which is (set (reg 0) (mult (float_extend (reg 1) (reg 2.
Hmm, something doesn't make sense here.  Combine knows how to do a 3->1 
combination.  I would expect to see the first step fail (substituting 
just one operand), then a later step try to combine all three 
instructions, substituting the extension for both input operands.
 
Can you pass along the .combine dump from the failing case?
 
Jeff
 

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

[Jeff Law via Gcc-patches]

On 6/27/23 22:15, Juzhe-Zhong wrote:

Consider the following complicate case:
#define TEST_TYPE(TYPE1, TYPE2)\
   __attribute__ ((noipa)) void vwadd_##TYPE1_##TYPE2 ( 
\
 TYPE1 *__restrict dst, TYPE1 *__restrict dst2, TYPE1 *__restrict dst3, 
\
 TYPE1 *__restrict dst4, TYPE2 *__restrict a, TYPE2 *__restrict b,  
\
 TYPE2 *__restrict a2, TYPE2 *__restrict b2, int n) 
\
   {
\
 for (int i = 0; i < n; i++)
\
   {
\
dst[i] = (TYPE1) a[i] * (TYPE1) b[i];  \
dst2[i] = (TYPE1) a2[i] * (TYPE1) b[i];\
dst3[i] = (TYPE1) a2[i] * (TYPE1) a[i];\
dst4[i] = (TYPE1) a[i] * (TYPE1) b2[i];\
   }
\
   }

TEST_TYPE (double, float)

Such complicate situation, Combine PASS can not combine extension of both 
operands on the fly.
So the combine PASS will first try to combine one of the combine extension, and 
then combine
the other. The combine flow is as follows:

Original IR:
(set (reg 0) (float_extend: (reg 1))
(set (reg 3) (float_extend: (reg 2))
(set (reg 4) (mult: (reg 0) (reg 3))

First step of combine:
(set (reg 3) (float_extend: (reg 2))
(set (reg 4) (mult: (float_extend: (reg 1) (reg 3))

Second step of combine:
(set (reg 4) (mult: (float_extend: (reg 1) (float_extend: (reg 2))

So, to enhance the combine optimization, we add a "pseudo vwfmul.wv" RTL 
pattern in autovec-opt.md
which is (set (reg 0) (mult (float_extend (reg 1) (reg 2.
Hmm, something doesn't make sense here.  Combine knows how to do a 3->1 
combination.  I would expect to see the first step fail (substituting 
just one operand), then a later step try to combine all three 
instructions, substituting the extension for both input operands.


Can you pass along the .combine dump from the failing case?

Jeff