On Fri, Jul 22, 2022 at 2:43 AM Palmer Dabbelt wrote:
>
> On Thu, 21 Jul 2022 02:03:35 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
> > LGTM, will merge once binuils part merge.
>
> +Nelson, in case he's already planning on handling those. If not then
> they're not in my inbox, so just poke me if
Hi Maciej:
Ooops, thanks for fixing that, the change was gotten from kernel
folks. I assume they have already used that for a while, but it's
really weird no bug report from those guys...
OK for trunk and backport for release branch.
On Wed, Jul 27, 2022 at 1:00 AM Maciej W. Rozycki wrote:
>
>
Hi Maciej:
I am convinced that is OK for now, I agree modeling fflags would be a
rabbit hole, I tried to build a full GNU toolchain with my quick patch
and saw many ICE during build libraries, that definitely should be a
long-term optimization project.
Although I'm thinking if we should default -
LGTM, thanks!
On Sun, Aug 7, 2022 at 3:42 AM Palmer Dabbelt wrote:
>
> These two patterns were independent, but exactly match the semantics of
> X. Replace them with a single paramaterized pattern. Thanks to Andrew
> for pointing this one out over IRC.
>
> gcc/ChangeLog
>
> * config/ris
LGTM, that's apparently some kind of copy & paste error (from *slt
pattern) when we add this pattern.
On Sun, Aug 7, 2022 at 3:42 AM Palmer Dabbelt wrote:
>
> There's no operand 2 here, so referencing it doesn't make sense. I
> couldn't find a way to trigger bad assembly output so I don't have a
LGTM, thanks :)
On Fri, Jul 29, 2022 at 3:52 AM Maciej W. Rozycki wrote:
>
> Complement commit 7915f6551343 ("RISC-V/testsuite: constraint some of
> tests to hard_float") and also restrict the remaining `fmin'/`fmax'
> tests to hard-float test configurations.
>
> gcc/testsuite/
>
LGTM, but with a nit, I don't get set.w but get an andi like below, so
maybe we should also scan-assembler-not andi? feel free to commit that
directly with that fix
```asm
sleu:
sgtua0,a0,a1# 9 [c=4 l=4] *sgtu_disi
xoria0,a0,1 # 10[c=4 l=4] *xorsi3_internal/
LGTM
於 2023年8月3日 週四 10:11 寫道：
> From: Pan Li
>
> This patch would like to remove the redudant declaration.
>
> Signed-off-by: Pan Li
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-vector-builtins-bases.h: Remove
> redudant declaration.
> ---
> gcc/config/riscv/riscv-vector-builti
I am working on that, it seems the cost of vsetvli instruction become 0 due
to this change, then loop invariant motion won't hoist vsetvli longer.
Jeff Law 於 2023年8月3日 週四 21:49 寫道：
>
>
> On 8/3/23 03:27, juzhe.zh...@rivai.ai wrote:
> >
> https://github.com/gcc-mirror/gcc/commit/e15d0b6680d10d766
> > I am working on that, it seems the cost of vsetvli instruction become 0
> > due to this change, then loop invariant motion won't hoist vsetvli longer.
> I haven't looked yet (generating baseline rvv.exp data right now). But
> before I went to bed last night I was worried that a change snuck
>
lgtm
On Thu, Aug 3, 2023 at 10:32 PM wrote:
>
> From: Pan Li
>
> The previous patch missed the vfsub comment for binop_frm, this
> patch would like to fix this.
>
> Signed-off-by: Pan Li
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-vector-builtins-bases.cc: Add vfsub.
> ---
> gcc/config
> >> That'll be the first thing to look at. THe costing change was supposed
> >> only affect if-then-else constructs, not sets in general.
> >
> >
> > If so, I think the most simple fix is adding more checks on the set
> > cost - only check the SET_SRC is if-then-else?
> No, the simple fix is to j
What about using similar way as vlmul?
# NOTE: diff is based on your patch.
[kitoc@hsinchu02 riscv]$ git diff
diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index 33f7cb1d670..3cb5c23cb09 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-pro
uot;type" "vfalu,vfwalu,vfmul,vfdiv,vfwmul,vfdiv,vfwmul")
> > -(const_string "dyn")]
> > +(const_string "FRM_DYN")]
> >(const_string "none")))
>
> Pan
>
> -Original Message-
> From: Kito Cheng
> + machine_mode m1_mode = TARGET_VECTOR_ELEN_64
> + ? (TARGET_MIN_VLEN >= 128 ? VNx2DImode :
> VNx1DImode)
> + : VNx1SImode;
This should update since JuZhe has update the mode system :P
> @@ -5907,7 +6057,7 @@ riscv_expand_epilogue (int style)
Thanks for the high quality patch, it's generally LGTM, only a few
minor comments :)
> + /* The number and alignment of vector registers need for this scalable
> vector
> + argument. When the mode size is less than a full vector, we use 1 vector
> + register to pass. Just call TARGET_HAR
Lgtm
Juzhe-Zhong 於 2023年8月8日 週二，09:37寫道：
> After this patch, this following case will be well optimized:
> #include "riscv_vector.h"
>
> #define DEF_OP_VV(PREFIX, NUM, TYPE, OP)
> \
> void __attribute__ ((noinline, noclone))
> \
> PREFIX##_##TYPE##NUM (TYPE *restrict a, TYPE *restri
LGTM :)
Juzhe-Zhong 於 2023年8月8日 週二 11:10 寫道：
> #include "riscv_vector.h"
>
> #define DEF_OP_V(PREFIX, NUM, TYPE, OP)
> \
> void __attribute__ ((noinline, noclone))
> \
> PREFIX##_##TYPE##NUM (TYPE *restrict a, TYPE *restrict b)
> \
> {
> \
> for (int i = 0; i < NUM; ++
OK for trunk and GCC 13 :)
On Tue, Aug 8, 2023 at 2:46 PM juzhe.zh...@rivai.ai
wrote:
>
> LGTM. Thanks for fixing it.
>
> @kito: Hi, kito. This is the bug also exists in GCC-13, can we backport to
> GCC-13?
>
>
>
> juzhe.zh...@rivai.ai
>
> From: shiyulong
> Date: 2023-08-08 12:12
> To: gcc-patch
> +/* Get the frm mode with given CONST_INT rtx, the default mode is
> + FRM_DYN. */
> +enum floating_point_rounding_mode
> +get_frm_mode (rtx operand)
> +{
> + gcc_assert (CONST_INT_P (operand));
> +
> + switch (INTVAL (operand))
> +{
> +case FRM_RNE:
> + return FRM_RNE;
> +c
Yeah, no further comment from me :)
On Thu, Aug 10, 2023 at 10:16 AM Li, Pan2 wrote:
>
> Thanks kito. It makes sense, should not reach default, may I prepare v3(add
> gcc_unreachable to default) if no more comments?
>
> Pan
>
> -Original Message-----
> From: Kito
, the default frm will be none, and the selected insn type
> will be dyn. For the floating point which honors the frm, we will
> set the frm_mode attr explicitly in define_insn.
>
> Signed-off-by: Pan Li
> Co-Authored-by: Kito Cheng
>
> gcc/ChangeLog:
>
> * confi
LGTM
On Thu, Aug 10, 2023 at 4:20 PM Pan Li via Gcc-patches
wrote:
>
> From: Pan Li
>
> This patch would like to support the rounding mode API for the
> VFNMACC for the below samples.
>
> * __riscv_vfnmacc_vv_f32m1_rm
> * __riscv_vfnmacc_vv_f32m1_rm_m
> * __riscv_vfnmacc_vf_f32m1_rm
> * __riscv_
LGTM
Juzhe-Zhong 於 2023年8月11日 週五 17:56 寫道：
> This patch enables COSNT_VECTOR for VLS modes.
>
> void foo1 (int * __restrict a)
> {
> for (int i = 0; i < 16; i++)
> a[i] = 8;
> }
>
> void foo2 (int * __restrict a)
> {
> for (int i = 0; i < 16; i++)
> a[i] = i;
> }
>
> Compile
> +template
You don't need a template class here since it can only be UNSPEC_VFREC7.
> +class vfrec7_frm : public function_base
> +{
> +public:
> + bool has_rounding_mode_operand_p () const override { return true; }
> +
> + rtx expand (function_expander &e) const override
> + {
> +return e
Pushed to the trunk, with slight updates like rename and update testcases :)
On Wed, Jun 7, 2023 at 10:28 PM Kito Cheng via Gcc-patches
wrote:
>
> Thanks Jiawei, v2 patch set are LGTM, but I would like to defer this until
> binutils part has merged, I know you guys already implement t
Checked with doc and llvm implementation, LGTM
Just a random idea came to my mind, maybe we could introduce one more
template argument to reduce those codes for rounding mode intrinsic
stuff?
example:
diff --git a/gcc/config/riscv/riscv-vector-builtins-bases.cc
b/gcc/config/riscv/riscv-vector-builtins-bases.cc
index 2074dac0f16..9cc60842a5b 1
Or using an enum value rather than bool?
I am thinking we could also simplify/remove most other frm classes,
some practical example:
diff --git a/gcc/config/riscv/riscv-vector-builtins-bases.cc
b/gcc/config/riscv/riscv-vector-builtins-bases.cc
index 2074dac0f16..ace63e963a5 100644
--- a/gcc/conf
m or inherit, and will start with the CVT parts, then
> refactor the existing frm class.
>
> Do you have any suggestion for the decision making?
>
> Pan
>
> -----Original Message-
> From: Kito Cheng
> Sent: Wednesday, August 16, 2023 11:30 AM
> To: Li, Pan2
>
LGTM
於 2023年8月16日 週三 13:17 寫道：
> From: Pan Li
>
> This patch would like to support the rounding mode API for the
> VFCVT.X.F.V as the below samples.
>
> * __riscv_vfcvt_x_f_v_i32m1_rm
> * __riscv_vfcvt_x_f_v_i32m1_rm_m
>
> Signed-off-by: Pan Li
>
> gcc/ChangeLog:
>
> * config/riscv/ris
lgtm
On Wed, Aug 16, 2023 at 2:21 PM Pan Li via Gcc-patches
wrote:
>
> From: Pan Li
>
> This patch would like to support the rounding mode API for the
> VFCVT.XU.F.V as the below samples.
>
> * __riscv_vfcvt_xu_f_v_u32m1_rm
> * __riscv_vfcvt_xu_f_v_u32m1_rm_m
>
> Signed-off-by: Pan Li
>
> gcc/C
lgtm
On Wed, Aug 16, 2023 at 2:51 PM wrote:
> From: Pan Li
>
> This patch would like to support the rounding mode API for the
> VFCVT.F.X.V and VFCVT.F.XU.V as the below samples.
>
> * __riscv_vfcvt_f_x_v_f32m1_rm
> * __riscv_vfcvt_f_x_v_f32m1_rm_m
> * __riscv_vfcvt_f_xu_v_f32m1_rm
> * __riscv_
lgtm
On Wed, Aug 16, 2023 at 3:32 PM wrote:
> From: Pan Li
>
> This patch would like to support the rounding mode API for the
> VFWCVT.X.F.V as the below samples.
>
> * __riscv_vfwcvt_x_f_v_i64m2_rm
> * __riscv_vfwcvt_x_f_v_i64m2_rm_m
>
> Signed-off-by: Pan Li
>
> gcc/ChangeLog:
>
> *
Hi Fei:
Tried to use Jiawei's patch to test this patch and found some issue:
> @@ -5430,13 +5632,15 @@ riscv_expand_prologue (void)
>/* Save the registers. */
>if ((frame->mask | frame->fmask) != 0)
> {
> - HOST_WIDE_INT step1 = riscv_first_stack_step (frame, remaining_size);
../riscv-gnu-toolchain-trunk/gcc/gcc/dwarf2cfi.cc:3309
0x10e7c5a execute
../../../../riscv-gnu-toolchain-trunk/gcc/gcc/dwarf2cfi.cc:3797
On Wed, Aug 16, 2023 at 4:33 PM Kito Cheng wrote:
>
> Hi Fei:
>
> Tried to use Jiawei's patch to test this patch and found some issue:
>
ok
On Wed, Aug 16, 2023 at 5:44 PM Pan Li via Gcc-patches
wrote:
>
> From: Pan Li
>
> In some build option combination, the default value may result in
> below error. This patch would like to fix it by passing a explict
> argument.
>
> riscv-vector-builtins-bases.cc:2495:24: error: invalid use o
ok
On Wed, Aug 16, 2023 at 4:10 PM Pan Li via Gcc-patches
wrote:
>
> From: Pan Li
>
> This patch would like to support the rounding mode API for the
> VFWCVT.X.F.V as the below samples.
>
> * __riscv_vfwcvt_xu_f_v_u64m2_rm
> * __riscv_vfwcvt_xu_f_v_u64m2_rm_m
>
> Signed-off-by: Pan Li
>
> gcc/C
LGTM
On Thu, Aug 17, 2023 at 9:23 AM Pan Li via Gcc-patches
wrote:
>
> From: Pan Li
>
> This patch would like to support the rounding mode API for the
> VFNCVT.XU.F.W as the below samples.
>
> * __riscv_vfncvt_xu_f_w_u16mf2_rm
> * __riscv_vfncvt_xu_f_w_u16mf2_rm_m
>
> Signed-off-by: Pan Li
>
>
Lgtm
Pan Li via Gcc-patches 於 2023年8月17日 週四，10:19寫道：
> From: Pan Li
>
> This patch would like to support the rounding mode API for the
> VFNCVT.F.{X|XU|F}.W as the below samples.
>
> * __riscv_vfncvt_f_x_w_f32m1_rm
> * __riscv_vfncvt_f_x_w_f32m1_rm_m
> * __riscv_vfncvt_f_xu_w_f32m1_rm
> * __risc
Lgtm
Pan Li via Gcc-patches 於 2023年8月17日 週四，11:09寫道：
> From: Pan Li
>
> This patch would like to support the rounding mode API for the
> VFREDUSUM.VS as the below samples.
>
> * __riscv_vfredusum_vs_f32m1_f32m1_rm
> * __riscv_vfredusum_vs_f32m1_f32m1_rm_m
>
> Signed-off-by: Pan Li
>
> gcc/Chang
LGTM, thanks :)
On Thu, Aug 17, 2023 at 1:59 PM Juzhe-Zhong wrote:
>
> void foo(_Float16 y, int64_t *i64p)
> {
> vint64m1_t vx =__riscv_vle64_v_i64m1 (i64p, 1);
> vx = __riscv_vadd_vv_i64m1 (vx, vx, 1);
> vfloat16m1_t vy =__riscv_vfmv_s_f_f16m1 (y, 1);
> asm volatile ("# use %0 %1" : : "v
ok
On Thu, Aug 17, 2023 at 3:26 PM Pan Li via Gcc-patches
wrote:
>
> From: Pan Li
>
> This patch would like to support the rounding mode API for the
> VFWREDOSUM.VS as the below samples
>
> * __riscv_vfwredosum_vs_f32m1_f64m1_rm
> * __riscv_vfwredosum_vs_f32m1_f64m1_rm_m
>
> Signed-off-by: Pan L
lgtm
On Thu, Aug 17, 2023 at 2:23 PM Pan Li via Gcc-patches
wrote:
>
> From: Pan Li
>
> This patch would like to support the rounding mode API for the
> VFREDOSUM.VS as the below samples.
>
> * __riscv_vfredosum_vs_f32m1_f32m1_rm
> * __riscv_vfredosum_vs_f32m1_f32m1_rm_m
>
> Signed-off-by: Pan L
Just one nit from me: plz add assertion to OP_TYPE_vx to make sure NO
FRM_OP == HAS_FRM there
On Mon, Aug 21, 2023 at 11:04 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 8/17/23 20:53, Pan Li via Gcc-patches wrote:
> > From: Pan Li
> >
> > As suggested by kito, we will add new frm_opt_type templ
I think I could do some details review tomorrow on the plane, I am free
from the meeting hell tomorrow :p
Robin Dapp via Gcc-patches 於 2023年8月21日 週一 23:24
寫道：
> Hi Juzhe,
>
> thanks, this is a reasonable approach and improves readability noticeably.
> LGTM but I'd like to wait for other opinio
ok for trunk, thanks :)
On Mon, Jun 26, 2023 at 4:44 PM Richard Biener via Gcc-patches
wrote:
>
> On Mon, 26 Jun 2023, Juzhe-Zhong wrote:
>
> > Previously, Richi has suggested that vcond patterns are only needed when
> > target
> > support comparison + select consuming 1 instruction.
> >
> > Now
Could you re-title this patch into something like "Support const
vector expansion with xxx pattern",
On Mon, Jun 26, 2023 at 3:52 PM Robin Dapp via Gcc-patches
wrote:
>
> Hi Juzhe,
>
> > Currently, we are able to generate step vector with base == 0:
> > { 0, 0, 2, 2, 4, 4, ... }
> >
> > ASM:
> >
Lgtm
juzhe.zh...@rivai.ai 於 2023年6月26日 週一，17:40寫道：
> LGTM
>
>
>
> juzhe.zh...@rivai.ai
>
> From: pan2.li
> Date: 2023-06-26 17:36
> To: gcc-patches
> CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang;
> kito.cheng
> Subject: [PATCH v1] RISC-V: Remove duplicated extern function_base
LLVM will try to find scratch register even after RA to resolve the long
jump issue. so maybe we could consider similar approach? And I guess the
most complicate part would be the scratch register is not found, and
require spill/reload after RA.
Jeff Law via Gcc-patches 於 2023年6月26日 週一，22:31寫道：
>
It seems because of canonical form of RTL, right?
LGTM, but plz add some more comments about the reason into the commit log.
On Wed, Jun 28, 2023 at 11:00 AM Juzhe-Zhong wrote:
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-vector-builtins-bases.cc: Adapt expand.
> * config/riscv/ve
LGTM with a minor comment.
> Currently, vfwadd.wv is the pattern with (set (reg) (float_extend:(reg))
> which makes
it's minor so you can just go commit after the fix: this should be
(set (plus (reg) (float_extend:(reg)))
> combine pass faile to combine.
>
> change RTL format of vfwadd.wv -
Do you mind giving some comments about what the difference between the
two versions?
On Wed, Jun 28, 2023 at 11:14 AM juzhe.zh...@rivai.ai
wrote:
>
> This patch is the critical patch for following patches since it is a bug
> which I already address in rvv-next.
>
> __
I mean the difference between v1 and v2 patch
On Wed, Jun 28, 2023 at 12:09 PM Jeff Law wrote:
>
>
>
> On 6/27/23 21:16, Kito Cheng wrote:
> > Do you mind giving some comments about what the difference between the
> > two versions?
> And I'd like a before/after a
LGTM
On Wed, Jun 28, 2023 at 4:28 PM Juzhe-Zhong wrote:
>
> This patch adds combine pattern as follows:
>
> 1. (set (reg) (fma (float_extend:reg)(float_extend:reg)(reg)))
>This pattern allows combine: vfwcvt + vfwcvt + vfmacc ==> vwfmacc.
>
> 2. (set (reg) (fma (float_extend:reg)(reg)(reg)))
LGTM, thanks :)
On Thu, Jun 29, 2023 at 10:24 AM juzhe.zh...@rivai.ai
wrote:
>
> LGTM
>
>
> juzhe.zh...@rivai.ai
>
>
> From: pan2.li
> Date: 2023-06-29 09:40
> To: gcc-patches
> CC: juzhe.zhong; kito.cheng; pan2.li; yanzhang.wang; jeffreyalaw
> Subject: [PATCH v1]
LGTM, thanks!
On Tue, Jun 27, 2023 at 3:02 PM Li, Pan2 wrote:
>
> Ack, thanks Juzhe.
>
>
>
> Pan
>
>
>
> From: juzhe.zh...@rivai.ai
> Sent: Tuesday, June 27, 2023 3:00 PM
> To: Li, Pan2 ; gcc-patches
> Cc: Kito.cheng ; Li, Pan2 ; Wang,
> Yanzhang ; jeffreyalaw
> Subject: Re: [PATCH v1] RISC-V
Hi Robin:
> diff --git a/gcc/lto/lto-lang.cc b/gcc/lto/lto-lang.cc
> index 52d7626e92e..14d419c2013 100644
> --- a/gcc/lto/lto-lang.cc
> +++ b/gcc/lto/lto-lang.cc
> @@ -1050,7 +1050,7 @@ lto_type_for_mode (machine_mode mode, int unsigned_p)
>else if (GET_MODE_CLASS (mode) == MODE_VECTOR_BOOL
>
> On 2023-05-13T16:44:41+0800, Kito Cheng via Gcc-patches
> wrote:
> > Tried this patch and I ran into some issues, some variables are using
> > unsigned char to hold machine mode and will have problems when the
> > number of modes is larger than 255...
> >
> &
Tried on local, widen-complicate-7.c, widen-complicate-8.c and
widen-complicate-9.c need those bridge pattern, otherwise will fail to
combine, so give an explicitly LGTM from my side.
On Mon, Jul 3, 2023 at 3:48 PM Robin Dapp via Gcc-patches
wrote:
>
> To reiterate, this is OK from my side. As d
Lgtm
juzhe.zh...@rivai.ai 於 2023年7月3日 週一，19:11寫道：
> LGTM
>
>
>
> juzhe.zh...@rivai.ai
>
> From: pan2.li
> Date: 2023-07-03 18:57
> To: gcc-patches
> CC: juzhe.zhong; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
> Subject: [PATCH v1] RISC-V: Fix one typo for emit_mode_set.
> From: Pan Li
>
>
Thanks, LGTM :)
Christoph Muellner 於 2023年7月3日 週一，19:08寫道：
> From: Christoph Müllner
>
> This series adds basic support for the vector crypto extensions:
> * Zvbb
> * Zvbc
> * Zvkg
> * Zvkned
> * Zvkhn[a,b]
> * Zvksed
> * Zvksh
> * Zvkn
> * Zvknc
> * Zvkng
> * Zvks
> * Zvksc
> * Zvksg
> * Zvkt
>
LGTM
On Mon, Jul 3, 2023 at 8:47 PM Robin Dapp wrote:
>
> LGTM.
>
> Regards
> Robin
>
LGTM, thanks :)
On Wed, Jul 5, 2023 at 3:03 PM Pan Li via Gcc-patches
wrote:
>
> From: Pan Li
>
> This patch would like to fix one bug to align below items of spec.
>
> 1. By default, the RVV floating-point will take dyn mode.
> 2. DYN is invalid in FRM register for RVV floating-point.
>
> When
On Wed, Jul 5, 2023 at 3:12 PM Robin Dapp via Gcc-patches
wrote:
>
> > LGTM, thanks :)
>
> just a moment please, I still wanted to reply ;)
Sure :)
>
> Regards
> Robin
>
LGTM
On Wed, Jul 5, 2023 at 10:08 AM juzhe.zh...@rivai.ai
wrote:
>
> LGTM.
>
>
>
> juzhe.zh...@rivai.ai
>
> From: pan2.li
> Date: 2023-07-04 20:26
> To: gcc-patches
> CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
> Subject: [PATCH v1] RISC-V: Use FRM_DYN when add the
Zfinx has provide fcsr like F, so rouding mode should use fcsr instead
of `soft` fenv.
libgcc/ChangeLog:
* config/riscv/sfp-machine.h (FP_INIT_ROUNDMODE): Check zfinx.
(FP_HANDLE_EXCEPTIONS): Ditto.
---
libgcc/config/riscv/sfp-machine.h | 2 +-
1 file changed, 1 insertion(+), 1 d
Lgtm
juzhe.zh...@rivai.ai 於 2023年7月5日 週三，21:04寫道：
> LGTM. Thanks for fixing this.
>
>
>
> juzhe.zh...@rivai.ai
>
> From: Robin Dapp
> Date: 2023-07-05 21:00
> To: gcc-patches; palmer; Kito Cheng; juzhe.zh...@rivai.ai; jeffreyalaw
> CC: rdapp.gcc
> Subject: [
Committed to trunk, and plan to back port to GCC 13 branch 1 week later :)
On Wed, Jul 5, 2023 at 10:15 PM Jeff Law wrote:
>
>
>
> On 7/5/23 02:11, Kito Cheng wrote:
> > Zfinx has provide fcsr like F, so rouding mode should use fcsr instead
> > of `soft` fenv.
LGTM
On Fri, Jul 7, 2023 at 4:26 PM juzhe.zh...@rivai.ai
wrote:
>
> LGTM. Thanks.
>
>
>
> juzhe.zh...@rivai.ai
>
> From: Li Xu
> Date: 2023-07-07 16:22
> To: gcc-patches
> CC: kito.cheng; palmer; juzhe.zhong; zhengyu; Li Xu
> Subject: [PATCH] RISCV: Fix local_eliminate_vsetvl_insn bug in VSETVL
Document `z` and `i` operand modifiers, we have much more modifiers
other than those two, but they are the only two implement on both
GCC and LLVM, consider the compatibility I would like to document those
two first, and then review other modifiers later to see if any other should
expose and implem
thanks, pushed to trunk :)
On Mon, Jul 10, 2023 at 10:33 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 7/10/23 08:19, Kito Cheng wrote:
> > Document `z` and `i` operand modifiers, we have much more modifiers
> > other than those two, but they are the only two implement
Hi Christoph:
Ooops, I thought Philipp will push those patches, does here any other
patches got approved but not committed? I can help to push those
patches tomorrow.
On Tue, Jul 11, 2023 at 11:42 PM Christoph Müllner
wrote:
>
> Hi Cooper,
>
> I addressed this in April this year.
> It even got a
TL;DR: I think most parts of the test could be added by generator
instead of adding those test cases directly, we gonna stop putting all
API testing testcase.
RISC-V Vector intrinsic is not implement through the *.def file way,
it's using same approach as SVE's intrinsic,
create and register by C
Hi Shihua:
Thanks for your patches! This patch set is generally in good shape,
but I would prefer to remove riscv_scalar_crypto.h at this moment
since it's NOT standardized yet.
Do you mind sending a new version of this patch set which does not
include that and also update the testcases?
On Th
e API has documented and merged I am happy to accept that part too.
On Thu, Feb 16, 2023 at 9:52 PM Markku-Juhani Olavi Saarinen
wrote:
>
> On Thu, Feb 16, 2023, 13:29 Kito Cheng wrote:
>
> > Hi Shihua:
> >
> > Thanks for your patches! This patch set is generally in go
Catched by running gcc.c-torture/execute/builtin-prefetch-2.c with
-march=rv64gc_zicbop.
gcc/ChangeLog:
* config/riscv/riscv.md (prefetch): Use r instead of p for the
address operand.
(riscv_prefetchi_): Ditto.
---
gcc/config/riscv/riscv.md | 4 ++--
1 file changed, 2 ins
Hi Richard Sandiford:
RISC-V part is OK to me, could you review the ADJUST_PRECISION part to
make sure this change is reasonable?
Thanks :)
On Tue, Feb 21, 2023 at 2:37 PM Li, Pan2 via Gcc-patches
wrote:
>
> Hi,
>
> Kindly reminder for this PR.
>
> Pan
>
> -Original Message-
> From: Li,
This will break some scenario which is to build anything by themself,
which does not use any header or library from the builtin one.
So that's why the spec needs to guard so many conditions, no
-nostartfiles, -nodefaultlibs, -nolibc and -nostdlib appears.
"%{!nostartfiles:%{!nodefaultlibs:%{!no
LTO might generate random string for the section name, which might contain `mv`,
then might cause random false alarm.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/_Float16-zhinxmin-1.c: Tweak test
condition.
---
gcc/testsuite/gcc.target/riscv/_Float16-zhinxmin-1.c | 2 +-
1 file c
Hi Jin:
Curious, did you introduce version info into the multi-lib path in
your donwstream GCC? I suspect we need a more complete solution to
deal with the multiversion issue, so it would be great if you can
provide more experience with this part?
Thanks :)
On Wed, Feb 22, 2023 at 5:44 PM Jin M
Hi Jeff:
> What I'd been planning to do internally at Ventana was to update our
> codebase to gcc-13 once it's released. Then I'd backport RVV autovec
> work from the gcc-14 dev tree into that Ventana branch.
>
> Instead, but along the same lines, we could have a public gcc-13 based
> branch whic
> diff --git a/gcc/config/riscv/thead.md b/gcc/config/riscv/thead.md
> index 158e9124c3a..2c684885850 100644
> --- a/gcc/config/riscv/thead.md
> +++ b/gcc/config/riscv/thead.md
> @@ -29,3 +29,14 @@ (define_insn "*th_addsl"
>"th.addsl\t%0,%3,%1,%2"
>[(set_attr "type" "bitmanip")
> (set_a
> +
> +(define_memory_constraint "Qmx"
> + "@internal
> + An address valid for GPR."
> + (and (match_code "mem")
> + (match_test "!riscv_legitimize_address_index_p (
> + XEXP (op, 0), GET_MODE (op), false)")))
Check TARGET_XTHEADFMEMIDX, and I don't quite understand why
Hi Christoph:
OK for trunk for the 1~8, feel free to commit 1~8 after you address
those minor comments, and could you also prepare release notes for
those extensions?
And 9~11 needs to take a few more rounds of review and test.
On Fri, Feb 24, 2023 at 1:52 PM Christoph Muellner
wrote:
>
> Fr
Got one fail:
FAIL: gcc.target/riscv/xtheadmempair-1.c -O2 scan-assembler-times
th.luwd\t 4
It should scan lwud rather than luwd?
> diff --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h
> index cf0cd669be4..5cd3f7673f0 100644
> --- a/gcc/config/riscv/riscv-opts.h
> +++ b/gcc/config/riscv/riscv-opts.h
> @@ -215,4 +215,7 @@ enum stack_protector_guard {
> #define TARGET_XTHEADMEMPAIR ((riscv_xthead_subext &
> > +(define_memory_constraint "Qmx"
> > + "@internal
> > + An address valid for GPR."
> > + (and (match_code "mem")
> > + (match_test "!riscv_legitimize_address_index_p (
> > + XEXP (op, 0), GET_MODE (op), false)")))
>
> Check TARGET_XTHEADFMEMIDX, and I don't quite und
My impression is that md patterns will use first-match patterns? so
the zba will get higher priority than xtheadba if both patterns are
matched?
On Fri, Feb 24, 2023 at 2:52 PM Andrew Pinski via Gcc-patches
wrote:
>
> On Thu, Feb 23, 2023 at 9:55 PM Christoph Muellner
> wrote:
> >
> > From: Chri
It did help people to identify what extension used in the binary, so I
would prefer keep that enable by default.
and lld is begin fix those merge issue, so the situation should be improved
soon.
Palmer Dabbelt 於 2023年2月24日 週五 10:29 寫道：
> We generate a handful of attributes by default, but they
Could you move those thead_* and th_* functions into thead.cc
> +static bool
> +thead_mempair_operand_p (rtx mem, machine_mode mode)
> +{
> + if (!MEM_SIZE_KNOWN_P (mem))
> +return false;
> +
> + /* Only DI or SI mempair instructions exist. */
add gcc_assert (mode == SImode || mode == DImo
Thanks!
RISC-V part is LGTM, and I would like to wait for Richard Sandiford to
say OK to the genmodes.cc part :)
On Fri, Mar 3, 2023 at 10:31 AM wrote:
>
> From: Pan Li
>
> Fix the bug of the rvv bool mode precision with the adjustment.
> The bits size of vbool*_t will be adjus
Hi Michael Collison:
It's REALLY NOT OK that you didn't mention RiVAI and Ju-Zhe in either
changelog or add he as co-author,
apparently you HAVE references and even copy his code from
https://github.com/riscv-collab/riscv-gcc/tree/riscv-gcc-rvv-next
Committed, thanks!
On Tue, Feb 28, 2023 at 12:36 PM Sinan wrote:
>
> From 73e743348a49a7fffcf2e328b8179e8dbbc3b2b4 Mon Sep 17 00:00:00 2001
> From: Lin Sinan
> Date: Tue, 28 Feb 2023 00:44:55 +0800
> Subject: [PATCH] RISC-V: Allow const0_rtx operand in max/min
>
> Optimize cases that use max[u]
Committed, thanks!
On Tue, Feb 28, 2023 at 5:32 PM Philipp Tomsich
wrote:
>
> On Tue, 28 Feb 2023 at 06:00, Lin Sinan wrote:
> >
> > From: Lin Sinan
> >
> > The partial subreg check should be for subreg operand(operand 1) instead of
> > the immediate operand(operand 2). This change also fix pr
LGTM :)
On Fri, Feb 24, 2023 at 7:19 PM Christoph Muellner
wrote:
>
> From: Christoph Müllner
>
> This patch documents the new T-Head CPU support for RISC-V.
>
> Signed-off-by: Christoph Müllner
> ---
> htdocs/gcc-13/changes.html | 24 +++-
> 1 file changed, 23 insertions(
LGTM :)
On Thu, Mar 2, 2023 at 4:36 PM Christoph Muellner
wrote:
>
> From: Christoph Müllner
>
> This series introduces support for the T-Head specific RISC-V ISA extensions
> which are available e.g. on the T-Head XuanTie C906.
>
> The ISA spec can be found here:
> https://github.com/T-head-S
Committed, thanks!
On Mon, Feb 20, 2023 at 3:01 PM Liao Shihua wrote:
>
> This series adds basic support for the Scalar Cryptography extensions:
> * Zbkb
> * Zbkc
> * Zbkx
> * Zknd
> * Zkne
> * Zknh
> * Zksed
> * Zksh
>
> The implementation follows the version Scalar Cryptography v1.0.0 of the
>
Committed, thanks for the fix :)
On Sun, Mar 5, 2023 at 6:25 PM wrote:
>
> From: Ju-Zhe Zhong
>
> FAIL: gcc.target/riscv/rvv/vsetvl/avl_single-86.c -Og -g (internal
> compiler error: Segmentation fault)
> FAIL: gcc.target/riscv/rvv/vsetvl/avl_single-86.c -Og -g (test for
> excess errors)
> F
Hi Pan:
Really appreciate your patch for fixing this issue!
committed to trunk with minor commit log tweak :)
On Tue, Mar 7, 2023 at 8:05 PM pan2.li--- via Gcc-patches
wrote:
>
> From: Pan Li
>
> Fix the bug of the rvv bool mode precision with the adjustment.
> The bits size of
1001 - 1100 of 1800 matches
Mail list logo
