> 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 <richard.guent...@gmail.com> 于2023年8月10日周四 20:46写道：
> On Thu, Aug 10, 2023 at 2:37 PM Phoebe Wang via Gcc-patches
> <gcc-patches@gcc.gnu.org> 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 <jos...@codesourcery.com> 于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
> > > jos...@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+unsubscr...@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
> > > .
> > >
>
