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

From: Pan Li This patch would like to add new sub extension (aka ZVFH) 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_ZVFH. The Zvfh extension depends on the Zve32f and Zfh

[PATCH v4] tree-sea-sink: Improve code sinking pass

Hello All: This patch improves code sinking pass to sink statements before call to reduce register pressure. Review comments are incorporated. For example : void bar(); int j; void foo(int a, int b, int c, int d, int e, int f) { int l; l = a + b + c + d +e + f; if (a != 5) { bar(

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

Hi, Richi. >> Note with SELECT_VL all bets will be off since as I understand the >> value it gives can vary from iteration to iteration (but we know >> a lower and maybe an upper bound?) Yes, in RVV side, the SELECT_VL output can be in range of [ceil(avl/2), vlmax], can be any value between the

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

On Wed, 31 May 2023, juzhe.zh...@rivai.ai wrote: > 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

[PATCH V1] Testsuite: Fix a fail about xtheadcondmov-indirect-rv64.c

From: yulong I find fail of the xtheadcondmov-indirect-rv64.c test case and provide the way to solve it. In this patch, I modify the check information of the function(ConEmv_imm_imm_reg and ConNmv_imm_imm_reg) body. gcc/testsuite/ChangeLog: * gcc.target/riscv/xtheadcondmov-indirect-rv

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

On 5/30/23 11:27, David Faust wrote: [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 t

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

On 5/30/23 11:27, David Faust wrote: [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.

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

On Tue, May 30, 2023 at 2:50 AM Takayuki 'January June' Suwa wrote: > > 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 gene

[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 n

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, req

[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 regi

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) >> >> 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] > https://gcc.gnu.org/pipermail/gcc

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: >> >>> Hi

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 co

[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. gcc/Change

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 sequ

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: > > * gcc.target/riscv/rvv/autovec/vls-vlmax/init-repeat-sequen

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 =rv64imafdc_zba_zbb_zbc_zb

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 avl

[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 ++ gcc/testsuite/gcc.dg/

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 use

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, 钟居哲 w

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 constr

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 locat

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 pat

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 valu

[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 know

[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: Bi

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 s

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 increasi

[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. * g

[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: V

[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 altogethe

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 > > [aarch64

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 humon

[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 exte

[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 the

[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 17e

[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. How

[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 t

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 y

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

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 d

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 exam

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 Markia

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 u

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 ob

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 zero,a3,e16,m1

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 we

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". > 2.

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. (invert_ju

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

[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 fail

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 previou

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 prehea

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. That's

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 shouldn

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 bre

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 v1,0(a0

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 SELET_VL).

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 a2,zero

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 (old_r

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. juzhe.zh...@rivai.a

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 la

[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 I

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 A

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, > > > >stmt_v

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 tar

[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 valid

[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 wo

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 "si

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 SE

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 last

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

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

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 (LOOP_VINFO_CAN_USE_PARTIAL

[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 (xtensa_expand_s

  1   2   >