[PATCH] early-remat: Resync with new DF postorders [PR109940]

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

Re: [PATCH] LoongArch: Fix the problem of structure parameter passing in C++. This structure has empty structure members and less than three floating point members.

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

Re: [PATCH] [testsuite] [x86] cope with --enable-frame-pointer

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

[PATCH] LoongArch: Fix the problem of structure parameter passing in C++. This structure has empty structure members and less than three floating point members.

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

Re: [PATCH] [testsuite] [ppc] xfail uninit-pred-9_b bogus warn on ppc32 too

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

[PATCH] [testsuite] [powerpc] adjust -m32 counts for fold-vec-extract*

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

[PATCH] [libstdc++] [testsuite] xfail to_chars/long_double on x86-vxworks

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

[PATCH] [testsuite] [x86] cope with --enable-frame-pointer

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

[PATCH] [x86] reenable dword MOVE_MAX for better memmove inlining

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

[PATCH] [testsuite] [ppc] xfail uninit-pred-9_b bogus warn on ppc32 too

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

Re: [PATCH] [testsuite] [i386] enable sse2 for signbit-2.c

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

Re: [PATCH v2] [PR100106] Reject unaligned subregs when strict alignment is required

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

Re: [PATCH v2] rs6000: Add buildin for mffscrn instructions

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

Re: [PATCH] Check for sysconf decl on vxworks

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

[PATCH] [testsuite] [i386] enable sse2 for signbit-2.c

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

Re: [PATCH 2/2] vect: Enhance cost evaluation in vect_transform_slp_perm_load_1

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

[PATCH] [testsuite] require profiling for -pg

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

[PATCH] [testsuite] require pthread for openmp

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

[PATCH] [testsuite] require pic for pr103074.c

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 |

[PATCH] [testsuite] tsvc: skip include malloc.h when unavailable

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

[PATCH] Check for sysconf decl on vxworks

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

Re: [PATCH] Replace __gnu_cxx::__ops::__negate with std::not_fn

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

RE: [PATCH V5] RISC-V: Add RVV comparison autovectorization

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

Re: [PATCH V5] RISC-V: Add RVV comparison autovectorization

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

RE: [PATCH] RISC-V: Support RVV VREINTERPRET from vbool*_t to vuint*m1_t

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

Re: Re: [PATCH V2] RISC-V: Add RVV comparison autovectorization

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

RE: [PATCH v2] RISC-V: Support RVV VREINTERPRET from vbool*_t to vint*m1_t

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

[PATCH V5] RISC-V: Add RVV comparison autovectorization

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

Re: [PATCH v2] RISC-V: Support RVV VREINTERPRET from vbool*_t to vint*m1_t

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

Re: [PATCH] RISC-V: Support RVV VREINTERPRET from vbool*_t to vuint*m1_t

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

Re: [PATCH V2] RISC-V: Add RVV comparison autovectorization

> +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

RE: [PATCH] RISC-V: Support RVV VREINTERPRET from v{u}int*_t to vbool[2-64]_t

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

Re: [PATCH V4] RISC-V: Add RVV comparison autovectorization

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

[PATCH V4] RISC-V: Add RVV comparison autovectorization

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

RE: [PATCH V2] RISC-V: Fix incorrect code of reaching inaccessible memory address

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

Re: [PATCH V2] RISC-V: Fix incorrect code of reaching inaccessible memory address

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

Re: Re: [PATCH] RISC-V: Fix incorrect code of touching inaccessible memory address

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

[PATCH V2] RISC-V: Fix incorrect code of reaching inaccessible memory address

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

RE: Re: [PATCH V2] RISC-V: Fix magic number of RVV auto-vectorization expander

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

Re: [PATCH] RISC-V: Fix incorrect code of touching inaccessible memory address

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

Re: [PATCH] MIPS: don't expand large block move

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 @@

[PATCH] RISC-V: Fix incorrect code of touching inaccessible memory address

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

Re: Re: [PATCH V2] RISC-V: Fix magic number of RVV auto-vectorization expander

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:

Re: Re: [PATCH V2] RISC-V: Fix magic number of RVV auto-vectorization expander

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

Re: Re: [PATCH V2] RISC-V: Fix magic number of RVV auto-vectorization expander

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

Re: Re: [PATCH V2] RISC-V: Fix magic number of RVV auto-vectorization expander

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

Re: Re: [PATCH V2] RISC-V: Fix magic number of RVV auto-vectorization expander

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

Re: [PATCH V2] RISC-V: Fix magic number of RVV auto-vectorization expander

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.

[PATCH V2] RISC-V: Fix magic number of RVV auto-vectorization expander

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.

Re: Re: [PATCH V2] RISC-V: Add RVV comparison autovectorization

Ok. Let's wait for Kito's more comments. Thanks. juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-05-24 05:07 To: 钟居哲; gcc-patches CC: rdapp.gcc; kito.cheng; kito.cheng; palmer; palmer; Jeff Law; richard.sandiford Subject: Re: [PATCH V2] RISC-V: Add RVV comparison autovectorization >>> Don't y

[PATCH] RISC-V: Fix magic number of RVV auto-vectorization expander

From: Juzhe-Zhong This simple patch fixes the magic number, replaced by enum to make code more reasonable. Ok for trunk ? gcc/ChangeLog: * config/riscv/riscv-v.cc (expand_vec_series): Fix magic number. (expand_const_vector): Ditto. (legitimize_move): Ditto. (exp

[PATCH] Dump if a pattern fails after having printed applying it

While trying to understand how to use the ! operand for match patterns, I noticed that the debug dumps would print out applying a pattern but nothing when it was rejected in the end. This was confusing me. This adds that by emitting a dump for the failed case. Note the patch is little more complex

Re: [PATCH v2] rs6000: Add buildin for mffscrn instructions

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 we also want the similar support for mffscrn, tha

[PATCH] libstdc++: Add missing constexpr to simd_neon

Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/109261 * include/experimental/bits/simd_neon.h (_S_reduce): Add constexpr and make NEON implementation conditional on not __builtin_is_constant_evaluated. --- .../include/experimental/bits/simd_n

Re: [PATCH V2] RISC-V: Add RVV comparison autovectorization

>>> Don't you want to use your shiny new operand passing style here as >>> with the other expanders? > H, I do this just following ARM code style. > You can see I do pass rtx[] for expand_vcond and pass rtx,rtx,rtx for > expand_vec_cmp. > Well, I just follow ARM SVE implementation (You can che

Re: [PATCH 2/2] xtensa: Merge '*addx' and '*subx' insn patterns into one

On Mon, May 22, 2023 at 12:06 AM Takayuki 'January June' Suwa wrote: > > By making use of the 'addsub_operator' added in the last patch. > > gcc/ChangeLog: > > * config/xtensa/xtensa.md (*addsubx): Rename from '*addx', > and change to also accept '*subx' pattern. > (*subx):

Re: [PATCH v2] xtensa: Optimize '(x & CST1_POW2) != 0 ? CST2_POW2 : 0'

On Mon, May 22, 2023 at 10:48 PM Takayuki 'January June' Suwa wrote: > > On 2023/05/23 11:27, Max Filippov wrote: > > Hi Suwa-san, > > Hi! > > > This change introduces a bunch of test failures on big endian configuration. > > I believe that's because the starting bit position for zero_extract is

RISC-V: Use extension instructions instead of bitwise "and"

In the case where the target supports extension instructions, it is preferable to use that instead of doing the same in other ways. For the following case void foo (unsigned long a, unsigned long* ptr) { ptr[0] = a & 0xUL; ptr[1] &= 0xUL; } GCC generates foo: li

[PATCH] libstdc++: use using instead of typedef for type_traits

Since the type_traits header is a C++11 header file, using can be used instead of typedef. This patch provides more readability, especially for long type names. libstdc++-v3/ChangeLog: * include/std/type_traits: Use using instead of typedef --- libstdc++-v3/include/std/type_traits | 158

[PATCH] PR middle-end/109840: Preserve popcount/parity type in match.pd.

PR middle-end/109840 is a regression introduced by my recent patch to fold popcount(bswap(x)) as popcount(x). When the bswap and the popcount have the same precision, everything works fine, but this optimization also allowed a zero-extension between the two. The oversight is that we need to be s

Re: [patch] mcore: Fix sprintf length warning

On 5/22/23 17:58, Jan-Benedict Glaw wrote: Hi! One of the supplied argument strings is unneccesarily long (c-sky, using basically the same code, fixed it to a shorter length) and this fixes overflow warnings, as GCC fails to deduce that the full 256 bytes for load_op[] are not used at all.

[avr,committed] Fix cost computation for bit insertions.

Applied this patchlet that implements proper cost computation of (set (zero_extract (...) ...)) kind patterns that do single-bit (inverted) bit insertions. Johann -- Improve cost computation for single-bit bit insertions. Some miscomputation of rtx_costs lead to sub-optimal code for single-

Re: [PATCH] tree-optimization/109747 - SLP cost of CTORs

Richard Biener writes: > The x86 backend looks at the SLP node passed to the add_stmt_cost > hook when costing vec_construct, looking for elements that require > a move from a GPR to a vector register and cost that. But since > vect_prologue_cost_for_slp decomposes the cost for an external > SLP

[COMMITTED] i386: Add V8QI and V4QImode partial vector shift operations

Add V8QImode and V4QImode vector shift patterns that call into ix86_expand_vecop_qihi_partial. Generate special sequences for constant count operands. The patch regresses g++.dg/pr91838.C - as explained in PR91838, the test returns different results, depending on whether V8QImode shift pattern is

Re: [PATCH] Account for vector splat GPR->XMM move cost

On Tue, May 23, 2023 at 5:18 PM Richard Biener wrote: > > The following also accounts for a GPR->XMM move cost for splat > operations and properly guards eliding the cost when moving from > memory only for SSE4.1 or HImode or larger operands. This > doesn't fix the PR fully yet. > > Bootstrapped

[PATCH] Account for vector splat GPR->XMM move cost

The following also accounts for a GPR->XMM move cost for splat operations and properly guards eliding the cost when moving from memory only for SSE4.1 or HImode or larger operands. This doesn't fix the PR fully yet. Bootstrapped and tested on x86_64-unknown-linux-gnu, OK? Thanks, Richard.

[PATCH] tree-optimization/109747 - SLP cost of CTORs

The x86 backend looks at the SLP node passed to the add_stmt_cost hook when costing vec_construct, looking for elements that require a move from a GPR to a vector register and cost that. But since vect_prologue_cost_for_slp decomposes the cost for an external SLP node into individual pieces this c

[PATCH] Generic vector op costing adjustment

This is a small adjustment to the work done for PR108752 and better reflects the cost of the generated sequence. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/108752 * tree-vect-stmts.cc (vectorizable_operation): For bit operations with

Re: Re: [PATCH V2] RISC-V: Add RVV comparison autovectorization

Hi, Robin. >> Don't you want to use your shiny new operand passing style here as >> with the other expanders? H, I do this just following ARM code style. You can see I do pass rtx[] for expand_vcond and pass rtx,rtx,rtx for expand_vec_cmp. Well, I just follow ARM SVE implementation (You can c

[PATCH V3] RISC-V: Add RVV comparison autovectorization

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

[PATCH 1/2] Missed opportunity to use [SU]ABD

From: oluade01 This adds a recognition pattern for the non-widening absolute difference (ABD). gcc/ChangeLog: * doc/md.texi (sabd, uabd): Document them. * internal-fn.def (ABD): Use new optab. * optabs.def (sabd_optab, uabd_optab): New optabs, * tree-vect-pattern

Re: [PATCH] [arm] testsuite: make mve_intrinsic_type_overloads-int.c libc-agnostic

On 23/05/2023 15:41, Christophe Lyon wrote: Glibc defines int32_t as 'int' while newlib defines it as 'long int'. Although these correspond to the same size, g++ complains when using the

[PATCH] [arm] testsuite: make mve_intrinsic_type_overloads-int.c libc-agnostic

Glibc defines int32_t as 'int' while newlib defines it as 'long int'. Although these correspond to the same size, g++ complains when using the

Re: [PATCH] vect: Missed opportunity to use [SU]ABD

> > + if (reject_unsigned && TYPE_UNSIGNED (abs_type)) > > +return false; > > + if (!ANY_INTEGRAL_TYPE_P (abs_type) || TYPE_OVERFLOW_WRAPS (abs_type)) > > +return false; > > Could you explain the reject_unsigned behaviour? I'd have expected > TYPE_OVERFLOW_WRAPS (abs_type) to reject the

RE: [PATCH] RISC-V: Fix warning of vxrm pattern

Committed, thanks Jeff. Pan -Original Message- From: Gcc-patches On Behalf Of Jeff Law via Gcc-patches Sent: Tuesday, May 23, 2023 9:43 PM To: juzhe.zh...@rivai.ai; gcc-patches@gcc.gnu.org Cc: kito.ch...@gmail.com; kito.ch...@sifive.com; pal...@dabbelt.com; pal...@rivosinc.com; rdapp..

Re: [PATCH V2] RISC-V: Add RVV comparison autovectorization

> +(define_expand "vec_cmp" > + [(set (match_operand: 0 "register_operand") > + (match_operator: 1 "comparison_operator" > + [(match_operand:VI 2 "register_operand") > +(match_operand:VI 3 "register_operand")]))] > + "TARGET_VECTOR" > + { > +riscv_vector::expand_vec_cmp (op

[PATCH V2] RISC-V: Add RVV comparison autovectorization

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

Re: [PATCH] RISC-V: Fix warning of vxrm pattern

On 5/23/23 04:09, juzhe.zh...@rivai.ai wrote: From: Juzhe-Zhong I just notice the warning: ../../../riscv-gcc/gcc/config/riscv/vector.md:618:1: warning: source missing a mode? gcc/ChangeLog: * config/riscv/vector.md: Add mode. While I'm a big fan of the gen* warnings, I do wish t

Re: [COMMITTED] Remove buggy special case in irange::invert [PR109934].

BTW, we should probably backport this to god knows how many branches. Aldy On Tue, May 23, 2023 at 2:58 PM Aldy Hernandez wrote: > > [Andrew, do you remotely remember what if anything this did? It came > from a wholesale merge from our long forgotten branch, so there's no > history on the speci

[COMMITTED] Remove buggy special case in irange::invert [PR109934].

[Andrew, do you remotely remember what if anything this did? It came from a wholesale merge from our long forgotten branch, so there's no history on the specifics of it. Not important, I'm just curious. It was probably me high on something.] This patch removes a buggy special case in irange::in

[patch]: Implement PR104327 for avr

PR target/104327 not only affects s390 but also avr: The avr backend pre-sets some options depending on optimization level. The inliner then thinks that always_inline functions are not eligible for inlining and terminates with an error. Proposing the following patch that implements TARGET_CAN_INL

Re: [PATCH V12] VECT: Add decrement IV iteration loop control by variable amount support

Bootstrap on X86 passed. Ok for trunk? Thanks. juzhe.zh...@rivai.ai From: juzhe.zhong Date: 2023-05-22 16:38 To: gcc-patches CC: richard.sandiford; rguenther; Ju-Zhe Zhong Subject: [PATCH V12] VECT: Add decrement IV iteration loop control by variable amount support From: Ju-Zhe Zhong gcc/C

Re: [PATCH] Fix type error of 'switch (SUBREG_BYTE (op)).'

Jeff Law via Gcc-patches writes: > On 5/17/23 03:03, Jin Ma wrote: >> For example: >> (define_insn "mov_lowpart_sidi2" >>[(set (match_operand:SI0 "register_operand" "=r") >> (subreg:SI (match_operand:DI 1 "register_operand" " r") 0))] >>"TARGET_64BIT" >>"mov\t%0,%1

Re: [PATCH] RISC-V: Refactor the framework of RVV auto-vectorization

"juzhe.zh...@rivai.ai" writes: > Yeah. I know. > Like ARM does everywhere: > (define_expand "vcond" > [(set (match_operand:SVE_ALL 0 "register_operand") > (if_then_else:SVE_ALL > (match_operator 3 "comparison_operator" > [(match_operand:SVE_I 4 "register_operand") >(match_op

Re: [PATCH] c-family: implement -ffp-contract=on

On Tue, 23 May 2023, Richard Biener wrote: > > Ah, no, I deliberately decided against that, because that way we would go > > via gimplify_arg, which would emit all side effects in *pre_p. That seems > > wrong if arguments had side-effects that should go in *post_p. > > Ah, true - that warrants a

RE: [PATCH] arm: Fix ICE due to infinite splitting [PR109800]

Hi Alex, > -Original Message- > From: Alex Coplan > Sent: Thursday, May 11, 2023 12:15 PM > To: gcc-patches@gcc.gnu.org > Cc: ni...@redhat.com; Richard Earnshaw ; > Ramana Radhakrishnan ; Kyrylo Tkachov > > Subject: [PATCH] arm: Fix ICE due to infinite splitting [PR109800] > > Hi, > >

Re: [PATCH 2/2] aarch64: Provide FPR alternatives for some bit insertions [PR109632]

Richard Biener writes: > On Tue, May 23, 2023 at 12:38 PM Richard Sandiford via Gcc-patches > wrote: >> >> At -O2, and so with SLP vectorisation enabled: >> >> struct complx_t { float re, im; }; >> complx_t add(complx_t a, complx_t b) { >> return {a.re + b.re, a.im + b.im}; >> }

[PATCH] Dump ANTIC_OUT before pruning it

This dumps ANTIC_OUT before pruning clobbered mems from it as part of the ANTIC_IN compute. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. * tree-ssa-pre.cc (compute_antic_aux): Dump the correct ANTIC_OUT. --- gcc/tree-ssa-pre.cc | 7 --- 1 file changed, 4 inser

Re: [PATCH 2/2] aarch64: Provide FPR alternatives for some bit insertions [PR109632]

On Tue, May 23, 2023 at 12:38 PM Richard Sandiford via Gcc-patches wrote: > > At -O2, and so with SLP vectorisation enabled: > > struct complx_t { float re, im; }; > complx_t add(complx_t a, complx_t b) { > return {a.re + b.re, a.im + b.im}; > } > > generates: > > fmov

[PATCH 1/2] md: Allow to refer to the value of int iterator FOO

In a follow-up patch, I wanted to use an int iterator to iterate over various possible values of a const_int. But one problem with int iterators was that there was no way of referring to the current value of the iterator. This is unlike modes and codes, which provide automatic "mode", "MODE", "co

[PATCH 2/2] aarch64: Provide FPR alternatives for some bit insertions [PR109632]

At -O2, and so with SLP vectorisation enabled: struct complx_t { float re, im; }; complx_t add(complx_t a, complx_t b) { return {a.re + b.re, a.im + b.im}; } generates: fmovw3, s1 fmovx0, d0 fmovx1, d2 fmovw2, s3 bfi x

RE: Re: [PATCH V2] RISC-V: Refactor the framework of RVV auto-vectorization

Committed, thanks Kito. Pan -Original Message- From: Gcc-patches On Behalf Of Kito Cheng via Gcc-patches Sent: Tuesday, May 23, 2023 5:57 PM To: 钟居哲 Cc: Robin Dapp ; gcc-patches ; Kito.cheng ; palmer ; palmer ; jeffreyalaw Subject: Re: Re: [PATCH V2] RISC-V: Refactor the framework o

[PATCH] RISC-V: Fix warning of vxrm pattern

From: Juzhe-Zhong I just notice the warning: ../../../riscv-gcc/gcc/config/riscv/vector.md:618:1: warning: source missing a mode? gcc/ChangeLog: * config/riscv/vector.md: Add mode. --- gcc/config/riscv/vector.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/

[PATCH][committed] aarch64: PR target/109855 Add predicate and constraints to define_subst in aarch64-simd.md

Hi all, In this PR we ICE because the substituted pattern for mla "lost" its predicate and constraint for operand 0 because the define_subst template: [(set (match_operand: 0) (vec_concat: (match_dup 1) (match_operand:VDZ 2 "aarch64_simd_or_scalar_imm_zero")))]) Uses

Re: Re: [PATCH V2] RISC-V: Refactor the framework of RVV auto-vectorization

Lgtm, we can always improve later, I am not intend to block things too :) juzhe.zh...@rivai.ai 於 2023年5月23日 週二 17:46 寫道： > Oh， Thanks. > Let's wait for Kito's final approved. > > > > juzhe.zh...@rivai.ai > > From: Robin Dapp > Date: 2023-05-23 17:44 > To: juzhe.zhong; gcc-patches > CC: rdapp.gcc

[PATCH] tree-optimization/109849 - missed code hoisting

The following fixes code hoisting to properly consider ANTIC_OUT instead of ANTIC_IN. That's a bit expensive to re-compute but since we no longer iterate we're doing this only once per BB which should be acceptable. This avoids missing hoistings to the end of blocks where something in the block c

Re: Re: [PATCH V2] RISC-V: Refactor the framework of RVV auto-vectorization

Oh， Thanks. Let's wait for Kito's final approved. juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-05-23 17:44 To: juzhe.zhong; gcc-patches CC: rdapp.gcc; kito.cheng; kito.cheng; palmer; palmer; jeffreyalaw Subject: Re: [PATCH V2] RISC-V: Refactor the framework of RVV auto-vectorization Hi Juz

Re: [PATCH V2] RISC-V: Refactor the framework of RVV auto-vectorization

Hi Juzhe, thanks, IMHO it's clearer with the changes now. There are still things that could be improved but it is surely an improvement over what we currently have. Therefore I'd vote to go ahead so we can continue with more expanders and changes. Still, we should be prepared for more refactori

[PATCH] testsuite, analyzer: Fix testcases with fclose

The gcc.dg/analyzer/data-model-4.c and gcc.dg/analyzer/torture/conftest-1.c fail with recent glibc headers and succeed with older headers. The new error message is: warning: use of possibly-NULL 'f' where non-null expected [CWE-690] [-Wanalyzer-possible-null-argument] Like similar previous fixes

Re: [PATCH] libatomic: Provide gthr.h default implementation

On 10.01.23 16:38, Sebastian Huber wrote: On 19/12/2022 17:02, Sebastian Huber wrote: Build libatomic for all targets.  Use gthr.h to provide a default implementation.  If the thread model is "single", then this implementation will not work if for example atomic operations are used for thread/

  1   2   >