On Wed, Aug 23, 2023 at 4:31 PM Jakub Jelinek wrote:
>
> On Wed, Aug 23, 2023 at 08:03:58AM +, Jiang, Haochen wrote:
> > We could first work on -mevex512 then further discuss -mavx10.1-256/512
> > since
> > these -mavx10.1-256/512 is quite controversial.
> >
> > Just to clarify, -mno-evex512
On Wed, Aug 23, 2023 at 08:03:58AM +, Jiang, Haochen wrote:
> We could first work on -mevex512 then further discuss -mavx10.1-256/512 since
> these -mavx10.1-256/512 is quite controversial.
>
> Just to clarify, -mno-evex512 -mavx512f should not enable 512 bit vector
> right?
I think it
On Wed, Aug 23, 2023 at 4:16 PM Jakub Jelinek wrote:
>
> On Wed, Aug 23, 2023 at 01:57:59AM +, Jiang, Haochen wrote:
> > > > Let's assume there's no detla now, AVX10.1-512 is equal to
> > > > AVX512{F,VL,BW,DQ,CD,BF16,FP16,VBMI,VBMI2,VNNI,IFMA,BITALG,VPOPCNTDQ}
> > > > > other stuff.
> > > >
On Wed, Aug 23, 2023 at 3:33 PM Richard Biener
wrote:
>
> On Tue, Aug 22, 2023 at 4:36 PM Hongtao Liu wrote:
> >
> > On Tue, Aug 22, 2023 at 9:54 PM Jakub Jelinek wrote:
> > >
> > > On Tue, Aug 22, 2023 at 09:35:44PM +0800, Hongtao Liu wrote:
> > > > Ok, then we can't avoid TARGET_AVX10_1 in
On Wed, Aug 23, 2023 at 01:57:59AM +, Jiang, Haochen wrote:
> > > Let's assume there's no detla now, AVX10.1-512 is equal to
> > > AVX512{F,VL,BW,DQ,CD,BF16,FP16,VBMI,VBMI2,VNNI,IFMA,BITALG,VPOPCNTDQ}
> > > > other stuff.
> > > > The current common/config/i386/i386-common.cc
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, August 23, 2023 3:32 PM
> To: Hongtao Liu
> Cc: Jakub Jelinek ; Jiang, Haochen
> ; ZiNgA BuRgA ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: Intel AVX10.1 Compiler Design and Support
>
> On Tue, A
On Tue, Aug 22, 2023 at 4:36 PM Hongtao Liu wrote:
>
> On Tue, Aug 22, 2023 at 9:54 PM Jakub Jelinek wrote:
> >
> > On Tue, Aug 22, 2023 at 09:35:44PM +0800, Hongtao Liu wrote:
> > > Ok, then we can't avoid TARGET_AVX10_1 in those existing 256/128-bit
> > > evex instruction patterns.
> >
> >
> -Original Message-
> From: Hongtao Liu
> Sent: Wednesday, August 23, 2023 10:19 AM
> To: Jiang, Haochen
> Cc: Jakub Jelinek ; Richard Biener
> ; ZiNgA BuRgA ;
> gcc-patches@gcc.gnu.org
> Subject: Re: Intel AVX10.1 Compiler Design and Support
>
> On Wed,
On Wed, Aug 23, 2023 at 9:58 AM Jiang, Haochen wrote:
>
> > -Original Message-
> > From: Jakub Jelinek
> > Sent: Tuesday, August 22, 2023 11:02 PM
> > To: Hongtao Liu
> > Cc: Richard Biener ; Jiang, Haochen
> > ; ZiNgA BuRgA ; gcc-
> > patc.
> -Original Message-
> From: Jakub Jelinek
> Sent: Tuesday, August 22, 2023 11:02 PM
> To: Hongtao Liu
> Cc: Richard Biener ; Jiang, Haochen
> ; ZiNgA BuRgA ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: Intel AVX10.1 Compiler Design and Support
>
> On Tue, Au
On Tue, Aug 22, 2023 at 10:35:55PM +0800, Hongtao Liu wrote:
> Let's assume there's no detla now, AVX10.1-512 is equal to
> AVX512{F,VL,BW,DQ,CD,BF16,FP16,VBMI,VBMI2,VNNI,IFMA,BITALG, VPOPCNTDQ}
> > other stuff.
> > The current common/config/i386/i386-common.cc OPTION_MASK_ISA*SET* would be
> >
On Tue, Aug 22, 2023 at 9:35 PM Hongtao Liu wrote:
>
> On Tue, Aug 22, 2023 at 9:24 PM Richard Biener
> wrote:
> >
> > On Tue, Aug 22, 2023 at 3:16 PM Jakub Jelinek wrote:
> > >
> > > On Tue, Aug 22, 2023 at 09:02:29PM +0800, Hongtao Liu wrote:
> > > > > Agreed. And I still think -mevex512 vs.
On Tue, Aug 22, 2023 at 9:54 PM Jakub Jelinek wrote:
>
> On Tue, Aug 22, 2023 at 09:35:44PM +0800, Hongtao Liu wrote:
> > Ok, then we can't avoid TARGET_AVX10_1 in those existing 256/128-bit
> > evex instruction patterns.
>
> Why?
> Internally for md etc. purposes, we should have the current
>
On Tue, Aug 22, 2023 at 09:35:44PM +0800, Hongtao Liu wrote:
> Ok, then we can't avoid TARGET_AVX10_1 in those existing 256/128-bit
> evex instruction patterns.
Why?
Internally for md etc. purposes, we should have the current
TARGET_AVX512* etc. ISA flags, plus one new one, whatever we call it
On Tue, Aug 22, 2023 at 9:24 PM Richard Biener
wrote:
>
> On Tue, Aug 22, 2023 at 3:16 PM Jakub Jelinek wrote:
> >
> > On Tue, Aug 22, 2023 at 09:02:29PM +0800, Hongtao Liu wrote:
> > > > Agreed. And I still think -mevex512 vs. -mno-evex512 is the best option
> > > > name to represent whether
On Tue, Aug 22, 2023 at 3:16 PM Jakub Jelinek wrote:
>
> On Tue, Aug 22, 2023 at 09:02:29PM +0800, Hongtao Liu wrote:
> > > Agreed. And I still think -mevex512 vs. -mno-evex512 is the best option
> > > name to represent whether the effective ISA set allows 512-bit vectors or
> > > not. I think
On Tue, Aug 22, 2023 at 09:02:29PM +0800, Hongtao Liu wrote:
> > Agreed. And I still think -mevex512 vs. -mno-evex512 is the best option
> > name to represent whether the effective ISA set allows 512-bit vectors or
> > not. I think -mavx10.1 -mno-avx512cd should be fine. And, -mavx10.1-256
> >
On Tue, Aug 22, 2023 at 4:34 PM Jakub Jelinek wrote:
>
> On Tue, Aug 22, 2023 at 09:36:15AM +0200, Richard Biener via Gcc-patches
> wrote:
> > I think internally we should have conditional 512bit support work across
> > AVX512 and AVX10.
> >
> > I also think it makes sense to _internally_ have
On Tue, Aug 22, 2023 at 10:53 AM Jiang, Haochen wrote:
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Tuesday, August 22, 2023 4:36 PM
> > To: Jakub Jelinek
> > Cc: Jiang, Haochen ; ZiNgA BuRgA
> > ; Hongtao Liu ; gcc-
> > patc.
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, August 22, 2023 4:36 PM
> To: Jakub Jelinek
> Cc: Jiang, Haochen ; ZiNgA BuRgA
> ; Hongtao Liu ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: Intel AVX10.1 Compiler Design and Support
>
> On Tue,
On Tue, Aug 22, 2023 at 10:34 AM Jakub Jelinek wrote:
>
> On Tue, Aug 22, 2023 at 09:36:15AM +0200, Richard Biener via Gcc-patches
> wrote:
> > I think internally we should have conditional 512bit support work across
> > AVX512 and AVX10.
> >
> > I also think it makes sense to _internally_ have
On Tue, Aug 22, 2023 at 09:36:15AM +0200, Richard Biener via Gcc-patches wrote:
> I think internally we should have conditional 512bit support work across
> AVX512 and AVX10.
>
> I also think it makes sense to _internally_ have AVX10.1 (10.1!) just
> enable the respective AVX512 features.
On Tue, Aug 22, 2023 at 5:20 AM Jiang, Haochen wrote:
>
> > -Original Message-
> > From: ZiNgA BuRgA
> > Sent: Monday, August 21, 2023 5:27 PM
> > To: Richard Biener ; Hongtao Liu
> >
> > Cc: Jiang, Haochen ; gcc-patches@gcc.gnu.org
> &g
> -Original Message-
> From: ZiNgA BuRgA
> Sent: Monday, August 21, 2023 5:27 PM
> To: Richard Biener ; Hongtao Liu
>
> Cc: Jiang, Haochen ; gcc-patches@gcc.gnu.org
> Subject: Re: Intel AVX10.1 Compiler Design and Support
>
> Another way (not saying this i
On Mon, Aug 21, 2023 at 5:35 PM Richard Biener
wrote:
>
> On Mon, Aug 21, 2023 at 10:28 AM Hongtao Liu wrote:
> >
> > On Mon, Aug 21, 2023 at 4:09 PM Jakub Jelinek wrote:
> > >
> > > On Mon, Aug 21, 2023 at 09:36:16AM +0200, Richard Biener via Gcc-patches
> > > wrote:
> > > > > On Sun, Aug 20,
On Mon, Aug 21, 2023 at 11:34 AM Richard Biener
wrote:
>
> On Mon, Aug 21, 2023 at 10:28 AM Hongtao Liu wrote:
> >
> > On Mon, Aug 21, 2023 at 4:09 PM Jakub Jelinek wrote:
> > >
> > > On Mon, Aug 21, 2023 at 09:36:16AM +0200, Richard Biener via Gcc-patches
> > > wrote:
> > > > > On Sun, Aug
On Mon, Aug 21, 2023 at 10:28 AM Hongtao Liu wrote:
>
> On Mon, Aug 21, 2023 at 4:09 PM Jakub Jelinek wrote:
> >
> > On Mon, Aug 21, 2023 at 09:36:16AM +0200, Richard Biener via Gcc-patches
> > wrote:
> > > > On Sun, Aug 20, 2023 at 6:44 AM ZiNgA BuRgA via Gcc-patches
> > > > wrote:
> > > > >
Another way (not saying this is better, just throwing out ideas) is to
break AVX10.1 into all the AVX-512 subsets.
So you'd have something like -mavx10.1-256-vl, -mavx10.1-512-vbmi etc.
* -mavx10.1-256 would effectively be an alias for all the 128+256-bit
subsets, and set the __AVX10_1__
On Mon, Aug 21, 2023 at 4:38 PM Jakub Jelinek wrote:
>
> On Mon, Aug 21, 2023 at 04:28:20PM +0800, Hongtao Liu wrote:
> > We have an undocumented option mavx10-max-512bit.
>
> How it is called internally is one thing, but it is weird to use
> avx10 in an option name which would be meant for
On Mon, Aug 21, 2023 at 04:28:20PM +0800, Hongtao Liu wrote:
> We have an undocumented option mavx10-max-512bit.
How it is called internally is one thing, but it is weird to use
avx10 in an option name which would be meant for finding common subset
of -mavx512xxx and -mavx10.1-256.
Jakub
On Mon, Aug 21, 2023 at 4:09 PM Jakub Jelinek wrote:
>
> On Mon, Aug 21, 2023 at 09:36:16AM +0200, Richard Biener via Gcc-patches
> wrote:
> > > On Sun, Aug 20, 2023 at 6:44 AM ZiNgA BuRgA via Gcc-patches
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > With the proposed design of these
On Mon, Aug 21, 2023 at 09:36:16AM +0200, Richard Biener via Gcc-patches wrote:
> > On Sun, Aug 20, 2023 at 6:44 AM ZiNgA BuRgA via Gcc-patches
> > wrote:
> > >
> > > Hi,
> > >
> > > With the proposed design of these switches, how would I restrict AVX10.1
> > > to particular AVX-512 subsets?
> >
Thanks for the responses!
It'd be unfortunate if AVX10 adoption is desired, yet there's no way to
compile existing 256-bit code to be compatible with it.
Relying on SDE to check the output isn't a particularly viable solution.
It looks like `-mavx512vl -mprefer-vector-width=256` is my best
On Mon, Aug 21, 2023 at 3:20 AM Hongtao Liu via Gcc-patches
wrote:
>
> On Sun, Aug 20, 2023 at 6:44 AM ZiNgA BuRgA via Gcc-patches
> wrote:
> >
> > Hi,
> >
> > With the proposed design of these switches, how would I restrict AVX10.1
> > to particular AVX-512 subsets?
> We can't, avx10.1 is taken
On Sun, Aug 20, 2023 at 6:44 AM ZiNgA BuRgA via Gcc-patches
wrote:
>
> Hi,
>
> With the proposed design of these switches, how would I restrict AVX10.1
> to particular AVX-512 subsets?
We can't, avx10.1 is taken as an indivisible ISA which contains all
AVX512 related instructions.
> We’ve been
> Am 20.08.2023 um 00:45 schrieb ZiNgA BuRgA via Gcc-patches
> :
>
> Hi,
>
> With the proposed design of these switches, how would I restrict AVX10.1 to
> particular AVX-512 subsets?
>
> For example, usage of the |_mm256_rol_epi32| intrinsic should be compatible
> on any AVX10/256
Hi,
With the proposed design of these switches, how would I restrict AVX10.1
to particular AVX-512 subsets?
For example, usage of the |_mm256_rol_epi32| intrinsic should be
compatible on any AVX10/256 implementation, /as well as /any AVX-512VL
without AVX10 implementation (e.g. Skylake-X).
On Thu, 10 Aug 2023, Richard Biener via Gcc-patches wrote:
> 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
>
On Thu, Aug 10, 2023 at 03:08:31PM +, Jiang, Haochen via Gcc-patches wrote:
> There are lots of discussions on arch level and ABIs and I really appreciate
> that.
>
> For the arch level issue, it might be a little early to discuss and should
> not block
> these patches.
>
> For ABI issue,
On Thu, Aug 10, 2023 at 03:08:11PM +, Zhang, Annita via Gcc-patches wrote:
> > 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
Hi all,
There are lots of discussions on arch level and ABIs and I really appreciate
that.
For the arch level issue, it might be a little early to discuss and should not
block
these patches.
For ABI issue, the problem actually comes from the current behavior between
GCC and clang/LLVM are
tao Liu ; gcc-
> patc...@gcc.gnu.org; ubiz...@gmail.com; Liu, Hongtao
> ; Zhang, Annita ; x86-64-
> abi ; llvm-dev ;
> Craig Topper ; Richard Biener
>
> Subject: RE: Intel AVX10.1 Compiler Design and Support
>
> > -Original Message-
> > From: Jan Beulich
> >
t; x86-64-abi ; llvm-dev d...@lists.llvm.org>; Craig Topper ; Richard Biener
>
> 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
On Thu, Aug 10, 2023 at 3:31 PM Jan Beulich wrote:
>
> 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
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
> 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
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
> 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
On Wed, Aug 09, 2023 at 08:43:00PM +, Joseph Myers wrote:
> 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
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
; ; x86-64-abi ;
> llvm-dev ; Craig Topper ;
> Joseph Myers
> Subject: RE: Intel AVX10.1 Compiler Design and Support
>
> Hello,
>
> On Wed, 9 Aug 2023, Zhang, Annita via Gcc-patches wrote:
>
> > > The question is whether you want to mandate the 16-bit floating
> &
Hello,
On Wed, 9 Aug 2023, Zhang, Annita via Gcc-patches wrote:
> > The question is whether you want to mandate the 16-bit floating point
> > extensions. You might get better adoption if you stay compatible with
> > shipping
> > CPUs. Furthermore, the 256-bit tuning apparently benefits
; llvm-dev ;
> Craig Topper ; Joseph Myers
>
> Subject: Re: Intel AVX10.1 Compiler Design and Support
>
> * Hongtao Liu:
>
> > On Wed, Aug 9, 2023 at 3:17 PM Jan Beulich wrote:
> >> Aiui these ABI levels were intended to be incremental, i.e. higher
> &
On Wed, Aug 9, 2023 at 5:15 PM Florian Weimer wrote:
>
> * Hongtao Liu:
>
> > On Wed, Aug 9, 2023 at 3:17 PM Jan Beulich wrote:
> >> Aiui these ABI levels were intended to be incremental, i.e. higher versions
> >> would include everything earlier ones cover. Without such a guarantee, how
> >>
* Hongtao Liu:
> On Wed, Aug 9, 2023 at 3:17 PM Jan Beulich wrote:
>> Aiui these ABI levels were intended to be incremental, i.e. higher versions
>> would include everything earlier ones cover. Without such a guarantee, how
>> would you propose compatibility checks to be implemented in a way
On Wed, Aug 9, 2023 at 4:14 PM Florian Weimer wrote:
>
> * Richard Biener via Gcc-patches:
>
> > 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
* Richard Biener via Gcc-patches:
> 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
On 09.08.2023 09:38, Hongtao Liu wrote:
> On Wed, Aug 9, 2023 at 3:17 PM Jan Beulich wrote:
>>
>> On 09.08.2023 04:14, Hongtao Liu wrote:
>>> On Wed, Aug 9, 2023 at 9:21 AM Hongtao Liu wrote:
On Wed, Aug 9, 2023 at 3:55 AM Joseph Myers
wrote:
>
> Do you have any comments
On Wed, Aug 9, 2023 at 3:17 PM Jan Beulich wrote:
>
> On 09.08.2023 04:14, Hongtao Liu wrote:
> > On Wed, Aug 9, 2023 at 9:21 AM Hongtao Liu wrote:
> >>
> >> On Wed, Aug 9, 2023 at 3:55 AM Joseph Myers
> >> wrote:
> >>>
> >>> Do you have any comments on the interaction of AVX10 with the
> >>>
On 09.08.2023 04:14, Hongtao Liu wrote:
> On Wed, Aug 9, 2023 at 9:21 AM Hongtao Liu wrote:
>>
>> On Wed, Aug 9, 2023 at 3:55 AM Joseph Myers wrote:
>>>
>>> Do you have any comments on the interaction of AVX10 with the
>>> micro-architecture levels defined in the ABI (and supported with
>>>
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, August 8, 2023 8:45 PM
> To: Jiang, Haochen
> Cc: Jakub Jelinek ; gcc-patches@gcc.gnu.org;
> ubiz...@gmail.com; Liu, Hongtao
> Subject: Re: Intel AVX10.1 Compiler Design and Support
>
> On Tue, Au
-abi a...@googlegroups.com>; llvm-dev ; Craig Topper
>
> Subject: Re: Intel AVX10.1 Compiler Design and Support
>
>
>
> > Am 09.08.2023 um 06:02 schrieb Phoebe Wang via Gcc-patches patc...@gcc.gnu.org>:
> >
> > I have some proposals about unifying ABI o
> Am 09.08.2023 um 06:02 schrieb Phoebe Wang via Gcc-patches
> :
>
> 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
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
: Hongtao Liu
Sent: Wednesday, August 9, 2023 10:19 AM
To: Joseph Myers
Cc: Jiang, Haochen ; gcc-patches@gcc.gnu.org;
ubiz...@gmail.com; Liu, Hongtao ; Zhang, Annita
; Wang, Phoebe ; x86-64-abi
; llvm-dev ; Craig Topper
Subject: Re: Intel AVX10.1 Compiler Design and Support
On Wed, Aug 9, 2023
On Wed, Aug 9, 2023 at 10:14 AM Hongtao Liu wrote:
>
> On Wed, Aug 9, 2023 at 9:21 AM Hongtao Liu wrote:
> >
> > On Wed, Aug 9, 2023 at 3:55 AM Joseph Myers wrote:
> > >
> > > Do you have any comments on the interaction of AVX10 with the
> > > micro-architecture levels defined in the ABI (and
On Wed, Aug 9, 2023 at 9:21 AM Hongtao Liu wrote:
>
> On Wed, Aug 9, 2023 at 3:55 AM Joseph Myers 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
On Wed, Aug 9, 2023 at 10:06 AM Hongtao Liu wrote:
>
> On Tue, Aug 8, 2023 at 8:45 PM Richard Biener via Gcc-patches
> wrote:
> >
> > On Tue, Aug 8, 2023 at 10:15 AM Jiang, Haochen via Gcc-patches
> > wrote:
> > >
> > > Hi Jakub,
> > >
> > > > So, what does this imply for the current ISAs?
> >
On Tue, Aug 8, 2023 at 8:45 PM Richard Biener via Gcc-patches
wrote:
>
> On Tue, Aug 8, 2023 at 10:15 AM Jiang, Haochen via Gcc-patches
> wrote:
> >
> > Hi Jakub,
> >
> > > So, what does this imply for the current ISAs?
> >
> > AVX10 will imply AVX2 on the ISA level. And we suppose AVX10 is an
>
On Wed, Aug 9, 2023 at 3:55 AM Joseph Myers 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
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
On Tue, Aug 8, 2023 at 10:15 AM Jiang, Haochen via Gcc-patches
wrote:
>
> Hi Jakub,
>
> > So, what does this imply for the current ISAs?
>
> AVX10 will imply AVX2 on the ISA level. And we suppose AVX10 is an
> independent ISA feature set. Although sharing the same instructions and
> encodings,
Hi Jakub,
> So, what does this imply for the current ISAs?
AVX10 will imply AVX2 on the ISA level. And we suppose AVX10 is an
independent ISA feature set. Although sharing the same instructions and
encodings, AVX10 and AVX512 are conceptual independent features, which
means they are orthogonal.
On Tue, Aug 08, 2023 at 03:13:09PM +0800, Haochen Jiang via Gcc-patches wrote:
> We will send out our initial support of AVX10 and some sample patches in this
> mailing thread. And there will be more coming up afterwards. Therefore, we
> would
> like to share our proposed AVX10 design in GCC.
>
74 matches
Mail list logo
