Re: [PATCH 1/2] bpf: Implementation of BPF CO-RE builtins

> This patch updates the support for the BPF CO-RE builtins > __builtin_preserve_access_index and __builtin_preserve_field_info, > and adds support for the CO-RE builtins __builtin_btf_type_id, > __builtin_preserve_type_info and __builtin_preserve_enum_value. > > These CO-RE relocations are now c

Re: [PATCH v1] [RFC] Improve folding for comparisons with zero in tree-ssa-forwprop.

On Wed, Aug 2, 2023 at 4:08 PM Manolis Tsamis wrote: > > Hi all, > > I'm pinging to discuss again if we want to move this forward for GCC14. > > I did some testing again and I haven't been able to find obvious > regressions, including testing the code from PR86270 and PR70359 that > Richard mentio

Re: [PATCH] gcc-13/changes.html: Add and fix URL to -fstrict-flex-array option.

On Wed, 2 Aug 2023, Qing Zhao wrote: > Ping. > > This is a very simple patch to correct a URL address in GCC13?s changes.html. > Currently, it?s pointing to a wrong address. > > Okay for committing? OK > > On Jul 21, 2023, at 3:02 PM, Qing Zhao wrote: > > > > Hi, > > > > In the current GCC

[x86 PATCH] Split SUBREGs of SSE vector registers into vec_select insns.

This patch is the final piece in the series to improve the ABI issues affecting PR 88873. The previous patches tackled inserting DFmode values into V2DFmode registers, by introducing insvti_{low,high}part patterns. This patch improves the extraction of DFmode values from v2DFmode registers via T

Re: [PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.

On Mon, Jul 10, 2023 at 9:12 PM Qing Zhao via Gcc-patches wrote: > > Hi, > > This is the change for the GCC14 releaes Notes on the deprecating of a C > extension about flexible array members. > > Okay for committing? > > thanks. > > Qing > > > > *htdocs/gcc-14/changes.html (Caveats): Add

Introduce -msmp to select /lib_smp/ on ppc-vx6

The .spec files used for linking on ppc-vx6, when the rtp-smp runtime is selected, add -L flags for /lib_smp/ and /lib/. There was a problem, though: although /lib_smp/ and /lib/ were to be searched in this order, and the specs files do that correctly, the compiler would search /lib/ first regar

Re: [PATCH] s390: Enable vect_bswap test cases

On 8/3/23 08:48, Stefan Schulze Frielinghaus wrote: > This enables the following tests which rely on instruction vperm which > is available since z13 with the initial vector support. > > testsuite/gcc.dg/vect/vect-bswap16.c > 42:/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" {

Re: [PATCH] s390: Try to emit vlbr/vstbr instead of vperm et al.

On 8/3/23 08:51, Stefan Schulze Frielinghaus wrote: > Bootstrapped and regtested on s390x. Ok for mainline? > > gcc/ChangeLog: > > * config/s390/s390.cc (expand_perm_as_a_vlbr_vstbr_candidate): > New function which handles bswap patterns for vec_perm_const. > (vectorize_vec_per

Re: [PATCH] Fix PR 110874: infinite loop in gimple_bitwise_inverted_equal_p with fre

On Thu, Aug 3, 2023 at 4:34 AM Andrew Pinski via Gcc-patches wrote: > > So I didn't expect valueization to cause calling gimple_nop_convert > to iterate between 2 different SSA names causing an infinite loop > in gimple_bitwise_inverted_equal_p. > So we should cause a bound on gimple_bitwise_inver

Re: [COMMITTEDv3] tree-optimization: [PR100864] `(a&!b) | b` is not opimized to `a | b` for comparisons

On Thu, 3 Aug 2023 at 02:54, Andrew Pinski wrote: > > On Wed, Aug 2, 2023 at 10:14 AM Andrew Pinski wrote: > > > > On Wed, Aug 2, 2023 at 10:13 AM Prathamesh Kulkarni via Gcc-patches > > wrote: > > > > > > On Mon, 31 Jul 2023 at 22:39, Andrew Pinski via Gcc-patches > > > wrote: > > > > > > > >

[PATCH 00/10] x86: (mainly) "prefix_extra" adjustments

Having noticed various bogus uses, I thought I'd go through and audit them all. This is the result, with some other attributes also adjusted as noticed in the process. (I think this tidying also is a good thing to have ahead of APX further complicating insn length calculations.) 01: "prefix_extra"

[PATCH 01/10] x86: "prefix_extra" tidying

Drop SSE5 leftovers from both its comment and its default calculation. A value of 2 simply cannot occur anymore. Instead extend the comment to mention the use of the attribute in "length_vex", clarifying why "prefix_extra" can actually be meaningful on VEX-encoded insns despite those not having any

[PATCH 02/10] x86: "sse4arg" adjustments

Record common properties in other attributes' default calculations: There's always a 1-byte immediate, and they're always encoded in a VEX3- like manner (note that "prefix_extra" already evaluates to 1 in this case). The drop now (or already previously) redundant explicit attributes, adding "mode"

[PATCH 03/10] x86: "ssemuladd" adjustments

They're all VEX3- (also covering XOP) or EVEX-encoded. Express that in the default calculation of "prefix". FMA4 insns also all have a 1-byte immediate operand. Where the default calculation is not sufficient / applicable, add explicit "prefix" attributes. While there also add a "mode" attribute t

[PATCH 04/10] x86: "prefix_extra" can't really be "2"

In the three remaining instances separate "prefix_0f" and "prefix_rep" are what is wanted instead. gcc/ * config/i386/i386.md (rdbase): Add "prefix_0f" and "prefix_rep". Drop "prefix_extra". (wrbase): Likewise. (ptwrite): Likewise. --- a/gcc/config/i386/i386.md ++

[PATCH 07/10] x86: add (adjust) XOP insn attributes

Many were lacking "prefix" and "prefix_extra", some had a bogus value of 2 for "prefix_extra" (presumably inherited from their SSE5 counterparts, which are long gone) and a meaningless "prefix_data16" one. Where missing, "mode" attributes are also added. (Note that "sse4arg" and "ssemuladd" ones do

[PATCH 09/10] x86: correct "length_immediate" in a few cases

When first added explicitly in 3ddffba914b2 ("i386.md (sse4_1_round2): Add avx512f alternative"), "*" should not have been used for the pre-existing alternative. The attribute was plain missing. Subsequent changes adding more alternatives then generously extended the bogus pattern. Apparently some

[PATCH 05/10] x86: replace/correct bogus "prefix_extra"

In the rdrand and rdseed cases "prefix_0f" is meant instead. For mmx_floatv2siv2sf2 1 is correct only for the first alternative. For the integer min/max cases 1 uniformly applies to legacy and VEX encodings (the UB and SW variants are dealt with separately anyway). Same for {,V}MOVNTDQA. Unlike {,

[PATCH 06/10] x86: drop stray "prefix_extra"

While the attribute is relevant for legacy- and VEX-encoded insns, it is of no relevance for EVEX-encoded ones. While there in avx512dq_broadcast_1 add the missing "length_immediate". gcc/ * config/i386/sse.md (*_eq3_1): Drop "prefix_extra". (avx512dq_vextract64x2

[PATCH 08/10] x86: add missing "prefix" attribute to VF{,C}MULC

gcc/ * config/i386/sse.md (__): Add "prefix" attribute. (avx512fp16_sh_v8hf): Likewise. --- Talking of "prefix": Shouldn't at least V32HF and V32BF have it also default to "evex"? (It won't matter right here, but it may matter elsewhere.) --- a/gcc/config/

[PATCH 10/10] x86: drop redundant "prefix_data16" attributes

The attribute defaults to 1 for TI-mode insns of type sselog, sselog1, sseiadd, sseimul, and sseishft. In *v8hi3 [smaxmin] and *v16qi3 [umaxmin] also drop the similarly stray "prefix_extra" at this occasion. These two max/min flavors are encoded in 0f space. gcc/ * config/i386/mmx.md (*m

Re: [PATCH 1/2] bpf: Implementation of BPF CO-RE builtins

Jose E. Marchesi writes: >> This patch updates the support for the BPF CO-RE builtins >> __builtin_preserve_access_index and __builtin_preserve_field_info, >> and adds support for the CO-RE builtins __builtin_btf_type_id, >> __builtin_preserve_type_info and __builtin_preserve_enum_value. >> >> T

[PATCH] Swap loop splitting and final value replacement

The following swaps the loop splitting pass and the final value replacement pass to avoid keeping the IV of the earlier loop live when not necessary. The existing gcc.target/i386/pr87007-5.c testcase shows that we otherwise fail to elide an empty loop later. I don't see any good reason why loop s

Re: [PATCH] Swap loop splitting and final value replacement

> The following swaps the loop splitting pass and the final value > replacement pass to avoid keeping the IV of the earlier loop > live when not necessary. The existing gcc.target/i386/pr87007-5.c > testcase shows that we otherwise fail to elide an empty loop > later. I don't see any good reason

[PATCH v3][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 v3 which addresses feedback for the v2 patch posted here: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626058.html Main changes since v2: - As per Jason's feedback, dropped the langhook in favour of

Re: [PATCH] Fix PR 110874: infinite loop in gimple_bitwise_inverted_equal_p with fre

On Thu, Aug 3, 2023 at 12:23 AM Richard Biener via Gcc-patches wrote: > > On Thu, Aug 3, 2023 at 4:34 AM Andrew Pinski via Gcc-patches > wrote: > > > > So I didn't expect valueization to cause calling gimple_nop_convert > > to iterate between 2 different SSA names causing an infinite loop > > in

[PATCH 3/5] [RISC-V] Generate Zicond instruction for select pattern with condition eq or neq to 0

https://github.com/gcc-mirror/gcc/commit/e15d0b6680d10d7666195e9db65581364ad5e5df This patch causes so many fails in the regression: FAIL: gcc.target/riscv/rvv/vsetvl/vlmax_conflict-2.c -O1 scan-assembler-times vsetvli 3 FAIL: gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-40.c -O2 scan-

Re: [PATCH] AArch64: Do not increase the vect reduction latency by multiplying count [PR110625]

Gentle ping. Is it OK for master? I'm afraid the ICE may cause trouble and hope it can be fixed ASAP. Thanks, Hao From: Hao Liu OS Sent: Wednesday, August 2, 2023 11:45 To: Richard Sandiford Cc: Richard Biener; GCC-patches@gcc.gnu.org Subject: Re: [PATCH

Re: [x86 PATCH] Split SUBREGs of SSE vector registers into vec_select insns.

On Thu, Aug 3, 2023 at 9:10 AM Roger Sayle wrote: > > > This patch is the final piece in the series to improve the ABI issues > affecting PR 88873. The previous patches tackled inserting DFmode > values into V2DFmode registers, by introducing insvti_{low,high}part > patterns. This patch improves

Re: Fix profile upate after vectorizer peeling

> > Note most of the profile consistency checks FAIL when testing with -m32 on > x86_64-unknown-linux-gnu ... > > For example vect-11.c has > > ;; basic block 4, loop depth 0, count 719407024 (estimated locally, > freq 0.6700), maybe hot > ;; Invalid sum of incoming counts 708669602 (estimat

Re: [PATCH 1/2] bpf: Implementation of BPF CO-RE builtins

>> + /* FIXED: This wat not Ok. > > Hm? If that is fixed, do we still need that comment? :) Touche! ;) > >> +emit_insn ( \ >> + gen_mov_reloc_coredi (reg, \ >> +gen_rtx_CONST_INT (Pmode, 0), \ >> +gen_rtx_CONS

Re: [v2 PATCH 1/2] bpf: Implementation of BPF CO-RE builtins

>From fda9603ded735205b6e20fc5b65a04f8d15685e6 Mon Sep 17 00:00:00 2001 From: Cupertino Miranda Date: Thu, 6 Apr 2023 15:22:48 +0100 Subject: [PATCH v2 1/2] bpf: Implementation of BPF CO-RE builtins This patch updates the support for the BPF CO-RE builtins __builtin_preserve_access_index and __bu

Re: [v2 PATCH 2/2] bpf: CO-RE builtins support tests.

Hi, Resending this patch since I have noticed I had a testcase added in previous patch. Makes more sense here. Thanks, Cupertino >From 334e9ae0f428f6573f2a5e8a3067a4d181b8b9c5 Mon Sep 17 00:00:00 2001 From: Cupertino Miranda Date: Thu, 27 Jul 2023 18:05:22 +0100 Subject: [PATCH v2 2/2] bpf: CO

Re: [PATCH] AArch64: Do not increase the vect reduction latency by multiplying count [PR110625]

Hao Liu OS writes: > Hi Richard, > > Update the patch with a simple case (see below case and comments). It shows > a live stmt may not have reduction def, which introduce the ICE. > > Is it OK for trunk? OK, thanks. Richard > > Fix the assertion failure on empty reduction define in info_

Re: Fix profile upate after vectorizer peeling

> > > > Note most of the profile consistency checks FAIL when testing with -m32 on > > x86_64-unknown-linux-gnu ... > > > > For example vect-11.c has > > > > ;; basic block 4, loop depth 0, count 719407024 (estimated locally, > > freq 0.6700), maybe hot > > ;; Invalid sum of incoming counts

Re: [PATCH] ipa-sra: Don't consider CLOBBERS as writes preventing splitting

> On Mon, Jul 31, 2023 at 7:05 PM Martin Jambor wrote: > > > > Hi, > > > > when IPA-SRA detects whether a parameter passed by reference is > > written to, it does not special case CLOBBERs which means it often > > bails out unnecessarily, especially when dealing with C++ destructors. > > Fixed by

[PATCH] c-family: Add _BitInt support for __atomic_*fetch* [PR102989]

Hi! The following patch implements the lowering of __atomic_*fetch* functions where first argument is a pointer to (optionally _Atomic) _BitInt which either doesn't have size 1, 2, 4, 8 or 16 bytes or has 16 byte size but target doesn't support TImode. Patch on top of the _BitInt patch series. Te

Re: [PATCH V2] RISC-V: Support CALL conditional autovec patterns

Hi Juzhe, I would find it a bit clearer if the prepare_ternay part were a separate patch. As it's mostly mechanical replacements I don't mind too much, though so it's LGTM from my side without that. As to the lmul = 8 ICE, is the problem that the register allocator would actually need 5 "registe

[RFC] c++: extend cold, hot attributes to classes

Most code is cold. This patch extends support for attribute ((cold)) to C++ Classes, Unions, and Structs (RECORD_TYPES and UNION_TYPES) to benefit from encapsulation - reducing the verbosity of using the attribute where deserved. The ((hot)) attribute is also extended for its semantic relation. Wha

[PATCH v3 0/8] Add Loongson SX/ASX instruction support to LoongArch target.

This is an update of : https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624770.html Changes since last version: - Revert vabsd/xvabsd RTL templates to unspec impl, because arithmetic RTL expression cannot cover the edge case of the instruction output. v2 impl of vabsd/xvabsd template cau

[PATCH v3 1/8] LoongArch: Add Loongson SX vector directive compilation framework.

From: Lulu Cheng gcc/ChangeLog: * config/loongarch/genopts/loongarch-strings: Add compilation framework. * config/loongarch/genopts/loongarch.opt.in: Ditto. * config/loongarch/loongarch-c.cc (loongarch_cpu_cpp_builtins): Ditto. * config/loongarch/loongarch-def.c:

[PATCH v3 4/8] LoongArch: Add Loongson ASX vector directive compilation framework.

From: Lulu Cheng gcc/ChangeLog: * config/loongarch/genopts/loongarch-strings: Add compilation framework. * config/loongarch/genopts/loongarch.opt.in: Ditto. * config/loongarch/loongarch-c.cc (loongarch_cpu_cpp_builtins): Ditto. * config/loongarch/loongarch-def.c:

Re: [RFC] light expander sra for parameters and returns

On Thu, 3 Aug 2023, Jiufu Guo wrote: > > Hi Richard, > > Richard Biener writes: > > > On Tue, 1 Aug 2023, Jiufu Guo wrote: > > > >> > >> Hi, > >> > >> Richard Biener writes: > >> > >> > On Mon, 24 Jul 2023, Jiufu Guo wrote: > >> > > >> >> > >> >> Hi Martin, > >> >> > >> >> Not sure about

Re: [PATCH][RFC] tree-optimization/92335 - Improve sinking heuristics for vectorization

On Wed, 2 Aug 2023 at 14:17, Richard Biener via Gcc-patches wrote: > > On Mon, 31 Jul 2023, Jeff Law wrote: > > > > > > > On 7/28/23 01:05, Richard Biener via Gcc-patches wrote: > > > The following delays sinking of loads within the same innermost > > > loop when it was unconditional before. That

Re: [COMMITTEDv3] tree-optimization: [PR100864] `(a&!b) | b` is not opimized to `a | b` for comparisons

Hello, Le 31/07/2023 à 19:07, Andrew Pinski via Gcc-patches a écrit : diff --git a/gcc/generic-match-head.cc b/gcc/generic-match-head.cc index a71c0727b0b..ddaf22f2179 100644 --- a/gcc/generic-match-head.cc +++ b/gcc/generic-match-head.cc @@ -121,3 +121,45 @@ bitwise_equal_p (tree expr1, tree ex

Re: PING^2 [PATCH] mklog: fix bugs of --append option

Gentle PING^2, thanks!

[COMMITTED] ada: Fix spurious error on 'Input of private type with Type_Invariant aspect

From: Eric Botcazou The problem is that it is necessary to break the privacy during the expansion of the Input attribute, which may introduce a view mismatch with the parameter of the routine checking the invariant of the type. gcc/ada/ * exp_util.adb (Make_Invariant_Call): Convert the

[COMMITTED] ada: Adjust again address arithmetics in System.Dwarf_Lines

From: Eric Botcazou Using the operator of System.Storage_Elements has introduced a range check that may be tripped on, so this removes the intermediate conversion to the Storage_Count subtype that is responsible for it. gcc/ada/ * libgnat/s-dwalin.adb ("-"): New subtraction operator.

[COMMITTED] ada: Add pragma Annotate for GNATcheck exemptions

From: Sheri Bernstein Exempt the GNATcheck rule "Improper_Returns" with the rationale "early returns for performance". gcc/ada/ * libgnat/s-aridou.adb: Add pragma to exempt Improper_Returns. * libgnat/s-atopri.adb (Lock_Free_Try_Write): Likewise. * libgnat/s-bitops.adb (

[COMMITTED] ada: Rewrite Set_Image_*_Unsigned routines to remove recursion.

From: Vasiliy Fofanov This rewriting removes algorithm inefficiencies due to unnecessary recursion and copying. The new version has much smaller and statically known stack requirements and is additionally up to 2x faster. gcc/ada/ * libgnat/s-imageb.adb (Set_Image_Based_Unsigned): Rewri

[PATCH] tree-optimization/110702 - avoid zero-based memory references in IVOPTs

Sometimes IVOPTs chooses a weird induction variable which downstream leads to issues. Most of the times we can fend those off during costing by rejecting the candidate but it looks like the address description costing synthesizes is different from what we end up generating so the following fixes t

RE: [PATCH]AArch64 Undo vec_widen_shiftl optabs [PR106346]

> > + > > +(define_constraint "D3" > > + "@internal > > + A constraint that matches vector of immediates that is with 0 to > > +(bits(mode)/2)-1." > > + (and (match_code "const,const_vector") > > + (match_test "aarch64_const_vec_all_same_in_range_p (op, 0, > > + (GET_MODE_UN

[PATCH] poly_int: Handle more can_div_trunc_p cases

can_div_trunc_p (a, b, &Q, &r) tries to compute a Q and r that satisfy the usual conditions for truncating division: (1) a = b * Q + r (2) |b * Q| <= |a| (3) |r| < |b| We can compute Q using the constant component (the case when all indeterminates are zero). Since |r| < |b| for th

Re: Re: [PATCH V2] RISC-V: Support CALL conditional autovec patterns

No. prepare_ternary can not be seperate patch. It's a bug fix patch which is discovered in autovectorization. Thanks for comments. I will commit it when middle-end is approved by Richi. >> As to the lmul = 8 ICE, is the problem that the register allocator >> would actually need 5 "registers" when

Re: [PATCH] poly_int: Handle more can_div_trunc_p cases

On Thu, Aug 3, 2023 at 2:46 PM Richard Sandiford via Gcc-patches wrote: > > can_div_trunc_p (a, b, &Q, &r) tries to compute a Q and r that > satisfy the usual conditions for truncating division: > > (1) a = b * Q + r > (2) |b * Q| <= |a| > (3) |r| < |b| > > We can compute Q using th

Re: [PATCH]AArch64 Undo vec_widen_shiftl optabs [PR106346]

Tamar Christina writes: >> > + >> > +(define_constraint "D3" >> > + "@internal >> > + A constraint that matches vector of immediates that is with 0 to >> > +(bits(mode)/2)-1." >> > + (and (match_code "const,const_vector") >> > + (match_test "aarch64_const_vec_all_same_in_range_p (op, 0, >> >

Re: [PATCH] tree-optimization/110838 - vectorization of widened shifts

On Wed, 2 Aug 2023, Richard Sandiford wrote: > Richard Biener writes: > > [...] > >> >> in vect_determine_precisions_from_range. Maybe we should drop > >> >> the shift handling from there and instead rely on > >> >> vect_determine_precisions_from_users, extending: > >> >> > >> >> if (TR

RE: [PATCH]AArch64 update costing for MLA by invariant

> >> Do you see vect_constant_defs in practice, or is this just for > >> completeness? > >> I would expect any constants to appear as direct operands. I don't > >> mind keeping it if it's just a belt-and-braces thing though. > > > > In the latency case where I had allow_constants the early reject

Re: [RFC] [v2] Extend fold_vec_perm to handle VLA vectors

Prathamesh Kulkarni writes: > On Tue, 25 Jul 2023 at 18:25, Richard Sandiford > wrote: >> >> Hi, >> >> Thanks for the rework and sorry for the slow review. > Hi Richard, > Thanks for the suggestions! Please find my responses inline below. >> >> Prathamesh Kulkarni writes: >> > Hi Richard, >> >

Re: [RFC] [v2] Extend fold_vec_perm to handle VLA vectors

Richard Sandiford writes: > Prathamesh Kulkarni writes: >> On Tue, 25 Jul 2023 at 18:25, Richard Sandiford >> wrote: >>> >>> Hi, >>> >>> Thanks for the rework and sorry for the slow review. >> Hi Richard, >> Thanks for the suggestions! Please find my responses inline below. >>> >>> Prathamesh K

Re: [PATCH V5 1/2] Add overflow API for plus minus mult on range

This is OK. On 8/2/23 22:18, Jiufu Guo wrote: Hi, I would like to have a ping on this patch. BR, Jeff (Jiufu Guo) Jiufu Guo writes: Hi, As discussed in previous reviews, adding overflow APIs to range-op would be useful. Those APIs could help to check if overflow happens when operating b

[PATCH] [libbacktrace] fix up broken test

zstdtest has some inline data where some testcases lack the uncompressed length field. Thus it computes that but still ends up allocating memory for the uncompressed buffer based on that (zero) length. Oops. Causes memory corruption if the allocator returns non-NULL. Tested on x86_64-unknown-li

[PATCH] mid-end: Use integral time intervals in timevar.cc

> > I think this is undesriable. With fused you mean we use FMA? > I think you could use -ffp-contract=off for the TU instead. > > Note you can't use __attribute__((noinline)) literally since the > host compiler might not support this. > > Richard. > Trying to make the timevar store integral

Re: [PATCH]AArch64 update costing for MLA by invariant

Tamar Christina writes: >> >> Do you see vect_constant_defs in practice, or is this just for >> >> completeness? >> >> I would expect any constants to appear as direct operands. I don't >> >> mind keeping it if it's just a belt-and-braces thing though. >> > >> > In the latency case where I had a

Re: [PATCH 3/5] [RISC-V] Generate Zicond instruction for select pattern with condition eq or neq to 0

On 8/3/23 03:27, juzhe.zh...@rivai.ai wrote: https://github.com/gcc-mirror/gcc/commit/e15d0b6680d10d7666195e9db65581364ad5e5df This patch causes so many fails in the regression: Mine. I'll take care of it.

[committed] analyzer: fix ICE on zero-sized arrays [PR110882]

Successfully bootstrapped and regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r14-2955-gc62f93d1e0383d. gcc/analyzer/ChangeLog: PR analyzer/110882 * region.cc (int_size_in_bits): Fail on zero-sized types. gcc/testsuite/ChangeLog: PR analyzer/110882 * gcc.dg/

Re: Fix profile upate after vectorizer peeling

On 8/3/23 04:13, Jan Hubicka wrote: Note most of the profile consistency checks FAIL when testing with -m32 on x86_64-unknown-linux-gnu ... For example vect-11.c has ;; basic block 4, loop depth 0, count 719407024 (estimated locally, freq 0.6700), maybe hot ;; Invalid sum of incoming co

Re: [PATCH 3/5] [RISC-V] Generate Zicond instruction for select pattern with condition eq or neq to 0

I am working on that, it seems the cost of vsetvli instruction become 0 due to this change, then loop invariant motion won't hoist vsetvli longer. Jeff Law 於 2023年8月3日 週四 21:49 寫道： > > > On 8/3/23 03:27, juzhe.zh...@rivai.ai wrote: > > > https://github.com/gcc-mirror/gcc/commit/e15d0b6680d10d766

Re: [PATCH 3/5] [RISC-V] Generate Zicond instruction for select pattern with condition eq or neq to 0

On 8/3/23 07:56, Kito Cheng wrote: I am working on that, it seems the cost of vsetvli instruction become 0 due to this change, then loop invariant motion won't hoist vsetvli longer. I haven't looked yet (generating baseline rvv.exp data right now). But before I went to bed last night I was w

Re: [PATCH] mid-end: Use integral time intervals in timevar.cc

On Thu, 2023-08-03 at 14:38 +0100, Matthew Malcomson via Gcc-patches wrote: > > > > I think this is undesriable.  With fused you mean we use FMA? > > I think you could use -ffp-contract=off for the TU instead. > > > > Note you can't use __attribute__((noinline)) literally since the > > host compi

[PATCH 2/3 v3] genmatch: Reduce variability of generated code

So far genmatch has been using an unordered map to store information about functions to be generated. Since corresponding locations from match.pd were used as keys in the map, even small changes to match.pd which caused line number changes would change the order in which the functions are generated

[PATCH 3/3 v3] genmatch: Log line numbers indirectly

Currently fprintf calls logging to a dump file take line numbers in the match.pd file directly as arguments. When match.pd is edited, referenced code changes line numbers, which causes changes to many fprintf calls and, thus, to many (usually all) .cc files generated by genmatch. This forces make t

[PATCH 0/3 v3] genmatch: Speed up recompilation after changes to match.pd

The following reduces the number of object files that need to be rebuilt after match.pd has been modified. Right now a change to match.pd which adds/removes a line almost always forces recompilation of all files that genmatch generates from it. This is because of unnecessary changes to the generate

[PATCH 1/3 v3] Support get_or_insert in ordered_hash_map

Get_or_insert method is already supported by the unordered hash map. Adding it to the ordered map enables us to replace the unordered map with the ordered one in cases where ordering may be useful. Signed-off-by: Andrzej Turko gcc/ChangeLog: * ordered-hash-map.h: Add get_or_insert.

Re: Fix profile upate after vectorizer peeling

> > Jeff, an help would be appreciated here :) > > > > I will try to debug this. One option would be to disable branch > > prediciton on vect_check for time being - it is not inlined anyway > Not a lot of insight. The backwards threader uses a totally different API > for the CFG/SSA updates and

Re: Fix profile upate after vectorizer peeling

On 8/3/23 08:23, Jan Hubicka wrote: Jeff, an help would be appreciated here :) I will try to debug this. One option would be to disable branch prediciton on vect_check for time being - it is not inlined anyway Not a lot of insight. The backwards threader uses a totally different API for th

Re: [PATCH 3/5] [RISC-V] Generate Zicond instruction for select pattern with condition eq or neq to 0

> > I am working on that, it seems the cost of vsetvli instruction become 0 > > due to this change, then loop invariant motion won't hoist vsetvli longer. > I haven't looked yet (generating baseline rvv.exp data right now). But > before I went to bed last night I was worried that a change snuck >

Re: [PATCH 3/3] genmatch: Log line numbers indirectly

Thank you for the review. Yes, this increases the binary size. I have implemented this in the third version of this patch series, is that what you had in mind? Originally, this change increased the sizes of binaries 8-12 kB, but after updating the master branch, this change would actually decreas

[PATCH v1] RISC-V: Fix one comment for binop_frm insn

From: Pan Li The previous patch missed the vfsub comment for binop_frm, this patch would like to fix this. Signed-off-by: Pan Li gcc/ChangeLog: * config/riscv/riscv-vector-builtins-bases.cc: Add vfsub. --- gcc/config/riscv/riscv-vector-builtins-bases.cc | 1 + 1 file changed, 1 inser

Re: [PATCH v1] RISC-V: Fix one comment for binop_frm insn

lgtm On Thu, Aug 3, 2023 at 10:32 PM wrote: > > From: Pan Li > > The previous patch missed the vfsub comment for binop_frm, this > patch would like to fix this. > > Signed-off-by: Pan Li > > gcc/ChangeLog: > > * config/riscv/riscv-vector-builtins-bases.cc: Add vfsub. > --- > gcc/config

Re: [PATCH 1/2] bpf: Implementation of BPF CO-RE builtins

> Jose E. Marchesi writes: > >>> This patch updates the support for the BPF CO-RE builtins >>> __builtin_preserve_access_index and __builtin_preserve_field_info, >>> and adds support for the CO-RE builtins __builtin_btf_type_id, >>> __builtin_preserve_type_info and __builtin_preserve_enum_value.

[PATCH v1] RISC-V: Support RVV VFMACC rounding mode intrinsic API

From: Pan Li This patch would like to support the rounding mode API for the VFMACC for the below samples. * __riscv_vfmacc_vv_f32m1_rm * __riscv_vfmacc_vv_f32m1_rm_m * __riscv_vfmacc_vf_f32m1_rm * __riscv_vfmacc_vf_f32m1_rm_m Signed-off-by: Pan Li gcc/ChangeLog: * config/riscv/riscv-

Re: [v2 PATCH 1/2] bpf: Implementation of BPF CO-RE builtins

Ok. Thanks! > From fda9603ded735205b6e20fc5b65a04f8d15685e6 Mon Sep 17 00:00:00 2001 > From: Cupertino Miranda > Date: Thu, 6 Apr 2023 15:22:48 +0100 > Subject: [PATCH v2 1/2] bpf: Implementation of BPF CO-RE builtins > > This patch updates the support for the BPF CO-RE builtins > __builtin_pre

Re: [v2 PATCH 2/2] bpf: CO-RE builtins support tests.

OK. Thanks. > Hi, > > Resending this patch since I have noticed I had a testcase added in > previous patch. Makes more sense here. > > Thanks, > Cupertino > > From 334e9ae0f428f6573f2a5e8a3067a4d181b8b9c5 Mon Sep 17 00:00:00 2001 > From: Cupertino Miranda > Date: Thu, 27 Jul 2023 18:05:22 +0100

Re: [PATCH 3/5] [RISC-V] Generate Zicond instruction for select pattern with condition eq or neq to 0

On 8/3/23 08:31, Kito Cheng wrote: I am working on that, it seems the cost of vsetvli instruction become 0 due to this change, then loop invariant motion won't hoist vsetvli longer. I haven't looked yet (generating baseline rvv.exp data right now). But before I went to bed last night I was w

RE: [PATCH v1] RISC-V: Fix one comment for binop_frm insn

Committed, thanks Kito. Pan -Original Message- From: Kito Cheng Sent: Thursday, August 3, 2023 10:35 PM To: Li, Pan2 Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; Wang, Yanzhang Subject: Re: [PATCH v1] RISC-V: Fix one comment for binop_frm insn lgtm On Thu, Aug 3, 2023 at 10:3

[committed] testsuite, analyzer: add test case [PR108171]

The ICE in PR analyzer/108171 appears to be a dup of the recently fixed PR analyzer/110882 and is likewise fixed by it; adding this test case. Successfully regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r14-2957-gf80efa49b7a163. gcc/testsuite/ChangeLog: PR analyzer/108171

Re: [PATCH] mid-end: Use integral time intervals in timevar.cc

On 8/3/23 15:09, David Malcolm wrote: Hi Matthew. I recently touched the timevar code (in r14-2881- g75d623946d4b6e) to add support for serializing the timevar data in JSON form as part of the SARIF output (PR analyzer/109361). Looking at your patch, it looks like the baseline for the patch se

Re: [PATCH 3/5] [RISC-V] Generate Zicond instruction for select pattern with condition eq or neq to 0

> >> That'll be the first thing to look at. THe costing change was supposed > >> only affect if-then-else constructs, not sets in general. > > > > > > If so, I think the most simple fix is adding more checks on the set > > cost - only check the SET_SRC is if-then-else? > No, the simple fix is to j

Re: [PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.

> On Aug 3, 2023, at 3:10 AM, Richard Biener wrote: > > On Mon, Jul 10, 2023 at 9:12 PM Qing Zhao via Gcc-patches > wrote: >> >> Hi, >> >> This is the change for the GCC14 releaes Notes on the deprecating of a C >> extension about flexible array members. >> >> Okay for committing? >> >> th

[committed][RISC-V] Remove errant hunk of code

I'm using this hunk locally to more thoroughly exercise the zicond paths due to inaccuracies elsewhere in the costing model. It was never supposed to be part of the costing commit though. And as we've seen it's causing problems with the vector bits. While my testing isn't complete, this hu

Re: [PATCH 3/5] [RISC-V] Generate Zicond instruction for select pattern with condition eq or neq to 0

On 8/3/23 08:56, Kito Cheng wrote: That'll be the first thing to look at. THe costing change was supposed only affect if-then-else constructs, not sets in general. If so, I think the most simple fix is adding more checks on the set cost - only check the SET_SRC is if-then-else? No, the si

Re: Fix profile upate after vectorizer peeling

On 8/3/23 16:29, Jeff Law wrote: On 8/3/23 08:23, Jan Hubicka wrote: Jeff, an help would be appreciated here :) I will try to debug this.  One option would be to disable branch prediciton on vect_check for time being - it is not inlined anyway Not a lot of insight.  The backwards threader

Re: [PATCH v1] [RFC] Improve folding for comparisons with zero in tree-ssa-forwprop.

On 8/3/23 01:04, Richard Biener wrote: On Wed, Aug 2, 2023 at 4:08 PM Manolis Tsamis wrote: Hi all, I'm pinging to discuss again if we want to move this forward for GCC14. I did some testing again and I haven't been able to find obvious regressions, including testing the code from PR86270

Re: [PATCH v2] analyzer: stash values for CPython plugin [PR107646]

On Wed, Aug 2, 2023 at 5:09 PM David Malcolm wrote: > > On Wed, 2023-08-02 at 14:46 -0400, Eric Feng wrote: > > On Wed, Aug 2, 2023 at 1:20 PM Marek Polacek > > wrote: > > > > > > On Wed, Aug 02, 2023 at 12:59:28PM -0400, David Malcolm wrote: > > > > On Wed, 2023-08-02 at 12:20 -0400, Eric Feng w

Re: [COMMITTEDv3] tree-optimization: [PR100864] `(a&!b) | b` is not opimized to `a | b` for comparisons

On Thu, Aug 3, 2023 at 4:58 AM Mikael Morin wrote: > > Hello, > > Le 31/07/2023 à 19:07, Andrew Pinski via Gcc-patches a écrit : > > diff --git a/gcc/generic-match-head.cc b/gcc/generic-match-head.cc > > index a71c0727b0b..ddaf22f2179 100644 > > --- a/gcc/generic-match-head.cc > > +++ b/gcc/generi

Re: [PATCH] mid-end: Use integral time intervals in timevar.cc

On Thu, 2023-08-03 at 15:54 +0100, Matthew Malcomson wrote: > On 8/3/23 15:09, David Malcolm wrote: > > > > Hi Matthew.  I recently touched the timevar code (in r14-2881- > > g75d623946d4b6e) to add support for serializing the timevar data in > > JSON form as part of the SARIF output (PR analyzer/

Re: [PATCH v2] analyzer: stash values for CPython plugin [PR107646]

On Thu, 2023-08-03 at 11:28 -0400, Eric Feng wrote: > On Wed, Aug 2, 2023 at 5:09 PM David Malcolm > wrote: > > > > On Wed, 2023-08-02 at 14:46 -0400, Eric Feng wrote: > > [...snip...] > > > > >  Otherwise, please let me know if I should request write > > > access first (the GettingStarted pa

Re: One question on the source code of tree-object-size.cc

On 2023-08-02 10:02, Qing Zhao wrote: /*when checking the observed access p->array, we only have info on the observed access, i.e, the TYPE_SIZE info from the access. We don't have info on the whole object. */ expect(__builtin_dynamic_object_size(q->array, 1), q->foo * sizeof(int

[PATCH] Add documentation for -Wflex-array-member-not-at-end.

When adding the option -Wflex-array-member-not-at-end in the commit https://gcc.gnu.org/pipermail/gcc-cvs/2023-June/385730.html the documentation for this new option was missing. This patch is to add the documentation for this warning option. bootstrapped and also checked the documentation, no i

  1   2   >