Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

On 6/28/23 22:04, Li, Pan2 wrote: It seems this patch may result in many test ICE failures on RISC-V backend. Could you help to double confirm about it follow the possible reproduce steps like blow? Thank you! I've one ICE due to this change as well but it wasn't in the

Re: [PATCH] i386: refactor macros.

On Thu, Jun 29, 2023 at 10:51 AM Hu, Lin1 via Gcc-patches wrote: > > Hi, all > > This patch aims to refactor macros in case some other thing is added to > AMX_TILE_SET in future. OK for trunk? Ok, thanks. > > BRs, > Lin > > gcc/ChangeLog: > > * common/config/i386/i386-common.cc

RE: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

Sorry for disturbing, cc kito, juzhe and robin for awareness. Pan -Original Message- From: Li, Pan2 Sent: Thursday, June 29, 2023 12:05 PM To: Jakub Jelinek ; Richard Biener Cc: gcc-patches@gcc.gnu.org; jeffreya...@gmail.com Subject: RE: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

RE: [PATCH v1] RISC-V: Allow rounding mode control for RVV floating-point add

Committed, thanks Kito and Juzhe. Pan -Original Message- From: Kito Cheng Sent: Thursday, June 29, 2023 10:35 AM To: Li, Pan2 Cc: juzhe.zh...@rivai.ai; gcc-patches ; Wang, Yanzhang ; jeffreyalaw Subject: Re: [PATCH v1] RISC-V: Allow rounding mode control for RVV floating-point add

RE: [PATCH v1] RISC-V: Support vfadd static rounding mode by mode switching

Committed, thanks Kito and Juzhe. pan -Original Message- From: Kito Cheng Sent: Thursday, June 29, 2023 10:34 AM To: juzhe.zh...@rivai.ai Cc: Li, Pan2 ; gcc-patches ; Wang, Yanzhang ; jeffreyalaw Subject: Re: [PATCH v1] RISC-V: Support vfadd static rounding mode by mode switching

RE: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

It seems this patch may result in many test ICE failures on RISC-V backend. Could you help to double confirm about it follow the possible reproduce steps like blow? Thank you! cd gcc && mkdir __BUILD__ && cd __BUILD__ ../configure \ --target=riscv64-unknown-elf \ --prefix= \

Re: [PATCH V3 1/4] rs6000: build constant via li;rotldi

Hi, Jiufu Guo via Gcc-patches writes: > Hi! > > Segher Boessenkool writes: > >> Hi! >> >> On Fri, Jun 16, 2023 at 04:34:12PM +0800, Jiufu Guo wrote: >>> +/* Check if value C can be built by 2 instructions: one is 'li', another is >>> + rotldi. >>> + >>> + If so, *SHIFT is set to the

Re: [PATCH V3] Optimize '(X - N * M) / N' to 'X / N - M' if valid

Hi, Jiufu Guo writes: > Hi, > > Integer expression "(X - N * M) / N" can be optimized to "X / N - M" if > there is no wrap/overflow/underflow and "X - N * M" has the same sign > with "X". > > Compare with the previous version: > https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620896.html

RE: [PATCH] x86: Update model values for Alderlake, Rocketlake and Raptorlake.

I will directly commit this patch, it can be considered as an obvious patch. Thanks, Lili. > -Original Message- > From: Gcc-patches On > Behalf Of Cui, Lili via Gcc-patches > Sent: Wednesday, June 28, 2023 6:52 PM > To: gcc-patches@gcc.gnu.org > Cc: Liu, Hongtao > Subject: [PATCH] x86:

RE: Re: [PATCH v1] RISC-V: Allow rounding mode control for RVV floating-point add

Sure thing, echo on below part. I think we need one place to put something like summary for this, for example, a table to indicate some information about this (aka rounding mode needed or not). I will try to summarize one draft then. > Check SPIKE implementation, make sure which API needs

[PATCH] i386: refactor macros.

Hi, all This patch aims to refactor macros in case some other thing is added to AMX_TILE_SET in future. OK for trunk? BRs, Lin gcc/ChangeLog: * common/config/i386/i386-common.cc (OPTION_MASK_ISA2_AMX_INT8_SET): Change OPTION_MASK_ISA2_AMX_TILE to OPTION_MASK_ISA2_AMX_TILE_SET.

Re: Re: [PATCH v1] RISC-V: Allow rounding mode control for RVV floating-point add

Hi, Pan. I think the last step is to support dynamic mode switching which may need to change the mode-switching PASS. After this done, I suggest you go over all rounding mode API (including fixed-point and floating-point.) Check SPIKE implementation, make sure which API needs rounding mode,

Re: [PATCH v1] RISC-V: Allow rounding mode control for RVV floating-point add

LGTM, thanks! On Tue, Jun 27, 2023 at 3:02 PM Li, Pan2 wrote: > > Ack, thanks Juzhe. > > > > Pan > > > > From: juzhe.zh...@rivai.ai > Sent: Tuesday, June 27, 2023 3:00 PM > To: Li, Pan2 ; gcc-patches > Cc: Kito.cheng ; Li, Pan2 ; Wang, > Yanzhang ; jeffreyalaw > Subject: Re: [PATCH v1]

Re: [PATCH v1] RISC-V: Support vfadd static rounding mode by mode switching

LGTM, thanks :) On Thu, Jun 29, 2023 at 10:24 AM juzhe.zh...@rivai.ai wrote: > > LGTM > > > juzhe.zh...@rivai.ai > > > From: pan2.li > Date: 2023-06-29 09:40 > To: gcc-patches > CC: juzhe.zhong; kito.cheng; pan2.li; yanzhang.wang; jeffreyalaw > Subject: [PATCH

Re: [PATCH v1] RISC-V: Support vfadd static rounding mode by mode switching

LGTM juzhe.zh...@rivai.ai From: pan2.li Date: 2023-06-29 09:40 To: gcc-patches CC: juzhe.zhong; kito.cheng; pan2.li; yanzhang.wang; jeffreyalaw Subject: [PATCH v1] RISC-V: Support vfadd static rounding mode by mode switching From: Pan Li This patch would like to support the vfadd static

[PATCH] PR gcc/110148:Avoid adding loop-carried ops to long chains

From: Lili Cui Hi Maintainer This patch is to fix TSVC242 regression related to loop-carried ops. Bootstrapped and regtested. Ok for trunk? Regards Lili. Avoid adding loop-carried ops to long chains, otherwise the whole chain will have dependencies across the loop iteration. Just keep

[PATCH v1] RISC-V: Support vfadd static rounding mode by mode switching

From: Pan Li This patch would like to support the vfadd static round mode similar to the fixed-point. Then the related fsrm instructions will be inserted correlatively. Please *NOTE* this PATCH doesn't cover anything about FRM dynamic mode, it will be implemented in the underlying PATCH(s).

Re: [PATCH] analyzer: Fix regression bug after r14-1632-g9589a46ddadc8b [pr110198]

On Thu, 2023-06-22 at 21:55 +0200, priour...@gmail.com wrote: > From: benjamin priour > > Resend with proper subject line ... > > Hi, Hi Benjamin > > Below is the fix to regression bug > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110198 > Was bootstrapped and regtested successfully on

[r14-2159 Regression] FAIL: gcc.target/i386/pieces-memcmp-2.c scan-assembler-times vptest[ \\t]*%xmm 2 on Linux/x86_64

On Linux/x86_64, 4afbebcdc5780d28e52b7d65643e462c7c3882ce is the first bad commit commit 4afbebcdc5780d28e52b7d65643e462c7c3882ce Author: Roger Sayle Date: Wed Jun 28 11:11:34 2023 +0100 i386: Add cbranchti4 pattern to i386.md (for -m32 compare_by_pieces). caused FAIL:

Re: [PATCH] RISC-V: Support vfwnmacc/vfwmsac/vfwnmsac combine lowering

On 6/28/23 16:10, 钟居哲 wrote: Sure. https://godbolt.org/z/8857KzTno Failed to match this instruction: (set (reg:VNx2DF 134 [ vect__31.47 ])     (fma:VNx2DF (neg:VNx2DF (float_extend:VNx2DF (reg:VNx2SF 136 [ vect__28.44 ])))         (reg:VNx2DF 150 [

Re: Re: [PATCH] RISC-V: Support vfwnmacc/vfwmsac/vfwnmsac combine lowering

Sure. https://godbolt.org/z/8857KzTno Failed to match this instruction: (set (reg:VNx2DF 134 [ vect__31.47 ]) (fma:VNx2DF (neg:VNx2DF (float_extend:VNx2DF (reg:VNx2SF 136 [ vect__28.44 ]))) (reg:VNx2DF 150 [ vect__8.12 ]) (reg:VNx2DF 171 [ vect__29.45 ])))

Re: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

You can see here: https://godbolt.org/z/d78646hWb The first case can't genreate vfwmul.vv but second case succeed. Failed to match this instruction: (set (reg:VNx2DF 150 [ vect__11.50 ]) (if_then_else:VNx2DF (unspec:VNx2BI [ (const_vector:VNx2BI repeat [

Re: Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

Ok. Plz go ahead commit this change with the testcases. Then it won't block the following patches. Thanks. juzhe.zh...@rivai.ai From: Richard Sandiford Date: 2023-06-29 04:42 To: Robin Dapp via Gcc-patches CC: 钟居哲; Jeff Law; Robin Dapp; kito.cheng; kito.cheng; palmer; palmer Subject: Re:

[PATCH] A couple of va_gc_atomic tweaks

The only current user of va_gc_atomic is Ada's: vec It uses the generic gt_pch_nx routines (with gt_pch_nx being the “note pointers” hooks), such as: template void gt_pch_nx (vec *v) { extern void gt_pch_nx (T &); for (unsigned i = 0; i < v->length (); i++)

[committed] testsuite: check_effective_target_lra: CRIS is LRA

Left-over from r14-383-gfaf8bea79b6256. * lib/target-supports.exp (check_effective_target_lra): Remove cris-*-* from expression for exceptions to LRA. --- gcc/testsuite/lib/target-supports.exp | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

[committed] CRIS: Don't apply PATTERN to insn before validation (PR 110144)

Oops. The validation was there, but PATTERN was applied before that. Noticeable only with rtl-checking (for example as in the report: "--enable-checking=yes,rtl") as this statement was only a (one of many) straggling olde-C declare-and-initialize-at-beginning-of-block thing. PR

Re: PR82943 - Suggested patch to fix

Hi Alex, welcome to the gfortran community. It is great that you are trying to get actively involved. You already did quite a few things right: patches shall be sent to the gcc-patches ML, but Fortran reviewers usually notice them only where they are copied to the fortran ML. There are some

Enable early inlining into always_inline functions

Hi, early inliner currently skips always_inline functions and moreover we ignore calls from always_inline in ipa_reverse_postorder. This leads to disabling most of propagation done using early optimization that is quite bad when early inline functions are not leaf functions, which is now quite

[PATCH, part3, committed] Fortran: ABI for scalar CHARACTER(LEN=1),VALUE dummy argument [PR110360]

Dear all, the previous patches to this PR unfortunately caused a regression, seen on Power big-endian systems/-m32 (pr110419), and while trying to investigate on x86 also showed a regression (ICE) on cases that were not covered in the testsuite before. The original fix did not properly handle

Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

Robin Dapp via Gcc-patches writes: > Hi Juzhe, > > I find the bug description rather confusing. What I can see is that > the constant in the literal pool is indeed wrong but how would DSE or > so play a role there? Particularly only for the smaller modes? > > My suspicion would be that the

Re: [PATCH] c++: cache partial template specialization selection

On 6/28/23 12:51, Patrick Palka wrote: There's currently no cheap way to obtain the partial template specialization (and arguments relative to it) that was selected for a class or variable template specialization. Our only option is to compute the result from scratch via

Re: [PATCH] c++: redundant targ coercion for var/alias tmpls

On Wed, Jun 28, 2023 at 11:50 AM Jason Merrill wrote: > > On 6/23/23 12:23, Patrick Palka wrote: > > On Fri, 23 Jun 2023, Jason Merrill wrote: > > > >> On 6/21/23 13:19, Patrick Palka wrote: > >>> When stepping through the variable/alias template specialization code > >>> paths, I noticed we

Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

Hi Juzhe, I find the bug description rather confusing. What I can see is that the constant in the literal pool is indeed wrong but how would DSE or so play a role there? Particularly only for the smaller modes? My suspicion would be that the constant in the literal/constant pool is wrong from

Re: Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

Try this: https://godbolt.org/z/x7bM5Pr84 juzhe.zh...@rivai.ai From: Jeff Law Date: 2023-06-29 02:11 To: Juzhe-Zhong; gcc-patches CC: kito.cheng; kito.cheng; palmer; palmer; rdapp.gcc Subject: Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

[committed] d: Fix wrong code-gen when returning structs by value.

Hi, Since r13-1104, structs in the D have had compute_record_mode called too early on them, causing them to return differently depending on the order that types are generated in, and whether there are forward references. This patch moves the call to compute_record_mode into its own function, and

Re: [PATCH] RISC-V: Fix out of range memory access of machine mode table

On 6/21/23 18:19, Li, Pan2 wrote: Hi there, I try to verify the offloading following below doc. https://gcc.gnu.org/wiki/Offloading#How_to_build_an_offloading-enabled_GCC with some steps: 1. Build nvptx-tools. 2. Symbol link nvptx-newlib to gcc source code. 3. Build the Nividia PTX accel

Re: [PATCH 10/11] riscv: thead: Add support for the XTheadMemIdx ISA extension

On 6/28/23 06:39, Christoph Müllner wrote: +;; XTheadMemIdx overview: +;; All peephole passes attempt to improve the operand utilization of +;; XTheadMemIdx instructions, where one sign or zero extended +;; register-index-operand can be shifted left by a 2-bit immediate. +;; +;; The basic

Re: [PATCH] RISC-V: Support vfwnmacc/vfwmsac/vfwnmsac combine lowering

On 6/28/23 05:55, Juzhe-Zhong wrote: Similar to vfwmacc. Add combine patterns as follows: For vfwnmsac: 1. (set (reg) (fma (neg (float_extend (reg))) (float_extend (reg))) (reg) ))) 2. (set (reg) (fma (neg (float_extend (reg))) (reg) (reg) ))) For vfwmsac: 1. (set (reg) (fma (float_extend

Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

.string "\001" .string "\001" .string "\001" .string "\001" .string "\001" .ascii "\001" .section.srodata,"a" .align 3 .type __PRETTY_FUNCTION__.0, @objec

Re: [PATCH] Relax type-printer regexp in libstdc++ test suite

On Wed, 28 Jun 2023 at 16:58, Tom Tromey via Libstdc++ < libstd...@gcc.gnu.org> wrote: > The libstdc++ test suite checks whether gdb type printers are > available like so: > > set do_whatis_tests [gdb_batch_check "python print(gdb.type_printers)" > \ >"\\\[\\\]"] >

Re: [PATCH] c++: Fix ICE with parameter pack of decltype(auto) [PR103497]

On Sat, Jun 24, 2023 at 9:24 AM Nathaniel Shead wrote: > > On Fri, Jun 23, 2023 at 11:59:51AM -0400, Patrick Palka wrote: > > Hi, > > > > On Sat, 22 Apr 2023, Nathaniel Shead via Gcc-patches wrote: > > > > > Bootstrapped and tested on x86_64-pc-linux-gnu. > > > > > > -- 8< -- > > > > > > This

[PATCH] c++: cache partial template specialization selection

There's currently no cheap way to obtain the partial template specialization (and arguments relative to it) that was selected for a class or variable template specialization. Our only option is to compute the result from scratch via most_specialized_partial_spec. For class templates this isn't

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

On 6/27/23 22:15, Juzhe-Zhong wrote: Consider the following complicate case: #define TEST_TYPE(TYPE1, TYPE2)\ __attribute__ ((noipa)) void vwadd_##TYPE1_##TYPE2 ( \ TYPE1 *__restrict dst, TYPE1 *__restrict dst2,

Re: [PATCH] Mark asm goto with outputs as volatile

On 6/27/23 11:23, Andrew Pinski via Gcc-patches wrote: On Tue, Jun 27, 2023 at 12:14 AM Richard Biener via Gcc-patches wrote: On Tue, Jun 27, 2023 at 5:26 AM Andrew Pinski via Gcc-patches wrote: The manual references asm goto as being implicitly volatile already and that was done when

RE: FW: [PATCH v5 0/19] Support early break/return auto-vectorization

Hi Juzhe, > > Hi, Tamar. > > This is an amazing auto-vectorization flow. > > I am thinking about whether RVV can also get benefits from this optimization. > IMHO, RVV should be also using this flow. > > So, to allow RVV (target uses len as loop_control and mask as flow control), > I > am

[PATCH] Relax type-printer regexp in libstdc++ test suite

The libstdc++ test suite checks whether gdb type printers are available like so: set do_whatis_tests [gdb_batch_check "python print(gdb.type_printers)" \ "\\\[\\\]"] This regexp assumes that the list of printers is empty. However, sometimes it's convenient to ship

[committed] d: Fix d_signed_or_unsigned_type is invoked for vector types (PR110193)

Hi, The function being changed in this patch can be invoked on VECTOR_TYPE, but the implementation assumes it works on integer types only. To fix, added a check whether the type passed is any `__vector(T)' or non-integral type, and return early by calling `signed_or_unsigned_type_for()' instead.

Re: [PATCH] c++: fix error reporting routines re-entered ICE [PR110175]

On 6/23/23 18:25, Marek Polacek wrote: Here we get the "error reporting routines re-entered" ICE because of an unguarded use of warning_at. While at it, I added a check for a warning_at just above it. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK. PR c++/110175

Re: [PATCH] c++: redundant targ coercion for var/alias tmpls

On 6/23/23 12:23, Patrick Palka wrote: On Fri, 23 Jun 2023, Jason Merrill wrote: On 6/21/23 13:19, Patrick Palka wrote: When stepping through the variable/alias template specialization code paths, I noticed we perform template argument coercion twice: first from instantiate_alias_template /

Re: [PATCH] c++: ahead of time variable template-id coercion [PR89442]

On 6/28/23 11:28, Jason Merrill wrote: On 5/3/23 09:50, Patrick Palka wrote: This patch makes us coerce the arguments of a variable template-id ahead of time, as we do for other template-ids, which allows us to immediately diagnose template parameter/argument kind mismatches and arity

Re: [PATCH] c++: ahead of time variable template-id coercion [PR89442]

On 5/3/23 09:50, Patrick Palka wrote: This patch makes us coerce the arguments of a variable template-id ahead of time, as we do for other template-ids, which allows us to immediately diagnose template parameter/argument kind mismatches and arity mismatches. Unfortunately this causes a

[PATCH 2/2] AArch64: New RTL for ABDL

From: oluade01 This patch adds new RTL for ABDL (sabdl, sabdl2, uabdl, uabdl2). gcc/ChangeLog: * config/aarch64/aarch64-simd.md (vec_widen_abdl_lo_, vec_widen_abdl_hi_): Expansions for abd vec widen optabs. (aarch64_abdl_insn): VQW based abdl RTL. *

Re: [PATCH 2/2] AArch64: New RTL for ABDL

> > +(define_insn "aarch64_abdl_hi_internal" > > + [(set (match_operand: 0 "register_operand" "=w") > > + (minus: > > + (USMAX: > > + (: > > + (vec_select: > > + (match_operand:VQW 1 "register_operand" "w") > > + (match_operand:VQW 3 "vect_par_cnst_hi_half"

[PATCH 1/2] Mid engine setup [SU]ABDL

From: oluade01 This updates vect_recog_abd_pattern to recognize the widening variant of absolute difference (ABDL, ABDL2). gcc/ChangeLog: * internal-fn.cc (widening_fn_p, decomposes_to_hilo_fn_p): Add IFN_VEC_WIDEN_ABD to the switch statement. * internal-fn.def

Re: [PATCH 1/2] Mid engine setup [SU]ABDL

> The new optabs need to be documented in doc/md.texi. Done. > “Long” is a bit of an architecture-specific term. Maybe just: > >Try to find the following ABsolute Difference (ABD) or >widening ABD (WIDEN_ABD) pattern: Change made. > >> - VTYPE x, y, out; > >> + VTYPE x, y; >

Re: [PATCH] Introduce hardbool attribute for C

> On Jun 28, 2023, at 3:26 AM, Alexandre Oliva wrote: > > I'd probably have arranged for the front-end to create the initializer > value, because expansion time is too late to figure it out: we may not > even have the front-end at hand any more, in case of lto compilation. >>>

Re: FW: [PATCH v5 0/19] Support early break/return auto-vectorization

Hi, Tamar. This is an amazing auto-vectorization flow. I am thinking about whether RVV can also get benefits from this optimization. IMHO, RVV should be also using this flow. So, to allow RVV (target uses len as loop_control and mask as flow control), I am not sure whether we can do this (Feel

Re: [testsuite] tolerate enabled but missing language frontends

On 6/28/23 05:25, Alexandre Oliva via Gcc-patches wrote: When a language is enabled but we run the testsuite against a tree in which the frontend compiler is not present, help.exp fails. It recognizes the output pattern for a disabled language, but not a missing frontend. Extend the

[committed] final+varasm: Change return type of predicate functions from int to bool

Also change some internal variables to bool and change return type of compute_alignments to void. gcc/ChangeLog: * output.h (leaf_function_p): Change return type from int to bool. (final_forward_branch_p): Ditto. (only_leaf_regs_used): Ditto. (maybe_assemble_visibility): Ditto.

Re: [PATCH] tree-optimization/110434 - avoid ={v} {CLOBBER} from NRV

On 6/28/23 04:21, Richard Biener via Gcc-patches wrote: When NRV replaces a local variable with it also replaces occurences in clobbers. This leads to being clobbered before the return of it which is strictly invalid but harmless in practice since there's no pass after NRV which would

Re: [PATCH] cprop_hardreg: fix ORIGINAL_REGNO/REG_ATTRS/REG_POINTER handling

Thanks! Applied to master with the requested changes as 417b8379b32945d61f1ce3d8281bee063eea1937. Note that the final version factors out the duplicated logic, so we now have a single place to add the comments. Philipp. On Sun, 25 Jun 2023 at 06:09, Jeff Law wrote: > > > > On 6/22/23 05:11,

[COMMITTED, PR 110308] cprop_hardreg: fix ORIGINAL_REGNO/REG_ATTRS/REG_POINTER handling

From: Manolis Tsamis Fixes: 6a2e8dcbbd4bab3 Propagation for the stack pointer in regcprop was enabled in 6a2e8dcbbd4bab3, but set ORIGINAL_REGNO/REG_ATTRS/REG_POINTER for stack_pointer_rtx which caused regression (e.g., PR 110313, PR 110308). This fix adds special handling for

[PATCH][vs] tree-optimization/110434 - avoid ={v} {CLOBBER} from NRV

When NRV replaces a local variable with it also replaces occurences in clobbers. This leads to being clobbered before the return of it which is strictly invalid but harmless in practice since there's no pass after NRV which would remove earlier stores. The following fixes this nevertheless.

RE: [PATCH 9/19] middle-end: refactor vectorizable_comparison to make the main body re-usable.

Adding proper maintainers. > -Original Message- > From: Tamar Christina > Sent: Wednesday, June 28, 2023 2:46 PM > To: gcc-patches@gcc.gnu.org > Cc: nd ; Richard Earnshaw ; > Marcus Shawcroft ; Kyrylo Tkachov > ; Richard Sandiford > > Subject: [PATCH 9/19]AArch64 middle-end: refactor

RE: [PATCH 3/19]middle-end clean up vect testsuite using pragma novector

Resending attached only due to size limit > -Original Message- > From: Tamar Christina > Sent: Wednesday, June 28, 2023 2:42 PM > To: gcc-patches@gcc.gnu.org > Cc: nd ; rguent...@suse.de; j...@ventanamicro.com > Subject: [PATCH 3/19]middle-end clean up vect testsuite using pragma >

[PATCH 16/19]AArch64 Add optimization for vector != cbranch fed into compare with 0 for Advanced SIMD

Hi All, Advanced SIMD lacks a cmpeq for vectors, and unlike compare to 0 we can't rewrite to a cmtst. This operation is however fairly common, especially now that we support early break vectorization. As such this adds a pattern to recognize the negated any comparison and transform it to an

[PATCH 15/19]AArch64: Add implementation for vector cbranch for Advanced SIMD

Hi All, This adds an implementation for conditional branch optab for AArch64. For e.g. void f1 () { for (int i = 0; i < N; i++) { b[i] += a[i]; if (a[i] > 0) break; } } For 128-bit vectors we generate: cmgtv1.4s, v1.4s, #0 umaxp v1.4s,

[PATCH 18/19]Arm: Add Advanced SIMD cbranch implementation

Hi All, This adds an implementation for conditional branch optab for AArch32. For e.g. void f1 () { for (int i = 0; i < N; i++) { b[i] += a[i]; if (a[i] > 0) break; } } For 128-bit vectors we generate: vcgt.s32q8, q9, #0 vpmax.u32

[PATCH 19/19]Arm: Add MVE cbranch implementation

Hi All, This adds an implementation for conditional branch optab for MVE. Unfortunately MVE has rather limited operations on VPT.P0, we are missing the ability to do P0 comparisons and logical OR on P0. For that reason we can only support cbranch with 0, as for comparing to a 0 predicate we

[PATCH 17/19]AArch64 Add optimization for vector cbranch combining SVE and Advanced SIMD

Hi All, Advanced SIMD lacks flag setting vector comparisons which SVE adds. Since machines with SVE also support Advanced SIMD we can use the SVE comparisons to perform the operation in cases where SVE codegen is allowed, but the vectorizer has decided to generate Advanced SIMD because of loop

[PATCH 13/19]middle-end testsuite: un-xfail TSVC loops that check for exit control flow vectorization

Hi All, I didn't want these to get lost in the noise of updates. The following three tests now correctly work for targets that have an implementation of cbranch for vectors so XFAILs are conditionally removed gated on vect_early_break support. Bootstrapped Regtested on aarch64-none-linux-gnu

[PATCH 12/19]middle-end: implement loop peeling and IV updates for early break.

Hi All, This patch updates the peeling code to maintain LCSSA during peeling. The rewrite also naturally takes into account multiple exits and so it didn't make sense to split them off. For the purposes of peeling the only change for multiple exits is that the secondary exits are all wired to

[PATCH 10/19]middle-end: implement vectorizable_early_break.

Hi All, This implements vectorable_early_exit which is used as the codegen part of vectorizing a gcond. For the most part it shares the majority of the code with vectorizable_comparison with addition that it needs to be able to reduce multiple resulting statements into a single one for use in

[PATCH 11/19]middle-end: implement code motion for early break.

Hi All, When performing early break vectorization we need to be sure that the vector operations are safe to perform. A simple example is e.g. for (int i = 0; i < N; i++) { vect_b[i] = x + i; if (vect_a[i]*2 != x) break; vect_a[i] = x; } where the store to vect_b is not allowed

[PATCH 9/19]AArch64 middle-end: refactor vectorizable_comparison to make the main body re-usable.

Hi All, Vectorization of a gcond starts off essentially the same as vectorizing a comparison witht he only difference being how the operands are extracted. This refactors vectorable_comparison such that we now have a generic function that can be used from vectorizable_early_break. The

[PATCH 8/19]middle-end: updated niters analysis to handle multiple exits.

Hi All, For early break vectorization we have to update niters analysis to record and analyze all exits of the loop, and so all conds. The niters of the loop is still determined by the main/natural exit of the loop as this is the O(n) bounds. For now we don't do much with the secondary conds,

[PATCH 7/19]middle-end: Refactor vectorizer loop conditionals and separate out IV to new variables

Hi All, This patch splits off the vectorizer's understanding of the main loop exit off from the normal loop infrastructure. Essentially we're relaxing the use of single_exit() in the vectorizer as we will no longer have a single single and need a well defined split between the main and secondary

[PATCH 6/19]middle-end: Don't enter piecewise expansion if VF is not constant.

Hi All, expand_vector_piecewise does not support VLA expansion as it has a hard assert on the type not being VLA. Instead of just failing to expand and so the call marked unsupported we ICE. This adjust it so we don't and can gracefully handle the expansion in support checks. Bootstrapped

[PATCH 5/19]middle-end: Enable bit-field vectorization to work correctly when we're vectoring inside conds

Hi All, The bitfield vectorization support does not currently recognize bitfields inside gconds. This means they can't be used as conditions for early break vectorization which is a functionality we require. This adds support for them by explicitly matching and handling gcond as a source.

[PATCH 4/19]middle-end: Fix scale_loop_frequencies segfault on multiple-exits

Hi All, There's an existing bug in loop frequency scaling where the if statement checks to see if there's a single exit, and records an dump file note but then continues. It then tries to access the null pointer, which of course fails. For multiple loop exists it's not really clear how to scale

[PATCH 2/19][front-end] C/C++ front-end: add pragma GCC novector

Hi All, FORTRAN currently has a pragma NOVECTOR for indicating that vectorization should not be applied to a particular loop. ICC/ICX also has such a pragma for C and C++ called #pragma novector. As part of this patch series I need a way to easily turn off vectorization of particular loops,

[PATCH 1/19]middle-end ifcvt: Support bitfield lowering of multiple-exit loops

Hi, With the patch enabling the vectorization of early-breaks, we'd like to allow bitfield lowering in such loops, which requires the relaxation of allowing multiple exits when doing so. In order to avoid a similar issue to PR107275, the code that rejects loops with certain types of gimple_stmts

[PATCH v5 0/19] Support early break/return auto-vectorization

Hi All, This patch adds initial support for early break vectorization in GCC. The support is added for any target that implements a vector cbranch optab, this includes both fully masked and non-masked targets. Depending on the operation, the vectorizer may also require support for boolean mask

[PATCH] middle-end/110452 - bad code generation with AVX512 mask splat

The following adds an alternate way of expanding a uniform mask vector constructor like _55 = _2 ? -1 : 0; vect_cst__56 = {_55, _55, _55, _55, _55, _55, _55, _55}; when the mask mode is a scalar int mode like for AVX512 or GCN. Instead of piecewise building the result via shifts and ors we

Re: [PATCH 11/11] riscv: thead: Add support for the XTheadFMemIdx ISA extension

On Sat, Jun 10, 2023 at 7:54 PM Jeff Law wrote: > > > > On 4/28/23 00:23, Christoph Muellner wrote: > > From: Christoph Müllner > > > > The XTheadFMemIdx ISA extension provides additional load and store > > instructions for floating-point registers with new addressing modes. > > > > The

Re: [PATCH 10/11] riscv: thead: Add support for the XTheadMemIdx ISA extension

On Sat, Jun 10, 2023 at 7:53 PM Jeff Law wrote: > > > > On 4/28/23 00:23, Christoph Muellner wrote: > > From: Christoph Müllner > > > > The XTheadMemIdx ISA extension provides a additional load and store > > instructions with new addressing modes. > > > > The following memory accesses types are

Re: [PATCH] tree-optimization/110434 - avoid ={v} {CLOBBER} from NRV

On Wed, Jun 28, 2023 at 12:32:51PM +, Richard Biener wrote: > As said there's nothing run after NRV. There is expansion but in the case I strongly doubt we are trying to stack reuse it for other vars, so maybe it is ok. > > On the other side, could there be partial clobbers for the var -> ,

[PATCH] tree-optimization/110451 - hoist invariant compare after interchange

The following adjusts the cost model of invariant motion to consider [VEC_]COND_EXPRs and comparisons producing a data value as expensive. For 503.bwaves_r this avoids an unnecessarily high vectorization factor because of an integer comparison besides data operations on double. Bootstrapped and

Re: [PATCH] tree-optimization/110434 - avoid ={v} {CLOBBER} from NRV

On Wed, 28 Jun 2023, Jakub Jelinek wrote: > On Wed, Jun 28, 2023 at 10:21:45AM +, Richard Biener via Gcc-patches > wrote: > > When NRV replaces a local variable with it also replaces > > occurences in clobbers. This leads to being clobbered > > before the return of it which is strictly

[PATCH] RISC-V: Support vfwnmacc/vfwmsac/vfwnmsac combine lowering

Similar to vfwmacc. Add combine patterns as follows: For vfwnmsac: 1. (set (reg) (fma (neg (float_extend (reg))) (float_extend (reg))) (reg) ))) 2. (set (reg) (fma (neg (float_extend (reg))) (reg) (reg) ))) For vfwmsac: 1. (set (reg) (fma (float_extend (reg)) (float_extend (reg))) (neg (reg))

Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors

From: Richard Biener Date: Tuesday, June 27, 2023 at 12:58 PM To: Tejas Belagod Cc: gcc-patches@gcc.gnu.org Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors On Tue, Jun 27, 2023 at 8:30 AM Tejas Belagod wrote: > > > > > > From: Richard Biener > Date: Monday, June 26, 2023

[testsuite] tolerate enabled but missing language frontends

When a language is enabled but we run the testsuite against a tree in which the frontend compiler is not present, help.exp fails. It recognizes the output pattern for a disabled language, but not a missing frontend. Extend the pattern so that it covers both cases. Tested on x86_64-linux-gnu.

Re: [PATCH] Basic asm blocks should always be volatile

Hi all, I've revised the change to be much neater >From 480954bc7d2b24e5d19a98260a2be0b49e112c42 Mon Sep 17 00:00:00 2001 From: TheShermanTanker Date: Wed, 28 Jun 2023 19:11:34 +0800 Subject: [PATCH] asm not using extended syntax should always be volatile --- gcc/cp/parser.cc | 2 +- 1 file

PING: Re: [PATCH] analyzer: Fix regression bug after r14-1632-g9589a46ddadc8b [pr110198]

Hi, Pinging that regression fix. Is everything OK for trunk ? Thanks, Benjamin On Thu, Jun 22, 2023 at 9:57 PM wrote: From: benjamin priour Resend with proper subject line ... Hi, Below is the fix to regression bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110198 Was

[PATCH] x86: Update model values for Alderlake, Rocketlake and Raptorlake.

Hi Hongtao, This patch is to update model values for Alderlake, Rocketlake and Raptorlake according to SDM. Ok for trunk? Thanks. Lili. Update model values for Alderlake, Rocketlake and Raptorlake according to SDM. gcc/ChangeLog * common/config/i386/cpuinfo.h (get_intel_cpu): Remove

Re: [PATCH] tree-optimization/110434 - avoid ={v} {CLOBBER} from NRV

On Wed, Jun 28, 2023 at 10:21:45AM +, Richard Biener via Gcc-patches wrote: > When NRV replaces a local variable with it also replaces > occurences in clobbers. This leads to being clobbered > before the return of it which is strictly invalid but harmless in > practice since there's no pass

[PATCH v2][RFC] c-family: Implement __has_feature and __has_extension [PR60512]

Hi, This patch implements clang's __has_feature and __has_extension in GCC. This is a v2 of the original RFC posted here: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617878.html Changes since v1: - Follow the clang behaviour where -pedantic-errors means that __has_extension behaves

[PATCH] tree-optimization/110434 - avoid ={v} {CLOBBER} from NRV

When NRV replaces a local variable with it also replaces occurences in clobbers. This leads to being clobbered before the return of it which is strictly invalid but harmless in practice since there's no pass after NRV which would remove earlier stores. The following fixes this nevertheless.

Re: [PATCH 2/2] [testsuite, arm]: Make mve_fp_fpu[12].c accept single or double precision FPU

On 28/06/2023 10:26, Christophe Lyon via Gcc-patches wrote: This tests currently expect a directive containing .fpu fpv5-sp-d16 and thus may fail if the test is executed for instance with -march=armv8.1-m.main+mve.fp+fp.dp This patch accepts either fpv5-sp-d16 or fpv5-d16 to avoid the failure.

Re: [PATCH 1/2] [testsuite,arm]: Make nomve_fp_1.c require arm_fp

On 28/06/2023 10:26, Christophe Lyon via Gcc-patches wrote: If GCC is configured with the default (soft) -mfloat-abi, and we don't override the target_board test flags appropriately, gcc.target/arm/mve/general-c/nomve_fp_1.c fails for lack of -mfloat-abi=softfp or -mfloat-abi=hard, because it

  1   2   >