will come soon.
Joshua
--
发件人：Kito Cheng
发送时间：2023年11月18日(星期六) 18:33
收件人：Philipp Tomsich
抄 送：Jeff Law;
"juzhe.zh...@rivai.ai";
"gcc-patches"; "kito.cheng";
"cooper.joshua"; Robin
Dapp; jkrid
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
o aware
of the proposal to use pseudo instructions to avoid duplication in Binutils.
Thank you very much!
Christoph
>
> After this change, you can send V2, then I can continue to review on GCC-15.
>
> Thanks.
>
>
> juzhe.zh...@rivai
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,
This patch series presents gcc implementation of the XTheadVector
extension [1].
[1] https://github.com/T-head-Semi/thead-extension-spec/
I updated my patch series, because I forgot to add co-authors in
the last version.
Contributors:
Jun Sha (Joshua)
Jin Ma
Christoph
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)
er.joshua; Robin Dapp; jeffreyalaw
Subject: RISC-V: Support XTheadVector extensions
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_opera
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)
(match_operand:VFULLI_D 2
This patch series presents gcc implementation of the XTheadVector
extension [1].
[1] https://github.com/T-head-Semi/thead-extension-spec/
Contributors:
Jun Sha (Joshua)
Jin Ma
RISC-V: minimal support for xtheadvector
RISC-V: Handle differences between xtheadvector and vector
29 matches
Mail list logo
