> it's just a vector cost model issue and some loops are not profitable
> to vectorize?
Yes. For example, when gpr2vr is 1, int8_t cannot vectorize while uint8_t can.
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv_zvl128b -mabi=lp64d --param=gpr2vr-cost=1" } */
+
+#include "vx_binary.h"
+
+DEF_VX_BINARY_CASE_1(int8_t, +, VX_BINARY_BODY_X16)
+
+/* { dg-final { scan-assembler-not {vadd.vx} } } */
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv_zvl128b -mabi=lp64d --param=gpr2vr-cost=1" } */
+
+#include "vx_binary.h"
+
+DEF_VX_BINARY_CASE_1(uint8_t, +, VX_BINARY_BODY_X16)
+
+/* { dg-final { scan-assembler {vadd.vx} } } */
Another case is int64_t can combine when gpr2vr is 1, and failed to combine
when gpr2vr is 2.
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv_zvl128b -mabi=lp64d --param=gpr2vr-cost=1" } */
+
+#include "vx_binary.h"
+
+DEF_VX_BINARY_CASE_1(int64_t, +, VX_BINARY_BODY)
+
+/* { dg-final { scan-assembler {vadd.vx} } } */
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv_zvl128b -mabi=lp64d --param=gpr2vr-cost=2" } */
+
+#include "vx_binary.h"
+
+DEF_VX_BINARY_CASE_1(int64_t, +, VX_BINARY_BODY)
+
+/* { dg-final { scan-assembler-not {vadd.vx} } } */
Pan
-----Original Message-----
From: Robin Dapp <[email protected]>
Sent: Thursday, May 8, 2025 8:01 PM
To: Li, Pan2 <[email protected]>; [email protected]
Cc: [email protected]; [email protected]; [email protected];
[email protected]; Chen, Ken <[email protected]>; Liu, Hongtao
<[email protected]>; Robin Dapp <[email protected]>
Subject: Re: [PATCH v1 0/5] Add testcases for another case of vec_duplicate +
vadd.vv combine
> This patch series would like to add the testcases for this. However,
> some test results is not that tidy, and we need more tuning for
> the vector cost model.
The test adjustments LGTM but what do you mean by not tidy? I see you're
scanning just for the presence of "vx" instead of an exact number so
it's just a vector cost model issue and some loops are not profitable
to vectorize?
--
Regards
Robin
