> -----Original Message----- > From: Jan Beulich <jbeul...@suse.com> > Sent: Thursday, August 10, 2023 9:31 PM > To: Phoebe Wang <phoebe.p...@gmail.com> > Cc: Joseph Myers <jos...@codesourcery.com>; Wang, Phoebe > <phoebe.w...@intel.com>; Hongtao Liu <crazy...@gmail.com>; Jiang, Haochen > <haochen.ji...@intel.com>; gcc-patches@gcc.gnu.org; ubiz...@gmail.com; Liu, > Hongtao <hongtao....@intel.com>; Zhang, Annita <annita.zh...@intel.com>; > x86-64-abi <x86-64-...@googlegroups.com>; llvm-dev <llvm- > d...@lists.llvm.org>; Craig Topper <craig.top...@gmail.com>; Richard Biener > <richard.guent...@gmail.com> > Subject: Re: Intel AVX10.1 Compiler Design and Support > > On 10.08.2023 15:12, Phoebe Wang wrote: > >> 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.
IMO it is not acceptable for AVX10-256 to generate zmm registers. If I have to choose among the three proposal, the second is better. But the best choice I suppose is to keep what we are doing currently, which is passing them in memory and emit a warning. It is a reasonable behavior. Thx, Haochen > > But you're only describing a pre-existing problem here afaict. Code compiled > with > -mavx51f passing __m512 type data to a function compiled with only, say, > -maxv2 > won't interoperate properly either. What's worse, imo the psABI doesn't > sufficiently define what __m256 etc actually are. After all these aren't types > defined by the C standard (as opposed to at least most other types in the > respective table there), and you can't really make assumptions like "this is > what > certain compilers think this is". > > Jan
