> The psABI should have some simple rule covering all of the above I think. psABI has a rule for the case doesn't mean the rule is a well defined ABI in practice. A well defined ABI should guarantee 1) interlinkable across different compile options within the same compiler; 2) interlinkable across different compilers. Both aspects are failed in the non 512-bit version. 1) is more important than 2) and becomes more critical on AVX10 targets. Because we expect AVX10-256 is a general setting for binaries that can run on both AVX10-256 and AVX10-512. It would be common that binaries compiled with AVX10-256 may link with native built binaries on AVX10-512 targets. Both 1) and 2) show the problem of the current rule in the psABI. So I think the psABI should be updated to solve them. Thanks Phoebe Richard Biener 于2023年8月10日周四 20:46写道： > On Thu, Aug 10, 2023 at 2:37 PM Phoebe Wang via Gcc-patches > wrote: > > > > > Changing ABIs like that for existing code that has worked for some > time > > on > > > existing hardware is a bad idea. > > > > I agree, so Proposal 3 is the last choice. > > > > The target of the proposals is to solve the ABI incompatible issue > between > > AVX10-256 and AVX10-512 when passing/returning 512 vectors. So we are > > discussing the default ABI rather than other vector variants. > > > > If you believe that changing 512-bit ABI (the 512-bit version) is a bad > > idea, how about Proposal 1 and 2? I don't want to call the non 512-bit > > version an ABI because it doesn't provide the interaction between 256-bit > > and 512-bit targets. Besides, LLVM also behaves differently with GCC on > non > > 512-bit targets. It is a good time to solve the problem together if we > make > > the 512-bit ABI consistent and target independent. WDYT? > > Isn't this situation similar to the not defined ABI when passing generic > vectors (via __attribute__((vector_size))) that do not map to vectors > supported > by the current ISA? There's cases like vector<2> char or vector<1> double > to consider for example that would fit in a lowpart of a supported vector > register and as in the AVX512 case vectors that are larger than any > supported > vector register. > > The psABI should have some simple rule covering all of the above I think. > > Richard. > > > Thanks > > Phoebe > > > > Joseph Myers 于2023年8月10日周四 04:43写道： > > > > > On Wed, 9 Aug 2023, Wang, Phoebe via Gcc-patches wrote: > > > > > > > Proposal 3: Change the ABI of 512-bit vector and always be > > > > passed/returned from memory. > > > > > > Changing ABIs like that for existing code that has worked for some > time on > > > existing hardware is a bad idea. > > > > > > At this point it seems appropriate to remind people of another ABI > > > consideration for vector extensions. glibc's libmvec defines vector > > > versions of various functions, including AVX512 ones (of course those > > > function versions only work on hardware with the relevant > instructions). > > > glibc's headers use both _Pragma ("omp declare simd notinbranch") and > > > __attribute__ ((__simd__ ("notinbranch"))) to declare, to the compiler > > > including those headers, what function variants are available in glibc. > > > > > > Existing glibc versions need to continue to work with new compiler > > > versions. That is, it's part of the ABI, which must remain stable, > > > exactly which function versions the above pragma and attribute imply > are > > > available - and of course the details of how those functions versions > take > > > arguments / return results are also part of the ABI (it would be OK > for a > > > new compiler to choose not to use some of those vector versions, but > not > > > to start calling them with a different ABI). > > > > > > Maybe you'll want to add new vector function versions, with different > > > interfaces, to libmvec in future. If so, you need a *different* > pragma or > > > attribute to declare to the compiler that the libmvec version using > that > > > pragma or attribute has the additional functions - so new compilers > using > > > the existing header will not try to generate calls to new function > > > versions that don't exist in that glibc version (but new compilers > using a > > > new header version from new glibc will see the new pragma or attribute > and > > > so be able to generate the relevant calls to new functions). And once > > > you've defined the ABI for such a new pragma or attribute, that itself > > > then becomes a stable interface - so if you end up with vector > extensions > > > involving yet another set of interfaces, they need another > corresponding > > > new pragma / attribute for libmvec to declare to the compiler that the > new > > > interfaces exist. > > > > > > -- > > > Joseph S. Myers > > > joseph@codesourcery.com > > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "X86-64 System V Application Binary Interface" group. > > > To unsubscribe from this group and stop receiving emails from it, send > an > > > email to x86-64-abi+unsubscribe@googlegroups.com. > > > To view this discussion on the web visit > > > > https://groups.google.com/d/msgid/x86-64-abi/8fb470de-d2a3-3e71-be6a-ccc7f4f31a31%40codesourcery.com > > > . > > > >