https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122762
--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Richard Sandiford from comment #17) > (In reply to Richard Biener from comment #11) > > (In reply to Richard Sandiford from comment #10) [...] > > > 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. Sure, but useless_type_conversion_p is generally the wrong place to address ABI compatibility issues. What breaks when not having this check in useless_type_conversion_p? The testcases added, if they break, would point to places where we use this function wrongly. It's by far "complete" to check whether two FUNCTION_TYPE have the same ABI. > > @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.
