https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121451
Zhongyao Chen <chenzhongyao.hit at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |chenzhongyao.hit at gmail dot
com
--- Comment #4 from Zhongyao Chen <chenzhongyao.hit at gmail dot com> ---
Had a quick look.
Even if the uarch optimizes zero-stride loads as described in the RVV spec,
I wouldn't expect
vlse64.v v3, 0(a1), zero
vfmacc.vv v1, v3, v2
better then
fld fa5, 0(a4)
vfmacc.vf v1, fa5, v2
So I prefer avoid zero-stride loads here.
I think the missed vfmacc.vf combine is real, though.
how about do something like this:
diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md
index 4efee02fb3b..08a9912f944 100644
--- a/gcc/config/riscv/vector.md
+++ b/gcc/config/riscv/vector.md
@@ -1625,7 +1626,7 @@
if (!satisfies_constraint_P (operands[1])
&& !satisfies_constraint_J (operands[1])
&& !rtx_equal_p (operands[1], CONST0_RTX (<VEL>mode))
- && !memory_operand (operands[1], <VEL>mode))
+ && riscv_vector::can_be_broadcast_p (operands[1]))
operands[1] = force_reg (<VEL>mode, operands[1]);
/* Otherwise keep the vec_duplicate pattern until split. */
@@ -1639,7 +1640,9 @@
[(set (match_operand:V_VLS 0 "register_operand")
(vec_duplicate:V_VLS
(match_operand:<VEL> 1 "any_broadcast_operand")))]
- "TARGET_VECTOR && can_create_pseudo_p ()"
+ "TARGET_VECTOR && can_create_pseudo_p ()
+ && !(MEM_P (operands[1])
+ && riscv_vector::can_be_broadcast_p (operands[1]))"
"#"
"&& 1"
