https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122762
--- Comment #17 from Richard Sandiford <rsandifo at gcc dot gnu.org> --- (In reply to Richard Biener from comment #11) > (In reply to Richard Sandiford from comment #10) > > +Andre since this is about SIMD clones. > > > > (In reply to Richard Biener from comment #8) > > > 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. > > > > Why do you say that it's wrong? AIUI (going only from the description) the > > ICE is caused by the fact that gimple (useless_type_conversion_p) does check > > TARGET_COMPATIBLE_VECTOR_TYPES_P. > > The comment says it does _not_ affect gimple type compatibility. Then of > course follows to say that's decided with that hook, but that hook checks > presence of the SVE type attribute. Ah, I see. I thought you meant that the bit in brackets was wrong. What the wider comment means is that the SVE type attribute created here is anonymous, whereas the SVE type attributes created for the “real” built-in SVE ACLE types are not anonymous. This would make the types created here incompatible in C/C++ terms with the built-in SVE types. For example, in C/C++ terms, a scalable vector of int32_ts created by this code would not be compatible with the built-in svint32_t type. But the two types would be compatible in gimple terms, because gimple only cares about the presence or absence of the SVE attribute, not what the names are. This is why creating a “proper” SVE type attribute wasn't worth the effort. In other words, the wider comment is describing compatibility rules between two SVE types, whereas in this PR the issue is compatiblity between SVE and non-SVE types. SVE and non-SVE types are incompatible in both C/C++ and gimple. > > As for why it does that, see the commit message for > > g:482b2b43e5101921ad94e51e052a18b353f8a3f5, which introduced the check. > > Hm, but that talks about argument passing / return ABIs? > useless_type_conversion_p applies to value types, at most its check > for FUNCTION_TYPE compatibility would need to use this check? Wouldn't that be bad for composability though? It would seem odd for "T1 f()" vs "T2 g()" to impose stricter rules than T1 vs T2. > @Richard Sandiford: Potentially silly question as you have probably > thought of this, but I was reading through your patch 'Add a > compatible_vector_types_p target hook' and I was wondering whether > it wouldn't make more sense to implement the more profitable ABI > by describing it as such. That is, get rid of this special 'SVE' > type thing and mark all previous functions that used this type as > 'vector_abi' (I think that's what we call it?) such that the types > are all the same/equivalent, but we only differ in behaviour at > ABI boundary where it matters? At least for SVE, “vector ABI” just controls the call-clobbered register state. Whether something is “vector ABI” is determined by how its arguments and return values are passed, rather than the other way around.
