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

ok juzhe.zh...@rivai.ai From: pan2.li Date: 2023-08-04 10:58 To: gcc-patches CC: juzhe.zhong; kito.cheng; pan2.li; yanzhang.wang Subject: [PATCH v1] RISC-V: Support RVV VFMSAC rounding mode intrinsic API From: Pan Li This patch would like to support the rounding mode API for the VFMSAC for

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

ok juzhe.zh...@rivai.ai From: pan2.li Date: 2023-08-04 11:28 To: gcc-patches CC: juzhe.zhong; kito.cheng; pan2.li; yanzhang.wang Subject: [PATCH v1] RISC-V: Support RVV VFNMSAC rounding mode intrinsic API From: Pan Li This patch would like to support the rounding mode API for the VFNMSAC

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

On 8/3/23 17:38, Vineet Gupta wrote: ;-)  Actually if you wanted to poke at zicond, the most interesting unexplored area I've come across is the COND_EXPR handling in gimple. When we expand a COND_EXPR into RTL the first approach we take is to try movcc in RTL. Unfortunately we don't

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

From: Pan Li This patch would like to support the rounding mode API for the VFNMSAC for the below samples. * __riscv_vfnmsac_vv_f32m1_rm * __riscv_vfnmsac_vv_f32m1_rm_m * __riscv_vfnmsac_vf_f32m1_rm * __riscv_vfnmsac_vf_f32m1_rm_m Signed-off-by: Pan Li gcc/ChangeLog: *

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

From: Pan Li This patch would like to support the rounding mode API for the VFMSAC for the below samples. * __riscv_vfmsac_vv_f32m1_rm * __riscv_vfmsac_vv_f32m1_rm_m * __riscv_vfmsac_vf_f32m1_rm * __riscv_vfmsac_vf_f32m1_rm_m Signed-off-by: Pan Li gcc/ChangeLog: *

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

Committed, thanks Juzhe. Pan From: juzhe.zh...@rivai.ai Sent: Friday, August 4, 2023 10:24 AM To: Li, Pan2 ; gcc-patches Cc: Kito.cheng ; Li, Pan2 ; Wang, Yanzhang Subject: Re: [PATCH v1] RISC-V: Support RVV VFNMACC rounding mode intrinsic API LGTM.

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

LGTM. juzhe.zh...@rivai.ai From: pan2.li Date: 2023-08-04 10:22 To: gcc-patches CC: juzhe.zhong; kito.cheng; pan2.li; yanzhang.wang Subject: [PATCH v1] RISC-V: Support RVV VFNMACC rounding mode intrinsic API From: Pan Li This patch would like to support the rounding mode API for the

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

From: Pan Li This patch would like to support the rounding mode API for the VFNMACC for the below samples. * __riscv_vfnmacc_vv_f32m1_rm * __riscv_vfnmacc_vv_f32m1_rm_m * __riscv_vfnmacc_vf_f32m1_rm * __riscv_vfnmacc_vf_f32m1_rm_m Signed-off-by: Pan Li gcc/ChangeLog: *

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

On Thu, Aug 3, 2023 at 4:09 PM Jan Beulich via Gcc-patches wrote: > > 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

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

On Thu, Aug 3, 2023 at 4:16 PM Jan Beulich via Gcc-patches wrote: > > gcc/ > > * config/i386/sse.md > (__): Add > "prefix" attribute. > > (avx512fp16_sh_v8hf): > Likewise. Ok. > --- > Talking of "prefix": Shouldn't at least V32HF and V32BF have it also >

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

On Thu, Aug 3, 2023 at 4:17 PM Jan Beulich via Gcc-patches wrote: > > 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

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

On Thu, Aug 3, 2023 at 4:14 PM Jan Beulich via Gcc-patches wrote: > > 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,

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

On Thu, Aug 3, 2023 at 4:14 PM Jan Beulich via Gcc-patches wrote: > > 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

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

On Thu, Aug 3, 2023 at 4:11 PM Jan Beulich via Gcc-patches wrote: > > In the three remaining instances separate "prefix_0f" and "prefix_rep" > are what is wanted instead. Ok. > > gcc/ > > * config/i386/i386.md (rdbase): Add "prefix_0f" and > "prefix_rep". Drop "prefix_extra". >

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

On Thu, Aug 3, 2023 at 4:16 PM Jan Beulich via Gcc-patches wrote: > > 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". Ok. > > gcc/ > > *

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

On Thu, Aug 3, 2023 at 4:14 PM Jan Beulich via Gcc-patches wrote: > > 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

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

On Thu, Aug 3, 2023 at 4:11 PM Jan Beulich via Gcc-patches wrote: > > 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 /

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

On Thu, Aug 3, 2023 at 4:10 PM Jan Beulich via Gcc-patches wrote: > > 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

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

On Thu, Aug 3, 2023 at 4:10 PM Jan Beulich via Gcc-patches wrote: > > 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 >

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

Committed, thanks Juzhe. Pan From: 钟居哲 Sent: Friday, August 4, 2023 6:22 AM To: Li, Pan2 ; gcc-patches Cc: Li, Pan2 ; Wang, Yanzhang ; kito.cheng Subject: Re: [PATCH v1] RISC-V: Support RVV VFMACC rounding mode intrinsic API LGTM

RE: [PATCH v1] RISC-V: Support RVV VFDIV and VFRDIV rounding mode intrinsic API

Committed, thanks Juzhe. Pan From: 钟居哲 Sent: Friday, August 4, 2023 6:15 AM To: Li, Pan2 ; gcc-patches Cc: Li, Pan2 ; Wang, Yanzhang ; kito.cheng Subject: Re: [PATCH v1] RISC-V: Support RVV VFDIV and VFRDIV rounding mode intrinsic API LGTM. I think you should go ahead to support and test

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

Committed, thanks Juzhe. Pan From: 钟居哲 Sent: Friday, August 4, 2023 6:16 AM To: Li, Pan2 ; gcc-patches Cc: Li, Pan2 ; Wang, Yanzhang ; kito.cheng Subject: Re: [PATCH v1] RISC-V: Support RVV VFWMUL rounding mode intrinsic API LGTM

Re: [PATCH] Replace invariant ternlog operands

On Fri, Aug 4, 2023 at 1:30 AM Alexander Monakov wrote: > > > On Thu, 27 Jul 2023, Liu, Hongtao via Gcc-patches wrote: > > > > +;; If the first and the second operands of ternlog are invariant and ;; > > > +the third operand is memory ;; then we should add load third operand > > > +from memory to

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

On 8/3/23 16:15, Jeff Law wrote: On 8/3/23 16:26, Vineet Gupta wrote: As discussed in Tue call, I definitely have 1 fix to riscv_rtx_costs (), which is worth pondering. It adjusts the cost of consts and helps Hoist GCSE constants (which granted kicks in only at -Os). However it does

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

On 8/3/23 16:26, Vineet Gupta wrote: As discussed in Tue call, I definitely have 1 fix to riscv_rtx_costs (), which is worth pondering. It adjusts the cost of consts and helps Hoist GCSE constants (which granted kicks in only at -Os). However it does affect codegen in subtle ways since

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

On 8/3/23 11:12, Jeff Law via Gcc-patches wrote: On Thu, 03 Aug 2023 08:05:09 PDT (-0700), gcc-patches@gcc.gnu.org wrote: [...] There's a bigger TODO in this space WRT a top-to-bottom evaluation of the costing on RISC-V.  I'm still formulating what that evaluation is going to look like, so

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

LGTM juzhe.zh...@rivai.ai From: pan2.li Date: 2023-08-03 22:38 To: gcc-patches CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng Subject: [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

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

LGTM juzhe.zh...@rivai.ai From: pan2.li Date: 2023-08-03 13:28 To: gcc-patches CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng Subject: [PATCH v1] RISC-V: Support RVV VFWMUL rounding mode intrinsic API From: Pan Li This patch would like to support the rounding mode API for the VFWMUL

Re: [PATCH v1] RISC-V: Support RVV VFDIV and VFRDIV rounding mode intrinsic API

LGTM. I think you should go ahead to support and test all api. juzhe.zh...@rivai.ai From: pan2.li Date: 2023-08-03 11:29 To: gcc-patches CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng Subject: [PATCH v1] RISC-V: Support RVV VFDIV and VFRDIV rounding mode intrinsic API From: Pan Li

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

So, the basic question is: Given the following: struct fix { int others; int array[10]; } extern struct fix * alloc_buf (); int main () { struct fix *p = alloc_buf (); __builtin_object_size(p->array,0) == ? } Given p->array, can the compiler determine that p points to an object that

Re: RISC-V: Added support for CRC.

On 8/3/23 13:37, Mariam Harutyunyan via Gcc-patches wrote: This patch adds CRC support for the RISC-V architecture. It adds internal functions and built-ins specifically designed to handle CRC computations efficiently. If the target is ZBC, the clmul instruction is used for the CRC code

Update estimated iteraitons counts after splitting

Hi, Hmmer's internal function has 4 loops. The following is the profile at start: loop 1: estimate 472 iterations by profile: 473.497707 (reliable) count in:84821 (precise, freq 0.9979) loop 2: estimate 99 iterations by profile: 100.00 (reliable) count in:39848881

Fix profiledbootstrap

Hi, Profiledbootstrap fails with ICE in update_loop_exit_probability_scale_dom_bbs called from loop unroling. The reason is that under relatively rare situations, we may run into case where loop has multiple exits and all are considered as likely but then we scale down the profile and one of the

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

On 8/1/23 19:38, Xiao Zeng wrote: This patch recognizes Zicond patterns when the select pattern with condition eq or neq to 0 (using eq as an example), namely: 1 rd = (rs2 == 0) ? non-imm : 0 2 rd = (rs2 == 0) ? non-imm : non-imm 3 rd = (rs2 == 0) ? reg : non-imm 4 rd = (rs2 == 0) ? reg : reg

Re: RISC-V: Added support for CRC.

Hi. Thank you. I'll add. Best regards, Mariam On Thu, Aug 3, 2023, 23:56 Andrew Pinski wrote: > On Thu, Aug 3, 2023 at 12:38 PM Mariam Harutyunyan via Gcc-patches > wrote: > > > > This patch adds CRC support for the RISC-V architecture. It adds internal > > functions and built-ins

Re: RISC-V: Added support for CRC.

On Thu, Aug 3, 2023 at 12:38 PM Mariam Harutyunyan via Gcc-patches wrote: > > This patch adds CRC support for the RISC-V architecture. It adds internal > functions and built-ins specifically designed to handle CRC computations > efficiently. > > If the target is ZBC, the clmul instruction is used

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

> On Aug 3, 2023, at 1:51 PM, Kees Cook wrote: > > On August 3, 2023 10:34:24 AM PDT, Qing Zhao wrote: >> One thing I need to point out first is, currently, even for regular fixed >> size array in the structure, >> We have this same issue, for example: >> >> #define LENGTH 10 >> >> struct

RISC-V: Added support for CRC.

This patch adds CRC support for the RISC-V architecture. It adds internal functions and built-ins specifically designed to handle CRC computations efficiently. If the target is ZBC, the clmul instruction is used for the CRC code generation; otherwise, table-based CRC is generated. A table with

[PATCH] Specify signed/unsigned/dontcare in calls to extract_bit_field_1.

This patch is inspired by Jakub's work on PR rtl-optimization/110717. The bitfield example described in comment #2, looks like: struct S { __int128 a : 69; }; unsigned type bar (struct S *p) { return p->a; } which on x86_64 with -O2 currently generates: bar:movzbl 8(%rdi), %ecx

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

Pushed to upstream master. Thanks ! Jose E. Marchesi writes: > 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

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

Pushed to upstream master. Thanks ! Jose E. Marchesi writes: > 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 >>

Re: [PATCH] [libbacktrace] fix up broken test

On Thu, Aug 3, 2023 at 6:27 AM Richard Biener via Gcc-patches wrote: > > 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

[COMMITTED] Add operand ranges to op1_op2_relation API.

We're looking to add the unordered relations for floating point, and as a result, we can no longer determine the relation between op1 and op2 in a statement based purely on the LHS... we also need to know the type of the operands on the RHS. This patch adjusts op1_op2_relation to fit the same

[COMMITTED] Provide a routine for NAME == NAME relation.

We've been assuming x == x is always VREL_EQ in GORI, but this is not always going to be true with floating point.  Provide an API to return the relation. Bootstraps on  x86_64-pc-linux-gnu with no regressions.   Pushed. Andrew From 430ff4f3e670e02185991190a5e2d90e61b39e07 Mon Sep 17 00:00:00

[COMMITTED] Automatically set type is certain Value_Range routines.

When you use a Value_Range, you need to set it's type first so it knows whether it will be an irange or an frange or whatever. There are a few set routines which take a type, and you shouldn't need to set the type first in those cases..  For instance set_varying() takes a type, so it seems

Re: [PATCH] Read global value/mask in IPA.

On 7/31/23 18:47, Martin Jambor wrote: Hello, On Tue, Jul 18 2023, Aldy Hernandez wrote: On 7/17/23 15:14, Aldy Hernandez wrote: Instead of reading the known zero bits in IPA, read the value/mask pair which is available. There is a slight change of behavior here. I have removed the check

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

On 8/3/23 11:41, Palmer Dabbelt wrote: On Thu, 03 Aug 2023 08:05:09 PDT (-0700), gcc-patches@gcc.gnu.org wrote: 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

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

On August 3, 2023 10:34:24 AM PDT, Qing Zhao wrote: >One thing I need to point out first is, currently, even for regular fixed size >array in the structure, >We have this same issue, for example: > >#define LENGTH 10 > >struct fix { > size_t foo; > int array[LENGTH]; >}; > >… >int main () >{ >

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

On Thu, 03 Aug 2023 08:05:09 PDT (-0700), gcc-patches@gcc.gnu.org wrote: 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

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

One thing I need to point out first is, currently, even for regular fixed size array in the structure, We have this same issue, for example: #define LENGTH 10 struct fix { size_t foo; int array[LENGTH]; }; … int main () { struct fix *p; p = alloc_buf_more ();

RE: [PATCH] Replace invariant ternlog operands

On Thu, 27 Jul 2023, Liu, Hongtao via Gcc-patches wrote: > > +;; If the first and the second operands of ternlog are invariant and ;; > > +the third operand is memory ;; then we should add load third operand > > +from memory to register and ;; replace first and second operands with > > +this

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

On Thu, 3 Aug 2023, Qing Zhao via Gcc-patches wrote: > +@opindex Wflex-array-member-not-at-end > +@opindex Wno-flex-array-member-not-at-end > +@item -Wflex-array-member-not-at-end I'd expect this to have @r{(C and C++ only)} to indicate what languages the option applies to. OK with that

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

On Thu, 3 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > --- gcc/testsuite/gcc.dg/bitint-18.c.jj 2023-08-03 12:26:35.510922996 > +0200 > +++ gcc/testsuite/gcc.dg/bitint-18.c 2023-08-03 12:26:42.114831050 +0200 > @@ -0,0 +1,44 @@ > +/* PR c/102989 */ > +/* { dg-do compile { target bitint

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

On 2023-08-03 12:43, Qing Zhao wrote: Surely we could emit that for __bdos(q->array, 0) though, couldn't we? For __bdos(q->array, 0), we only have the access info for the sub-object q->array, we can surely decide the size of the sub-object q->array, but we still cannot decide the whole

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

> On Aug 3, 2023, at 12:15 PM, Siddhesh Poyarekar wrote: > > 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. */ >>

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

This changes gimple_bitwise_inverted_equal_p to use a 2 different match patterns to try to match bit_not wrapped with a possible nop_convert and a comparison also wrapped with a possible nop_convert. This is to avoid being recursive. OK? Bootstrapped and tested on x86_64-linux-gnu with no

[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

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 *

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

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

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

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

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

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

[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

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

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

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

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

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

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

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 >

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

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.

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

[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

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

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

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

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

[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

[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

[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

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

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

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

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

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

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.

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

[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

[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

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

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

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

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

  1   2   >