Re: Intel AVX10.1 Compiler Design and Support

[Richard Biener via Gcc-patches]

> Am 09.08.2023 um 06:02 schrieb Phoebe Wang via Gcc-patches 
> <gcc-patches@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.

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
>> .
>>