https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122762
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
Component|tree-optimization |target
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
simd_clone_adjust_sve_vector_type does
30276 /* ??? This creates anonymous "SVE type" attributes for all types,
30277 even those that correspond to <arm_sve.h> types. This affects
type
30278 compatibility in C/C++, but not in gimple. (Gimple type
equivalence
30279 is instead decided by TARGET_COMPATIBLE_VECTOR_TYPES_P.)
30280
(gdb)
30281 Thus a C/C++ definition of the implementation function will have a
30282 different function type from the declaration that this code
creates.
30283 However, it doesn't seem worth trying to fix that until we have a
30284 way of handling implementations that operate on unpacked types.
*/
30285 type = build_distinct_type_copy (type);
30286 aarch64_sve::add_sve_type_attribute (type, num_zr, num_pr, NULL,
NULL);
but at least the comment about GIMPLE type compatibility is wrong.
I believe this is really a target issue. I can workaround this in the
vectorizer by re-building the simdclone argument vector (boolean) type
like with
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index 748b3bcb0ab..7a062cc0634 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -4499,7 +4499,9 @@ vectorizable_simd_clone_call (vec_info *vinfo,
stmt_vec_info stmt_info,
(exact_div (bestn->simdclone->simdlen, num_mask_args),
TYPE_MODE (bestn->simdclone->args[i].vector_type));
else
- arg_vectype = bestn->simdclone->args[i].vector_type;
+ arg_vectype = build_truth_vector_type_for_mode
+ (TYPE_VECTOR_SUBPARTS
(bestn->simdclone->args[i].vector_type),
+ TYPE_MODE (bestn->simdclone->args[i].vector_type));
vect_record_loop_mask (loop_vinfo,
&LOOP_VINFO_MASKS (loop_vinfo),
ncopies * num_mask_args, arg_vectype,
but I have no idea why the ICE is even dependent on ASLR, thus why we get
sometimes the mixup of SVE builtin annotated types and sometimes not.
I also have not traced down the reason for the num_mask_args thing (splitting
a mask into multiple arguments?) or why we got away with using 'vectype'
(the vector type of the result) instead of the vector type of the arguments.
The original reason for the change was that we ran into this with
V4DF / V8DF mixup for simd clone arguments vs. result. The code seems
to handle concat/extract of pieces OK-ish in the end.
So maybe the change in the rev. was wrong, but it's now more in-line with
the assertion earlier when selecting 'bestn' with respect to
num_mask_args.
Test coverage is quite bad here.
