On 10/15/25 4:56 PM, Andrew Pinski wrote:
The problem here is that when the backend folds the vset intrinsics,
it tries to keep the lhs of the new statement to be the same as the old
statement
due to the check in gsi_replace. The problem is with a MEM_REF vset::fold was
unsharing the new lhs here and using the original lhs in the other new
statement.
This meant the check in gsi_replace would fail.
This fixes that oversight by switching around which statement gets the unshared
version.
Note the comment in vset::fold was already correct just not matching the code:
/* Replace the call with two statements: a copy of the full tuple
to the call result, followed by an update of the individual vector.
The fold routines expect the replacement statement to have the
same lhs as the original call, so return the copy statement
rather than the field update. */
Changes since v1:
* v2: Fix testcase.
PR target/122270
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc (vset::fold): Use the
unshare_expr for the statement that will be added seperately rather
the one which will be used for the replacement.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr122270-1.c: New test.
FTR: The pre-commit tester and mine were both happy with this.
OK for the trunk. One formatting nit though:
/* Get a reference to the individual vector. */
tree field = tuple_type_field (TREE_TYPE (f.lhs));
tree lhs_array
- = build3 (COMPONENT_REF, TREE_TYPE (field), f.lhs, field, NULL_TREE);
+ = build3 (COMPONENT_REF, TREE_TYPE (field), unshare_expr (f.lhs), field,
NULL_TREE);
Overly long line reported by pre-commit lint.
jeff
