[PING] [PATCH v3 3/4] ree: Main functionality to Improve ree pass for rs6000 target

Hello Jeff: Please review Jeff. Thanks & Regards Ajit On 12/05/23 4:48 pm, Ajit Agarwal via Gcc-patches wrote: > Hello Jeff: > > > On 29/04/23 3:40 am, Jeff Law wrote: >> >> >> On 4/20/23 15:03, Ajit Agarwal wrote: >> >>> >>> Currently I support AND with const1_rtx. This is what is equivalent

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

On 30.05.23 13:17, Richard Biener wrote: The alternative would be to provide the required subset of atomic library functions from libgcov.a and emit calls to that directly? The locked data isn't part of any ABI so no compatibility guarantee needs to be maintained? So, if atomic operations are

Re: [PATCH 3/3 v2] xtensa: Optimize 'cstoresi4' insn pattern

Hi Suwa-san, On Tue, May 30, 2023 at 2:51 AM Takayuki 'January June' Suwa wrote: > > Resubmitting the correct one due to a mistake in merging order of fixes. > --- > This patch introduces more optimized implementations for the 6 cstoresi4 > insn comparison methods (eq/ne/lt/le/gt/ge, however,

[PATCH] Fix PR 110042: ifcvt regression due to paradoxical subregs

After r14-1014-gc5df248509b489364c573e8, GCC started to emit directly a zero_extract for `(t1&0x8)!=0`. This introduced a small regression where ifcvt would not do the ifconversion as there is now a paradoxical subreg in the dest which was being rejected. Since paradoxical subreg set the whole

ping^^: [PATCH] rs6000: Enable const_anchor for 'addi'

Gentle ping... Jiufu Guo via Gcc-patches writes: > Gentle ping... > > Jiufu Guo via Gcc-patches writes: > >> Hi, >> >> I'm thinking that we may enable this patch for stage1, so ping it. >> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603530.html >> >> BR, >> Jeff (Jiufu) >> >>

Ping^^^ [PATCH 0/4] rs6000: build constant via li/lis;rldicX

Gentle ping... Jiufu Guo via Gcc-patches writes: > Hi, > > I would like to ping these patches. > [0/4] > https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611286.html > [1/4] > https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611287.html > [2/4] >

ping^^^: [PATCH V2] rs6000: Enhance lowpart/highpart DI->SF by mtvsrws/mtvsrd

Gentle ping... Jiufu Guo via Gcc-patches writes: > Gentle ping... > > Jiufu Guo via Gcc-patches writes: > >> Hi >> >> I would like to ping this patch for stage1: >> https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612168.html >> >> BR, >> Jeff (Jiufu) >> >> Jiufu Guo writes: >> >>>

Re: Re: [PATCH] VECT: Change flow of decrement IV

Hi，all. I have posted my several investigations: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620101.html https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620105.html https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620108.html Turns out when "niters is a constant value and vf is a

[PATCH] Fix ICE in rewrite_expr_tree_parallel

Hi, This patch is to fix ICE in rewrite_expr_tree_parallel. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110038 Bootstrapped and regtested. Ok for trunk? Regards Lili. 1. Limit the value of tree-reassoc-width to IntegerRange(0, 256). 2. Add width limit in rewrite_expr_tree_parallel.

RE: [PATCH] RISC-V: Fix unreachable test code for init repeat sequence.

Committed, thanks Kito. Pan -Original Message- From: Kito Cheng Sent: Wednesday, May 31, 2023 8:50 AM To: Li, Pan2 Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; Wang, Yanzhang ; daisukeokahas...@gmail.com Subject: Re: [PATCH] RISC-V: Fix unreachable test code for init repeat

Re: [PATCH] RISC-V: Fix unreachable test code for init repeat sequence.

OK On Wed, May 31, 2023 at 8:29 AM wrote: > > From: Pan Li > > This patch fix one unreachable test code, which is for debugging purpose > without cleanup before commit. > > Signed-off-by: Pan Li > > gcc/testsuite/ChangeLog: > > *

Re: [RFC] RISC-V: Eliminate extension after for *w instructions

On 5/24/23 17:14, Jivan Hakobyan via Gcc-patches wrote: gcc/ChangeLog: * config/riscv/bitmanip.md (rotrdi3): New pattern. (rotrsi3): Likewise. (rotlsi3): Likewise. * config/riscv/riscv-protos.h (riscv_emit_binary): New function declaration

[PATCH] RISC-V: Fix unreachable test code for init repeat sequence.

From: Pan Li This patch fix one unreachable test code, which is for debugging purpose without cleanup before commit. Signed-off-by: Pan Li gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/vls-vlmax/init-repeat-sequence-run-1.c: Remove debug code. Signed-off-by: Pan Li

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

On 5/30/23 08:48, Maciej W. Rozycki wrote: On Mon, 29 May 2023, Jin Ma wrote: Can you give me a specific example (compilation options and multilibs available) of a failure you refer to? A simple example: 1. Use "--disable-multilib --with-abi =lp64d --with-arch

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

On Tue, 30 May 2023, Qing Zhao via Gcc-patches wrote: > Joseph, > > could you please review this patch and see whether it's Okay for commit > now? This version is OK. -- Joseph S. Myers jos...@codesourcery.com

Re: Re: [PATCH] RISC-V: Basic VLS code gen for RISC-V

Hi, Kito. After consideration, I think extending VLS modes into VLA pattern is not a wise choice now. And I prefer everything to be pefect (Otherwise, I will rework the whole thing in the future and it's wasting time). So I have suggestions as follows: First, add a new avl_type here: enum

[pushed] testsuite: add verify-sarif-file to some testcases that were missing it

Pushed to trunk as r14-1420-ge4c8f7024f02d8. gcc/testsuite/ChangeLog: * gcc.dg/analyzer/malloc-sarif-1.c: Add missing verify-sarif-file directive. * gcc.dg/analyzer/sarif-pr107366.c: Likewise. --- gcc/testsuite/gcc.dg/analyzer/malloc-sarif-1.c | 2 ++

Re: [C PATCH 3/4] introduce ubsan checking for assigment of VM types 3/4

On Mon, 29 May 2023, Martin Uecker via Gcc-patches wrote: > Support instrumentation of function arguments for functions > called via a declaration. We can support only simple size What do you mean by "via a declaration"? If the *definition* is visible (and known to be the definition

Re: Re: [PATCH] VECT: Change flow of decrement IV

Hi, Richi. >> As I said in the PR with the proposed scheme you get a loop around copy of >> the IV since both the pre and the post decrement values are live at the same >> time. >> If the CPU has a underflow bit set from the subtraction and a branch on that >> test using that could avoid the

Re: [PATCH] RISC-V: Synthesize power-of-two constants.

Assuming a fully pipelined vector unit (and from experience on AArch64), an u-arch's scalar-to-vector move cost is likely to play a significant role in whether this will be profitable or not. --Philipp. On Wed, 31 May 2023 at 00:10, Jeff Law via Gcc-patches wrote: > > > > On 5/30/23 16:01, 钟居哲

Re: [PATCH] RISC-V: Synthesize power-of-two constants.

On 5/30/23 16:13, 钟居哲 wrote: Ok. I prefer just keep scalar load + vmv.v.x by default since I believe most machines prefer this way. Seems quite reasonable to me. jeff

Re: Re: [PATCH] RISC-V: Synthesize power-of-two constants.

Ok. I prefer just keep scalar load + vmv.v.x by default since I believe most machines prefer this way. juzhe.zh...@rivai.ai From: Jeff Law Date: 2023-05-31 06:09 To: 钟居哲; andrew; rdapp.gcc CC: gcc-patches; kito.cheng; palmer Subject: Re: [PATCH] RISC-V: Synthesize power-of-two constants.

Re: [PATCH] RISC-V: Synthesize power-of-two constants.

On 5/30/23 16:01, 钟居哲 wrote: I agree with Andrew. And I don't think this patch is appropriate for following reasons: 1. This patch increases vector workload in machine since      it convert scalar load + vmv.v.x into vmv.v.i + vsll.vi. This is probably uarch dependent. I can probably

Re: Re: [PATCH] RISC-V: Synthesize power-of-two constants.

I agree with Andrew. And I don't think this patch is appropriate for following reasons: 1. This patch increases vector workload in machine since it convert scalar load + vmv.v.x into vmv.v.i + vsll.vi. 2. For multi-issue OoO machine, scalar instructions are very cheap when they are

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

> On May 26, 2023, at 12:12 PM, Kees Cook wrote: > > On Thu, May 25, 2023 at 04:14:47PM +, Qing Zhao wrote: >> This patch set introduces a new attribute "element_count" to annotate bounds >> for C99 flexible array member. > > Thank you for this work! I'm really excited to start using it

[WIP] Have -Wpointer-sign be enabled by -Wextra, too [PR109836]

PR109836 is a request to have -Wpointer-sign enabled by default. There were points of disagreement raised in the bug report, so I figured that maybe as a compromise, the warning could just be enabled by -Wextra, as well (I have in fact seen some projects that enable -Wextra but not -Wall). This

Re: [PATCH] tree: Fix up save_expr [PR52339]

On 5/30/23 16:51, Jakub Jelinek wrote: On Tue, May 30, 2023 at 04:36:34PM -0400, Jason Merrill wrote: Note that it is fine to treat p->fld as invariant in C++ if fld is TREE_READONLY and p is itself invariant. The implementation is allowed to assume that other code didn't destroy *p and create

Re: [PATCH] tree: Fix up save_expr [PR52339]

On Tue, May 30, 2023 at 04:36:34PM -0400, Jason Merrill wrote: > Note that it is fine to treat p->fld as invariant in C++ if fld is > TREE_READONLY and p is itself invariant. The implementation is allowed to > assume that other code didn't destroy *p and create a new object with a > different

[PATCH] rs6000: Update the vsx-vector-6.* tests.

GCC maintainers: The following patch takes the tests in vsx-vector-6-p7.h, vsx-vector- 6-p8.h, vsx-vector-6-p9.h and reorganizes them into a series of smaller test files by functionality rather than processor version. The patch has been tested on Power 10 with no regressions. Please let me

[PATCH] rs6000, fix vec_replace_unaligned builtin arguments

GCC maintainers: The following patch fixes the first argument in the builtin definition and the corresponding test cases. Initially, the builtin specification was wrong due to a cut and past error. The documentation was fixed in: commit 8cb748a31cd8c7ac9c88b6abc38ce077dd462a7a Author:

Re: [PATCH] tree: Fix up save_expr [PR52339]

On 5/30/23 04:23, Jakub Jelinek wrote: On Tue, May 30, 2023 at 10:03:05AM +0200, Eric Botcazou wrote: We want to be able to treat such things as invariant somehow even if we can't do that for references to user data that might be changed by intervening code. That is, indicate that we know that

Re: [pushed] LRA: Update insn sp offset if its input reload changes SP

On 5/30/23 14:05, Vladimir Makarov wrote: The following patch fixes an LRA bug triggered by switching H8300 target from reload to LRA.  The description of the problem is in the commit message. The patch was successfully bootstrapped and tested on x86-64, aarch64, and ppc64le. THanks. We

Re: [PATCH] RISC-V: Synthesize power-of-two constants.

This turns out to be a de-optimization for implementations with any amount of temporal execution (which is most machines with LMUL > 1 and even some machines with LMUL <= 1). Scalar instructions are generally cheaper than multi-cycle-occupancy vector operations, so reducing scalar work by

[testsuite,applied] PR52641: Fix more implicit int=32 fallout.

Committed to undo implicit assumptions. Johann testsuite/52641: Fix more of implicit int=32 assumption fallout. gcc/testsuite/ PR testsuite/52641 * gcc.dg/torture/pr107451.c: Require int32plus. * gcc.dg/torture/pr108574-3.c: Use __INT32_TYPE__ instead of int. *

[pushed] LRA: Update insn sp offset if its input reload changes SP

The following patch fixes an LRA bug triggered by switching H8300 target from reload to LRA.  The description of the problem is in the commit message. The patch was successfully bootstrapped and tested on x86-64, aarch64, and ppc64le. commit 30038a207c10a2783fa2695b62c7c8458ef05e73 Author:

[PATCH] RISC-V: Synthesize power-of-two constants.

Hi, I figured I'd send this patch that I quickly hacked together some days back. It's likely going to be controversial because we don't have vector costs in place at all yet and even with costs it's probably debatable as the emitted sequence is longer :) I'm willing to defer or ditch it

Re: [PATCH] Refactor wi::bswap as a function (instead of a method).

"Roger Sayle" writes: > This patch implements Richard Sandiford's suggestion from > https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618215.html > that wi::bswap (and a new wi::bitreverse) should be functions, > and ideally only accessors are member functions. This patch > implements the first

Re: [PATCH] jump: Change return type of predicate functions from int to bool

On 5/30/23 08:36, Uros Bizjak via Gcc-patches wrote: gcc/ChangeLog: * rtl.h (comparison_dominates_p): Change return type from int to bool. (condjump_p): Ditto. (any_condjump_p): Ditto. (any_uncondjump_p): Ditto. (simplejump_p): Ditto. (returnjump_p): Ditto.

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

Prathamesh Kulkarni writes: > Hi Richard, > The s32 case for single constant patch doesn't regress now after the > above commit. > Bootstrapped+tested on aarch64-linux-gnu, and verified that the new > tests pass for aarch64_be-linux-gnu. > Is it OK to commit ? > > Thanks, > Prathamesh > >

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

On 5/26/23 16:38, Vineet Gupta wrote: On 5/25/23 13:26, Thomas Schwinge wrote: I'm pasting a snippet of gcc.log. Issue is indeed triggered by rvv.exp which needs some love. I'd intentionally asked to "see a complete 'gcc.log' file where the ERRORs are visible". The full log files are

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

Joseph, could you please review this patch and see whether it's Okay for commit now? thanks a lot for all your comments and suggestions for this patch. Qing. == on a structure with a C99 flexible array member being nested in another structure. "The GCC

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

Richard or Jakub, could you please review this patch and see whether it's Okay to commit? thanks a lot. Qing === GCC extension accepts the case when a struct with a C99 flexible array member is embedded into another struct or union (possibly recursively) as

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

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 8th version, the Only change is in PATCH 2/2 (per Joseph's comment): diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index

[PATCH 2/2] btf: improve -dA comments for testsuite

[Changes from v1: - Fix typos. - Split unrelated change into separate commit. - Improve asm comment for enum constants, update btf-enum-1 test. - Improve asm comment for DATASEC records, update btf-datasec-2 test.] Many BTF type kinds refer to other types via index to the final types list.

[PATCH 1/2] btf: be clear when record size/type is not used

[Changes from v1: split this change into own commit.] All BTF type records have a 4-byte field used to encode a size or link to another type, depending on the type kind. But BTF_KIND_ARRAY and BTF_KIND_FWD do not use this field at all, and should write zero. GCC already correctly writes zero in

Re: [COMMITTED] ada: Remove the body of System.Storage_Elements

On Tue, 2023-05-30 09:05:43 +0100, Maciej W. Rozycki wrote: [Ada as a cross-compiler fails to build with a slightly-older compiler.] > Alternatively you can just bootstrap GCC under test natively first and > then use the newly-built compiler for all the cross builds you want to > verify. As

Re: [PATCH] btf: improve -dA comments for testsuite

On 5/30/23 09:08, David Faust wrote: @@ -793,7 +917,8 @@ btf_asm_enum_const (unsigned int size, ctf_dmdef_t * dmd) /* Asm'out a function parameter description following a BTF_KIND_FUNC_PROTO. */ static void -btf_asm_func_arg (ctf_func_arg_t * farg, size_t stroffset)

Re: [PATCH] btf: improve -dA comments for testsuite

On 5/30/23 00:30, Indu Bhagat wrote: > On 5/25/23 9:37 AM, David Faust via Gcc-patches wrote: >> 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

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

> On May 27, 2023, at 6:20 AM, Martin Uecker wrote: > > > Thank you for working on this! > > > Here are a couple of comments: > > How is the size for an object with FAM defined? Right now, with the attribute approach, the sizeof for the object with FAM is not impacted, and kept the same

Re: Re: [PATCH] RISC-V: Basic VLS code gen for RISC-V

It's long mail but I think this should explain most high level concept why I did this: I guess I skipped too much story about the VLS-mode support; VLS-mode support can be split into the middle-end and back-end. # Middle-end As Richard mentioned, those VLS types can be held by VLA-modes; for

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

Ok. Thanks, Kyrill From: Christophe Lyon Sent: Tuesday, May 30, 2023 4:44 PM To: Kyrylo Tkachov Cc: gcc-patches@gcc.gnu.org; Stam Markianos-Wright Subject: Re: [PATCH] [arm] testsuite: make mve_intrinsic_type_overloads-int.c libc-agnostic Ping? On Tue, 23 May 2023 at 16:59, Stamatis

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

Ping? On Tue, 23 May 2023 at 16:59, Stamatis Markianos-Wright < stam.markianos-wri...@arm.com> wrote: > > 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

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

> On May 26, 2023, at 4:40 PM, Kees Cook wrote: > > On Thu, May 25, 2023 at 04:14:47PM +, Qing Zhao wrote: >> GCC will pass the number of elements info from the attached attribute to >> both >> __builtin_dynamic_object_size and bounds sanitizer to check the out-of-bounds >> or dynamic

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

> On May 26, 2023, at 4:12 PM, Joseph Myers wrote: > > On Fri, 26 May 2023, Qing Zhao via Gcc-patches wrote: > >> Another question: is it better for me to rearrange the Patch 1/2 and Patch >> 2/2 a little bit, >> to put the FE , doc change and corresponding testing case together into one

Re: Re: [PATCH] VECT: Change flow of decrement IV

More information of power's testcase: Before this patch: test_npeel_int16_t: lui a4,%hi(.LANCHOR0+130) lui a3,%hi(.LANCHOR1) addi a3,a3,%lo(.LANCHOR1) addi a4,a4,%lo(.LANCHOR0+130) li a5,58 li a2,16 vsetivli zero,16,e16,m1,ta,ma vl1re16.v v3,0(a3) vid.v v1 .L5: minu a3,a5,a2 vsetvli

Re: [PATCH] doc: clarify semantics of vector bitwise shifts

On Thu, 25 May 2023, Richard Biener wrote: > On Wed, May 24, 2023 at 8:36 PM Alexander Monakov wrote: > > > > > > On Wed, 24 May 2023, Richard Biener via Gcc-patches wrote: > > > > > I’d have to check the ISAs what they actually do here - it of course > > > depends > > > on RTL semantics as

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

On Mon, 29 May 2023, Jin Ma wrote: > > Can you give me a specific example (compilation options and multilibs > > available) of a failure you refer to? > > A simple example: > 1. Use "--disable-multilib --with-abi =lp64d --with-arch > =rv64imafdc_zba_zbb_zbc_zbs" > to build the toolchain". >

Re: Re: [PATCH] VECT: Change flow of decrement IV

Also, I have investigated power's testcase in RVV: #include #define TEST_ALL(T)\ T (int8_t) \ T (uint8_t)

[PATCH] jump: Change return type of predicate functions from int to bool

gcc/ChangeLog: * rtl.h (comparison_dominates_p): Change return type from int to bool. (condjump_p): Ditto. (any_condjump_p): Ditto. (any_uncondjump_p): Ditto. (simplejump_p): Ditto. (returnjump_p): Ditto. (eh_returnjump_p): Ditto. (onlyjump_p): Ditto.

Re: [PATCH 1/2] ipa-cp: Avoid long linear searches through DECL_ARGUMENTS

> On Mon, May 29, 2023 at 6:20 PM Martin Jambor wrote: > > > > Hi, > > > > there have been concerns that linear searches through DECL_ARGUMENTS > > that are often necessary to compute the index of a particular > > PARM_DECL which is the key to results of IPA-CP can happen often > > enough to be a

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

On 5/23/23 06:27, Richard Sandiford wrote: 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))]

Re: Re: [PATCH] VECT: Change flow of decrement IV

Hi, all. After several investigations: Here is my experiements: void single_rgroup (int32_t *__restrict a, int32_t *__restrict b, int n) { for (int i = 0; i < n; i++) a[i] = b[i] + a[i]; } void mutiple_rgroup (float *__restrict f, double *__restrict d, int n) { for (int i = 0; i < n; ++i)

RE: [PATCH] [arm][testsuite]: Fix ACLE data-intrinsics testcases

> -Original Message- > From: Christophe Lyon > Sent: Tuesday, May 30, 2023 3:00 PM > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; > Chris Sidebottom > Cc: Christophe Lyon > Subject: [PATCH] [arm][testsuite]: Fix ACLE data-intrinsics testcases > > data-intrinsics-assembly.c forces

[PATCH] [arm][testsuite]: Fix ACLE data-intrinsics testcases

data-intrinsics-assembly.c forces -march=armv6 using dg-add-options arm_arch_v6, which implicitly adds -mfloat-abi=softfp. However, for a toolchain configured for arm-linux-gnueabihf and --with-arch=armv7-a, the testcase will fail when including arm_acle.h (which includes stdint.h, which will

Ping #1: [patch,avr] Fix PR109650 wrong code

Ping #1 for: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618976.html https://gcc.gnu.org/pipermail/gcc-patches/attachments/20230519/9536bf8c/attachment-0001.bin Johann Am 19.05.23 um 10:49 schrieb Georg-Johann Lay: Here is a revised version of the patch.  The difference to the

Re: Re: [PATCH] VECT: Change flow of decrement IV

>> That's odd, you only need to adjust the IV which is used in the exit test, >> not all the others. Sorry for my incorrect information. I checked the codegen of both single-rgroup and multi-rgroup. Their codegen are same behavior, after this patch, there will be 1 more neg instruction in

Re: [PATCH] VECT: Change flow of decrement IV

On Tue, 30 May 2023, juzhe.zhong wrote: > This patch will generate the number of rgroup ?mov? instructions inside the > loop. This is unacceptable. For example?if number of rgroups=3? will be 3 more > instruction in loop. If this patch is necessary? I think I should find a way > to fix it.

Re: [PATCH] VECT: Change flow of decrement IV

"juzhe.zhong" writes: > Maybe we can include rgroup number into select vl pattern？So that， I always > use select vl pattern. In my backend， if it is single rgroup，we gen vsetvl， > otherwise we gen min. That just seems to be a way of hiding an “is the target RVV?” test though. IMO targets

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

On Wed, 24 May 2023, YunQiang Su wrote: > > or even: > > > > if (INTVAL (length) <= MIPS_MAX_MOVE_BYTES_STRAIGHT) > > ... > > else if (INTVAL (length) < 64 && optimize) > > ... > > > > I don't think this is a good option, since somebody may add some code, > and may

Re: [PATCH] VECT: Change flow of decrement IV

"juzhe.zh...@rivai.ai" writes: > Before this patch: > foo: > ble a2,zero,.L5 > csrr a3,vlenb > srli a4,a3,2 > .L3: > minu a5,a2,a4 > vsetvli zero,a5,e32,m1,ta,ma > vle32.v v2,0(a1) > vle32.v v1,0(a0) > vsetvli t1,zero,e32,m1,ta,ma > vadd.vv v1,v1,v2 > vsetvli zero,a5,e32,m1,ta,ma > vse32.v

Re: Re: [PATCH] VECT: Change flow of decrement IV

>> How does it affect RVV code quality? I thought you specifically chose >> the previous approach because code quality was better that way. Yes, previous way is better for RVV. But as I said, we will definitely use SELECT_VL then in SELECT_VL, we will using remain - step (produced by

Re: decremnt IV patch create fails on PowerPC

On Tue, 30 May 2023, Richard Sandiford wrote: > Richard Biener writes: > >> But how easy would it be to extend SCEV analysis, via a pattern match? > >> The evolution of the IV phi wrt the inner loop is still a normal SCEV. > > > > No, the IV isn't a normal SCEV, the final value is different. >

Re: Re: [PATCH] VECT: Change flow of decrement IV

Before this patch: foo: ble a2,zero,.L5 csrr a3,vlenb srli a4,a3,2 .L3: minu a5,a2,a4 vsetvli zero,a5,e32,m1,ta,ma vle32.v v2,0(a1) vle32.v v1,0(a0) vsetvli t1,zero,e32,m1,ta,ma vadd.vv v1,v1,v2 vsetvli zero,a5,e32,m1,ta,ma vse32.v v1,0(a0) add a1,a1,a3 add a0,a0,a3 sub a2,a2,a5 bne

Re: [PATCH] VECT: Change flow of decrement IV

juzhe.zh...@rivai.ai writes: > From: Ju-Zhe Zhong > > Follow Richi's suggestion, I change current decrement IV flow from: > > do { >remain -= MIN (vf, remain); > } while (remain != 0); > > into: > > do { >old_remain = remain; >len = MIN (vf, remain); >remain -= vf; > } while

Re: Re: decremnt IV patch create fails on PowerPC

Hi, Richi. I have send patch by following your suggestion and change the decrement IV follow: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620086.html It works well in RVV. Could you take a look at it? If it's ok, I will send patch of SELECT_VL base on this. Thanks.

Re: decremnt IV patch create fails on PowerPC

Richard Biener writes: >> But how easy would it be to extend SCEV analysis, via a pattern match? >> The evolution of the IV phi wrt the inner loop is still a normal SCEV. > > No, the IV isn't a normal SCEV, the final value is different. Which part of the IV though? Won't all executions of the

[PATCH] VECT: Change flow of decrement IV

From: Ju-Zhe Zhong Follow Richi's suggestion, I change current decrement IV flow from: do { remain -= MIN (vf, remain); } while (remain != 0); into: do { old_remain = remain; len = MIN (vf, remain); remain -= vf; } while (old_remain >= vf); to enhance SCEV. ALL tests (decrement

Re: [PATCH v1] tree-ssa-sink: Improve code sinking pass.

On Tue, May 30, 2023 at 9:35 AM Ajit Agarwal wrote: > > Hello Richard: > > On 30/05/23 12:34 pm, Richard Biener wrote: > > On Tue, May 30, 2023 at 7:06 AM Ajit Agarwal wrote: > >> > >> Hello Richard: > >> > >> On 22/05/23 6:26 pm, Richard Biener wrote: > >>> On Thu, May 18, 2023 at 9:14 AM Ajit

Re: [PATCH V2] [vect]Enhance NARROW FLOAT_EXPR vectorization by truncating integer to lower precision.

On Mon, May 29, 2023 at 5:21 AM Hongtao Liu via Gcc-patches wrote: > > ping. > > On Mon, May 8, 2023 at 9:59 AM liuhongt wrote: > > > > > > @@ -4799,7 +4800,8 @@ vect_create_vectorized_demotion_stmts (vec_info > > > > *vinfo, vec *vec_oprnds, > > > >

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

On Tue, May 30, 2023 at 12:17 PM Sebastian Huber wrote: > > On 30.05.23 11:53, Richard Biener wrote: > > On Tue, May 23, 2023 at 11:28 AM Sebastian Huber > > wrote: > >> On 10.01.23 16:38, Sebastian Huber wrote: > >>> On 19/12/2022 17:02, Sebastian Huber wrote: > Build libatomic for all

[committed] OpenMP: Improve C/C++ parsing error message [PR109999]

I stumbled over that error message the other day and found it a bit confusing: error: expected ‘#pragma omp’ clause before ‘uses_allocators’ The new wording is not the best, but I think at least better: error: expected an OpenMP clause before ‘uses_allocators’ ('uses_allocators' is a

[PATCH] Update perf auto profile script

- Fix gen_autofdo_event: The download URL for the Intel Perfmon Event list has changed, as well as the JSON format. Also it now uses pattern matching to match CPUs. Update the script to support all of this. - Regenerate gcc-auto-profile with the latest published Intel model numbers, so it

Re: [PATCH] riscv: update riscv_asan_shadow_offset

Andreas Schwab via Gcc-patches 於 2023年5月30日 週二 17:37 寫道： > Ok for 12 and 13 branch? > Yes, thanks! > -- > Andreas Schwab, SUSE Labs, sch...@suse.de > GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 > "And now for something completely different." >

Re: decremnt IV patch create fails on PowerPC

On Tue, 30 May 2023, Richard Sandiford wrote: > My understanding was that we went into this knowing that the IVs > would defeat SCEV analysis. Apparently that wasn't a problem for RVV, > but it's not surprising that it is a problem in general. > > This isn't just about SELECT_VL though. We use

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

On 30.05.23 11:53, Richard Biener wrote: On Tue, May 23, 2023 at 11:28 AM Sebastian Huber wrote: 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

Re: decremnt IV patch create fails on PowerPC

My understanding was that we went into this knowing that the IVs would defeat SCEV analysis. Apparently that wasn't a problem for RVV, but it's not surprising that it is a problem in general. This isn't just about SELECT_VL though. We use the same type of IV for cases what aren't going to use

Re: Re: decremnt IV patch create fails on PowerPC

>> No, I said the current scheme does sth along >> do { >>remain -= MIN (vf, remain); >> } while (remain != 0); >> and I suggest to instead do >> do { >>old_remain = remain; >>len = MIN (vf, remain); >>remain -= vf; >> } while (old_remain >= vf); >> basically since only the

Re: decremnt IV patch create fails on PowerPC

On Tue, 30 May 2023, Kewen.Lin wrote: > on 2023/5/30 17:26, juzhe.zh...@rivai.ai wrote: > > Ok. > > > > It seems that for this conditions: > > > > + /* If we're vectorizing a loop that uses length "controls" and > > + can iterate more than once, we apply decrementing IV approach > > +

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

On Tue, May 23, 2023 at 11:28 AM Sebastian Huber wrote: > > 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 > >>

Re: Re: decremnt IV patch create fails on PowerPC

>> No, since powerpc is fine with decrementing VL it should also use it. >>Instead you should make sure to produce SCEV analyzable IVs when >>possible (when SELECT_VL is not or cannot be used). Ok. Would you mind giving me the guideline how to rewrite the decrement IV? Since I am not familiar with

Re: decremnt IV patch create fails on PowerPC

on 2023/5/30 17:26, juzhe.zh...@rivai.ai wrote: > Ok. > > It seems that for this conditions: > > + /* If we're vectorizing a loop that uses length "controls" and > + can iterate more than once, we apply decrementing IV approach > + in loop control. */ > + if

[PATCH 3/3 v2] xtensa: Optimize 'cstoresi4' insn pattern

Resubmitting the correct one due to a mistake in merging order of fixes. --- This patch introduces more optimized implementations for the 6 cstoresi4 insn comparison methods (eq/ne/lt/le/gt/ge, however, required TARGET_NSA for eq). gcc/ChangeLog: * config/xtensa/xtensa.cc

[PATCH 2/3 v2] xtensa: Add 'adddi3' and 'subdi3' insn patterns

Resubmitting the correct one due to a mistake in merging order of fixes. --- More optimized than the default RTL generation. gcc/ChangeLog: * config/xtensa/xtensa.md (adddi3, subdi3): New RTL generation patterns implemented according to the instruc- tion idioms described

Re: Re: decremnt IV patch create fails on PowerPC

On Tue, 30 May 2023, juzhe.zh...@rivai.ai wrote: > Ok. > > It seems that for this conditions: > > + /* If we're vectorizing a loop that uses length "controls" and > + can iterate more than once, we apply decrementing IV approach > + in loop control. */ > + if

Re: [PATCH] Optimized "(X - N * M) / N + M" to "X / N" if valid

On Wed, 17 May 2023, Jiufu Guo wrote: > Hi, > > This patch tries to optimize "(X - N * M) / N + M" to "X / N". But if that's valid why not make the transform simpler and transform (X - N * M) / N to X / N - M instead? You use the same optimize_x_minus_NM_div_N_plus_M validator for the

Re: Re: [PATCH] RISC-V: Basic VLS code gen for RISC-V

I think I prefer doing VLS mode like these: This is current VLA patterns: (define_insn "@pred_" [(set (match_operand:VI 0 "register_operand" "=vd, vd, vr, vr, vd, vd, vr, vr, vd, vd, vr, vr") (if_then_else:VI (unspec: [(match_operand: 1 "vector_mask_operand" " vm, vm,Wc1,

[PATCH][committed] aarch64: Convert ADDLP and ADALP patterns to standard RTL codes

Hi all, This patch converts the patterns for the integer widen and pairwise-add instructions to standard RTL operations. The pairwise addition withing a vector can be represented as an addition of two vec_selects, one selecting the even elements, and one selecting odd. Thus for the intrinsic

Re: [PATCH] Detect bswap + rotate for byte permutation in pass_bswap.

On Tue, May 9, 2023 at 9:06 AM liuhongt via Gcc-patches wrote: > > The patch doesn't handle: > 1. cast64_to_32, > 2. memory source with rsize < range. > > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. > Ok for trunk? OK and sorry for the delay. Richard. > gcc/ChangeLog: > >

[PATCH][committed] aarch64: Reimplement v(r)hadd and vhsub intrinsics with RTL codes

Hi all, This patch reimplements the MD patterns for the UHADD,SHADD,UHSUB,SHSUB,URHADD,SRHADD instructions using standard RTL operations rather than unspecs. The correct RTL representations involves widening the inputs before adding them and halving, followed by a truncation back to the

Re: Re: [PATCH] RISC-V: Basic VLS code gen for RISC-V

>> For the future it would be then good to have the vectorizer >>re-vectorize loops with >>VLS vector uses to VLA style? Not really, this patch is just using a magic convert VLS vector into VLA stype since it can avoid defining the RVV patterns with VLS modes and avoid a lot of work. There is

  1   2   >