[Bug target/121451] RISC-V: zero-stride load broadcast vs. vector-scalar

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"