From: Juzhe-Zhong
This simple patch fixes the magic number, remove magic number make codes more
reasonable.
Ok for trunk ?
gcc/ChangeLog:
* config/riscv/riscv-v.cc (expand_vec_series): Remove magic number.
(expand_const_vector): Ditto.
(legitimize_move): Ditto.
On Tue, 23 May 2023 18:28:48 PDT (-0700), juzhe.zh...@rivai.ai wrote:
From: Juzhe-Zhong
This simple patch fixes the magic number, remove magic number make codes more
reasonable.
Ok for trunk ?
gcc/ChangeLog:
* config/riscv/riscv-v.cc (expand_vec_series): Remove magic number.
Yeah. Can I merge it?
juzhe.zh...@rivai.ai
From: Palmer Dabbelt
Date: 2023-05-24 09:32
To: juzhe.zhong
CC: gcc-patches; Kito Cheng; kito.cheng; jeffreyalaw; rdapp.gcc; juzhe.zhong
Subject: Re: [PATCH V2] RISC-V: Fix magic number of RVV auto-vectorization
expander
On Tue, 23 May 2023 18:28:48
On Tue, 23 May 2023 18:34:00 PDT (-0700), juzhe.zh...@rivai.ai wrote:
Yeah. Can I merge it?
You built it? Then I'm fine with merging it.
juzhe.zh...@rivai.ai
From: Palmer Dabbelt
Date: 2023-05-24 09:32
To: juzhe.zhong
CC: gcc-patches; Kito Cheng; kito.cheng; jeffreyalaw; rdapp.gcc; juz
Yes, I built it and regression has passed.
juzhe.zh...@rivai.ai
From: Palmer Dabbelt
Date: 2023-05-24 09:37
To: juzhe.zhong
CC: gcc-patches; Kito Cheng; kito.cheng; jeffreyalaw; rdapp.gcc
Subject: Re: Re: [PATCH V2] RISC-V: Fix magic number of RVV auto-vectorization
expander
On Tue, 23 May 20
I always finished build up && regression testsuite before I posted the patches.
juzhe.zh...@rivai.ai
From: juzhe.zh...@rivai.ai
Date: 2023-05-24 09:37
To: palmer
CC: gcc-patches; kito.cheng; Kito.cheng; jeffreyalaw; Robin Dapp
Subject: Re: Re: [PATCH V2] RISC-V: Fix magic number of RVV auto-ve
On Tue, 23 May 2023 18:37:39 PDT (-0700), juzhe.zh...@rivai.ai wrote:
Yes, I built it and regression has passed.
OK, thanks!
juzhe.zh...@rivai.ai
From: Palmer Dabbelt
Date: 2023-05-24 09:37
To: juzhe.zhong
CC: gcc-patches; Kito Cheng; kito.cheng; jeffreyalaw; rdapp.gcc
Subject: Re: Re:
From: Juzhe-Zhong
For VLMAX situation, rtx len = ops[m_op_num] is incorrect since
the last element the ops array should be ops[m_op_num - 1];
I notice this issue when I am debugging code.
This is a code bug even though the following codes will hide this issue.
We still should need this minor fix
Maciej W. Rozycki 于2023年5月20日周六 03:21写道：
>
> On Fri, 19 May 2023, Jeff Law wrote:
>
> > > diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc
> > > index ca491b981a3..00f26d5e923 100644
> > > --- a/gcc/config/mips/mips.cc
> > > +++ b/gcc/config/mips/mips.cc
> > > @@ -8313,6 +8313,12 @@
I am a little hesitant about that, since I feel the vl and normal op
should be put in separately, otherwise the means of m_op_num is kind
of unclear, we have comments there but I think it's not ideal since it
is really context sensitive and hard to determine.
And I suspect gcc_assert (ops[m_op_num
Committed, thanks Palmer.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Palmer Dabbelt
Sent: Wednesday, May 24, 2023 9:37 AM
To: juzhe.zh...@rivai.ai
Cc: gcc-patches@gcc.gnu.org; Kito Cheng ;
kito.ch...@sifive.com; jeffreya...@gmail.com; rdapp@gmail.com
Subject: Re: Re: [PA
From: Juzhe-Zhong
To fix this issue, we seperate Vl operand and normal operands.
gcc/ChangeLog:
* config/riscv/autovec.md: Adjust for new interface.
* config/riscv/riscv-protos.h (emit_vlmax_insn): Add VL operand.
(emit_nonvlmax_insn): Add AVL operand.
* config/r
Thanks. I fix it by separating VL and normal operand.
V2 patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619356.html
Does it look more reasonable to you?
Just finished the building test && regression.
Thanks.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-05-24 10:10
To: juzhe.zh
Lgtm, thanks
於 2023年5月24日 週三，10:39寫道：
> From: Juzhe-Zhong
>
> To fix this issue, we seperate Vl operand and normal operands.
>
> gcc/ChangeLog:
>
> * config/riscv/autovec.md: Adjust for new interface.
> * config/riscv/riscv-protos.h (emit_vlmax_insn): Add VL operand.
> (e
Committed, thanks Kito.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Kito Cheng via Gcc-patches
Sent: Wednesday, May 24, 2023 10:55 AM
To: juzhe.zh...@rivai.ai
Cc: gcc-patches@gcc.gnu.org; jeffreya...@gmail.com; kito.ch...@gmail.com;
pal...@dabbelt.com; pal...@rivosinc.com; rd
From: Juzhe-Zhong
This patch enable RVV auto-vectorization including floating-point
unorder and order comparison.
The testcases are leveraged from Richard.
So include Richard as co-author.
Co-Authored-By: Richard Sandiford
gcc/ChangeLog:
* config/riscv/autovec.md (@vcond_mask_): New
Hi, this patch is the patch that fixed all comments from Robin.
And this patch is the prerequisite patch for my current middle-end work.
Without this patch, I can't support len_mask_xxx middle-end pattern since
the mask is generated by comparison.
For example,
for (int i...; i < n.)
if (cond[i
Just to make sure below 2 VREINTERPRET related PATCH are still in the queue, 😉!
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618877.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618881.html
Pan
From: Kito Cheng
Sent: Saturday, May 20, 2023 9:58 PM
To: Li, Pan2
Cc: gcc-patches@g
> +void
> +expand_vec_cmp (rtx target, rtx_code code, rtx mask, rtx maskoff, rtx op0,
> + rtx op1)
> ...
> + rtx cmp = gen_rtx_fmt_ee (code, mask_mode, op0, op1);
> + rtx ops[RVV_CMP_OP + 2] = {target, mask, maskoff, cmp, op0, op1};
> + emit_vlmax_cmp_insn (icode, RVV_CMP_OP + 2, o
ok
On Thu, May 18, 2023 at 2:32 PM Pan Li via Gcc-patches
wrote:
>
> From: Pan Li
>
> This patch support the RVV VREINTERPRET from the vbool*_t to the
> vuint*m1_t. Aka:
>
> vuint*m1_t __riscv_vreinterpret_x_x(vbool*_t);
>
> These APIs help the users to convert vector the vbool*_t to the LMUL=1
LGTM
On Thu, May 18, 2023 at 2:37 PM Pan Li via Gcc-patches
wrote:
>
> From: Pan Li
>
> This patch support the RVV VREINTERPRET from the vbool*_t to the
> vint*m1_t. Aka:
>
> vint*m1_t __riscv_vreinterpret_x_x(vbool*_t);
>
> These APIs help the users to convert vector the vbool*_t to the LMUL=1
From: Juzhe-Zhong
This patch enable RVV auto-vectorization including floating-point
unorder and order comparison.
The testcases are leveraged from Richard.
So include Richard as co-author.
And this patch is the prerequisite patch for my current middle-end work.
Without this patch, I can't suppo
Committed, thanks Kito.
Pan
-Original Message-
From: Kito Cheng
Sent: Wednesday, May 24, 2023 11:22 AM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@sifive.com; Wang,
Yanzhang
Subject: Re: [PATCH v2] RISC-V: Support RVV VREINTERPRET from vbool*_t to
vint
Thanks a lot. Part of the comments has already been fixed in V4.
But forget about V4 patch.
Could you continue review V5 patch that I just send ?
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619366.html
with all comments from you have been fixed.
Thanks.
juzhe.zh...@rivai.ai
From: Kito
Committed, thanks Kito.
Pan
-Original Message-
From: Kito Cheng
Sent: Wednesday, May 24, 2023 11:22 AM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@sifive.com; Wang,
Yanzhang
Subject: Re: [PATCH] RISC-V: Support RVV VREINTERPRET from vbool*_t to
vuint*m
LGTM
On Wed, May 24, 2023 at 11:29 AM wrote:
>
> From: Juzhe-Zhong
>
> This patch enable RVV auto-vectorization including floating-point
> unorder and order comparison.
>
> The testcases are leveraged from Richard.
> So include Richard as co-author.
>
> And this patch is the prerequisite patch f
Committed, thanks Kito.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Kito Cheng via Gcc-patches
Sent: Wednesday, May 24, 2023 11:35 AM
To: juzhe.zh...@rivai.ai
Cc: gcc-patches@gcc.gnu.org; kito.ch...@gmail.com; pal...@dabbelt.com;
pal...@rivosinc.com; jeffreya...@gmail.com; rd
On 22/05/2023 22:55, Jonathan Wakely wrote:
On Mon, 22 May 2023 at 21:51, François Dumont via Libstdc++
mailto:libstdc%2b...@gcc.gnu.org>> wrote:
I was thinking that it might be nice to get rid of
predefined_ops.h content.
So here is a start with __negate. Drawback is that stl
The sysconf function is only available in rtp mode on vxworks. In
kernel mode, it is not even declared, but the feature test macro in
the testsuite doesn't notice its absence because it's a link test, and
vxworks kernel mode uses partial linking.
This patch introduces an alternate test on vxwor
tsvc tests all fail on systems that don't offer a malloc.h, other than
those that explicitly rule that out. Use the preprocessor to test for
malloc.h's availability.
tsvc.h also expects a definition for struct timeval, but it doesn't
include sys/time.h. Add a conditional include thereof.
Boot
Fix test that uses -fPIC without stating the requirement for PIC
support.
Bootstrapped on x86_64-linux-gnu. Also tested on ppc- and x86-vx7r2
with gcc-12.
for gcc/testsuite/ChangeLog
* gcc.target/i386/pr103074.c: Require fpic support.
---
gcc/testsuite/gcc.target/i386/pr103074.c |
Fix test that uses -fopenmp without declaring requirement for pthread
support.
Bootstrapped on x86_64-linux-gnu. Also tested on ppc- and x86-vx7r2
with gcc-12.
for gcc/testsuite/ChangeLog
* g++.dg/pr80481.C: Add explicit pthread requirement.
---
gcc/testsuite/g++.dg/pr80481.C |2
Fix two tests that use -pg but don't declare their requirement for
profiling support.
Bootstrapped on x86_64-linux-gnu. Also tested on ppc- and x86-vx7r2
with gcc-12.
for gcc/testsuite/ChangeLog
* gcc.target/i386/mcount_pic.c: Add dg-require-profiling.
* gcc.target/i386/pr104
on 2023/5/23 14:19, Richard Biener wrote:
> On Tue, May 23, 2023 at 5:01 AM Kewen.Lin wrote:
>>
>> Hi Richi,
>>
>> Thanks for the review!
>>
>> on 2023/5/22 21:44, Richard Biener wrote:
>>> On Wed, May 17, 2023 at 8:15 AM Kewen.Lin wrote:
Hi,
Following Richi's suggestion in [1
The expected results for signbit-2 only arise on x86 with avx512f
disabled and sse2 enabled. The patch already disables avx512f
explicitly, but it fails to enable sse2.
Bootstrapped on x86_64-linux-gnu. Also tested on ppc- and x86-vx7r2
with gcc-12.
for gcc/testsuite/ChangeLog
* gcc
Good for me, thanks Alex!
> On 24 May 2023, at 07:08, Alexandre Oliva wrote:
>
>
> The sysconf function is only available in rtp mode on vxworks. In
> kernel mode, it is not even declared, but the feature test macro in
> the testsuite doesn't notice its absence because it's a link test, and
on 2023/5/24 06:30, Peter Bergner wrote:
> On 5/23/23 12:24 AM, Kewen.Lin wrote:
>> on 2023/5/23 01:31, Carl Love wrote:
>>> The builtins were requested for use in GLibC. As of version 2.31 they
>>> were added as inline asm. They requested a builtin so the asm could be
>>> removed.
>>
>> So IMHO
On May 5, 2022, Alexandre Oliva wrote:
> for gcc/ChangeLog
> PR target/100106
> * emit-rtl.cc (validate_subreg): Reject a SUBREG of a MEM that
> requires stricter alignment than MEM's.
> for gcc/testsuite/ChangeLog
> PR target/100106
> * gcc.target/powerpc/pr10
On Wed, May 24, 2023 at 1:24 PM Alexandre Oliva via Gcc-patches
wrote:
>
>
> The expected results for signbit-2 only arise on x86 with avx512f
> disabled and sse2 enabled. The patch already disables avx512f
> explicitly, but it fails to enable sse2.
>
> Bootstrapped on x86_64-linux-gnu. Also tes
The bogus warning is present on 32-bit ppc-vx7r2 too, so drop the 64
from the powerpc xfail triplet.
Bootstrapped on x86_64-linux-gnu. Also tested on ppc- and x86-vx7r2
with gcc-12.
for gcc/testsuite/ChangeLog
* gcc.dg/uninit-pred-9_b.c: Xfail bogus warning on 32-bit ppc
as w
MOVE_MAX on x86* used to accept up to 16 bytes, even without SSE,
which enabled inlining of small memmove by loading and then storing
the entire range. After the "x86: Update piecewise move and store"
r12-2666 change, memmove of more than 4 bytes would not be inlined in
gimple_fold_bultin_memory
Various x86 tests fail if the toolchain is configured with
--enable-frame-pointer, because the unexpected extra insns mess with
the expected asm counts. Add -fomit-frame-pointer so that they can
still pass.
Bootstrapped on x86_64-linux-gnu. Also tested on ppc- and x86-vx7r2
with gcc-12.
for
Just as on aarch64, x86's wider long double experiences loss of
precision with from_chars implemented in terms of double. Expect the
execution fail.
Bootstrapped on x86_64-linux-gnu. Also tested on ppc- and x86-vx7r2
with gcc-12.
for libstdc++-v3/ChangeLog
* testsuite/20_util/to_cha
Codegen changes caused add instruction count mismatches on
ppc-*-linux-gnu and other 32-bit ppc targets. At some point the
expected counts were adjusted for lp64, but ilp32 differences
remained, and published test results confirm it.
Bootstrapped on x86_64-linux-gnu. Also tested on ppc- and x8
on 2023/5/24 13:42, Alexandre Oliva via Gcc-patches wrote:
>
> The bogus warning is present on 32-bit ppc-vx7r2 too, so drop the 64
> from the powerpc xfail triplet.
>
> Bootstrapped on x86_64-linux-gnu. Also tested on ppc- and x86-vx7r2
> with gcc-12.
It xfail-ed on my local BE -m32 testing bu
An empty struct type that is not non-trivial for the purposes of calls
will be treated as though it were the following C type:
struct {
char c;
};
Before this patch was added, a structure parameter containing an empty
structure and
less than three floating-point members was passed through one
On Wed, May 24, 2023 at 7:48 AM Alexandre Oliva wrote:
>
>
> Various x86 tests fail if the toolchain is configured with
> --enable-frame-pointer, because the unexpected extra insns mess with
> the expected asm counts. Add -fomit-frame-pointer so that they can
> still pass.
>
> Bootstrapped on x86
On Wed, 2023-05-24 at 14:04 +0800, Lulu Cheng wrote:
> An empty struct type that is not non-trivial for the purposes of calls
> will be treated as though it were the following C type:
>
> struct {
> char c;
> };
>
> Before this patch was added, a structure parameter containing an empty
> struc
When I wrote early-remat, the DF_FORWARD block order was a postorder
of a reverse/backward walk (i.e. of the inverted cfg), rather than a
reverse postorder of a forward walk. A postorder of a backward walk
lacked the important property that dominators come before the blocks
they dominate; instead
101 - 149 of 149 matches
Mail list logo
