RE: Intel AVX10.1 Compiler Design and Support

> -Original Message- > From: Hongtao Liu > Sent: Wednesday, August 23, 2023 10:19 AM > To: Jiang, Haochen > Cc: Jakub Jelinek ; Richard Biener > ; ZiNgA BuRgA ; > gcc-patches@gcc.gnu.org > Subject: Re: Intel AVX10.1 Compiler Design and Support > > On Wed, Aug 23, 2023 at 9:58 AM Jiang, H

Re: [pushed][PATCH v2] libffi: Backport of LoongArch support for libffi.

Pushed to r14-3405. 在 2023/8/23 上午10:56, Lulu Cheng 写道: v1 -> v2: Modify the changelog information and add PR libffi/108682. This is a backport of , and contains modifications to commit 5a4774cd4d, as well as the LoongArch schema p

RE: [PATCH v1] Mode-Switching: Add optional EMIT_AFTER hook

Thanks Jeff for comments, and sorry for late response. The background comes from the CALL insn. For the RISC-V dynamic rounding mode we need to 1. restore the frm BEFORE call, to avoid the static rounding mode pollute the call. 2. Backup the frm AFTER call, to ensure the frm value after call is

Re: [committed] i386: Fix grammar typo in diagnostic

On Wed, Aug 23, 2023 at 7:28 AM Hongtao Liu wrote: > > On Tue, Aug 8, 2023 at 5:22 AM Marek Polacek via Libstdc++ > wrote: > > > > On Mon, Aug 07, 2023 at 10:12:35PM +0100, Jonathan Wakely via Gcc-patches > > wrote: > > > Committed as obvious. > > > > > > Less obvious (to me) is whether it's cor

Re: [PATCH 1/3] vect: Remove some manual release in vectorizable_store

on 2023/8/22 20:32, Richard Biener wrote: > On Tue, Aug 22, 2023 at 10:45 AM Kewen.Lin wrote: >> >> Hi, >> >> To avoid some duplicates in some follow-up patches on >> function vectorizable_store, this patch is to adjust some >> existing vec with auto_vec and remove some manual release >> invocatio

[PATCH V1 1/2] light expander sra v0

Hi, I just updated the patch. We could review this one. Compare with previous patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627287.html This version: * Supports bitfield access from one register. * Allow return scalar registers cleaned via contructor. Bootstrapped and regtested

[PATCH] Fix target_clone ("arch=graniterapids-d") and target_clone ("arch=arrowlake-s")

Both "graniterapid-d" and "graniterapids" are attached with PROCESSOR_GRANITERAPID in processor_alias_table but mapped to different __cpu_subtype in get_intel_cpu. And get_builtin_code_for_version will try to match the first PROCESSOR_GRANITERAPIDS in processor_alias_table which maps to "granitepr

Re: [PATCH] RISC-V: Add conditional unary neg/abs/not autovec patterns

Hi Robin, Thanks for these nice comments! - emit_insn (gen_vcond_mask (vmode, vmode, d->target, d->op0, d->op1, mask)); + /* swap op0 and op1 since the order is opposite to pred_merge. */ + rtx ops2[] = {d->target, d->op1, d->op0, mask}; + emit_vlmax_merge_insn (code_for_pred_merge (vmode)

[PATCH V2] RISC-V: Add conditional unary neg/abs/not autovec patterns

V2 changes: 1. remove xfail 2. testcase files naming harmonized with existing --- Hi, This patch add conditional unary neg/abs/not autovec patterns to RISC-V backend. For this C code: void test_3 (float *__restrict a, float *__restrict b, int *__restrict pred, int n) { for (int i = 0; i < n;

[PATCH v2] libffi: Backport of LoongArch support for libffi.

v1 -> v2: Modify the changelog information and add PR libffi/108682. This is a backport of , and contains modifications to commit 5a4774cd4d, as well as the LoongArch schema portion of commit ee22ecbd11. This is needed for libgo. libffi

[PATCH] RISC-V: Fix potential ICE of global vsetvl elimination

Committed for following VSETVL refactor patch to make V2 patch easier to review. gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (pass_vsetvl::global_eliminate_vsetvl_insn): Fix potential ICE. --- gcc/config/riscv/riscv-vsetvl.cc | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-

[PATCH] RISC-V: Fix VTYPE fuse rule bug

This bug is exposed after refactor patch. Separate it and commited. gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (ge_sew_ratio_unavailable_p): Fix fuse rule bug. * config/riscv/riscv-vsetvl.def (DEF_SEW_LMUL_FUSE_RULE): Ditto. --- gcc/config/riscv/riscv-vsetvl.cc | 10 +++

[PATCH] RISC-V: Fix gather_load_run-12.c test

FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_run-12.c gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_run-12.c: Add vsetvli asm. --- .../riscv/rvv/autovec/gather-scatter/gather_load_run-12.c | 6 ++ 1 file changed, 6 insertions(

Re: Intel AVX10.1 Compiler Design and Support

On Wed, Aug 23, 2023 at 9:58 AM Jiang, Haochen wrote: > > > -Original Message- > > From: Jakub Jelinek > > Sent: Tuesday, August 22, 2023 11:02 PM > > To: Hongtao Liu > > Cc: Richard Biener ; Jiang, Haochen > > ; ZiNgA BuRgA ; gcc- > > patc...@gcc.gnu.org > > Subject: Re: Intel AVX10.1 C

[PATCH] libgcc/m68k: Fixes for soft float

Check for non-zero denorm in __adddf3. Need to check both the upper and lower 32-bit chunks of a 64-bit float for a non-zero value when checking to see if the value is -0. Fix __addsf3 when the sum exponent is exactly 0xff to ensure that produces infinity and not nan. Handle converting NaN/inf va

[PATCH] RISC-V: Add attribute to vtype change only vsetvl

This patch is prepare patch for VSETVL PASS. Commited. gcc/ChangeLog: * config/riscv/vector.md: Add attribute. --- gcc/config/riscv/vector.md | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md index e772e7905

Re: [PATCH] vect: Replace DR_GROUP_STORE_COUNT with DR_GROUP_LAST_ELEMENT

Hi Richi, on 2023/8/22 20:17, Richard Biener wrote: > On Tue, Aug 22, 2023 at 10:44 AM Kewen.Lin wrote: >> >> Hi, >> >> Now we use DR_GROUP_STORE_COUNT to record how many stores >> in a group have been transformed and only do the actual >> transform when encountering the last one. I'm making >>

Ping^^ [PATCH V5 2/2] Optimize '(X - N * M) / N' to 'X / N - M' if valid

Hi, I would like to have a gentle ping... BR, Jeff (Jiufu Guo) On 2023-08-07 10:45, guojiufu via Gcc-patches wrote: Hi, Gentle ping... On 2023-07-18 22:05, Jiufu Guo wrote: Hi, Integer expression "(X - N * M) / N" can be optimized to "X / N - M" if there is no wrap/overflow/underflow and "

RE: Intel AVX10.1 Compiler Design and Support

> -Original Message- > From: Jakub Jelinek > Sent: Tuesday, August 22, 2023 11:02 PM > To: Hongtao Liu > Cc: Richard Biener ; Jiang, Haochen > ; ZiNgA BuRgA ; gcc- > patc...@gcc.gnu.org > Subject: Re: Intel AVX10.1 Compiler Design and Support > > On Tue, Aug 22, 2023 at 10:35:55PM +0800,

Re: Re: [PATCH] RISC-V: Refactor Phase 3 (Demand fusion) of VSETVL PASS

>> This seems relax the compatiblitly check to allow optimize more case, >> if so this should be a sperated patch. This is not a optimization fix, It's an bug fix. Since fusion for these 2 demands: 1. demand SEW and GE_SEW (meaning demand a SEW larger than a specific SEW). 2. demand SEW and GE_SEW

[PATCH] RISC-V: Adapt live-1.c testcase

Commited. Fix failures: FAIL: gcc.target/riscv/rvv/autovec/partial/live-1.c scan-tree-dump-times optimized ".VEC_EXTRACT" 10 FAIL: gcc.target/riscv/rvv/autovec/partial/live-1.c scan-tree-dump-times optimized ".VEC_EXTRACT" 10 gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/par

Re: [committed] i386: Fix grammar typo in diagnostic

On Tue, Aug 8, 2023 at 5:22 AM Marek Polacek via Libstdc++ wrote: > > On Mon, Aug 07, 2023 at 10:12:35PM +0100, Jonathan Wakely via Gcc-patches > wrote: > > Committed as obvious. > > > > Less obvious (to me) is whether it's correct to say "GCC V13" here. I > > don't think we refer to a version th

[PATCH] RISC-V: Clang format riscv-vsetvl.cc[NFC]

Commited. gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (change_insn): Clang format. (vector_infos_manager::all_same_ratio_p): Ditto. (vector_infos_manager::all_same_avl_p): Ditto. (pass_vsetvl::refine_vsetvls): Ditto. (pass_vsetvl::cleanup_vsetvls): Ditto.

[PATCH] RISC-V: Add riscv-vsetvl.def to t-riscv

This patch will be backport to GCC 13 and commit to trunk. gcc/ChangeLog: * config/riscv/t-riscv: Add riscv-vsetvl.def --- gcc/config/riscv/t-riscv | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/gcc/config/riscv/t-riscv b/gcc/config/riscv/t-riscv index 1252d6f851a.

Re: Re: [PATCH] RISC-V: Refactor Phase 3 (Demand fusion) of VSETVL PASS

>> I saw you has update serveral testcase, why update instead of add new >> testcase?? Since original testcase failed after this patch. >> could you say more about why some testcase added __riscv_vadd_vv_i8mf8 >> or add some more dependency of vl variable? These are 2 separate questions. 1. Why

Re: Patch ping Re: [PATCH 0/12] GCC _BitInt support [PR102989]

On Mon, Aug 21, 2023 at 8:25 AM Jakub Jelinek via Gcc-patches wrote: > > Hi! > > On Wed, Aug 09, 2023 at 08:14:14PM +0200, Jakub Jelinek via Gcc-patches wrote: > > Jakub Jelinek (12): > > expr: Small optimization [PR102989] > > lto-streamer-in: Adjust assert [PR102989] > > phiopt: Fix phiopt

[pushed] analyzer: reimplement kf_strlen [PR105899]

Reimplement kf_strlen in terms of the new string scanning implementation, sharing strlen's implementation with __analyzer_get_strlen. Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r14-3391-g3242fb533d48ab. gcc/analyzer/ChangeLog: PR analyzer/105899

Re: [PATCH] RISC-V: Add conditional unary neg/abs/not autovec patterns

Hi Lehua, no concerns here, just tiny remarks but in general LGTM as is. > +(define_insn_and_split "*copysign_neg" > + [(set (match_operand:VF 0 "register_operand") > +(neg:VF > + (unspec:VF [ > +(match_operand:VF 1 "register_operand") > +(match_operand:V

Re: [PATCH v10 3/5] c++: Implement __is_function built-in trait

On Wed, 12 Jul 2023, Ken Matsui via Libstdc++ wrote: > This patch implements built-in trait for std::is_function. > > gcc/cp/ChangeLog: > > * cp-trait.def: Define __is_function. > * constraint.cc (diagnose_trait_expr): Handle CPTK_IS_FUNCTION. > * semantics.cc (trait_expr_value

Re: [PATCH][committed] RISC-V: Add multiarch support on riscv-linux-gnu

On 8/22/23 12:03, Palmer Dabbelt wrote: On Tue, 22 Aug 2023 10:39:38 PDT (-0700), Jeff Law wrote: The docs seem to suggest that we should have a multarch-compatible MULTILIB_OSDIRNAMES as we support both multilib and multiarch:    @code{MULTIARCH_DIRNAME} is not used for configurations

Re: [PATCH V2 2/5] OpenMP: C front end support for imperfectly-nested loops

On 8/22/23 07:23, Jakub Jelinek wrote: diff --git a/gcc/testsuite/c-c++-common/goacc/collapse-1.c b/gcc/testsuite/c-c++-common/goacc/collapse-1.c index 11b14383983..0feac8f8ddb 100644 --- a/gcc/testsuite/c-c++-common/goacc/collapse-1.c +++ b/gcc/testsuite/c-c++-common/goacc/collapse-1.c @@ -8,

Re: [PATCH] Fortran: implement vector sections in DATA statements [PR49588]

Hi Paul, Am 22.08.23 um 08:32 schrieb Paul Richard Thomas via Gcc-patches: Hi Harald, It all looks good to me and does indeed make the code clearer. OK for trunk. Thanks for the patch. thanks for the review! I was shocked to find that there are 217 older bugs than 49588. Does anybody test

[pushed 2/2] c++: maybe_substitute_reqs_for fix

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- While working on PR109751 I found that maybe_substitute_reqs_for was doing the wrong thing for a non-template friend, substituting in the template args of the scope's original template rather than those of the instantiation. This didn't end

[pushed 1/2] c++: constrained hidden friends [PR109751]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- r13-4035 avoided a problem with overloading of constrained hidden friends by checking satisfaction, but checking satisfaction early is inconsistent with the usual late checking and can lead to hard errors, so let's not do that after all. We

Re: [PATCH] RISC-V: output Autovec params explicitly in --help ...

On 8/22/23 11:07, Palmer Dabbelt wrote: We should probably put them in invoke.texi as well (and anything else we're missing that's been added recently). Looks like I'd pushed the patch already. A whole bunch of them are missing, so guess that can happen seperately. -Vineet

[Committed] RISC-V: output Autovec params explicitly in --help ...

... otherwise user has no clue what -param to actually change gcc/ChangeLog: * config/riscv/riscv.opt: Add --param names riscv-autovec-preference and riscv-autovec-lmul Signed-off-by: Vineet Gupta --- gcc/config/riscv/riscv.opt | 4 ++-- 1 file changed, 2 insertions(+), 2 deleti

Re: [PATCH] RISC-V: output Autovec params explicitly in --help ...

On Tue, 22 Aug 2023 10:59:35 PDT (-0700), gcc-patches@gcc.gnu.org wrote: On 8/22/23 11:40, Vineet Gupta wrote: ... otherwise user has no clue what -param to actually change gcc/ChangeLog: * config/riscv/riscv.opt: Add --param names riscv-autovec-preference and riscv-autovec-

Re: [PATCH][committed] RISC-V: Add multiarch support on riscv-linux-gnu

On Tue, 22 Aug 2023 10:39:38 PDT (-0700), Jeff Law wrote: This adds multiarch support to the RISC-V port so that bootstraps work with Debian out-of-the-box. Without this patch the stage1 compiler is unable to find headers/libraries when building the stage1 runtime. This is functionally (and po

Re: [PATCH] RISC-V: output Autovec params explicitly in --help ...

On 8/22/23 11:40, Vineet Gupta wrote: ... otherwise user has no clue what -param to actually change gcc/ChangeLog: * config/riscv/riscv.opt: Add --param names riscv-autovec-preference and riscv-autovec-lmul OK jeff

Re: [PATCH v4] c++: extend cold, hot attributes to classes

On 8/15/23 09:41, Javier Martinez wrote: On Mon, Aug 14, 2023 at 8:32 PM Jason Merrill > wrote: > I think you also want to check for ATTR_FLAG_TYPE_IN_PLACE. > [...] > > +  propagate_class_warmth_attribute (t); > Maybe call this in check_bases_and_members instead? Ye

[PATCH] RISC-V: output Autovec params explicitly in --help ...

... otherwise user has no clue what -param to actually change gcc/ChangeLog: * config/riscv/riscv.opt: Add --param names riscv-autovec-preference and riscv-autovec-lmul Signed-off-by: Vineet Gupta --- gcc/config/riscv/riscv.opt | 4 ++-- 1 file changed, 2 insertions(+), 2 dele

[PATCH][committed] RISC-V: Add multiarch support on riscv-linux-gnu

This adds multiarch support to the RISC-V port so that bootstraps work with Debian out-of-the-box. Without this patch the stage1 compiler is unable to find headers/libraries when building the stage1 runtime. This is functionally (and possibly textually) equivalent to Debian's fix for the sa

Re: [PATCH] libgomp, testsuite: Do not call nonstandard functions on darwin

On Tue, Aug 22, 2023 at 10:25:51AM +0200, FX Coudert wrote: > > Revised patch. I does the job on darwin, can you check that it still tests > > the functions on Linux? > > And if so, OK to commit? > > With the correct file, sorry. Seems to work for me, I see ... -DNONSTDFUNC=1 ... on the test's c

Re: [PATCH] RISC-V: Refactor Phase 3 (Demand fusion) of VSETVL PASS

It's really great improvement, it's drop some state like HARD_EMPTY and DIRTY_WITH_KILLED_AVL which make this algorithm more easy to understand! also this also fundamentally improved the phase 3, although one concern is the time complexity might be come more higher order, (and it's already high eno

Re: [PATCH] libgccjit: Add support for `restrict` attribute on function parameters

Since the tests in the PR for rustc_codegen_gcc (https://github.com/rust-lang/rustc_codegen_gcc/pull/312) currently fails, let's wait a bit before merging the patch, in case it would need some fixes. On Thu, 2023-08-17 at 20:09 +0200, Guillaume Gomez via Jit wrote: > Quick question: do you plan to

Re: Intel AVX10.1 Compiler Design and Support

On Tue, Aug 22, 2023 at 10:35:55PM +0800, Hongtao Liu wrote: > Let's assume there's no detla now, AVX10.1-512 is equal to > AVX512{F,VL,BW,DQ,CD,BF16,FP16,VBMI,VBMI2,VNNI,IFMA,BITALG, VPOPCNTDQ} > > other stuff. > > The current common/config/i386/i386-common.cc OPTION_MASK_ISA*SET* would be > > lik

Re: [PATCH] RISC-V: Add Types to Un-Typed Sync Instructions:

On 8/21/2023 2:41 PM, Jeff Law via Gcc-patches wrote: On 8/21/23 10:51, Edwin Lu wrote: @@ -77,4 +78,4 @@ (define_insn "atomic_store_ztso"     return "s\t%z1,%0";     }     [(set_attr "type" "atomic") -   (set (attr "length") (const_int 8))]) \ No newline at end of file +   (set (attr "len

Re: Intel AVX10.1 Compiler Design and Support

On Tue, Aug 22, 2023 at 9:35 PM Hongtao Liu wrote: > > On Tue, Aug 22, 2023 at 9:24 PM Richard Biener > wrote: > > > > On Tue, Aug 22, 2023 at 3:16 PM Jakub Jelinek wrote: > > > > > > On Tue, Aug 22, 2023 at 09:02:29PM +0800, Hongtao Liu wrote: > > > > > Agreed. And I still think -mevex512 vs.

Re: Intel AVX10.1 Compiler Design and Support

On Tue, Aug 22, 2023 at 9:54 PM Jakub Jelinek wrote: > > On Tue, Aug 22, 2023 at 09:35:44PM +0800, Hongtao Liu wrote: > > Ok, then we can't avoid TARGET_AVX10_1 in those existing 256/128-bit > > evex instruction patterns. > > Why? > Internally for md etc. purposes, we should have the current > TAR

Re: Re: [PATCH] RISC-V: Add conditional unary neg/abs/not autovec patterns

>> It's certainly got the potential to get out of hand. And it's not just >> the vectorizer operations. I know of an architecture that can execute >> most of its ALU and loads/stores conditionally (not predication, but >> actual conditional ops) like target = (x COND Y) ? a << b ; a) Do you mea

RE: [PATCH] VECT: Add LEN_FOLD_EXTRACT_LAST pattern

Committed as passed both the regression and bootstrap tests in x86, thanks Richard. Pan -Original Message- From: Gcc-patches On Behalf Of Richard Biener via Gcc-patches Sent: Tuesday, August 22, 2023 7:08 PM To: Juzhe-Zhong Cc: gcc-patches@gcc.gnu.org; richard.sandif...@arm.com Subjec

Re: [committed] i386: Fix grammar typo in diagnostic

On Mon, 7 Aug 2023, Marek Polacek via Gcc-patches wrote: >> Less obvious (to me) is whether it's correct to say "GCC V13" here. I >> don't think we refer to a version that way anywhere else, do we? >> >> Would "since GCC 13.1.0" be better? > x86_field_alignment uses > > inform (inpu

Re: [PATCH] RISC-V: Add conditional unary neg/abs/not autovec patterns

On 8/22/23 02:08, juzhe.zh...@rivai.ai wrote: Yes, I agree long-term we want every-thing be optimized as early as possible. However, IMHO, it's impossible we can support every conditional patterns in the middle-end (match.pd). It's a really big number. For example, for sign_extend convers

Re: Intel AVX10.1 Compiler Design and Support

On Tue, Aug 22, 2023 at 09:35:44PM +0800, Hongtao Liu wrote: > Ok, then we can't avoid TARGET_AVX10_1 in those existing 256/128-bit > evex instruction patterns. Why? Internally for md etc. purposes, we should have the current TARGET_AVX512* etc. ISA flags, plus one new one, whatever we call it (TA

Re: [PATCH] doc: Remove obsolete sentence about _Float* not being supported in C++ [PR106652]

On 8/22/23 02:15, Jakub Jelinek via Gcc-patches wrote: Hi! As mentioned in the PR, these types are supported in C++ since GCC 13, so we shouldn't confuse users. Ok for trunk? 2023-08-22 Jakub Jelinek PR c++/106652 * doc/extend.texi (_Float): Drop obsolete sentence that t

Re: [PATCH V2 5/5] OpenMP: Fortran support for imperfectly-nested loops

On Sun, Jul 23, 2023 at 04:15:21PM -0600, Sandra Loosemore wrote: > OpenMP 5.0 removed the restriction that multiple collapsed loops must > be perfectly nested, allowing "intervening code" (including nested > BLOCKs) before or after each nested loop. In GCC this code is moved > into the inner loop

Re: Intel AVX10.1 Compiler Design and Support

On Tue, Aug 22, 2023 at 9:24 PM Richard Biener wrote: > > On Tue, Aug 22, 2023 at 3:16 PM Jakub Jelinek wrote: > > > > On Tue, Aug 22, 2023 at 09:02:29PM +0800, Hongtao Liu wrote: > > > > Agreed. And I still think -mevex512 vs. -mno-evex512 is the best option > > > > name to represent whether th

Re: [PATCH V2 4/5] OpenMP: New C/C++ testcases for imperfectly nested loops.

On Sun, Jul 23, 2023 at 04:15:20PM -0600, Sandra Loosemore wrote: > gcc/testsuite/ChangeLog > * c-c++-common/gomp/imperfect-attributes.c: New. > * c-c++-common/gomp/imperfect-badloops.c: New. > * c-c++-common/gomp/imperfect-blocks.c: New. > * c-c++-common/gomp/imperfect-exte

Re: [PATCH V2 3/5] OpenMP: C++ support for imperfectly-nested loops

On Sun, Jul 23, 2023 at 04:15:19PM -0600, Sandra Loosemore wrote: > OpenMP 5.0 removed the restriction that multiple collapsed loops must > be perfectly nested, allowing "intervening code" (including nested > BLOCKs) before or after each nested loop. In GCC this code is moved > into the inner loop

Re: [PATCH 3/3] vect: Move VMAT_GATHER_SCATTER handlings from final loop nest

On Tue, Aug 22, 2023 at 10:52 AM Kewen.Lin wrote: > > Hi, > > Like r14-3317 which moves the handlings on memory access > type VMAT_GATHER_SCATTER in vectorizable_load final loop > nest, this one is to deal with vectorizable_store side. > > Bootstrapped and regtested on x86_64-redhat-linux, > aarch

Re: [PATCH 2/3] vect: Move VMAT_LOAD_STORE_LANES handlings from final loop nest

On Tue, Aug 22, 2023 at 10:49 AM Kewen.Lin wrote: > > Hi, > > Like commit r14-3214 which moves the handlings on memory > access type VMAT_LOAD_STORE_LANES in vectorizable_load > final loop nest, this one is to deal with the function > vectorizable_store. > > Bootstrapped and regtested on x86_64-re

Re: [PATCH v1] libffi: Backport of LoongArch support for libffi.

On Tue, 2023-08-22 at 20:42 +0800, Lulu Cheng wrote: > This is a backport of , > and contains modifications to commit 5a4774cd4d, as well as the LoongArch > schema portion of commit ee22ecbd11. This is needed for libgo. > > > libffi/ChangeLog:

Re: Intel AVX10.1 Compiler Design and Support

On Tue, Aug 22, 2023 at 3:16 PM Jakub Jelinek wrote: > > On Tue, Aug 22, 2023 at 09:02:29PM +0800, Hongtao Liu wrote: > > > Agreed. And I still think -mevex512 vs. -mno-evex512 is the best option > > > name to represent whether the effective ISA set allows 512-bit vectors or > > > not. I think -

Re: [PATCH V2 2/5] OpenMP: C front end support for imperfectly-nested loops

> New common C/C++ testcases are in a separate patch. > > gcc/c-family/ChangeLog > * c-common.h (c_omp_check_loop_binding_exprs): Declare. > * c-omp.cc: Include tree-iterator.h. > (find_binding_in_body): New. > (check_loop_binding_expr_r): New. > (LOCATION_OR): New. >

Re: [PATCH v1] libffi: Backport of LoongArch support for libffi.

On Tue, 22 Aug 2023, Lulu Cheng wrote: > This is a backport of , > and contains modifications to commit 5a4774cd4d, as well as the LoongArch > schema portion of commit ee22ecbd11. This is needed for libgo. OK. > > libffi/ChangeLog: > >

[PATCH] Simplify intereaved store vectorization processing

When doing interleaving we perform code generation when visiting the last store of a chain. We keep track of this via DR_GROUP_STORE_COUNT, the following localizes this to the caller of vectorizable_store, also avoing redundant non-processing of the other stores. Bootstrapped and tested on x86_64

Re: Intel AVX10.1 Compiler Design and Support

On Tue, Aug 22, 2023 at 09:02:29PM +0800, Hongtao Liu wrote: > > Agreed. And I still think -mevex512 vs. -mno-evex512 is the best option > > name to represent whether the effective ISA set allows 512-bit vectors or > > not. I think -mavx10.1 -mno-avx512cd should be fine. And, -mavx10.1-256 > > o

Re: Intel AVX10.1 Compiler Design and Support

On Tue, Aug 22, 2023 at 4:34 PM Jakub Jelinek wrote: > > On Tue, Aug 22, 2023 at 09:36:15AM +0200, Richard Biener via Gcc-patches > wrote: > > I think internally we should have conditional 512bit support work across > > AVX512 and AVX10. > > > > I also think it makes sense to _internally_ have AV

Re: [PATCH V2 1/5] OpenMP: Add OMP_STRUCTURED_BLOCK and GIMPLE_OMP_STRUCTURED_BLOCK.

On Sun, Jul 23, 2023 at 04:15:17PM -0600, Sandra Loosemore wrote: > In order to detect invalid jumps in and out of intervening code in > imperfectly-nested loops, the front ends need to insert some sort of > marker to identify the structured block sequences that they push into > the inner body of t

Re: [PATCH V2 0/5] OpenMP: support for imperfectly-nested loops

On Sun, Jul 23, 2023 at 04:15:16PM -0600, Sandra Loosemore wrote: > Here is the latest version of my imperfectly-nested loops patches. > Compared to the initial version I'd posted in April > > https://gcc.gnu.org/pipermail/gcc-patches/2023-April/617103.html > > this version includes many minor co

[PATCH v1] libffi: Backport of LoongArch support for libffi.

This is a backport of , and contains modifications to commit 5a4774cd4d, as well as the LoongArch schema portion of commit ee22ecbd11. This is needed for libgo. libffi/ChangeLog: * configure.host: Add LoongArch support. * Makefi

Re: [PATCH 1/3] vect: Remove some manual release in vectorizable_store

On Tue, Aug 22, 2023 at 10:45 AM Kewen.Lin wrote: > > Hi, > > To avoid some duplicates in some follow-up patches on > function vectorizable_store, this patch is to adjust some > existing vec with auto_vec and remove some manual release > invocation. Also refactor a bit and remove some useless > c

Re: [PATCH] vect: Replace DR_GROUP_STORE_COUNT with DR_GROUP_LAST_ELEMENT

On Tue, Aug 22, 2023 at 10:44 AM Kewen.Lin wrote: > > Hi, > > Now we use DR_GROUP_STORE_COUNT to record how many stores > in a group have been transformed and only do the actual > transform when encountering the last one. I'm making > patches to move costing next to the transform code, it's > awk

Re: Loop-ch improvements, part 3

> > We seem to peel one iteration for no good reason. The loop is > a do-while loop already. The key is we see the first iteration > exit condition is known not taken and then: > > Registering value_relation (path_oracle) (iter.24_6 > iter.24_5) (root: > bb2) > Stmt is static (constant in

[PATCH] rtl: Forward declare rtx_code

Now that we require C++ 11, we can safely forward declare rtx_code so that we can use it in target hooks. gcc/ChangeLog * coretypes.h (rtx_code): Add forward declaration. * rtl.h (rtx_code): Make compatible with forward declaration. --- gcc/coretypes.h | 4 gcc/rtl.h |

[PATCH 14/12] libgcc _BitInt helper documentation [PR102989]

On Mon, Aug 21, 2023 at 05:32:04PM +, Joseph Myers wrote: > I think the libgcc functions (i.e. those exported by libgcc, to which > references are generated by the compiler) need documenting in libgcc.texi. > Internal functions or macros in the libgcc patch need appropriate comments > speci

Re: [PATCH 7/12] ubsan: _BitInt -fsanitize=undefined support [PR102989]

On Wed, 9 Aug 2023, Jakub Jelinek wrote: > Hi! > > The following patch introduces some -fsanitize=undefined support for _BitInt, > but some of the diagnostics is limited by lack of proper support in the > library. > I've filed https://github.com/llvm/llvm-project/issues/64100 to request > proper

Re: [PATCH] VECT: Add LEN_FOLD_EXTRACT_LAST pattern

On Tue, 22 Aug 2023, Juzhe-Zhong wrote: > Hi, Richard and Richi. > > This is the last autovec pattern I want to add for RVV (length loop control). > > This patch is supposed to handled this following case: > > int __attribute__ ((noinline, noclone)) > condition_reduction (int *a, int min_v, int

Re: [PATCH 02/11] Handle epilogues that contain jumps

On Tue, Aug 22, 2023 at 12:42 PM Szabolcs Nagy via Gcc-patches wrote: > > From: Richard Sandiford > > The prologue/epilogue pass allows the prologue sequence > to contain jumps. The sequence is then partitioned into > basic blocks using find_many_sub_basic_blocks. > > This patch treats epilogues

[PATCH] VECT: Add LEN_FOLD_EXTRACT_LAST pattern

Hi, Richard and Richi. This is the last autovec pattern I want to add for RVV (length loop control). This patch is supposed to handled this following case: int __attribute__ ((noinline, noclone)) condition_reduction (int *a, int min_v, int n) { int last = 66; /* High start value. */ for (i

[PATCH 11/11] aarch64,arm: Move branch-protection data to targets

The branch-protection types are target specific, not the same on arm and aarch64. This currently affects pac-ret+b-key, but there will be a new type on aarch64 that is not relevant for arm. gcc/ChangeLog: * config/aarch64/aarch64-opts.h (enum aarch64_key_type): Rename to ... (enu

[PATCH 05/11] aarch64: Add eh_return compile tests

gcc/testsuite/ChangeLog: * gcc.target/aarch64/eh_return-2.c: New test. * gcc.target/aarch64/eh_return-3.c: New test. --- gcc/testsuite/gcc.target/aarch64/eh_return-2.c | 9 + gcc/testsuite/gcc.target/aarch64/eh_return-3.c | 14 ++ 2 files changed, 23 insertion

[PATCH 10/11] aarch64: Fix branch-protection error message tests

Update tests for the new branch-protection parser errors. gcc/testsuite/ChangeLog: * gcc.target/aarch64/branch-protection-attr.c: Update. * gcc.target/aarch64/branch-protection-option.c: Update. --- gcc/testsuite/gcc.target/aarch64/branch-protection-attr.c | 6 +++--- gcc/tests

[PATCH 04/11] aarch64: Do not force a stack frame for EH returns

EH returns no longer rely on clobbering the return address on the stack so forcing a stack frame is not necessary. This does not actually change the code gen for the unwinder since there are calls before the EH return. gcc/ChangeLog: * config/aarch64/aarch64.cc (aarch64_needs_frame_chain

[PATCH 09/11] aarch64,arm: Fix branch-protection= parsing

Refactor the parsing to have a single API and fix a few parsing issues: - Different handling of "bti+none" and "none+bti": these should be rejected because "none" can only appear alone. - Accepted empty strings such as "bti++pac-ret" or "bti+", this bug was caused by using strtok_r. - Memory

[PATCH 02/11] Handle epilogues that contain jumps

From: Richard Sandiford The prologue/epilogue pass allows the prologue sequence to contain jumps. The sequence is then partitioned into basic blocks using find_many_sub_basic_blocks. This patch treats epilogues in the same way. It's needed for a follow-on aarch64 patch that adds conditional co

[PATCH 03/11] aarch64: Use br instead of ret for eh_return

The expected way to handle eh_return is to pass the stack adjustment offset and landing pad address via EH_RETURN_STACKADJ_RTX EH_RETURN_HANDLER_RTX to the epilogue that is shared between normal return paths and the eh_return paths. EH_RETURN_HANDLER_RTX is the stack slot of the return addre

[PATCH 08/11] aarch64,arm: Remove accepted_branch_protection_string

On aarch64 this caused ICE with pragma push_options since commit ae54c1b09963779c5c3914782324ff48af32e2f1 Author: Wilco Dijkstra CommitDate: 2022-06-01 18:13:57 +0100 AArch64: Cleanup option processing code The failure is at pop_options: internal compiler error: ‘global_options’ ar

[PATCH 07/11] aarch64: Disable branch-protection for pcs tests

The tests manipulate the return address in abitest-2.h and thus not compatible with -mbranch-protection=pac-ret+leaf or -mbranch-protection=gcs. gcc/testsuite/ChangeLog: * gcc.target/aarch64/aapcs64/func-ret-1.c: Disable branch-protection. * gcc.target/aarch64/aapcs64/func-ret-2.c

[PATCH 06/11] aarch64: Fix pac-ret eh_return tests

This is needed since eh_return no longer prevents pac-ret in the normal return path. gcc/testsuite/ChangeLog: * gcc.target/aarch64/return_address_sign_1.c: Move func4 to ... * gcc.target/aarch64/return_address_sign_2.c: ... here and fix the scan asm check. * gcc.ta

[PATCH 01/11] aarch64: AARCH64_ISA_RCPC was defined twice

gcc/ChangeLog: * config/aarch64/aarch64.h (AARCH64_ISA_RCPC): Remove dup. --- gcc/config/aarch64/aarch64.h | 1 - 1 file changed, 1 deletion(-) diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h index 2b0fc97bb71..c783cb96c48 100644 --- a/gcc/config/aarch64/aarch64.

[PATCH 00/11] aarch64 GCS preliminary patches

I'm working on Guarded Control Stack support for aarch64 and have a set of patches that are needed for GCS but seem useful without it so makes sense to review them separately from the rest of the GCS work. GCS support will depend on the linux ABI that is under discussion at https://lore.kernel.org

[patch] libgomp.c/simd-math-1.c: Test scalb{, l}n{, f} and un-XFAIL for non-nvptx/amdgcn

As mentioned in the 'libgomp, testsuite: Do not call nonstandard functions on darwin' thread: * scalb was deprecated then deleted in POSIX in favor of scalbn{,f} and scalbln{,f} which take an int or long, respectively, instead of double for the 'exp' argument of 'x * FLT_RADIX ** exp'. It

RE: [PATCH 1/9] arm: [MVE intrinsics] factorize vmullbq vmulltq

Hi Christophe, > -Original Message- > From: Christophe Lyon > Sent: Monday, August 14, 2023 7:34 PM > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; > Richard Earnshaw ; Richard Sandiford > > Cc: Christophe Lyon > Subject: [PATCH 1/9] arm: [MVE intrinsics] factorize vmullbq vmulltq > >

RE: [PATCH] arm: [MVE intrinsics] Remove dead check for float type in parse_element_type

> -Original Message- > From: Christophe Lyon > Sent: Monday, August 14, 2023 7:10 PM > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; > Richard Earnshaw ; Richard Sandiford > > Cc: Christophe Lyon > Subject: [PATCH] arm: [MVE intrinsics] Remove dead check for float type in > parse_elem

RE: [PATCH] arm: [MVE intrinsics] fix binary_acca_int32 and binary_acca_int64 shapes

Hi Christophe, > -Original Message- > From: Christophe Lyon > Sent: Monday, August 14, 2023 7:01 PM > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; > Richard Earnshaw ; Richard Sandiford > > Cc: Christophe Lyon > Subject: [PATCH] arm: [MVE intrinsics] fix binary_acca_int32 and > binary_

[patch] OpenMP: Handle 'all' as category in defaultmap

I stumbled over this when compiling the defaultmap files of the OpenMP example document (upcoming version). Seemingly, an 'all' was sneaked in when the syntax representation was changed (as alias for not specifying a category). I wonder which intended or nonintended changes are still hiding and

Re: Intel AVX10.1 Compiler Design and Support

On Tue, Aug 22, 2023 at 10:53 AM Jiang, Haochen wrote: > > > -Original Message- > > From: Richard Biener > > Sent: Tuesday, August 22, 2023 4:36 PM > > To: Jakub Jelinek > > Cc: Jiang, Haochen ; ZiNgA BuRgA > > ; Hongtao Liu ; gcc- > > patc...@gcc.gnu.org > > Subject: Re: Intel AVX10.1 C

Re: [PATCH] tree-optimization/94864 - vector insert of vector extract simplification

On Tue, Aug 22, 2023 at 5:05 PM Richard Biener via Gcc-patches wrote: > > The PRs ask for optimizing of > > _1 = BIT_FIELD_REF ; > result_4 = BIT_INSERT_EXPR ; > > to a vector permutation. The following implements this as > match.pd pattern, improving code generation on x86_64. > > On the RTL

Re: [OpenMP/offloading][RFC] How to handle target/device-specifics with C pre-processor (in general, inside 'omp declare variant')

On Tue, Aug 22, 2023 at 10:43:54AM +0200, Tobias Burnus wrote: > On 22.08.23 09:25, Richard Biener wrote: > > On Mon, Aug 21, 2023 at 6:23 PM Tobias Burnus > > wrote: > > > ... > > Err, so the OMP standard doesn't put any constraints on what to allow > > inside the > > variants? Is declare vari

  1   2   >