[Bug target/113014] RISC-V: Redundant zeroing instructions in reduction due to r14-3998-g6223ea766daf7c

2024-07-02 Thread law at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113014

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug target/113014] RISC-V: Redundant zeroing instructions in reduction due to r14-3998-g6223ea766daf7c

2023-12-14 Thread rdapp at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113014

--- Comment #4 from Robin Dapp  ---
Richard has posted it and asked for reviews.  I have tested it and we have
several testsuite regressions with it but no severe ones.  Most or all of them
are dump fails because we combine into vx variants that would be vv variants
before.
I replied to Richard's post mentioning that we would very much like to see that
go in because it helps us generate the code we want.
To me it appears very likely that it will land.

[Bug target/113014] RISC-V: Redundant zeroing instructions in reduction due to r14-3998-g6223ea766daf7c

2023-12-14 Thread juzhe.zhong at rivai dot ai via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113014

--- Comment #3 from JuzheZhong  ---
(In reply to Robin Dapp from comment #2)
> Yes, that's right.

It seems that I don't need to optimize it since we will eventually have
late-combine.

Could you tell what status of late-combine PASS ?

Will it be landed on GCC-14?

Btw, I want this PASS, so that we can do vv->vx transformation.

[Bug target/113014] RISC-V: Redundant zeroing instructions in reduction due to r14-3998-g6223ea766daf7c

2023-12-14 Thread rdapp at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113014

--- Comment #2 from Robin Dapp  ---
Yes, that's right.

[Bug target/113014] RISC-V: Redundant zeroing instructions in reduction due to r14-3998-g6223ea766daf7c

2023-12-13 Thread juzhe.zhong at rivai dot ai via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113014

--- Comment #1 from JuzheZhong  ---
Richard S has a late combine PASS which is going to be merged in GCC-14.

Since we generate this following RTL int split1:

(insn 48 24 49 5 (set (reg:SI 149)
(const_int 0 [0])) -1
 (nil))

(insn 49 48 50 5 (set (reg:RVVM1SI 148)
(if_then_else:RVVM1SI (unspec:RVVMF32BI [
(const_vector:RVVMF32BI [
(const_int 1 [0x1])
repeat [
(const_int 0 [0])
]
])
(const_int 1 [0x1])
(const_int 2 [0x2]) repeated x2
(const_int 0 [0])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(vec_duplicate:RVVM1SI (reg:SI 149))
(unspec:RVVM1SI [
(reg:SI 0 zero)
] UNSPEC_VUNDEF))) -1
 (nil))

I suspect late-combine PASS can combine it into:

(insn 49 48 50 5 (set (reg:RVVM1SI 148)
(if_then_else:RVVM1SI (unspec:RVVMF32BI [
(const_vector:RVVMF32BI [
(const_int 1 [0x1])
repeat [
(const_int 0 [0])
]
])
(const_int 1 [0x1])
(const_int 2 [0x2]) repeated x2
(const_int 0 [0])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(CONST_VECTOR: 0)
(unspec:RVVM1SI [
(reg:SI 0 zero)
] UNSPEC_VUNDEF))) -1
 (nil))

that is: combine

(set(reg0) (0)) and (vec_duplicate:reg0) 

into:

(CONST_VECTOR:0)

after split1 by late-combine PASS.

I am not sure.

Hi,Robin. Could you confirm it for me ?