RE: [PATCH]middle-end: rejects loops with nonlinear inductions and early breaks [PR113163]

> -Original Message- > From: Richard Biener > Sent: Monday, January 8, 2024 12:07 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com > Subject: Re: [PATCH]middle-end: rejects loops with nonlinear inductions and > early > breaks [P

RE: [PATCH] tree-optimization/113026 - avoid vector epilog in more cases

> -Original Message- > From: Richard Biener > Sent: Monday, January 8, 2024 11:29 AM > To: gcc-patches@gcc.gnu.org > Cc: Tamar Christina > Subject: [PATCH] tree-optimization/113026 - avoid vector epilog in more cases > > The following avoids creating a n

[PATCH][frontend]: don't ice with pragma NOVECTOR if loop in C has no condition [PR113267]

Hi All, In C you can have loops without a condition, the original version of the patch was rejecting the use of #pragma GCC novector, however during review it was changed to not due this with the reason that we didn't want to give a compile error with such cases. However because annotations seem

Re: [PATCH]middle-end: thread through existing LCSSA variable for alternative exits too [PR113237]

for alternative exits too [PR113237] On 1/7/24 18:29, Tamar Christina wrote: > gcc/ChangeLog: > >PR tree-optimization/113237 >* tree-vect-loop-manip.cc (slpeel_tree_duplicate_loop_to_edge_cfg): Use >existing LCSSA variable for exit when all exits are earl

[PATCH]middle-end: thread through existing LCSSA variable for alternative exits too [PR113237]

Hi All, Builing on top of the previous patch, similar to when we have a single exit if we have a case where all exits are considered early exits and there are existing non virtual phi then in order to maintain LCSSA we have to use the existing PHI variables. We can't simply clear them and just

RE: [PATCH]middle-end: Don't apply copysign optimization if target does not implement optab [PR112468]

> On Fri, 2024-01-05 at 11:02 +0000, Tamar Christina wrote: > > Ok, so something like: > > > > > > ([istarget loongarch*-*-*] && > > > > ([check_effective_target_loongarch_sx] || > > > > [check_effective_target_hard_float])) >

RE: [PATCH]middle-end: Don't apply copysign optimization if target does not implement optab [PR112468]

> -Original Message- > From: Xi Ruoyao > Sent: Thursday, January 4, 2024 10:39 PM > To: Palmer Dabbelt ; Tamar Christina > > Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de; Jeff Law > > Subject: Re: [PATCH]middle-end: Don't apply copysign optimi

[PATCH]middle-end: Don't apply copysign optimization if target does not implement optab [PR112468]

Hi All, currently GCC does not treat IFN_COPYSIGN the same as the copysign tree expr. The latter has a libcall fallback and the IFN can only do optabs. Because of this the change I made to optimize copysign only works if the target has impemented the optab, but it should work for those that have

RE: [PATCH 20/21]Arm: Add Advanced SIMD cbranch implementation

> -Original Message- > From: Kyrylo Tkachov > Sent: Thursday, January 4, 2024 11:12 AM > To: Tamar Christina ; gcc-patches@gcc.gnu.org > Cc: nd ; Ramana Radhakrishnan > ; Richard Earnshaw > ; ni...@redhat.com > Subject: RE: [PATCH 20/21]Arm: Add Advanced SIM

RE: [PATCH 20/21]Arm: Add Advanced SIMD cbranch implementation

Ping, --- Hi All, This adds an implementation for conditional branch optab for AArch32. The previous version only allowed operand 0 but it looks like cbranch expansion does not check with the target and so we have to implement all. I therefore did not commit it. This is a larger version. I've

[PATCH]middle-end: check if target can do extract first for early breaks [PR113199]

Hi All, I was generating the vector reverse mask without checking if the target actually supported such an operation. It also seems like more targets implement VEC_EXTRACT than permute on mask registers. So this adds a check for IFN_VEC_EXTRACT support when required and changes the select first

RE: skip vector profiles multiple exits

> -Original Message- > From: Jan Hubicka > Sent: Friday, December 29, 2023 10:32 PM > To: Tamar Christina > Cc: rguent...@suse.de; GCC Patches ; nd > > Subject: Re: skip vector profiles multiple exits > > > Hi Honza, > Hi, > > > > I was

skip vector profiles multiple exits

Hi Honza, I wasn't sure what to do here so I figured I'd ask. In adding support for multiple exits to the vectorizer I didn't know how to update this bit: https://github.com/gcc-mirror/gcc/blob/master/gcc/tree-vect-loop-manip.cc#L3363 Essentially, if skip_vector (i.e. not enough iteration to

[PATCH]middle-end: maintain LCSSA form when peeled vector iterations have virtual operands

Hi All, This patch fixes several interconnected issues. 1. When picking an exit we wanted to check for niter_desc.may_be_zero not true. i.e. we want to pick an exit which we know will iterate at least once. However niter_desc.may_be_zero is not a boolean. It is a tree that encodes a

[PATCH]middle-end: Fix dominators updates when peeling with multiple exits [PR113144]

Hi All, Only trying to update certain dominators doesn't seem to work very well because as the loop gets versioned, peeled, or skip_vector then we end up with very complicated control flow. This means that the final merge blocks for the loop exit are not easy to find or update. Instead of

[PATCH]middle-end: rejects loops with nonlinear inductions and early breaks [PR113163]

Hi All, We can't support nonlinear inductions other than neg when vectorizing early breaks and iteration count is known. For early break we currently require a peeled epilog but in these cases we can't compute the remaining values. Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.

[PATCH 20/21]Arm: Add Advanced SIMD cbranch implementation

Hi All, This adds an implementation for conditional branch optab for AArch32. The previous version only allowed operand 0 but it looks like cbranch expansion does not check with the target and so we have to implement all. I therefore did not commit it. This is a larger version. For e.g. void

[PATCH]AArch64 Update costing for vector conversions [PR110625]

Hi All, In gimple the operation short _8; double _9; _9 = (double) _8; denotes two operations. First we have to widen from short to long and then convert this integer to a double. Currently however we only count the widen/truncate operations: (double) _5 6 times vec_promote_demote costs 12

[PATCH][committed]middle-end: explicitly initialize vec_stmts [PR113132]

Hi All, when configured with --enable-checking=release we get a false positive on the use of vec_stmts as the compiler seems unable to notice it gets initialized through the pass-by-reference. This explicitly initializes the local. Bootstrapped Regtested on x86_64-pc-linux-gnu and no issues.

[PATCH][testsuite]: Add more pragma novector to new tests

Hi All, This patch was pre-appproved by Richi. This updates the testsuite and adds more #pragma GCC novector to various tests that would otherwise vectorize the vector result checking code. This cleans out the testsuite since the last rebase and prepares for the landing of the early break

RE: [PATCH 3/21]middle-end: Implement code motion and dependency analysis for early breaks

> > + /* If we've moved a VDEF, extract the defining MEM and update > > +usages of it. */ > > + tree vdef; > > + /* This statement is to be moved. */ > > + if ((vdef = gimple_vdef (stmt))) > > + LOOP_VINFO_EARLY_BRK_CONFLICT_STMTS >

RE: RE: [PATCH] Regression FIX: Remove vect_variable_length XFAIL from some tests

guess whomever added the vect_variable_length indended It to fail when VLA though. Perhaps these tests need a dg-add-options ? Since I think other tests already test fixed-length vectors. But lets see what Richi says. Thanks, Tamar From: 钟居哲 Sent: Tuesday, December 19, 2023 1:02 PM To: Tamar

RE: [PATCH] Regression FIX: Remove vect_variable_length XFAIL from some tests

Hi Juzhe, > -Original Message- > From: Juzhe-Zhong > Sent: Tuesday, December 19, 2023 11:19 AM > To: gcc-patches@gcc.gnu.org > Cc: rguent...@suse.de; Tamar Christina ; Juzhe- > Zhong > Subject: [PATCH] Regression FIX: Remove vect_variable_length XFAIL from

[PATCH]middle-end: Handle hybrid SLP induction vectorization with early breaks.

Hi All, While we don't support SLP for early break vectorization, we can land in the situation where the induction was vectorized through hybrid SLP. This means when vectorizing the early break live operation we need to get the results of the SLP operation. Bootstrapped Regtested on

RE: [PATCH 3/21]middle-end: Implement code motion and dependency analysis for early breaks

> > > > + /* Save destination as we go, BB are visited in order and the > > > > last one > > > > + is where statements should be moved to. */ > > > > + if (!dest_bb) > > > > + dest_bb = gimple_bb (c); > > > > + else > > > > + { > > > > + basic_block

RE: [PATCH 9/21]middle-end: implement vectorizable_early_exit for codegen of exit code

> -Original Message- > From: Richard Biener > Sent: Thursday, December 14, 2023 1:13 PM > To: Tamar Christina > Cc: Richard Sandiford ; gcc-patches@gcc.gnu.org; > nd ; j...@ventanamicro.com > Subject: RE: [PATCH 9/21]middle-end: implement vectorizable_early_exit

RE: [PATCH 17/21]AArch64: Add implementation for vector cbranch for Advanced SIMD

> I see you've changed it from: > > + rtx cc_reg = aarch64_gen_compare_reg (code, val, const0_rtx); > + rtx cmp_rtx = gen_rtx_fmt_ee (code, DImode, cc_reg, const0_rtx); > + emit_jump_insn (gen_condjump (cmp_rtx, cc_reg, operands[3])); > > to: > > + emit_jump_insn (gen_cbranchdi4

RE: [PATCH 9/21]middle-end: implement vectorizable_early_exit for codegen of exit code

> > > else if (vect_use_mask_type_p (stmt_info)) > > > { > > > unsigned int precision = stmt_info->mask_precision; > > > scalar_type = build_nonstandard_integer_type (precision, 1); > > > vectype = get_mask_type_for_scalar_type (vinfo, scalar_type, > > > group_size); > > >

RE: [PATCH 9/21]middle-end: implement vectorizable_early_exit for codegen of exit code

> -Original Message- > From: Richard Biener > Sent: Tuesday, December 12, 2023 10:10 AM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com; > Richard Sandiford > Subject: RE: [PATCH 9/21]middle-end: implement vectorizable_early_exit

RE: [PATCH 9/21]middle-end: implement vectorizable_early_exit for codegen of exit code

> > + vectype = truth_type_for (comp_type); > > so this leaves the producer of the mask in the GIMPLE_COND and we > vectorize the GIMPLE_COND as > > mask_1 = ...; > if (mask_1 != {-1,-1...}) > .. > > ? In principle only the mask producer needs a vector type and that > adjusted by

[PATCH]middle-end: Mark all control flow as used_in_scope.

Hi All, While compiling SPECCPU 2017 I ran accross the reason (I had forgotten) why my initial patch marked all control statements as used in scope and not just gconds: There are other statements that can introduce multiple exits, like switch statements. If we ignore them as not relevant we

RE: [PATCH 15/21]middle-end: [RFC] conditionally support forcing final edge for debugging

> -Original Message- > From: Richard Biener > Sent: Monday, December 11, 2023 7:38 AM > To: Richard Sandiford > Cc: Tamar Christina ; gcc-patches@gcc.gnu.org; nd > ; j...@ventanamicro.com > Subject: Re: [PATCH 15/21]middle-end: [RFC] conditionally support fo

RE: [PATCH 9/21]middle-end: implement vectorizable_early_exit for codegen of exit code

> > > > > > Hmm, but we're visiting them then? I wonder how you get along > > > without doing adjustmens on the uses if you consider > > > > > > _1 = a < b; > > > _2 = c != d; > > > _3 = _1 | _2; > > > if (_3 != 0) > > > exit loop; > > > > > > thus a combined condition like

RE: [PATCH 9/21]middle-end: implement vectorizable_early_exit for codegen of exit code

> -Original Message- > From: Richard Biener > Sent: Friday, December 8, 2023 2:00 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com > Subject: RE: [PATCH 9/21]middle-end: implement vectorizable_early_exit for > codegen of exit code &g

RE: [PATCH 9/21]middle-end: implement vectorizable_early_exit for codegen of exit code

> -Original Message- > From: Richard Biener > Sent: Friday, December 8, 2023 10:28 AM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com > Subject: RE: [PATCH 9/21]middle-end: implement vectorizable_early_exit for > codegen of exit co

RE: [PATCH 9/21]middle-end: implement vectorizable_early_exit for codegen of exit code

> --param vect-partial-vector-usage=2 would, no? > I.. didn't even know it went to 2! > > In principal I suppose I could mask the individual stmts, that should > > handle the > future case when > > This is relaxed to supposed non-fix length buffers? > > Well, it looks wrong - either put in an

RE: [PATCH 17/21]AArch64: Add implementation for vector cbranch for Advanced SIMD

> -Original Message- > From: Richard Sandiford > Sent: Tuesday, November 28, 2023 5:56 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw > ; Marcus Shawcroft > ; Kyrylo Tkachov > Subject: Re: [PATCH 17/21]AArch64: Add implement

RE: [PATCH 13/21]middle-end: Update loop form analysis to support early break

> -Original Message- > From: Richard Biener > Sent: Wednesday, December 6, 2023 9:15 AM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com > Subject: RE: [PATCH 13/21]middle-end: Update loop form analysis to support > early > break

RE: [PATCH 12/21]middle-end: Add remaining changes to peeling and vectorizer to support early breaks

> -Original Message- > From: Richard Biener > Sent: Wednesday, December 6, 2023 8:32 AM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com > Subject: Re: [PATCH 12/21]middle-end: Add remaining changes to peeling and > vectorizer to

RE: [PATCH]middle-end: Fix peeled vect loop IV values.

> -Original Message- > From: Tamar Christina > Sent: Wednesday, December 6, 2023 8:48 AM > To: Richard Biener > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com > Subject: RE: [PATCH]middle-end: Fix peeled vect loop IV values. > > > > Hi All, > &g

RE: [PATCH 13/21]middle-end: Update loop form analysis to support early break

> -Original Message- > From: Richard Biener > Sent: Wednesday, December 6, 2023 8:18 AM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com > Subject: Re: [PATCH 13/21]middle-end: Update loop form analysis to support > early > break

RE: [PATCH]middle-end: Fix peeled vect loop IV values.

> > Hi All, > > > > While waiting for reviews I found this case where both loop exit needs to > > go to > > epilogue loop, but there was an IV related variable that was used in the > > scalar > > iteration as well. > > > > vect_update_ivs_after_vectorizer then blew the value away and replaced it

RE: [PATCH 9/21]middle-end: implement vectorizable_early_exit for codegen of exit code

> > > + > > > + tree truth_type = truth_type_for (vectype_op); machine_mode mode = > > > + TYPE_MODE (truth_type); int ncopies; > > > + > > more line break issues ... (also below, check yourself) > > shouldn't STMT_VINFO_VECTYPE already match truth_type here? If not > it looks to be set

RE: [PATCH 8/21]middle-end: update vectorizable_live_reduction with support for multiple exits and different exits

> > > is the exit edge you are looking for without iterating over all loop > > > exits. > > > > > > > + gimple *tmp_vec_stmt = vec_stmt; > > > > + tree tmp_vec_lhs = vec_lhs; > > > > + tree tmp_bitstart = bitstart; > > > > + /* For early

RE: [PATCH 10/21]middle-end: implement relevancy analysis support for control flow

> > > + && LOOP_VINFO_LOOP_IV_COND (loop_vinfo) != cond) > > > + *relevant = vect_used_in_scope; > > but why not simply mark all gconds as vect_used_in_scope? > We break outer-loop vectorization since doing so would pull the inner loop's exit into scope for the outerloop. Also we can't

[PATCH]middle-end: Fix peeled vect loop IV values.

Hi All, While waiting for reviews I found this case where both loop exit needs to go to epilogue loop, but there was an IV related variable that was used in the scalar iteration as well. vect_update_ivs_after_vectorizer then blew the value away and replaced it with the value if it took the

[PATCH]middle-end: correct loop bounds for early breaks and peeled vector loops

Hi All, While waiting for reviews I've continued to run more test. In this case this was one found running 32-bit systems. While we calculate the right latch count for the epilog, the vectorizer overrides SCEV and so unrolling goes wrong. This updates the bounds for the case where we've peeled

RE: [PATCH 13/21]middle-end: Update loop form analysis to support early break

ping > -Original Message- > From: Tamar Christina > Sent: Monday, November 27, 2023 10:48 PM > To: Tamar Christina ; gcc-patches@gcc.gnu.org > Cc: nd ; rguent...@suse.de; j...@ventanamicro.com > Subject: RE: [PATCH 13/21]middle-end: Update loop form analysis to suppor

RE: RE: [PATCH 9/21]middle-end: implement vectorizable_early_exit for codegen of exit code

); that variable `bias` isn’t defined. And I can’t find any other usage of IFN_VCOND_MASK_LEN creation to figure out what it’s supposed to be  is it just an SImode 0? Thanks, Tamar From: juzhe.zh...@rivai.ai Sent: Thursday, November 30, 2023 11:49 AM To: Tamar Christina ; gcc-patches Cc

RE: [PATCH 9/21]middle-end: implement vectorizable_early_exit for codegen of exit code

to do for vectorizable_live_operations how to get the first element rather than the last. Thanks, Tamar From: juzhe.zh...@rivai.ai Sent: Thursday, November 30, 2023 4:48 AM To: gcc-patches Cc: Richard Biener ; Tamar Christina Subject: [PATCH 9/21]middle-end: implement vectorizable_early_exit

RE: [PATCH 8/21]middle-end: update vectorizable_live_reduction with support for multiple exits and different exits

> -Original Message- > From: Richard Biener > Sent: Wednesday, November 29, 2023 2:29 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com > Subject: RE: [PATCH 8/21]middle-end: update vectorizable_live_reduction > with suppo

RE: [PATCH 9/21]middle-end: implement vectorizable_early_exit for codegen of exit code

Ping > -Original Message- > From: Tamar Christina > Sent: Monday, November 6, 2023 7:40 AM > To: gcc-patches@gcc.gnu.org > Cc: nd ; rguent...@suse.de; j...@ventanamicro.com > Subject: [PATCH 9/21]middle-end: implement vectorizable_early_exit for > codegen of

RE: [PATCH 10/21]middle-end: implement relevancy analysis support for control flow

Ping > -Original Message- > From: Tamar Christina > Sent: Monday, November 6, 2023 7:40 AM > To: gcc-patches@gcc.gnu.org > Cc: nd ; rguent...@suse.de; j...@ventanamicro.com > Subject: [PATCH 10/21]middle-end: implement relevancy analysis support for > con

RE: [PATCH 12/21]middle-end: Add remaining changes to peeling and vectorizer to support early breaks

Ping > -Original Message- > From: Tamar Christina > Sent: Monday, November 6, 2023 7:41 AM > To: gcc-patches@gcc.gnu.org > Cc: nd ; rguent...@suse.de; j...@ventanamicro.com > Subject: [PATCH 12/21]middle-end: Add remaining changes to peeling and > vectorizer to

RE: [PATCH 13/21]middle-end: Update loop form analysis to support early break

Ping > -Original Message- > From: Tamar Christina > Sent: Monday, November 6, 2023 7:41 AM > To: gcc-patches@gcc.gnu.org > Cc: nd ; rguent...@suse.de; j...@ventanamicro.com > Subject: [PATCH 13/21]middle-end: Update loop form analysis to support > early break >

RE: [PATCH 8/21]middle-end: update vectorizable_live_reduction with support for multiple exits and different exits

> > > This is a respun patch with a fix for VLA. > > > > This adds support to vectorizable_live_reduction to handle multiple > > exits by doing a search for which exit the live value should be > > materialized in. > > > > Additionally which value in the index we're after depends on whether > >

[PATCH]middle-end: refactor vectorizable_live_operation into helper method for codegen

Hi All, To make code review of the updates to add multiple exit supports to vectorizable_live_operation easier I've extracted the refactoring part to its own patch. This patch is a straight extract of the function with no functional changes. Bootstrapped Regtested on aarch64-none-linux-gnu and

[PATCH]middle-end: prevent LIM from hoising vector compares from gconds if target does not support it.

Hi All, LIM notices that in some cases the condition and the results are loop invariant and tries to move them out of the loop. While the resulting code is operationally sound, moving the compare out of the gcond results in generating code that no longer branches, so cbranch is no longer

RE: [PATCH] rs6000: Canonicalize copysign (x, -1) back to -abs (x) in the backend [PR112606]

> -Original Message- > From: Jakub Jelinek > Sent: Monday, November 27, 2023 8:13 AM > To: Tamar Christina > Cc: Xi Ruoyao ; Segher Boessenkool > ; David Edelsohn ; gcc- > patc...@gcc.gnu.org; Andrew Pinski > Subject: Re: [PATCH] rs6000: Canonicalize copysign

RE: [PATCH] rs6000: Canonicalize copysign (x, -1) back to -abs (x) in the backend [PR112606]

> On Sat, Nov 25, 2023 at 12:03:56PM +0000, Tamar Christina wrote: > > For the C99 versions of copysign, expand_COPYSIGN has optimized > expansions inplace. > > One of the hooks there forces it to abs/neg. There is also code in > > place for if the target prefers integer

RE: [PATCH] rs6000: Canonicalize copysign (x, -1) back to -abs (x) in the backend [PR112606]

> -Original Message- > From: Xi Ruoyao > Sent: Saturday, November 25, 2023 10:43 AM > To: Jakub Jelinek ; Segher Boessenkool > ; David Edelsohn > Cc: gcc-patches@gcc.gnu.org; Tamar Christina ; > Andrew Pinski > Subject: Re: [PATCH] rs6000: Canonicalize copysign

RE: [PATCH 8/21]middle-end: update vectorizable_live_reduction with support for multiple exits and different exits

Good morning, This is a respun patch with a fix for VLA. This adds support to vectorizable_live_reduction to handle multiple exits by doing a search for which exit the live value should be materialized in. Additionally which value in the index we're after depends on whether the exit it's

RE: [PATCH 7/21]middle-end: update IV update code to support early breaks and arbitrary exits

Hi, Having simplified peeling this patch becomes smaller as well: This changes the PHI node updates to support early breaks. It has to support both the case where the loop's exit matches the normal loop exit and one where the early exit is "inverted", i.e. it's an early exit edge. In the latter

RE: [PATCH 4/21]middle-end: update loop peeling code to maintain LCSSA form for early breaks

Hi All, Here's an updated patch, which takes a slightly different approach but makes things much easier later on. Peeling for early breaks works by redirecting all early break exits to a single "early break" block and combine them and the normal exit edge together later in a different block

[PATCH]AArch64: fix aarch64_usubw pattern

Hi All, It looks like during my pre-commit testrun I forgot to apply this patch to the patch stack. It had a typo in the element size. It also looks like since the hi/lo operations take different element counts for the assembler syntax that I can't have a unified pattern. This splits it into

RE: [PATCH] aarch64: Add support for Ampere-1B (-mcpu=ampere1b) CPU

Hi Philipp, Could you rebase this patch on top of master please. Essentially we put each tuning model in its own file now. Thanks, Tamar > -Original Message- > From: Philipp Tomsich > Sent: Thursday, November 16, 2023 6:16 AM > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov ;

RE: [PATCH]AArch64 docs: update -mcpu=generic definition on aarch64

> -Original Message- > From: Richard Biener > Sent: Tuesday, November 21, 2023 9:41 AM > To: Richard Earnshaw > Cc: Tamar Christina ; gcc-patches@gcc.gnu.org; > nd ; Richard Earnshaw ; > Marcus Shawcroft ; Kyrylo Tkachov > ; Richard Sandiford > > Subject: R

RE: [PATCH]AArch64 docs: update -mcpu=generic definition on aarch64

> > On 20/11/2023 21:49, Tamar Christina wrote: > >> -Original Message- > >> From: Richard Earnshaw > >> Sent: Monday, November 20, 2023 12:53 PM > >> To: Tamar Christina ; > >> gcc-patches@gcc.gnu.org > >> Cc: nd ; Richard Earn

RE: [PATCH 8/21]middle-end: update vectorizable_live_reduction with support for multiple exits and different exits

Good morning, Here's the respun patch, as discussed we now use reductions and inductions rather than scalar values: This adds support to vectorizable_live_reduction to handle multiple exits by doing a search for which exit the live value should be materialized in. Additinally which value in

RE: [PATCH 7/21]middle-end: update IV update code to support early breaks and arbitrary exits

> > > > Ok, so I currently have the following solution. Let me know if you > > agree with it and I'll polish it up today and tomorrow and respin things. > > > > 1. During vect_update_ivs_after_vectorizer we no longer touch any PHIs > aside from > > Just updating IVtemps with the expected

RE: [PATCH 4/21]middle-end: update loop peeling code to maintain LCSSA form for early breaks

Hi All, Here's the respun patch: This splits the part of the function that does peeling for loops at exits to a different function. In this new function we also peel for early breaks. Peeling for early breaks works by redirecting all early break exits to a single "early break" block and

RE: [PATCH]AArch64 docs: update -mcpu=generic definition on aarch64

> -Original Message- > From: Richard Earnshaw > Sent: Monday, November 20, 2023 12:53 PM > To: Tamar Christina ; gcc-patches@gcc.gnu.org > Cc: nd ; Richard Earnshaw ; > Marcus Shawcroft ; Kyrylo Tkachov > ; Richard Sandiford > > Subject: Re: [PATCH]AArch64

RE: [PATCH 7/21]middle-end: update IV update code to support early breaks and arbitrary exits

> > > > > Yes, but that only works for the inductions marked so. We'd > > > > > need to mark the others as well, but only for the early exits. > > > > > > > > > > > although I don't understand why we use the scalar count, I > > > > > > suppose the reasoning is that we don't really want to keep

RE: [PATCH 7/21]middle-end: update IV update code to support early breaks and arbitrary exits

> -Original Message- > From: Tamar Christina > Sent: Thursday, November 16, 2023 3:19 PM > To: Richard Biener > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com > Subject: RE: [PATCH 7/21]middle-end: update IV update code to support early > break

[PATCH]AArch64 docs: update -mcpu=generic definition on aarch64

Hi All, This documents the behavior of the generic CPU options on AArch64. Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. Ok for master? Thanks, Tamar gcc/ChangeLog: * doc/invoke.texi (generic): Update defintion. (generic-armv8-a, generic-armv9-a): Document.

RE: [PATCH 7/21]middle-end: update IV update code to support early breaks and arbitrary exits

> -Original Message- > From: Richard Biener > Sent: Thursday, November 16, 2023 2:18 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com > Subject: RE: [PATCH 7/21]middle-end: update IV update code to support early > breaks and arbitr

RE: [PATCH 7/21]middle-end: update IV update code to support early breaks and arbitrary exits

> -Original Message- > From: Richard Biener > Sent: Thursday, November 16, 2023 1:36 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com > Subject: RE: [PATCH 7/21]middle-end: update IV update code to support early > breaks and arbitr

RE: [PATCH 7/21]middle-end: update IV update code to support early breaks and arbitrary exits

> > > > > > > > > > > > Perhaps I'm missing something here? > > > > > > > > > > OK, so I refreshed my mind of what > > > > > vect_update_ivs_after_vectorizer > > > does. > > > > > > > > > > I still do not understand the (complexity of the) patch. > > > > > Basically the function computes the new

RE: [PATCH 7/21]middle-end: update IV update code to support early breaks and arbitrary exits

> -Original Message- > From: Richard Biener > Sent: Thursday, November 16, 2023 11:28 AM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com > Subject: RE: [PATCH 7/21]middle-end: update IV update code to support early > breaks and arbitr

RE: [PATCH 7/21]middle-end: update IV update code to support early breaks and arbitrary exits

> -Original Message- > From: Richard Biener > Sent: Thursday, November 16, 2023 10:40 AM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com > Subject: RE: [PATCH 7/21]middle-end: update IV update code to support early > breaks and arbitr

RE: [PATCH 6/6]AArch64: only emit mismatch error when features would be disabled.

> -Original Message- > From: Richard Earnshaw > Sent: Thursday, November 16, 2023 9:42 AM > To: Tamar Christina ; gcc-patches@gcc.gnu.org > Cc: nd ; Richard Earnshaw ; > Marcus Shawcroft ; Kyrylo Tkachov > ; Richard Sandiford > > Subject: Re: [PATCH 6/6]AArch6

RE: [PATCH 6/6]AArch64: only emit mismatch error when features would be disabled.

> -Original Message- > From: Richard Earnshaw > Sent: Thursday, November 16, 2023 9:27 AM > To: Tamar Christina ; gcc-patches@gcc.gnu.org > Cc: nd ; Richard Earnshaw ; > Marcus Shawcroft ; Kyrylo Tkachov > ; Richard Sandiford > > Subject: Re: [PATCH 6/6]AArch6

[PATCH 4/6]AArch64: Add new generic-armv9-a CPU and make it the default for Armv9

Hi All, This patch adds a new generic scheduling model "generic-armv9-a" and makes it the default for all Armv9 architectures. -mcpu=generic and -mtune=generic is kept around for those that really want the deprecated cost model. Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.

[PATCH 6/6]AArch64: only emit mismatch error when features would be disabled.

Hi All, At the moment we emit a warning whenever you specify both -march and -mcpu and the architecture of them differ. The idea originally was that the user may not be aware of this change. However this has a few problems: 1. Architecture revisions is not an observable part of the

[PATCH 3/6]AArch64: Add new generic-armv8-a CPU and make it the default.

Hi All, This patch adds a new generic scheduling model "generic-armv8-a" and makes it the default for all Armv8 architectures. -mcpu=generic and -mtune=generic is kept around for those that really want the deprecated cost model. This shows on SPECCPU 2017 the following: generic: SPECINT 1.0%

[PATCH 2/6]AArch64: Remove special handling of generic cpu.

Hi All, In anticipation of adding new generic turning values this removes the hardcoding of the "generic" CPU and instead just specifies it as a normal CPU. No change in behavior is expected. Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. Ok for master? Thanks, Tamar

[PATCH]AArch64: only discount MLA for vector and scalar statements

Hi All, In testcases gcc.dg/tree-ssa/slsr-19.c and gcc.dg/tree-ssa/slsr-20.c we have a fairly simple computation. On the current generic costing we generate: f: add w0, w0, 2 maddw1, w0, w1, w1 lsl w0, w1, 1 ret but on any other cost model but

[PATCH]AArch64 Add pattern for unsigned widenings (uxtl) to zip{1,2}

Hi All, This changes unpack instructions to use zip{1,2} when doing a zero-extending widening operation. Permutes generally have a higher throughput than the widening operations. Zeros are shuffled into the top half of the registers. The testcase void d2 (unsigned * restrict a, unsigned short

[PATCH]middle-end: skip checking loop exits if loop malformed [PR111878]

Hi All, Before my refactoring if the loop->latch was incorrect then find_loop_location skipped checking the edges and would eventually return a dummy location. It turns out that a loop can have loops_state_satisfies_p (LOOPS_HAVE_RECORDED_EXITS) but also not have a latch in which case

RE: [PATCH 8/21]middle-end: update vectorizable_live_reduction with support for multiple exits and different exits

> -Original Message- > From: Richard Biener > Sent: Wednesday, November 15, 2023 1:42 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com > Subject: RE: [PATCH 8/21]middle-end: update vectorizable_live_reduction > with suppo

RE: [PATCH 7/21]middle-end: update IV update code to support early breaks and arbitrary exits

> -Original Message- > From: Richard Biener > Sent: Wednesday, November 15, 2023 1:23 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com > Subject: RE: [PATCH 7/21]middle-end: update IV update code to support early > breaks and arbitr

RE: [PATCH 7/21]middle-end: update IV update code to support early breaks and arbitrary exits

> -Original Message- > From: Richard Biener > Sent: Wednesday, November 15, 2023 1:01 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com > Subject: RE: [PATCH 7/21]middle-end: update IV update code to support early > breaks and arbitr

RE: [PATCH 8/21]middle-end: update vectorizable_live_reduction with support for multiple exits and different exits

Patch updated to trunk. This adds support to vectorizable_live_reduction to handle multiple exits by doing a search for which exit the live value should be materialized in. Additinally which value in the index we're after depends on whether the exit it's materialized in is an early exit or

RE: [PATCH 7/21]middle-end: update IV update code to support early breaks and arbitrary exits

Patch updated to latest trunk: Hi All, This changes the PHI node updates to support early breaks. It has to support both the case where the loop's exit matches the normal loop exit and one where the early exit is "inverted", i.e. it's an early exit edge. In the latter case we must always

RE: [PATCH 4/21]middle-end: update loop peeling code to maintain LCSSA form for early breaks

Patch updated to latest trunk, This splits the part of the function that does peeling for loops at exits to a different function. In this new function we also peel for early breaks. Peeling for early breaks works by redirecting all early break exits to a single "early break" block and combine

RE: [PATCH 5/21]middle-end: update vectorizer's control update to support picking an exit other than loop latch

> > OK, but then I think the fix is to not use > > standard_iv_increment_position (it's a weird API anyway). Instead insert > before the main exit condition. > > I figured as much, Almost done respinning it with the vectorizer's own simpler > copy. > Should be out today with the rest. > > > > >

RE: [PATCH 5/21]middle-end: update vectorizer's control update to support picking an exit other than loop latch

> -Original Message- > From: Richard Biener > Sent: Tuesday, November 14, 2023 7:56 AM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com > Subject: RE: [PATCH 5/21]middle-end: update vectorizer's control update to > support picking an

RE: [PATCH 5/21]middle-end: update vectorizer's control update to support picking an exit other than loop latch

> -Original Message- > From: Richard Biener > Sent: Tuesday, November 7, 2023 3:04 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com > Subject: Re: [PATCH 5/21]middle-end: update vectorizer's control update to > support picking an

RE: [PATCH v3 2/2]middle-end match.pd: optimize fneg (fabs (x)) to copysign (x, -1) [PR109154]

> -Original Message- > From: Richard Biener > Sent: Monday, November 13, 2023 7:09 AM > To: Andrew Pinski > Cc: Tamar Christina ; Prathamesh Kulkarni > ; gcc-patches@gcc.gnu.org; nd > ; j...@ventanamicro.com > Subject: Re: [PATCH v3 2/2]middle-end match.pd

RE: [PATCH] Fix (fcopysign x, NEGATIVE_CONST) -> (fneg (fabs x)) simplification [PR112483]

> -Original Message- > From: Richard Biener > Sent: Monday, November 13, 2023 6:55 AM > To: Xi Ruoyao > Cc: gcc-patches@gcc.gnu.org; chenglulu ; > i...@xen0n.name; xucheng...@loongson.cn; Tamar Christina > ; tschwi...@gcc.gnu.org; Roger Sayle > > Subject: R

<    1   2   3   4   5   6   7   8   9   10   >