> -----Original Message-----
> From: Richard Biener <richard.guent...@gmail.com>
> Sent: Wednesday, August 9, 2023 1:38 PM
> To: Phoebe Wang <phoebe.p...@gmail.com>
> Cc: Hongtao Liu <crazy...@gmail.com>; Joseph Myers
> <jos...@codesourcery.com>; Jiang, Haochen <haochen.ji...@intel.com>; gcc-
> patc...@gcc.gnu.org; ubiz...@gmail.com; Liu, Hongtao
> <hongtao....@intel.com>; Zhang, Annita <annita.zh...@intel.com>; Wang,
> Phoebe <phoebe.w...@intel.com>; x86-64-abi <x86-64-
> a...@googlegroups.com>; llvm-dev <llvm-...@lists.llvm.org>; Craig Topper
> <craig.top...@gmail.com>
> Subject: Re: Intel AVX10.1 Compiler Design and Support
> 
> 
> 
> > Am 09.08.2023 um 06:02 schrieb Phoebe Wang via Gcc-patches <gcc-
> patc...@gcc.gnu.org>:
> >
> > I have some proposals about unifying ABI on AVX10 for both 256-bit
> > and 512-bit.
> >
> >
> >
> > Proposal 1: Promote attribute from AVX10-256 to AVX10-512 for any
> > function which has 512-bit or above vectors in passing/returning arguments.
> >
> > Problem: Binary cannot run on AVX10-256 only target.
> >
> > Reason:
> >
> > When user tries to pass/return 512-bit vector, they should be aware of
> > it will become target dependent. User should be taught not to use it
> > on 256-bit targets and there will be unexpected things happening if
> > they insist.
> >
> > Actually, ICC and MSVC already have chosen to promote for the argument:
> > https://godbolt.org/z/vcrf9qW5z I think if compiler have to choose the
> > misbehavior between fail in result and crash due to illegal
> > instruction, the latter is definitely better than the former.
> >
> > In this way, we can also declare x86-64-v5 is inherit from x86-64-v4
> > and has the interaction with previous versions.
> >
> >
> >
> > Proposal 2: Abort compilation when user tries to pass/return 512-bit
> > vectors.
> >
> > Reason: This turns possible run time crash into compile time error.
> >
> >
> >
> > Proposal 3: Change the ABI of 512-bit vector and always be
> > passed/returned from memory.
> 
> I don’t think we can realistically change the ABI.  If we could passing them 
> in two
> 256bit registers would be possible as well.
> 
> Note I fully expect intel to turn around and implement 512 bits on a 256 but 
> data
> path on the E cores in 5 years.  And it will take at least that time for 
> AVX10 to take
> off (look at AVX512 for this and how they cautionously chose to include bf16 
> to
> cut off Zen4).  So IMHO we shouldn’t worry at all and just wait and see for 
> AVX42
> to arrive.

Let me try to clarify the whole thing.

I suppose Phoebe's "change" is based on LLVM.

In GCC, current behavior is to pass 512 bit vector in memory when there is no
512 bit support. But when there is support, everything should be passed in 
register.

In AVX10, I prefer to still keep to this pattern. But if most of you want to 
change it,
I have no objection since AVX10 is a new start.

Thx,
Haochen

> 
> Richard
> 
> > Reason: We expect AVX10-256 is a universal configuration and in most
> > scenarios, 512-bit vector won't bring performance improvements. So we
> > can sacrifice a little 512-bit performance to achieve the interaction
> > between
> > AVX10-256 and AVX10-512. In this way, there won't have any runtime
> > issue in the future either.
> >
> >
> >
> > Thanks
> >
> > Phoebe
> >
> > Hongtao Liu <crazy...@gmail.com> 于2023年8月9日周三 10:18写道:
> >
> >>> On Wed, Aug 9, 2023 at 10:14 AM Hongtao Liu <crazy...@gmail.com> wrote:
> >>>
> >>> On Wed, Aug 9, 2023 at 9:21 AM Hongtao Liu <crazy...@gmail.com> wrote:
> >>>>
> >>>> On Wed, Aug 9, 2023 at 3:55 AM Joseph Myers
> >>>> <jos...@codesourcery.com>
> >> wrote:
> >>>>>
> >>>>> Do you have any comments on the interaction of AVX10 with the
> >>>>> micro-architecture levels defined in the ABI (and supported with
> >>>>> glibc-hwcaps directories in glibc)?  Given that the levels are
> >> cumulative,
> >>>>> should we take it that any future levels will be ones supporting
> >> 512-bit
> >>>>> vector width for AVX10 (because x86-64-v4 requires the current
> >> AVX512F,
> >>>>> AVX512BW, AVX512CD, AVX512DQ and AVX512VL) - and so any future
> >> processors
> >>>>> that only support 256-bit vector width will be considered to match
> >> the
> >>>>> x86-64-v3 micro-architecture level but not any higher level?
> >>>> This is actually something we really want to discuss in the
> >>>> community, our proposal for x86-64-v5: AVX10.2-256(Implying AVX10.1-
> 256) + APX.
> >>>> One big reason is Intel E-core will only support AVX10 256-bit, if
> >>>> we want to use x86-64-v5 accross  server and client, it's better to
> >>>> 256-bit default.
> >>> + ABI and LLVM folked for this topic.
> >> s/folked/folks/
> >>
> >>>>>
> >>>>> --
> >>>>> Joseph S. Myers
> >>>>> jos...@codesourcery.com
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> BR,
> >>>> Hongtao
> >>>
> >>>
> >>>
> >>> --
> >>> BR,
> >>> Hongtao
> >>
> >>
> >>
> >> --
> >> BR,
> >> Hongtao
> >>
> >> --
> >> 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/CAMZc-bzj5971PJ4UN2aB4LB
> >> -9nj4q_fRiykT9My3syohGLbZrw%40mail.gmail.com
> >> .
> >>

Reply via email to