Re: [PATCH] RISC-V: Optimize TARGET_XTHEADCONDMOV

On 5/25/23 20:43, Kito Cheng wrote: I would defer this to vrull or t-head folks :) Given the overlap between where this is going and how I think we should be handling Zicondops, I'll take it. It overlaps with work I've had Raphael doing recently. jeff

Re: [aarch64] Code-gen for vector initialization involving constants

On Thu, 25 May 2023 at 15:26, Prathamesh Kulkarni wrote: > > On Thu, 25 May 2023 at 13:04, Richard Sandiford > wrote: > > > > LGTM, just a couple of comment tweaks: > > > > Prathamesh Kulkarni writes: > > > diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc > > > index

[PATCH] RISC-V: Fix VSETVL PASS ICE on SLP auto-vectorization

From: Juzhe-Zhong Fix bug reported here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109974 PR target/109974 gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (source_equal_p): Fix ICE. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/vsetvl/pr109974.c: New test. ---

[PATCH] genmatch: Emit debug message right before "return x" instead of earlier

This is based on the review of https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619342.html . Instead of emitting debug message even if we don't apply a pattern, this fixes the issue by only emitting it if it the pattern finally succeeded. OK? Bootstrapped and tested on x86_64-linux-gnu with

[PATCHv3, rs6000] Splat vector small V2DI constants with ISA 2.07 instructions [PR104124]

Hi, This patch adds a new insn for vector splat with small V2DI constants on P8. If the value of constant is in RANGE (-16, 15) and not 0 or -1, it can be loaded with vspltisw and vupkhsw on P8. It should be efficient than loading vector from memory. Compared to last version, the main change

[PATCH] Disable avoid_false_dep_for_bmi for atom and icelake(and later) core processors.

lzcnt/tzcnt has been fixed since skylake, popcnt has been fixed since icelake. At least for icelake and later intel Core processors, the errata tune is not needed. And the tune isn't need for ATOM either. Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. Ready to push to trunk.

Re: [PATCH] RISC-V: Optimize TARGET_XTHEADCONDMOV

I would defer this to vrull or t-head folks :) Die Li 於 2023年5月26日 週五 08:53 寫道： > This patch allows less instructions to be used when TARGET_XTHEADCONDMOV > is enabled. > > Provide an example from the existing testcases. > > Testcase: > int ConEmv_imm_imm_reg(int x, int y){ > if (x == 1000)

RE: [COMMITTED] i386: Use 2x-wider modes when emulating QImode vector instructions

> gcc/ChangeLog: > > * config/i386/i386-expand.cc (ix86_expand_vecop_qihi2): > Rewrite to expand to 2x-wider (e.g. V16QI -> V16HImode) > instructions when available. Emulate truncation via > ix86_expand_vec_perm_const_1 when native truncate insn > is not available. >

[PATCH] [x86] Split notl + pbraodcast + pand to pbroadcast + pandn more modes.

r12-5595-gc39d77f252e895306ef88c1efb3eff04e4232554 adds 2 splitter to transform notl + pbroadcast + pand to pbroadcast + pandn for VI124_AVX2 which leaves out all DI-element-size ones as well as all 512-bit ones. This patch extend the splitter to VI_AVX2 which will handle DImode for AVX2, and

RE: [PATCH] RISC-V: Fix zero-scratch-regs-3.c fail

Committed the PATCH v2, thanks Kito. Pan -Original Message- From: Gcc-patches On Behalf Of Kito Cheng via Gcc-patches Sent: Friday, May 26, 2023 7:48 AM To: 钟居哲 Cc: GCC Patches ; Jeff Law ; Jeff Law ; Kito Cheng ; Palmer Dabbelt Subject: Re: [PATCH] RISC-V: Fix

Re: [PATCH] RISC-V: Add autovec sign/zero extension and truncation.

I realize that both TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES and TARGET_VECTORIZE_RELATED_MODE will partially enable some auto-vectorization even preferred_simd_mode does not enable auto-vectorization when we don't specify --param=riscv-autovec-preference. So plz add autovec_use_vlmax_p into

[PATCH] RISC-V: Optimize TARGET_XTHEADCONDMOV

This patch allows less instructions to be used when TARGET_XTHEADCONDMOV is enabled. Provide an example from the existing testcases. Testcase: int ConEmv_imm_imm_reg(int x, int y){ if (x == 1000) return 10; return y; } Cflags: -O2 -march=rv64gc_xtheadcondmov -mabi=lp64d before patch:

[PATCH] RISC-V: Eliminate the magic number in riscv-v.cc

From: Pan Li This patch would like to remove the magic number in the riscv-v.cc, and align the same value to one macro. Signed-off-by: Pan Li gcc/ChangeLog: * config/riscv/riscv-v.cc (emit_vlmax_insn): Eliminate the magic number. (emit_nonvlmax_insn): Ditto.

[PATCH V2] RISC-V: Fix zero-scratch-regs-3.c fail

From: Juzhe-Zhong gcc/ChangeLog: * config/riscv/riscv.cc (vector_zero_call_used_regs): Add explict VL and drop VL in ops. --- gcc/config/riscv/riscv.cc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc index

RE: [PATCH] RISC-V: Add autovec sign/zero extension and truncation.

Looks Juzhe has fixed this issue as below, thanks Juzhe. https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619733.html Pan -Original Message- From: Li, Pan2 Sent: Thursday, May 25, 2023 8:22 PM To: gcc-patches ; Wang, Yanzhang Cc: Robin Dapp ; Kito Cheng ; palmer ;

Re: [V8][PATCH 2/2] Update documentation to clarify a GCC extension [PR77650]

> On May 25, 2023, at 4:51 PM, Joseph Myers wrote: > > The documentation in this case is OK, though claims about how a future > version will behave have a poor track record (we tend to end up with such > claims persisting in the documentation even though the change in question > didn't get

Re: [PATCH] RISC-V/testsuite: Run target testing over all the usual optimization levels

On 5/25/23 14:17, Vineet Gupta wrote: Thanks for taking a look at this. Please don't get me wrong, never mean to vilify the patches above - and I should have verified first (by reverting those) if they caused the issue - if at all. It just seemed that we started seeing these relatively

Re: RISC-V Test Errors and Failures

On 5/25/23 13:29, Thomas Schwinge wrote: Hi! On 2023-05-17T09:52:13+0200, Andreas Schwab via Gcc-patches wrote: On Mai 16 2023, Vineet Gupta wrote: Yes I was seeing similar tcl errors and such - and in my case an even higher count. They are coming from commit d6654a4be3b. I call FUD.

Re: [PATCH] RISC-V: Fix zero-scratch-regs-3.c fail

Lgtm with a minor comment 於 2023年5月26日 週五 07:18 寫道： > From: Juzhe-Zhong > > Fix ICE of zero-scratch-regs-3.c: > bug.c:7:1: internal compiler error: Segmentation fault > 7 | } > | ^ > 0x1647b23 crash_signal > ../../../riscv-gcc/gcc/toplev.cc:314 > 0x147053f

[PATCH] RISC-V: Fix zero-scratch-regs-3.c fail

From: Juzhe-Zhong Fix ICE of zero-scratch-regs-3.c: bug.c:7:1: internal compiler error: Segmentation fault 7 | } | ^ 0x1647b23 crash_signal ../../../riscv-gcc/gcc/toplev.cc:314 0x147053f maybe_legitimize_operand ../../../riscv-gcc/gcc/optabs.cc:7947 0x1470dc2

[committed] libstdc++: Add relational operators to __gnu_test::PointerBase

Tested x86_64-linux. Pushed to trunk. -- >8 -- The Cpp17Allocator requirements say that an allocator's pointer and const_pointer types must meet the Cpp17RandomAccessIterator requirements. That means our PointerBase helper for defining fancy pointer types should support the full set of

Re: Re: [PATCH v2] RISC-V: Implement autovec abs, vneg, vnot.

LGTM this patch. Let's wait for kito's final approval. Thanks. juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-05-25 22:43 To: 钟居哲; gcc-patches; kito.cheng; palmer; Jeff Law CC: rdapp.gcc Subject: Re: [PATCH v2] RISC-V: Implement autovec abs, vneg, vnot. > Beside, V2 patch should change this:

decremnt IV patch create fails on PowerPC

Yesterday's patch has been approved (decremnt IV support): https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619663.html However, it creates fails on PowerPC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109971 I am really sorry for causing inconvinience. I wonder as we disccussed: + /* If

Re: [PATCH] RISC-V/testsuite: Run target testing over all the usual optimization levels

On 5/25/23 14:17, Vineet Gupta wrote: FWIW if you want to test this out at your end, it is super easy. |git clone https://github.com/riscv-collab/riscv-gnu-toolchain toolchain-upstream cd toolchain-upstream git submodule init git submodule update ||./configure --with-arch=rv64imafdc

Re: [PATCH] RISC-V/testsuite: Run target testing over all the usual optimization levels

Hi Thomas, On 5/25/23 13:56, Thomas Schwinge wrote: Hi! On 2022-02-08T00:22:37+0800, Kito Cheng via Gcc-patches wrote: Hi Maciej: Thanks for doing this, OK to trunk. On Tue, Feb 1, 2022 at 7:04 AM Maciej W. Rozycki wrote: Use `gcc-dg-runtest' test driver rather than `dg-runtest' to run

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

What happens if the field giving the number of elements is in a contained anonymous structure or union? struct s { struct { size_t count; }; int array[] __attribute__ ((element_count ("count"))); }; This ought to work - a general principle in C is that anonymous structures and unions are

Re: [PATCH] RISC-V/testsuite: Run target testing over all the usual optimization levels

Hi! On 2022-02-08T00:22:37+0800, Kito Cheng via Gcc-patches wrote: > Hi Maciej: > > Thanks for doing this, OK to trunk. > > On Tue, Feb 1, 2022 at 7:04 AM Maciej W. Rozycki wrote: >> >> Use `gcc-dg-runtest' test driver rather than `dg-runtest' to run the >> RISC-V testsuite as several targets

Re: [V8][PATCH 2/2] Update documentation to clarify a GCC extension [PR77650]

The documentation in this case is OK, though claims about how a future version will behave have a poor track record (we tend to end up with such claims persisting in the documentation even though the change in question didn't get made and might sometimes no longer be considered desirable). --

Re: RISC-V Test Errors and Failures

Hi! On 2023-05-17T09:52:13+0200, Andreas Schwab via Gcc-patches wrote: > On Mai 16 2023, Vineet Gupta wrote: > >> Yes I was seeing similar tcl errors and such - and in my case an even >> higher count. > > They are coming from commit d6654a4be3b. I call FUD. Until you prove otherwise, of

Re: [PATCH] RISC-V: Add missing torture-init and torture-finish for rvv.exp

Hi! On 2023-05-24T15:13:19-0700, Vineet Gupta wrote: > On 5/24/23 13:34, Thomas Schwinge wrote: >> Yeah, at this point I'm not sure whether my recent changes really are >> related/relevant here. >> >>> Apparently in addition to Kito's patch below, If I comment out the >>> additional torture

Re: [committed] testsuite: Require trampolines for nestev-vla tests

Thanks! I will try to not forget this next time. Am Donnerstag, dem 25.05.2023 um 21:20 +0300 schrieb Dimitar Dimitrov: > Three recent test cases declare nested C functions, so they fail on > targets lacking support for trampolines. Fix by adding the necessary > filter. > > Committed as

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

On Thu, 25 May 2023 at 19:32, Patrick Palka via Libstdc++ < libstd...@gcc.gnu.org> wrote: > On Tue, May 23, 2023 at 3:42 PM Ken Matsui via Gcc-patches > wrote: > > > > Since the type_traits header is a C++11 header file, using can be used > instead > > of typedef. This patch provides more

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

On Thu, May 25, 2023 at 11:31 AM Patrick Palka wrote: > > On Tue, May 23, 2023 at 3:42 PM Ken Matsui via Gcc-patches > wrote: > > > > 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

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

On Tue, May 23, 2023 at 3:42 PM Ken Matsui via Gcc-patches wrote: > > 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: > > *

[committed] testsuite: Require trampolines for nestev-vla tests

Three recent test cases declare nested C functions, so they fail on targets lacking support for trampolines. Fix by adding the necessary filter. Committed as obvious. gcc/testsuite/ChangeLog: * gcc.dg/nested-vla-1.c: Require effective target trampolines. * gcc.dg/nested-vla-2.c:

Re: [PATCH] RISC-V: In pipeline scheduling, insns should not be fusion in different BB blocks.

On 5/25/23 02:32, Jin Ma wrote: When the last insn1 of BB1 and the first insn2 of BB2 are fusion, insn2 will clear all dependencies in the function chain_to_prev_insn, resulting in insn2 may mov to any BB, and the program calculation result is wrong. gcc/ChangeLog: * sched-deps.cc

[avr,committed]: Implement PR104327 for avr

Am 25.05.23 um 17:07 schrieb Richard Biener: Am 25.05.2023 um 16:22 schrieb Georg-Johann Lay :  Am 25.05.23 um 08:35 schrieb Richard Biener: On Wed, May 24, 2023 at 5:44 PM Georg-Johann Lay wrote: Am 24.05.23 um 11:38 schrieb Richard Biener: On Tue, May 23, 2023 at 2:56 PM

[COMMITTED] i386: Use 2x-wider modes when emulating QImode vector instructions

Rewrite ix86_expand_vecop_qihi2 to expand fo 2x-wider (e.g. V16QI -> V16HImode) instructions when available. Currently, the compiler generates following assembly for V16QImode multiplication (-mavx2): vpunpcklbw %xmm0, %xmm0, %xmm3 vpunpcklbw %xmm1, %xmm1, %xmm2 vpunpckhbw

[avr,committed] PR82931: Improve single-bit transfers between registers.

Applied this patch that makes one insn more generic so it can handle more bit positions than just 0. Johann -- target/82931: Make a pattern more generic to match more bit-transfers. There is already a pattern in avr.md that matches single-bit transfers from one register to another one, but it

Re: [i386 PATCH] A minor code clean-up: Use NULL_RTX instead of nullptr

On Wed, 24 May 2023 18:54:06 +0100 "Roger Sayle" wrote: > My understanding is that GCC's preferred null value for rtx is NULL_RTX > (and for tree is NULL_TREE), and by being typed allows strict type checking, > and use with function polymorphism and template instantiation. > C++'s nullptr is

[PATCH] btf: improve -dA comments for testsuite

Many BTF type kinds refer to other types via index to the final types list. However, the order of the final types list is not guaranteed to remain the same for the same source program between different runs of the compiler, making it difficult to test inter-type references. This patch updates the

[V1][PATCH 3/3] Use the element_count attribute information in bound sanitizer[PR108896]

2023-05-17 Qing Zhao gcc/c-family/ChangeLog: PR C/108896 * c-ubsan.cc (ubsan_instrument_bounds): Use element_count attribute information. gcc/testsuite/ChangeLog: PR C/108896 * gcc.dg/ubsan/flex-array-element-count-bounds.c: New test. ---

[V1][PATCH 2/3] Use the element_count atribute info in builtin object size [PR108896].

2023-05-17 Qing Zhao gcc/ChangeLog: PR C/108896 * tree-object-size.cc (addr_object_size): Use the element_count attribute info. * tree.cc (component_ref_has_element_count_p): New function. (component_ref_get_element_count): New function. * tree.h

[V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

'element_count ("COUNT")' The 'element_count' attribute may be attached to the flexible array member of a structure. It indicates that the number of the elements of the array is given by the field named "COUNT" in the same structure as the flexible array member. GCC uses this

[V1][PATCH 0/3] New attribute "element_count" to annotate bounds for C99 FAM(PR108896)

Hi, This patch set introduces a new attribute "element_count" to annotate bounds for C99 flexible array member. A gcc bugzilla PR108896 has been created to record this task: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896 A nice writeup "Bounded Flexible Arrays in C"

Re: [PATCH v2] i386: Allow -mlarge-data-threshold with -mcmodel=large

On 2023-05-25, Jan Beulich wrote: On 25.05.2023 17:16, Fangrui Song wrote: --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -32942,9 +32942,10 @@ the cache line size. @samp{compat} is the default. @opindex mlarge-data-threshold @item -mlarge-data-threshold=@var{threshold} -When

Re: [PATCH] RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation.

> When testing a extension, it is often necessary for a certain program not to > need some kind of extension, such as the bitmanip extension, to evaluate the > performance or codesize of the extension. However, the current multilib rules > will report an error when it is not a superset of the

Re: [PATCH] stor-layout, aarch64: Express SRA intrinsics with RTL codes

Kyrylo Tkachov via Gcc-patches writes: > Hi all, > > This patch expresses the intrinsics for the SRA and RSRA instructions with > standard RTL codes rather than relying on UNSPECs. > These instructions perform a vector shift right plus accumulate with an > optional rounding constant addition for

[V8][PATCH 2/2] Update documentation to clarify a GCC extension [PR77650]

on a structure with a C99 flexible array member being nested in another structure. "The GCC extension accepts a structure containing an ISO C99 "flexible array member", or a union containing such a structure (possibly recursively) to be a member of a structure. There are two situations: * A

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

Peter, Kewen: On Thu, 2023-05-25 at 13:28 +0800, Kewen.Lin wrote: > on 2023/5/24 23:20, Carl Love wrote: > > On Wed, 2023-05-24 at 13:32 +0800, Kewen.Lin wrote: > > > 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

Re: [PATCH] Only use NO_REGS in cost calculation when !hard_regno_mode_ok for GENERAL_REGS and mode.

On Thu, May 25, 2023 at 10:29:47AM -0400, Vladimir Makarov wrote: > > On 5/17/23 02:57, liuhongt wrote: > >r14-172-g0368d169492017 replaces GENERAL_REGS with NO_REGS in cost > >calculation when the preferred register class are not known yet. > >It regressed powerpc PR109610 and PR109858, it looks

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

Hi Alex, On Thu, May 25, 2023 at 10:55:37AM -0300, Alexandre Oliva wrote: > On May 25, 2023, Segher Boessenkool wrote: > > Fwiw, updating the insn counts blindly like this > > ... is a claim that carries a wildly incorrect and insulting underlying > assumption: Sorry you feel that way. I'm

[V8][PATCH 0/2]Accept and Handle the case when a structure including a FAM nested in another structure

(Resend due to the previous patches didn't include the version number) Hi, This is the 8th version of the patch, which rebased on the latest trunk. This is an important patch needed by Linux Kernel security project. compared to the 7th version, the major change are: 1. update the documentation

[V8][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

GCC extension accepts the case when a struct with a C99 flexible array member is embedded into another struct or union (possibly recursively) as the last field. __builtin_object_size should treat such struct as flexible size. gcc/c/ChangeLog: PR tree-optimization/101832 *

Re: [PATCH v2] i386: Allow -mlarge-data-threshold with -mcmodel=large

On 25.05.2023 17:16, Fangrui Song wrote: > --- a/gcc/doc/invoke.texi > +++ b/gcc/doc/invoke.texi > @@ -32942,9 +32942,10 @@ the cache line size. @samp{compat} is the default. > > @opindex mlarge-data-threshold > @item -mlarge-data-threshold=@var{threshold} > -When @option{-mcmodel=medium} is

[PATCH] VECT: Add SELECT_VL support

From: Ju-Zhe Zhong This patch is adding SELECT_VL middle-end support allow target have target dependent optimization in case of length calculation. This patch is inspired by RVV ISA and LLVM: https://reviews.llvm.org/D99750 The SELECT_VL is same behavior as LLVM "get_vector_length" with these

Re: [V7][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

> On May 25, 2023, at 1:41 AM, Bernhard Reutner-Fischer > wrote: > > On 24 May 2023 16:09:21 CEST, Qing Zhao wrote: >> Bernhard, >> >> Thanks a lot for your comments. >> >>> On May 19, 2023, at 7:11 PM, Bernhard Reutner-Fischer >>> wrote: >>> >>> On Fri, 19 May 2023 20:49:47 + >>>

[PATCH v2] i386: Allow -mlarge-data-threshold with -mcmodel=large

When using -mcmodel=medium, large data objects larger than the -mlarge-data-threshold threshold are placed into large data sections (.lrodata, .ldata, .lbss and some variants). GNU ld and ld.lld 17 place .l* sections into separate output sections. If small and medium code model object files are

[PATCH 3/3] xtensa: Rework 'setmemsi' insn pattern

In order to reject voodoo estimation logic with lots of magic numbers, this patch revises the code to measure the costs of the three memset methods based on the actual emission size of the insn sequence corresponding to each method and choose the smallest one. gcc/ChangeLog: *

[PATCH 1/3] xtensa: Addendum of the commit e33d2dcb463161a110ac345a451132ce8b2b23d9

gcc/ChangeLog: * config/xtensa/xtensa.md (*extzvsi-1bit_ashlsi3): Retract excessive line folding, and correct the value of the "length" insn attribute related to TARGET_DENSITY. (*extzvsi-1bit_addsubx): Ditto. --- gcc/config/xtensa/xtensa.md | 11 ++- 1

[PATCH 2/3] xtensa: Add 'subtraction from constant' insn pattern

This patch makes try to eliminate using temporary pseudo for '(minus:SI (const_int) (reg:SI))' if the addition of negative constant value can be emitted in a single machine instruction. /* example */ int test0(int x) { return 1 - x; } int test1(int x) { return 100 - x;

Re: [patch]: Implement PR104327 for avr

> Am 25.05.2023 um 16:22 schrieb Georg-Johann Lay : > >  > >> Am 25.05.23 um 08:35 schrieb Richard Biener: >>> On Wed, May 24, 2023 at 5:44 PM Georg-Johann Lay wrote: >>> Am 24.05.23 um 11:38 schrieb Richard Biener: On Tue, May 23, 2023 at 2:56 PM Georg-Johann Lay wrote: > >

RE: [PATCH V16] VECT: Add decrement IV iteration loop control by variable amount support

Committed, thanks Richard. Pan -Original Message- From: Gcc-patches On Behalf Of Richard Biener via Gcc-patches Sent: Thursday, May 25, 2023 9:06 PM To: Richard Sandiford Cc: juzhe.zh...@rivai.ai; gcc-patches@gcc.gnu.org Subject: Re: [PATCH V16] VECT: Add decrement IV iteration loop

Re: [PATCH v2] RISC-V: Implement autovec abs, vneg, vnot.

> Beside, V2 patch should change this: > emit_vlmax_masked_insn (unsigned icode, int op_num, rtx *ops) > > change it into emit_vlmax_masked_mu_insn . V3 is inline with these changes. This patch implements abs2, vneg2 and vnot2 expanders for integer vector registers and adds tests for them.

Re: [PATCH] Only use NO_REGS in cost calculation when !hard_regno_mode_ok for GENERAL_REGS and mode.

On 5/17/23 02:57, liuhongt wrote: r14-172-g0368d169492017 replaces GENERAL_REGS with NO_REGS in cost calculation when the preferred register class are not known yet. It regressed powerpc PR109610 and PR109858, it looks too aggressive to use NO_REGS when mode can be allocated with GENERAL_REGS.

RE: [PATCH 1/1] arm: merge MVE_5 and MVE_6 iterators

> -Original Message- > From: Christophe Lyon > Sent: Thursday, May 25, 2023 1:25 PM > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov > Cc: Christophe Lyon > Subject: [PATCH 1/1] arm: merge MVE_5 and MVE_6 iterators > > MVE_5 and MVE_6 iterators are the same: this patch replaces MVE_6

Re: [patch]: Implement PR104327 for avr

Am 25.05.23 um 08:35 schrieb Richard Biener: On Wed, May 24, 2023 at 5:44 PM Georg-Johann Lay wrote: Am 24.05.23 um 11:38 schrieb Richard Biener: On Tue, May 23, 2023 at 2:56 PM Georg-Johann Lay wrote: PR target/104327 not only affects s390 but also avr: The avr backend pre-sets some

Re: [PATCH 1/2] Implementation of new RISCV optimizations pass: fold-mem-offsets.

On Thu, 25 May 2023 at 16:14, Jeff Law via Gcc-patches wrote: > > > > On 5/25/23 07:50, Richard Biener wrote: > > On Thu, May 25, 2023 at 3:32 PM Jeff Law via Gcc-patches > > wrote: > >> > >> > >> > >> On 5/25/23 07:01, Richard Biener via Gcc-patches wrote: > >>> On Thu, May 25, 2023 at 2:36 PM

Re: [PATCH 1/2] Implementation of new RISCV optimizations pass: fold-mem-offsets.

On 5/25/23 07:50, Richard Biener wrote: On Thu, May 25, 2023 at 3:32 PM Jeff Law via Gcc-patches wrote: On 5/25/23 07:01, Richard Biener via Gcc-patches wrote: On Thu, May 25, 2023 at 2:36 PM Manolis Tsamis wrote: Implementation of the new RISC-V optimization pass for memory offset

Re: [PATCH 1/2] Implementation of new RISCV optimizations pass: fold-mem-offsets.

On Thu, May 25, 2023 at 4:53 PM Richard Biener via Gcc-patches wrote: > > On Thu, May 25, 2023 at 3:32 PM Jeff Law via Gcc-patches > wrote: > > > > > > > > On 5/25/23 07:01, Richard Biener via Gcc-patches wrote: > > > On Thu, May 25, 2023 at 2:36 PM Manolis Tsamis > > > wrote: > > >> > > >>

[PATCH][committed] aarch64: PR target/99195 Annotate complex FP patterns for vec-concat-zero

Hi all, This patch annotates the complex add and mla patterns for vec-concat-zero. Testing showed an interesting bug in our MD patterns where they were defined to match: (plus:VHSDF (match_operand:VHSDF 1 "register_operand" "0") (unspec:VHSDF [(match_operand:VHSDF 2

Re: [COMMITTED 4/4] - Gimple range PHI analyzer and testcases

On 5/25/23 03:03, Richard Biener wrote: On Wed, May 24, 2023 at 11:21 PM Andrew MacLeod via Gcc-patches There is about a 1.5% slowdown to VRP to invoke and utilize the analyzer in all 3 passes of VRP. overall compile time is 0.06% slower. Bootstraps on x86_64-pc-linux-gnu with no

[PATCH][committed] arm: Implement ACLE Data Intrinsics

Hi all, This patch implements a number of scalar data processing intrinsics from ACLE that were requested by some users. Some of these have fast single-instruction sequences for Armv6 and later, but even for earlier versions they can still emit an inline sequence or a call to libgcc (and ACLE

Re: [PATCH 0/2] RISC-V: New pass to optimize calculation of offsets for memory operations.

On Thu, May 25, 2023 at 4:42 PM Jeff Law wrote: > > > > On 5/25/23 06:35, Manolis Tsamis wrote: > > > > This pass tries to optimize memory offset calculations by moving them > > from add immediate instructions to the memory loads/stores. > > For example it can transform this: > > > >addi

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

On May 25, 2023, Segher Boessenkool wrote: > Fwiw, updating the insn counts blindly like this ... is a claim that carries a wildly incorrect and insulting underlying assumption: I've actually identified the corresponding change to the lp64 tests, compared the effects of the codegen changes, and

Re: RISC-V Bootstrap problems

On 5/24/23 22:19, juzhe.zh...@rivai.ai wrote: >> It's highly unlikely we'll switch from the mechanisms we're using. They're pretty deeply embedded into how all the ports are developed and work. We just take a look at the build file. It seems that the functions generated by define_insn

Re: [PATCH 1/2] Implementation of new RISCV optimizations pass: fold-mem-offsets.

On Thu, May 25, 2023 at 3:32 PM Jeff Law via Gcc-patches wrote: > > > > On 5/25/23 07:01, Richard Biener via Gcc-patches wrote: > > On Thu, May 25, 2023 at 2:36 PM Manolis Tsamis > > wrote: > >> > >> Implementation of the new RISC-V optimization pass for memory offset > >> calculations,

Re: [PATCH] RISC-V: In pipeline scheduling, insns should not be fusion in different BB blocks.

On 5/25/23 03:22, Richard Sandiford wrote: Jin Ma writes: When the last insn1 of BB1 and the first insn2 of BB2 are fusion, insn2 will clear all dependencies in the function chain_to_prev_insn, resulting in insn2 may mov to any BB, and the program calculation result is wrong.

Re: [PATCH 0/2] RISC-V: New pass to optimize calculation of offsets for memory operations.

On 5/25/23 06:35, Manolis Tsamis wrote: This pass tries to optimize memory offset calculations by moving them from add immediate instructions to the memory loads/stores. For example it can transform this: addi t4,sp,16 add t2,a6,t4 shl t3,t2,1 ld a2,0(t3) addi a2,1 sd

Re: [PATCH 2/2] cprop_hardreg: Enable propagation of the stack pointer if possible.

On 5/25/23 06:35, Manolis Tsamis wrote: Propagation of the stack pointer in cprop_hardreg is currenty forbidden in all cases, due to maybe_mode_change returning NULL. Relax this restriction and allow propagation when no mode change is requested. gcc/ChangeLog: * regcprop.cc

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

On Thu, May 25, 2023 at 3:25 PM Alexandre Oliva wrote: > > On May 25, 2023, Richard Biener wrote: > > > On Thu, May 25, 2023 at 1:10 PM Alexandre Oliva wrote: > >> > >> On May 25, 2023, Richard Biener wrote: > >> > >> > I mean we could do what RTL expansion would do later and do > >> >

Re: [PATCH 1/2] Implementation of new RISCV optimizations pass: fold-mem-offsets.

On 5/25/23 07:01, Richard Biener via Gcc-patches wrote: On Thu, May 25, 2023 at 2:36 PM Manolis Tsamis wrote: Implementation of the new RISC-V optimization pass for memory offset calculations, documentation and testcases. Why do fwprop or combine not what you want to do? I think a lot

Re: [PATCH 1/2] Implementation of new RISCV optimizations pass: fold-mem-offsets.

On Thu, May 25, 2023 at 4:03 PM Richard Biener wrote: > > On Thu, May 25, 2023 at 2:36 PM Manolis Tsamis > wrote: > > > > Implementation of the new RISC-V optimization pass for memory offset > > calculations, documentation and testcases. > > Why do fwprop or combine not what you want to do? >

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

On May 25, 2023, Richard Biener wrote: > On Thu, May 25, 2023 at 1:10 PM Alexandre Oliva wrote: >> >> On May 25, 2023, Richard Biener wrote: >> >> > I mean we could do what RTL expansion would do later and do >> > by-pieces, thus emit multiple loads/stores but not n loads and then >> > n

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

On Thu, 25 May 2023, Richard Sandiford wrote: > This looks good to me. Just a couple of very minor cosmetic things: > > juzhe.zh...@rivai.ai writes: > > @@ -753,17 +846,35 @@ vect_set_loop_condition_partial_vectors (class loop > > *loop, > > continue; > > } > > > > - /* See

Re: Re: [PATCH v2] RISC-V: Implement autovec abs, vneg, vnot.

>> Yes, this is the emitted sequence, but the vsetvli mask is indeed >> wrong. Just got lucky there. Or what else did you mean with >> logically incorrect? Oh, sorry. I didn't mean this patch logically incorrect. I mean the MASK_ANY is logicall incorrect. This patch is ok to me as long as you

Re: [PATCH 1/2] Implementation of new RISCV optimizations pass: fold-mem-offsets.

On Thu, May 25, 2023 at 2:36 PM Manolis Tsamis wrote: > > Implementation of the new RISC-V optimization pass for memory offset > calculations, documentation and testcases. Why do fwprop or combine not what you want to do? > gcc/ChangeLog: > > * config.gcc: Add riscv-fold-mem-offsets.o

[PATCH] RISC-V: Add ZVFHMIN extension to the -march= option

From: Pan Li This patch would like to add new sub extension (aka ZVFHMIN) to the -march= option. To make it simple, only the sub extension itself is involved in this patch, and the underlying FP16 related RVV intrinsic API depends on the TARGET_ZVFHMIN. You can locate more information about

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

Thanks Richard so much. I have sent V17 patch for commit (fix format as you suggested). You don't need to reply that. I am waiting for Richi's final approval. Thanks. juzhe.zh...@rivai.ai From: Richard Sandiford Date: 2023-05-25 20:36 To: juzhe.zhong CC: gcc-patches; rguenther Subject: Re:

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

From: Ju-Zhe Zhong Fix format for Richard. This patch is supporting decrement IV by following the flow designed by Richard: (1) In vect_set_loop_condition_partial_vectors, for the first iteration of: call vect_set_loop_controls_directly. (2) vect_set_loop_controls_directly calculates

Re: [PATCH v4] libgfortran: Replace mutex with rwlock

On 1/1/1970 8:00 AM, Thomas Koenig wrote: Hi Lipeng, May I know any comment or concern on this patch, thanks for your time :) Thanks for your patience in getting this reviewed. A few remarks / questions. Which strategy is used in this implementation, read-preferring or

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

This looks good to me. Just a couple of very minor cosmetic things: juzhe.zh...@rivai.ai writes: > @@ -753,17 +846,35 @@ vect_set_loop_condition_partial_vectors (class loop > *loop, > continue; > } > > - /* See whether zero-based IV would ever generate all-false masks

[PATCH 1/2] Implementation of new RISCV optimizations pass: fold-mem-offsets.

Implementation of the new RISC-V optimization pass for memory offset calculations, documentation and testcases. gcc/ChangeLog: * config.gcc: Add riscv-fold-mem-offsets.o to extra_objs. * config/riscv/riscv-passes.def (INSERT_PASS_AFTER): Schedule a new pass. *

[PATCH 0/2] RISC-V: New pass to optimize calculation of offsets for memory operations.

This pass tries to optimize memory offset calculations by moving them from add immediate instructions to the memory loads/stores. For example it can transform this: addi t4,sp,16 add t2,a6,t4 shl t3,t2,1 ld a2,0(t3) addi a2,1 sd a2,8(t2) into the following (one instruction

[PATCH 2/2] cprop_hardreg: Enable propagation of the stack pointer if possible.

Propagation of the stack pointer in cprop_hardreg is currenty forbidden in all cases, due to maybe_mode_change returning NULL. Relax this restriction and allow propagation when no mode change is requested. gcc/ChangeLog: * regcprop.cc (maybe_mode_change): Enable stack pointer

Re: [PATCH v2] RISC-V: Implement autovec abs, vneg, vnot.

> I think it's logically incorrect.  For ABS, you want: > > operands[0] = operads[1] > 0 ? operands[1] :  (-operands[1]) > So you should do this following sequence: > > vmslt v0,v1,0 > vneg v1,v1v0.t (should use Mask undisturbed) Yes, this is the emitted sequence, but the vsetvli mask is indeed

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

> -Original Message- > From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Kyrylo > Tkachov via Gcc-patches > Sent: Thursday, May 25, 2023 11:48 AM > To: Alex Coplan > Cc: gcc-patches@gcc.gnu.org; ni...@redhat.com; Richard Earnshaw > ; Ramana Radhakrishnan > >

[PATCH 1/1] arm: merge MVE_5 and MVE_6 iterators

MVE_5 and MVE_6 iterators are the same: this patch replaces MVE_6 with MVE_5 everywhere in mve.md and removes MVE_6 from iterators.md. 2023-05-25 Christophe Lyon gcc/ * config/arm/iterators.md (MVE_6): Remove. * config/arm/mve.md: Replace MVE_6 with MVE_5. ---

RE: [PATCH] RISC-V: Add autovec sign/zero extension and truncation.

The zero-scratch-regs-3.c comes from below PATCH. https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615494.html Hi Yanzhang, Could you please help to double check the issue reported by Robin? Aka: " zero-scratch-regs-3.c seems to FAIL in vcondu but that already happens on trunk." Thanks

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

Thank you so much for your patience. Could you take a look at V16 patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619652.html whether it is ok for trunk ? Thanks. juzhe.zh...@rivai.ai From: Richard Sandiford Date: 2023-05-25 18:19 To: juzhe.zhong\@rivai.ai CC: gcc-patches;

  1   2   >