On 4/10/23 08:48, juzhe.zh...@rivai.ai wrote:
From: Juzhe-Zhong
According RVV ISA:
https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#vector-type-register-vtype
We have LMUL: 1/8, 1/4, 1/2, 1, 2, 4, 8
Also, for segment instructions, we have tuple type for NF = 2 ~ 8.
For example,
On Mon, Apr 10, 2023 at 10:48:08PM +0800, juzhe.zh...@rivai.ai wrote:
> * rtl.h (struct GTY): Ditto.
> --- a/gcc/rtl.h
> +++ b/gcc/rtl.h
> @@ -313,7 +313,7 @@ struct GTY((desc("0"), tag("0"),
>ENUM_BITFIELD(rtx_code) code: 16;
>
>/* The kind of value the expression has. */
> -
On Mon, Apr 10, 2023 at 08:54:12AM -0600, Jeff Law wrote:
> This is likely going to be very controversial. It's going to increase the
> size of two of most heavily used data structures in GCC (rtx and trees).
>
> The first thing I would ask is whether or not we really need the full matrix
> in pr
On 4/10/23 09:18, Jakub Jelinek wrote:
On Mon, Apr 10, 2023 at 08:54:12AM -0600, Jeff Law wrote:
This is likely going to be very controversial. It's going to increase the
size of two of most heavily used data structures in GCC (rtx and trees).
The first thing I would ask is whether or not w
On 4/10/23 09:33, juzhe.zh...@rivai.ai wrote:
I saw many redundant scalar modes:
E_CDImode, /* machmode.def:267 */
#define HAVE_CDImode
#ifdef USE_ENUM_MODES
#define CDImode E_CDImode
#else
#define CDImode (complex_mode ((complex_mode::from_int) E_CDImode))
#endif
E_CTImode
On 4/10/23 09:22, juzhe.zh...@rivai.ai wrote:
Yeah, aarch64 already has 178, RVV has much more types than aarch64...
You can see intrinsic doc:
https://github.com/riscv-non-isa/rvv-intrinsic-doc/blob/eopc/tuple-type-for-seg-load-store/auto-generated/intrinsic_funcs/02_vector_unit-stride_segmen
writes:
> ARM SVE has：svint8_t, svint8x2_t, svint8x3_t, svint8x4_t
> As far as I known, they don't have tuple type for partial vector.
Yeah, there are no separate types for partial vectors, but there
are separate modes. E.g. VNx2QI is a partial vector of QIs,
with each QI stored in a 64-bit cont
On Tue, Apr 11, 2023 at 10:46:25AM +0100, Richard Sandiford wrote:
> I agree with all the comments about the danger of growing the number of
> modes too much. But it looks like rtx_def should be easy to rearrange.
> Unless I'm missing something, there are less than 256 rtx codes at
> present. So
On 11/04/2023 10:46, Richard Sandiford via Gcc-patches wrote:
writes:
ARM SVE has：svint8_t, svint8x2_t, svint8x3_t, svint8x4_t
As far as I known, they don't have tuple type for partial vector.
Yeah, there are no separate types for partial vectors, but there
are separate modes. E.g. VNx2QI
Richard Earnshaw writes:
> On 11/04/2023 10:46, Richard Sandiford via Gcc-patches wrote:
>> writes:
>>> ARM SVE has：svint8_t, svint8x2_t, svint8x3_t, svint8x4_t
>>> As far as I known, they don't have tuple type for partial vector.
>>
>> Yeah, there are no separate types for partial vectors, but
On Tue, 11 Apr 2023, Richard Sandiford wrote:
> writes:
> > ARM SVE has?svint8_t, svint8x2_t, svint8x3_t, svint8x4_t
> > As far as I known, they don't have tuple type for partial vector.
>
> Yeah, there are no separate types for partial vectors, but there
> are separate modes. E.g. VNx2QI is a
Richard Biener writes:
> On Tue, 11 Apr 2023, Richard Sandiford wrote:
>
>> writes:
>> > ARM SVE has?svint8_t, svint8x2_t, svint8x3_t, svint8x4_t
>> > As far as I known, they don't have tuple type for partial vector.
>>
>> Yeah, there are no separate types for partial vectors, but there
>> are s
钟居哲 writes:
> Yeah, like kito said.
> Turns out the tuple type model in ARM SVE is the optimal solution for RVV.
> And we like ARM SVE style implmentation.
>
> And now we see swapping rtx_code and mode in rtx_def can make rtx_def overal
> not exceed 64 bit.
> But it seems that there is still prob
On Thu, 13 Apr 2023, Richard Sandiford wrote:
> ??? writes:
> > Yeah, like kito said.
> > Turns out the tuple type model in ARM SVE is the optimal solution for RVV.
> > And we like ARM SVE style implmentation.
> >
> > And now we see swapping rtx_code and mode in rtx_def can make rtx_def
> > over
On Thu, 13 Apr 2023, Richard Biener via Gcc-patches wrote:
> On Thu, 13 Apr 2023, Richard Sandiford wrote:
>
> > ??? writes:
> > > Yeah, like kito said.
> > > Turns out the tuple type model in ARM SVE is the optimal solution for RVV.
> > > And we like ARM SVE style implmentation.
> > >
> > > And
On Fri, 14 Apr 2023, Hans-Peter Nilsson wrote:
> On Thu, 13 Apr 2023, Richard Biener via Gcc-patches wrote:
>
> > On Thu, 13 Apr 2023, Richard Sandiford wrote:
> >
> > > ??? writes:
> > > > Yeah, like kito said.
> > > > Turns out the tuple type model in ARM SVE is the optimal solution for
> >
On Mon, 17 Apr 2023, Richard Biener wrote:
> On Fri, 14 Apr 2023, Hans-Peter Nilsson wrote:
> > If after all, a change to the size of the code and mode
> > bit-fields in rtx_def is necessary, like to still fit 64 bytes
(Sorry: 64 bits, not counting the union u.)
> > such become non-byte sizes *
On 5/6/23 19:55, Li, Pan2 wrote:
It looks like we cannot simply swap the code and mode in rtx_def, the code may
have to be the same bits as the tree_code in tree_base. Or we will meet ICE
like below.
rtx_def code 16 => 8 bits.
rtx_def mode 8 => 16 bits.
static inline decl_or_value
dv_from_
I see. Thank you, will have a try soon.
Pan
-Original Message-
From: Jeff Law
Sent: Sunday, May 7, 2023 11:24 PM
To: Li, Pan2 ; Kito Cheng
Cc: juzhe.zh...@rivai.ai; rguenther ; richard.sandiford
; gcc-patches ; palmer
; jakub
Subject: Re: [PATCH] machine_mode type size: Extend enum
On Sun, 7 May 2023, Jeff Law wrote:
>
>
> On 5/6/23 19:55, Li, Pan2 wrote:
> > It looks like we cannot simply swap the code and mode in rtx_def, the code
> > may have to be the same bits as the tree_code in tree_base. Or we will meet
> > ICE like below.
> >
> > rtx_def code 16 => 8 bits.
> > rt
...@rivai.ai; richard.sandiford ;
gcc-patches ; palmer ; jakub
Subject: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to
16-bit
On Sun, 7 May 2023, Jeff Law wrote:
>
>
> On 5/6/23 19:55, Li, Pan2 wrote:
> > It looks like we cannot simply swap the code and mode in rt
essage-
From: Li, Pan2
Sent: Monday, May 8, 2023 2:42 PM
To: Richard Biener ; Jeff Law
Cc: Kito Cheng ; juzhe.zh...@rivai.ai; richard.sandiford
; gcc-patches ; palmer
; jakub
Subject: RE: [PATCH] machine_mode type size: Extend enum size from 8-bit to
16-bit
Oops. Actually I am patching a vers
and keep you posted.
>
> Pan
>
> -Original Message-
> From: Richard Biener
> Sent: Monday, May 8, 2023 2:30 PM
> To: Jeff Law
> Cc: Li, Pan2 ; Kito Cheng ;
> juzhe.zh...@rivai.ai; richard.sandiford ;
> gcc-patches ; palmer ; jakub
>
> Subject: Re: [P
ff Law
>
> Cc: Kito Cheng ; juzhe.zh...@rivai.ai;
> richard.sandiford ; gcc-patches
> ; palmer ; jakub
>
> Subject: RE: [PATCH] machine_mode type size: Extend enum size from
> 8-bit to 16-bit
>
> Oops. Actually I am patching a version as you mentioned like storage
&g
; palmer ; jakub
Subject: RE: [PATCH] machine_mode type size: Extend enum size from 8-bit to
16-bit
After the bits patch like below.
rtx_def code 16 => 8 bits.
rtx_def mode 8 => 16 bits.
tree_base code unchanged.
The structure layout of both the rtx_def and tree_base will be something
s
66818255397 +0.6%|
> 166819397831 +0.6%
>
> Pan
>
>
> -Original Message-
> From: Li, Pan2
> Sent: Monday, May 8, 2023 4:06 PM
> To: Richard Biener
> Cc: Jeff Law ; Kito Cheng ;
> juzhe.zh...@rivai.ai; richard.sandiford ;
> gcc-patche
its.
> rtx_def mode 8 => 12 bits.
> tree_base code 16 => 12 bits.
>
> Pan
>
> -Original Message-
> From: Richard Biener
> Sent: Monday, May 8, 2023 3:38 PM
> To: Li, Pan2
> Cc: Jeff Law ; Kito Cheng ;
> juzhe.zh...@rivai.ai; richard.sandiford ;
>
gly, but a simplistic
> > conversion isn't what we want.
> >
> > An alternative "solution" might be to also shrink tree_code when we shrink
> > rtx_code and keep the 1:1 overlap.
> >
> > Richard.
> >
> >> I will re-trigger the
rtx_def mode 8 => 12 bits.
> > tree_base code 16 => 12 bits.
> >
> > Pan
> >
> > -Original Message-
> > From: Richard Biener
> > Sent: Monday, May 8, 2023 3:38 PM
> > To: Li, Pan2
> > Cc: Jeff Law ; Kito Cheng
> > ; juzhe.zh.
Message-
From: Li, Pan2
Sent: Tuesday, May 9, 2023 7:51 PM
To: Richard Biener ; Richard Sandiford
Cc: Jeff Law ; Kito Cheng ;
juzhe.zh...@rivai.ai; gcc-patches ; palmer
; jakub
Subject: RE: [PATCH] machine_mode type size: Extend enum size from 8-bit to
16-bit
Sure thing, I will have a try
; Richard Sandiford
Cc: Jeff Law ; Kito Cheng ;
juzhe.zh...@rivai.ai; gcc-patches ; palmer
; jakub
Subject: RE: [PATCH] machine_mode type size: Extend enum size from 8-bit to
16-bit
Just migrated to the pointer_mux for the var-tracking, it works well even the
bitsize of tree_base code is different
.zh...@rivai.ai
From: Jeff Law
Date: 2023-04-10 22:54
To: juzhe.zhong; gcc-patches
CC: kito.cheng; palmer; jakub; richard.sandiford; rguenther
Subject: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to
16-bit
On 4/10/23 08:48, juzhe.zh...@rivai.ai wrote:
> From: Juzhe
type size: Extend enum size from 8-bit to
16-bit
On 4/10/23 08:48, juzhe.zh...@rivai.ai wrote:
> From: Juzhe-Zhong
>
> According RVV ISA:
> https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#vector-type-register-vtype
> We have LMUL: 1/8, 1/4, 1/2, 1, 2, 4, 8
-patches; kito.cheng; palmer; richard.sandiford; rguenther
Subject: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to
16-bit
On Mon, Apr 10, 2023 at 08:54:12AM -0600, Jeff Law wrote:
> This is likely going to be very controversial. It's going to increase the
> size of two o
: Re: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to
16-bit
Yeah, aarch64 already has 178, RVV has much more types than aarch64...
You can see intrinsic doc:
https://github.com/riscv-non-isa/rvv-intrinsic-doc/blob/eopc/tuple-type-for-seg-load-store/auto-generated/intrinsic_funcs
e.zh...@rivai.ai
From: Jeff Law
Date: 2023-04-11 04:36
To: Jakub Jelinek
CC: juzhe.zhong; gcc-patches; kito.cheng; palmer; richard.sandiford; rguenther
Subject: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to
16-bit
On 4/10/23 09:18, Jakub Jelinek wrote:
> On Mon, Ap
; richard.sandiford; rguenther
Subject: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to
16-bit
On 4/10/23 09:22, juzhe.zh...@rivai.ai wrote:
> Yeah, aarch64 already has 178, RVV has much more types than aarch64...
> You can see intrinsic doc:
> https://github.com/riscv-no
; jakub
CC: gcc-patches; kito.cheng; palmer; richard.sandiford; rguenther
Subject: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to
16-bit
On 4/10/23 09:22, juzhe.zh...@rivai.ai wrote:
> Yeah, aarch64 already has 178, RVV has much more types than aarch64...
> You c
On Mon, Apr 10, 2023 at 11:14:46PM +0800, juzhe.zh...@rivai.ai wrote:
> ARM SVE has：svint8_t, svint8x2_t, svint8x3_t, svint8x4_t
> As far as I known, they don't have tuple type for partial vector.
> However, for RVV not only has vint8m1_t, vint8m1x2_t, vint8m1x3_t,
> vint8m1x4_t, vint8m1x5_t, vint
quot;vint8mf8x3_t", I don't known
how to define such instruction RTL pattern. Should its dest operand mode be
BLKmode?
But we want the dest operand is a register operand.
juzhe.zh...@rivai.ai
From: Jakub Jelinek
Date: 2023-04-11 17:16
To: juzhe.zhong
CC: Jeff Law; gcc-patches; kito.che
?
Thanks for all comments.
juzhe.zh...@rivai.ai
From: Jakub Jelinek
Date: 2023-04-11 17:59
To: juzhe.zhong; Jeff Law; gcc-patches; kito.cheng; palmer; rguenther;
richard.sandiford
Subject: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to
16-bit
On Tue, Apr 11, 2023 at 10:46
On Tue, Apr 11, 2023 at 05:46:15PM +0800, juzhe.zh...@rivai.ai wrote:
> I am not sure whether aggregate type without a tuple mode can work for us.
> Here is the example:
>
> We already had a vector type "vint8mf8_t", the corresponding mode is
> VNx1SImode.
>
> Now we have an intrinsic as followi
inek
Date: 2023-04-11 18:11
To: juzhe.zh...@rivai.ai
CC: jeffreyalaw; gcc-patches; kito.cheng; palmer; richard.sandiford; rguenther;
Vladimir Makarov
Subject: Re: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to
16-bit
On Tue, Apr 11, 2023 at 05:46:15PM +0800, juzhe.zh...@rivai.ai
On Tue, Apr 11, 2023 at 06:25:58PM +0800, juzhe.zh...@rivai.ai wrote:
> Explicit sets multiple VNx1SImode with multiple dest operand and let RA to
> assign them with continguous regsiters
> will make RTL patterns in RVV hard to maintain.
Not necessarily. It can be handled through define_subst.
: juzhe.zhong; Jeff Law; gcc-patches; kito.cheng; palmer; jakub
Subject: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to
16-bit
Richard Biener writes:
> On Tue, 11 Apr 2023, Richard Sandiford wrote:
>
>> writes:
>> > ARM SVE has?svint8_t, svint8x2_t, svint8x3_t, svint8
Let me give more explanation why RISC-V vector need so many modes than AArch64.
The following will use "RVV" as an abbreviation for "RISC-V Vector"
instructions.
There are two key points here:
- RVV has a concept called LMUL - you can understand that as register
grouping, we can group up to 8 ad
On Tue, 11 Apr 2023, Kito Cheng wrote:
> Let me give more explanation why RISC-V vector need so many modes than
> AArch64.
>
> The following will use "RVV" as an abbreviation for "RISC-V Vector"
> instructions.
>
> There are two key points here:
>
> - RVV has a concept called LMUL - you can un
Hi Richard:
> > In order to model LMUL in backend, we have to the combination of
> > scalar type and LMUL; possible LMUL is 1, 2, 4, 8, 1/2, 1/4, 1/8 - 8
> > different types of LMUL, and we'll have QI, HI, SI, DI, HF, SF and DF,
> > so basically we'll have 7 (LMUL type) * 7 (scalar type) here.
>
>
On Wed, 12 Apr 2023, Kito Cheng wrote:
> Hi Richard:
>
> > > In order to model LMUL in backend, we have to the combination of
> > > scalar type and LMUL; possible LMUL is 1, 2, 4, 8, 1/2, 1/4, 1/8 - 8
> > > different types of LMUL, and we'll have QI, HI, SI, DI, HF, SF and DF,
> > > so basically
> > The concept of fractional LMUL is the same as the concept of AArch64's
> > partial SVE vectors,
> > so they can only access the lowest part, like SVE's partial vector.
> >
> > We want to spill/restore the exact size of those modes (1/2, 1/4,
> > 1/8), so adding dedicated modes for those partial
he.zh...@rivai.ai
From: Kito Cheng
Date: 2023-04-12 17:31
To: Richard Biener
CC: juzhe.zh...@rivai.ai; richard.sandiford; jeffreyalaw; gcc-patches; palmer;
jakub
Subject: Re: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to
16-bit
> > The concept of fractional LMUL is the same as
s?
Thank you so much for all comments.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-04-12 17:31
To: Richard Biener
CC: juzhe.zh...@rivai.ai; richard.sandiford; jeffreyalaw; gcc-patches; palmer;
jakub
Subject: Re: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to
16-b
~0.0%
>
> Pan
>
>
> -Original Message-
> From: Gcc-patches On
> Behalf Of ???
> Sent: Thursday, April 13, 2023 7:23 AM
> To: kito.cheng ; rguenther
> Cc: richard.sandiford ; Jeff Law
> ; gcc-patches ; palmer
> ; jakub
> Subject: Re: Re: [PATCH] mac
, 2023 2:25 PM
To: Li, Pan2
Cc: 钟居哲 ; kito.cheng ;
richard.sandiford ; Jeff Law
; gcc-patches ; palmer
; jakub
Subject: RE: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to
16-bit
On Fri, 5 May 2023, Li, Pan2 wrote:
> I tried the memory profiling by valgrind --tool=memch
| 12121745383 -1.5%
> > 458.sjeng | 3884712615 | 3755481930 -3.3%
> > 462.libquantum| 1966619940 | 1852274342 -5.8%
> > 464.h264ref | 19219365552 | 19050288201 ~0.0%
> > 471.omnetpp |
; 钟居哲; richard.sandiford; Jeff Law; gcc-patches; palmer; jakub
Subject: Re: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to
16-bit
Hi Pan:
Could you try to apply the following diff and measure again? This
makes tree_type_common size unchanged.
sizeof tree_type_common= 128
, Pan2
Cc: rguenther ; richard.sandiford
; jeffreyalaw ; gcc-patches
; palmer ; jakub
Subject: Re: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to
16-bit
Yeah, you should also swap mode and code in rtx_def according to Richard
suggestion
since it will not change the rtx_def
> Cc: rguenther ; richard.sandiford
> ; jeffreyalaw ; gcc-patches
> ; palmer ; jakub
>
> Subject: Re: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit
> to 16-bit
>
> Yeah, you should also swap mode and code in rtx_def according to Richard
> suggestion
> sin
, 2023 10:00 AM
> To: kito.cheng ; Li, Pan2
> Cc: rguenther ; richard.sandiford
> ; jeffreyalaw ;
> gcc-patches ; palmer ;
> jakub
> Subject: Re: Re: [PATCH] machine_mode type size: Extend enum size from
> 8-bit to 16-bit
>
> Yeah, you should also swap mode and code
; palmer ; jakub
Subject: RE: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to
16-bit
Yes, that makes sense, will have a try and keep you posted.
Pan
-Original Message-
From: Kito Cheng
Sent: Saturday, May 6, 2023 10:19 AM
To: Li, Pan2
Cc: juzhe.zh...@rivai.ai
ge-
From: Li, Pan2
Sent: Saturday, May 6, 2023 10:20 AM
To: Kito Cheng
Cc: juzhe.zh...@rivai.ai; rguenther ; richard.sandiford
; jeffreyalaw ; gcc-patches
; palmer ; jakub
Subject: RE: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to
16-bit
Yes, that makes sense, will have
-Original Message-
From: Li, Pan2
Sent: Saturday, May 6, 2023 10:20 AM
To: Kito Cheng
Cc: juzhe.zh...@rivai.ai; rguenther ; richard.sandiford
; jeffreyalaw ; gcc-patches
; palmer ; jakub
Subject: RE: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to
16-bit
Yes, th
62 matches
Mail list logo
