On Tue, Nov 28, 2023 at 5:21 PM Jeff Law wrote:
>
> On 11/28/23 12:56, Philipp Tomsich wrote:
>
> >> That's obviously a risky thing to do given it was sent right at the end
> >> of the window, but it meets the rules.
> >>
> >> Folks in the call seemed generally amenable to at least trying for 14,
On 11/28/23 12:56, Philipp Tomsich wrote:
That's obviously a risky thing to do given it was sent right at the end
of the window, but it meets the rules.
Folks in the call seemed generally amenable to at least trying for 14,
so unless anyone's opposed on the lists it seems like the way to
On 11/28/23 12:45, Palmer Dabbelt wrote:
IMO we're just stuck between a rock and a hard place here. Specifically,
this isn't just an assembly syntax change but also comes with a bunch of
behaviorial changes to the instructions in question -- I'm specifically
thinking of things like the
On Tue, 28 Nov 2023 at 20:31, Palmer Dabbelt wrote:
>
> On Wed, 22 Nov 2023 14:27:50 PST (-0800), jeffreya...@gmail.com wrote:
> > ...
>
> [Trimming everything else, as this is a big change. I'm also making it
> a new subject/thread, so folks can see.]
>
> > More generally, I think I need to
On Fri, 17 Nov 2023 16:01:27 PST (-0800), jeffreya...@gmail.com wrote:
On 11/17/23 16:16, 钟居哲 wrote:
>> I assume this hunk is meant for riscv_output_operand in riscv.cc. We
may also need to add '^' to the punct_valid_p hook. But yes, this is
the preferred way to go when all we need to do
On Wed, 22 Nov 2023 14:27:50 PST (-0800), jeffreya...@gmail.com wrote:
...
[Trimming everything else, as this is a big change. I'm also making it
a new subject/thread, so folks can see.]
More generally, I think I need to soften my prior statement about
deferring this to gcc-15. This code
I am less worry about the thead vector combined with other zv extension,
instead we should reject those combinations at all.
My reason is thead vector is transitional products, they won't have any
further new products with that longer, also it's not compatible with all
other zv extension in
On Wed, Nov 22, 2023 at 11:48 PM Kito Cheng wrote:
>
> I am less worry about the thead vector combined with other zv extension,
> instead we should reject those combinations at all.
>
> My reason is thead vector is transitional products, they won't have any
> further new products with that
ot;th." in vrev.v
instruction.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-11-23 06:27
To: Christoph Müllner; 钟居哲
CC: gcc-patches; kito.cheng; kito.cheng; cooper.joshua; rdapp.gcc;
philipp.tomsich; Cooper Qu; jinma; Nelson Chu
Subject: Re: RISC-V: Support XTheadVector extensions
O
On 11/22/23 07:24, Christoph Müllner wrote:
On Wed, Nov 22, 2023 at 2:52 PM 钟居哲 wrote:
I am totally ok to approve theadvector on GCC-14 before stage 3 close
as long as it doesn't touch the current RVV codes too much and binutils
supports theadvector.
I have provided the draft approach:
h...@rivai.ai
>
>
> From: Christoph Müllner
> Date: 2023-11-22 18:07
> To: juzhe.zh...@rivai.ai
> CC: gcc-patches; kito.cheng; Kito.cheng; cooper.joshua; Robin Dapp;
> jeffreyalaw; Philipp Tomsich; Cooper Qu; Jin Ma; Nelson Chu
> Subject: Re: RISC-V: Support XTheadVector exte
-patches; kito.cheng; Kito.cheng; cooper.joshua; Robin Dapp;
jeffreyalaw; Philipp Tomsich; Cooper Qu; Jin Ma; Nelson Chu
Subject: Re: RISC-V: Support XTheadVector extensions
Hi Juzhe,
Sorry for the late reply, but I was not on CC, so I missed this email.
On Fri, Nov 17, 2023 at 2:41 PM juzhe.zh
Hi Juzhe,
Sorry for the late reply, but I was not on CC, so I missed this email.
On Fri, Nov 17, 2023 at 2:41 PM juzhe.zh...@rivai.ai
wrote:
>
> Ok. I just read the theadvector extension.
>
> https://github.com/T-head-Semi/thead-extension-spec/blob/master/xtheadvector.adoc
>
> Theadvector is
Add theadvector gating on target-support.exp. We don't want to run
> theadvector test
> when we don't enable theadvector.
>
> Thanks.
>
> --
> juzhe.zh...@rivai.ai
>
>
> *From:* Kito Cheng
> *Date:* 2023-11-18 18:32
> *To:* Philipp T
ai.ai; gcc-patches; kito.cheng; cooper.joshua;
Robin Dapp; jkridner
Subject: Re: RISC-V: Support XTheadVector extensions
I guess it would be worth to state my thought publicly:
I *support* adding the T-head vector (a.k.a. vector 0.7) to upstream
GCC since T-Head vector already ships a large enough number of
; cooper.joshua;
Robin Dapp; jkridner
Subject: Re: RISC-V: Support XTheadVector extensions
I guess it would be worth to state my thought publicly:
I *support* adding the T-head vector (a.k.a. vector 0.7) to upstream
GCC since T-Head vector already ships a large enough number of boards,
also it's
I guess it would be worth to state my thought publicly:
I *support* adding the T-head vector (a.k.a. vector 0.7) to upstream
GCC since T-Head vector already ships a large enough number of boards,
also it's not really T-head's problem as Palmer described in another
mail.
My biggest concern before
On Fri, 17 Nov 2023 at 22:47, Jeff Law wrote:
>
>
>
> On 11/17/23 04:39, juzhe.zh...@rivai.ai wrote:
> > 90% theadvector extension reusing current RVV 1.0 instructions patterns:
> > Just change ASM, For example:
> >
> > @@ -2923,7 +2923,7 @@ (define_insn "*pred_mulh_scalar"
> >
On Fri, Nov 17, 2023 at 12:40 PM juzhe.zh...@rivai.ai
wrote:
>
> 90% theadvector extension reusing current RVV 1.0 instructions patterns:
> Just change ASM, For example:
>
> @@ -2923,7 +2923,7 @@ (define_insn "*pred_mulh_scalar"
> (match_operand:VFULLI_D 3 "register_operand" "vr,vr, vr,
w
Date: 2023-11-18 08:01
To: 钟居哲; palmer
CC: gcc-patches; kito.cheng; kito.cheng; cooper.joshua; rdapp.gcc
Subject: Re: RISC-V: Support XTheadVector extensions
On 11/17/23 16:16, 钟居哲 wrote:
> >> I assume this hunk is meant for riscv_output_operand in riscv.cc. We
&g
On 11/17/23 16:16, 钟居哲 wrote:
>> I assume this hunk is meant for riscv_output_operand in riscv.cc. We
may also need to add '^' to the punct_valid_p hook. But yes, this is
the preferred way to go when all we need to do is prefix the instruction
with "th.".
No. I don't think we need to
mer Dabbelt
Date: 2023-11-18 01:11
To: juzhe.zhong
CC: gcc-patches; Kito Cheng; kito.cheng; cooper.joshua; rdapp.gcc; jeffreyalaw
Subject: Re: RISC-V: Support XTheadVector extensions
On Fri, 17 Nov 2023 03:39:48 PST (-0800), juzhe.zh...@rivai.ai wrote:
> 90% theadvector extension reusing current RVV 1.0 ins
On Fri, 17 Nov 2023 03:39:48 PST (-0800), juzhe.zh...@rivai.ai wrote:
90% theadvector extension reusing current RVV 1.0 instructions patterns:
Just change ASM, For example:
@@ -2923,7 +2923,7 @@ (define_insn "*pred_mulh_scalar"
(match_operand:VFULLI_D 3 "register_operand" "vr,vr,
On 11/17/23 04:39, juzhe.zh...@rivai.ai wrote:
90% theadvector extension reusing current RVV 1.0 instructions patterns:
Just change ASM, For example:
@@ -2923,7 +2923,7 @@ (define_insn "*pred_mulh_scalar"
(match_operand:VFULLI_D 3 "register_operand" "vr,vr, vr, vr")]
VMULH)
Ok. I just read the theadvector extension.
https://github.com/T-head-Semi/thead-extension-spec/blob/master/xtheadvector.adoc
Theadvector is not custom extension. Just a uarch to disable some of the RVV1.0
extension
Theadvector can be considered as subextension of 'V' extension with disabling
25 matches
Mail list logo