> -Original Message-
> From: Pengfei Li
> Sent: Friday, August 8, 2025 11:00 AM
> To: Kyrylo Tkachov
> Cc: gcc-patches@gcc.gnu.org; Richard Sandiford ;
> Tamar Christina
> Subject: [PATCH v2] AArch64: Fix invalid immediate offsets in SVE
> gather/scatter
&g
> -Original Message-
> From: Richard Sandiford
> Sent: Friday, August 8, 2025 11:40 AM
> To: Richard Henderson
> Cc: gcc-patches@gcc.gnu.org; Karl Meakin ;
> pins...@gmail.com; Wilco Dijkstra ; Tamar Christina
>
> Subject: Re: [PATCH v2 05/1
, 2025 4:13 PM
> To: GCC Patches
> Cc: Alex Coplan ; Andrew Pinski ;
> Richard Earnshaw ; Richard Sandiford
> ; Kyrylo Tkachov ; Tamar
> Christina
> Subject: [PATCH 2/3] AArch64: Implement target hooks for dispatch scheduling.
>
> This patch adds dispatch scheduling fo
> -Original Message-
> From: Richard Biener
> Sent: Friday, August 1, 2025 6:06 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH 2/2] Put SLP_TREE_SIMD_CLONE_INFO into type specifc data
>
>
>
> > Am 31.07.2025
> -Original Message-
> From: Richard Biener
> Sent: Thursday, July 31, 2025 3:09 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Tamar Christina
> Subject: [PATCH 2/2] Put SLP_TREE_SIMD_CLONE_INFO into type specifc data
>
> The following adds vect_simd_clone_data as a c
> -Original Message-
> From: Kyrylo Tkachov
> Sent: Thursday, July 31, 2025 3:47 PM
> To: Jennifer Schmitz
> Cc: GCC Patches ; Andrew Pinski
> ; Richard Earnshaw ; Richard
> Sandiford ; Tamar Christina
> ; Alex Coplan
> Subject: Re: [PATCH 3/3] AArch64: Ena
ourse with a vla epilogue we skip it again.
Cheers,
Tamar
From: Richard Biener
Sent: Thursday, July 31, 2025 1:30 PM
To: Tamar Christina
Cc: gcc-patches@gcc.gnu.org ; nd
Subject: Re: [PATCH][vect] Don't set bogus bounds on epilogues [PR120805]
On Thu, Jul 3
Hi All,
The testcases in the PR are failing due to the code trying to set a vector range
on an epilogue.
However on epilogues the range doesn't make sense. In particular we are setting
ranged to help niters analysis. But the epilogue doesn't iterate.
Secondly the bounds variable hasn't been adj
> -Original Message-
> From: Richard Biener
> Sent: Thursday, July 31, 2025 12:27 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Tamar Christina
> Subject: [PATCH] Add checks for node in aarch64 vector cost modeling
>
> After removing STMT_VINFO_MEMORY_ACCESS_TYPE we no
> -Original Message-
> From: Tamar Christina
> Sent: Thursday, July 31, 2025 7:41 AM
> To: Richard Biener ; gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH 2/2] Put SLP_TREE_SIMD_CLONE_INFO into type specifc data
>
> > -Original Message-
> >
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, July 30, 2025 12:17 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Tamar Christina
> Subject: [PATCH 2/2] Put SLP_TREE_SIMD_CLONE_INFO into type specifc data
>
> The following adds vect_simd_clone_data as a c
> -Original Message-
> From: Richard Biener
> Sent: Monday, July 28, 2025 2:28 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Sandiford ; Tamar Christina
>
> Subject: [PATCH] Record get_load_store_info results from analysis
>
> The following is a prototy
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, July 29, 2025 1:43 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Alex Coplan ; Alice Carlotti
> ;
> pins...@gmail.com; ktkac...@nvidia.com; Richard Earnshaw
> ; Tamar Christina ;
> Wilco Dijkstra
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, July 29, 2025 5:20 PM
> To: Alex Coplan ; Alice Carlotti
> ;
> pins...@gmail.com; ktkac...@nvidia.com; Richard Earnshaw
> ; Tamar Christina ;
> Wilco Dijkstra ; gcc-patches@gcc.gnu.org
> Cc: R
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, July 29, 2025 5:20 PM
> To: Alex Coplan ; Alice Carlotti
> ;
> pins...@gmail.com; ktkac...@nvidia.com; Richard Earnshaw
> ; Tamar Christina ;
> Wilco Dijkstra ; gcc-patches@gcc.gnu.org
> Cc: R
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, July 29, 2025 4:33 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Alex Coplan ; Alice Carlotti
> ;
> pins...@gmail.com; ktkac...@nvidia.com; Richard Earnshaw
> ; Tamar Christina ;
> Wilco Dijkstra
>
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, July 29, 2025 1:08 PM
> To: Pengfei Li
> Cc: Tamar Christina ; Richard Biener
> ; gcc-patches@gcc.gnu.org; s...@gentoo.org
> Subject: Re: [PATCH] vect: Fix insufficient alignment requirement for
> specu
> -Original Message-
> From: Pengfei Li
> Sent: Tuesday, July 29, 2025 12:10 PM
> To: Richard Biener
> Cc: Tamar Christina ; Richard Biener
> ; gcc-patches@gcc.gnu.org; s...@gentoo.org
> Subject: Re: [PATCH] vect: Fix insufficient alignment requirement for
> -Original Message-
> From: Pengfei Li
> Sent: Tuesday, July 29, 2025 10:17 AM
> To: Richard Biener ; Tamar Christina
>
> Cc: gcc-patches@gcc.gnu.org; rguent...@suse.de; s...@gentoo.org
> Subject: Re: [PATCH] vect: Fix insufficient alignment requirement for
Hi Yury,
> -Original Message-
> From: Yury Khrustalev
> Sent: Wednesday, July 23, 2025 9:45 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Andrew Pinski ; Richard Sandiford
> ; Tamar Christina ;
> Alfie Richards ; Alice Carlotti
> ;
> Victor Do Nascimento
> Sub
Hi Yury,
> -Original Message-
> From: Yury Khrustalev
> Sent: Wednesday, July 23, 2025 9:45 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Andrew Pinski ; Richard Sandiford
> ; Tamar Christina ;
> Alfie Richards ; Alice Carlotti
> ;
> Victor Do Nascimento
> Sub
> -Original Message-
> From: Yury Khrustalev
> Sent: Wednesday, July 23, 2025 9:45 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Andrew Pinski ; Richard Sandiford
> ; Tamar Christina ;
> Alfie Richards ; Alice Carlotti
> ;
> Victor Do Nascimento
> Subject: [PAT
> -Original Message-
> From: Pengfei Li
> Sent: Monday, July 21, 2025 12:07 PM
> To: gcc-patches@gcc.gnu.org
> Cc: rguent...@suse.de; s...@gentoo.org; Tamar Christina
> ; Pengfei Li
> Subject: [PATCH] vect: Add missing skip-vector check for peeling with
>
Hi Pengfei,
> -Original Message-
> From: Pengfei Li
> Sent: Monday, July 21, 2025 12:03 PM
> To: gcc-patches@gcc.gnu.org
> Cc: rguent...@suse.de; s...@gentoo.org; Tamar Christina
> ; Pengfei Li
> Subject: [PATCH] vect: Fix insufficient alignment requirement for
> -Original Message-
> From: Kyrylo Tkachov
> Sent: Monday, July 21, 2025 11:36 AM
> To: Tamar Christina
> Cc: GCC Patches ; Richard Sandiford
> ; Andrew Pinski ; Alex Coplan
> ; Remi Machet ; Jennifer Schmitz
>
> Subject: Re: [PATCH 2/2] aarch64: Allow CPU
Hi Kyrill,
> -Original Message-
> From: Kyrylo Tkachov
> Sent: Friday, July 18, 2025 10:40 AM
> To: GCC Patches
> Cc: Tamar Christina ; Richard Sandiford
> ; Andrew Pinski ; Alex Coplan
>
> Subject: [PATCH 2/2] aarch64: Allow CPU tuning to avoid INS-(W|X)ZR
&g
> -Original Message-
> From: Richard Biener
> Sent: Friday, July 18, 2025 1:09 PM
> To: gcc-patches@gcc.gnu.org
> Cc: seg...@kernel.crashing.org; Jan Hubicka ; Richard
> Sandiford
> ; Tamar Christina ;
> rdapp@gmail.com; j...@ventanamicro.com
>
> -Original Message-
> From: Kyrylo Tkachov
> Sent: Friday, July 18, 2025 5:48 PM
> To: Tamar Christina
> Cc: GCC Patches ; Richard Sandiford
> ; Alex Coplan ; Andrew
> Pinski
> Subject: Re: [PATCH 1/2] aarch64: NFC - Make vec_* rtx costing logic
> consiste
Hi Kyrill,
> -Original Message-
> From: Kyrylo Tkachov
> Sent: Friday, July 18, 2025 10:40 AM
> To: GCC Patches
> Cc: Tamar Christina ; Richard Sandiford
> ; Alex Coplan ; Andrew
> Pinski
> Subject: [PATCH 1/2] aarch64: NFC - Make vec_* rtx costing logi
> -Original Message-
> From: Yury Khrustalev
> Sent: Wednesday, July 16, 2025 1:14 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Sandiford ; Tamar Christina
> ; Mark Rutland
> Subject: [PATCH v2] aarch64: Adapt unwinder to linux's SME signal behaviour
&g
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, July 15, 2025 9:41 AM
> To: Tamar Christina
> Cc: Yury Khrustalev ; gcc-patches@gcc.gnu.org; Mark
> Rutland
> Subject: Re: [PATCH 1/1] aarch64: Adapt unwinder to linux's SME signal
> behaviour
Hi Yury,
This looks in general OK to me (Thanks for the clear comments!), but had some
questions:
> -Original Message-
> From: Yury Khrustalev
> Sent: Thursday, June 19, 2025 2:40 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Sandiford ; Mark Rutland
>
> Subject: [PATCH 1/1] aarch64:
> -Original Message-
> From: Richard Sandiford
> Sent: Friday, July 11, 2025 4:23 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Alex Coplan ; Alice Carlotti
> ;
> pins...@gmail.com; ktkac...@nvidia.com; Richard Earnshaw
> ; Tamar Christina ;
> Wilco Dijkstra
> S
> -Original Message-
> From: Richard Biener
> Sent: Thursday, July 10, 2025 6:42 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; Richard Sandiford ;
> CI RISC-V
> Subject: Re: [PATCH] Reject single lane vector types for SLP build
>
>
>
> >
> -Original Message-
> From: Richard Biener
> Sent: Thursday, July 10, 2025 3:09 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; Richard Sandiford ;
> RISC-V CI
> Subject: RE: [PATCH] Reject single lane vector types for SLP build
>
> On Thu, 10 Jul
> -Original Message-
> From: Richard Biener
> Sent: Thursday, July 10, 2025 1:31 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Sandiford ; Tamar Christina
> ; RISC-V CI
> Subject: [PATCH] Reject single lane vector types for SLP build
>
> The following makes
tors?
This would mean though that all target checks needs to be updated unless we
update the supports checks with a helper?
Thanks,
Tamar
From: Richard Biener
Sent: Wednesday, July 9, 2025 1:24 PM
To: Tamar Christina
Cc: gcc-patches@gcc.gnu.org ; nd
Subject: RE:
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, July 9, 2025 12:36 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: RE: [PATCH 1/3]middle-end: support vec_cbranch_any and
> vec_cbranch_all [PR118974]
>
> On Wed, 9 Jul
> > +Operand 0 is a comparison operator. Operand 1 and operand 2 are the
> > +first and second operands of the comparison, respectively. Operand 3
> > +is the @code{code_label} to jump to.
> > +
> > +@cindex @code{cbranch_all@var{mode}4} instruction pattern
> > +@item @samp{cbranch_all@var{mode}4
Before the change in g:309dbcea2cabb31bde1a65cdfd30bb7f87b170a2 we would never
set a range for constant VF and requires partial vector loops.
I think a range could be set, since I think the number of latch executions is a
ceiling division of TYPE_MAX_VALUE / vf. To account for the partial iteratio
This patch adds support for niters ranges for partial
vector loops.
Due to the last iteration being partial the bounds should
be at least 1 but niters // vf as the max.
Bootstrapped Regtested on aarch64-none-linux-gnu,
arm-none-linux-gnueabihf, x86_64-pc-linux-gnu
-m32, -m64 and no issues.
Teste
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, July 8, 2025 10:07 AM
> To: Tamar Christina
> Cc: Kyrylo Tkachov ; GCC Patches patc...@gcc.gnu.org>; Richard Earnshaw ; Alex
> Coplan ; Andrew Pinski
> Subject: Re: [PATCH 3/7] aarch64: Handl
> -Original Message-
> From: Kyrylo Tkachov
> Sent: Monday, July 7, 2025 11:19 AM
> To: GCC Patches
> Cc: Richard Sandiford ; Richard Earnshaw
> ; Alex Coplan ; Andrew
> Pinski
> Subject: [PATCH 4/7] aarch64: Use EOR3 for DImode values
>
> Hi all,
>
> Similar to BCAX, we can use EOR3 f
> -Original Message-
> From: Remi Machet
> Sent: Monday, July 7, 2025 5:53 PM
> To: Kyrylo Tkachov ; GCC Patches patc...@gcc.gnu.org>
> Cc: Richard Sandiford ; Richard Earnshaw
> ; Alex Coplan ; Andrew
> Pinski
> Subject: Re: [PATCH 4/7] aarch64: Use EOR3 for DImode values
>
> On 7/7/25
> -Original Message-
> From: Richard Sandiford
> Sent: Monday, July 7, 2025 12:55 PM
> To: Kyrylo Tkachov
> Cc: GCC Patches ; Richard Earnshaw
> ; Alex Coplan ; Andrew
> Pinski
> Subject: Re: [PATCH 3/7] aarch64: Handle DImode BCAX operations
>
> Richard Sandiford writes:
> > Kyrylo Tk
Drop down from SVE2 to SVE1 as that's the minimum
required for the test, and since it's a mid-end test
add the aarch64_sve_hw check.
Regtested on aarch64-none-linux-gnu and no issues.
committed to master.
Thanks,
Tamar
gcc/testsuite/ChangeLog:
PR tree-optimization/120817
* gcc.
> -Original Message-
> From: Richard Biener
> Sent: Monday, July 7, 2025 12:30 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Tamar Christina
> Subject: [PATCH] tree-optimization/120817 - bogus DSE of .MASK_STORE
>
> DSE used ao_ref_init_from_ptr_and_size for .MASK_ST
> -Original Message-
> From: Kyrylo Tkachov
> Sent: Monday, July 7, 2025 11:16 AM
> To: GCC Patches
> Cc: Richard Earnshaw ; Richard Sandiford
> ; Alex Coplan ; Andrew
> Pinski
> Subject: [PATCH 1/7] aarch64: Allow 64-bit vector modes in pattern for BCAX
> instruction
>
> Hi all,
>
> T
> -Original Message-
> From: Kyrylo Tkachov
> Sent: Monday, July 7, 2025 10:38 AM
> To: GCC Patches
> Cc: Richard Sandiford ; Richard Earnshaw
> ; Alex Coplan ; Andrew
> Pinski
> Subject: [PATCH] aarch64: Improve popcountti2 with SVE
>
> Hi all,
>
> The TImode popcount sequence can be
100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -57,6 +57,7 @@ docs, and the testsuite related to that.
aarch64 ldp/stp Alex Coplan
aarch64 portRichard Earnshaw
aarch64 portRichard Sandiford
+aarch64 portTamar Christina
> -Original Message-
> From: Richard Biener
> Sent: Friday, July 4, 2025 10:42 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Sandiford ; Tamar Christina
>
> Subject: [PATCH 1/2] Allow the target to request a masked vector epilogue
>
> Targets recently got
ping
> -Original Message-
> From: Tamar Christina
> Sent: Monday, June 23, 2025 7:01 AM
> To: Tamar Christina ; Richard Biener
>
> Cc: gcc-patches@gcc.gnu.org; Richard Sandiford ;
> nd
> Subject: RE: [PATCH 1/3]middle-end: support vec_cbranch_any and
>
This fixes a small typo in the Label attributes docs.
Committed as obvious.
Thanks,
Tamar
gcc/ChangeLog:
* doc/extend.texi: Fix typo in unsed attribute docs.
---
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index
69c6512074642ece47f1f9a3d7bdde20ec800d40..6e80ef8a2055c2015973
store_bit_field_1 has an optimization where if a target is not a memory operand
and the entire value is being set from something larger we can just wrap a
subreg around the source and emit a move.
For vector constructors this is however problematic because the subreg means
that the expansion of th
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, June 24, 2025 9:58 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Sandiford
>
> Subject: Re: [PATCH]middle-end: Fix store_bit_field expansions of vector
> constructors [PR120718]
ping
> -Original Message-
> From: Tamar Christina
> Sent: Tuesday, June 10, 2025 4:19 PM
> To: Richard Biener
> Cc: gcc-patches@gcc.gnu.org; Richard Sandiford ;
> nd
> Subject: RE: [PATCH 1/3]middle-end: support vec_cbranch_any and
> vec_cbranch_all [PR1189
Consider the loop
void f1 (int *restrict a, int n)
{
#pragma GCC unroll 4 requested
for (int i = 0; i < n; i++)
a[i] *= 2;
}
Which today is vectorized and then unrolled 3x by the RTL unroller due to the
use of the pragma. This is unfortunate because the pragma was intended for the
scalar l
This patch fixes a bug where the current code assumed that exact_log2 returns
NULL on failure, but it instead returns -1. So there are some cases where the
right shift could shift out the entire value.
Secondly it also removes the requirement that VF be a power of two. With an
uneven unroll fact
; The optab allows us to avoid this by just emitting the SVE commit directly,
> > and
> > completely avoid the AND by generating a predicated compare.
> >
> > So I am trying to fix some of the optimization in RTL, but for some cases
> expanding
> > correctly is
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, June 10, 2025 2:12 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; Richard Sandiford ;
> nd
> Subject: RE: [PATCH 1/3]middle-end: support vec_cbranch_any and
> vec_cbranch_all [PR118974]
>
> -Original Message-
> From: Richard Sandiford
> Sent: Monday, June 9, 2025 2:13 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; ktkac...@gcc.gnu.org
> Subject: Re: [PATCH 2/3]AArch64: Support eliding ptest on masked compares
>
> -Original Message-
> From: Richard Biener
> Sent: Monday, June 9, 2025 10:30 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; Richard Sandiford ;
> nd
> Subject: Re: [PATCH 1/3]middle-end: support vec_cbranch_any and
> vec_cbranch_all [PR118974]
>
> >> +param value will be used.
> >> +
> >> @opindex march
> >> @item -march=@var{name}
> >> Specify the name of the target architecture and, optionally, one or
> >
> > --params are supposed to be internal developer flags that could go away
> > at any time. So now that we have the user-facing flag
The following example:
#define N 640
int a[N] = {};
int b[N] = {};
int c[N] = {};
void f1 (int d)
{
for (int i = 0; i < N; i++)
{
b[i] += a[i];
if (a[i] != d)
break;
}
}
today generates with
-Ofast -march=armv8-a+sve --param aarch64-autovec-preference=asimd-only
.L
In the example
void f1 ()
{
for (int i = 0; i < N; i++)
{
b[i] += a[i];
if (a[i] > 0)
break;
}
}
when compiled for SVE we generate:
ld1wz28.s, p7/z, [x4, x0, lsl 2]
cmpgt p14.s, p7/z, z28.s, #0
ptest p15, p14.b
b.none .L3
Wh
This patch introduces two new vector cbranch optabs vec_cbranch_any and
vec_cbranch_all.
To explain why we need two new optabs let me explain the current cbranch and its
limitations and what I'm trying to optimize. So sorry for the long email, but I
hope it explains why I think we want new optabs.
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, June 4, 2025 10:43 AM
> To: Richard Sandiford
> Cc: Tamar Christina ; Richard Biener
> ; Pengfei Li ; gcc-
> patc...@gcc.gnu.org; ktkac...@nvidia.com
> Subject: Re: [PATCH] vect: Improve vectorizat
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, June 4, 2025 8:34 AM
> To: Tamar Christina
> Cc: Richard Biener ; Richard Sandiford
> ; Pengfei Li ; gcc-
> patc...@gcc.gnu.org; ktkac...@nvidia.com
> Subject: RE: [PATCH] vect: Improve vectorizat
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, June 4, 2025 8:04 AM
> To: Tamar Christina
> Cc: Richard Biener ; Richard Sandiford
> ; Pengfei Li ; gcc-
> patc...@gcc.gnu.org; ktkac...@nvidia.com
> Subject: RE: [PATCH] vect: Improve vectorizat
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, June 3, 2025 2:12 PM
> To: Tamar Christina
> Cc: Richard Biener ; Richard Sandiford
> ; Pengfei Li ; gcc-
> patc...@gcc.gnu.org; ktkac...@nvidia.com
> Subject: Re: [PATCH] vect: Improve vectorization fo
Hi All,
With the middle-end providing a way to make vectorization more profitable by
scaling vect-scalar-cost-multiplier this makes a more user friendly option
to make it easier to use.
I propose making it an actual -m option that we document and retain vs using
the parameter name. In the future
The documentation for outline atomics is missing the entry for
-mno-outline-atomics which this patch adds.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
* doc/extend.texi (outline-atomics): Document the inverse -mno flag.
-
As requested in my patch for -mmax-vectorization this promotes the parameter
--param aarch64-autovec-preference to a first class top target flag.
If both the parameter and the flag is specified the parameter takes precedence
with the reasoning that it may already be embedded in build systems.
Boo
> -Original Message-
> From: Richard Biener
> Sent: Monday, May 26, 2025 2:56 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: RE: [PATCH 1/2]middle-end: Apply loop->unroll directly in vectorizer
>
> On Mon, 19 May
> > +-param=vect-scalar-cost-multiplier=
> > +Common Joined UInteger Var(param_vect_scalar_cost_multiplier) Init(1)
> IntegerRange(0, 10) Param Optimization
> > +The scaling multiplier to add to all scalar loop costing when performing
> vectorization profitability analysis. The default value i
> >/* Complete the target-specific cost calculations. */
> >loop_vinfo->vector_costs->finish_cost (loop_vinfo->scalar_costs);
> >vec_prologue_cost = loop_vinfo->vector_costs->prologue_cost ();
> > @@ -12373,6 +12394,13 @@ vect_transform_loop (loop_vec_info loop_vinfo,
> gimple *loop_ve
> -Original Message-
> From: Richard Biener
> Sent: Friday, May 16, 2025 11:35 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Sandiford ; Tamar Christina
>
> Subject: [PATCH][RFC] Allow the target to request a masked vector epilogue
>
> Targets recently got
Hi All,
The vectorizer now tries to maintain the target VF that a user wanted through
uncreasing the unroll factor if the user used pragma GCC unroll and we've
vectorized the loop.
This change makes the AArch64 backend honor this initial value being set by
the vectorizer.
Consider the loop
void
> > > >
> > > > - /* Loops vectorized with a variable factor won't benefit from
> > > > + /* Loops vectorized would have already taken into account unrolling
> specified
> > > > + by the user as the suggested unroll factor, as such we need to
> > > > prevent the
> > > > + RTL unroller fr
> -Original Message-
> From: Tamar Christina
> Sent: Wednesday, May 14, 2025 12:19 PM
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; rguent...@suse.de
> Subject: [PATCH v2 1/2]middle-end: Add new parameter to scale scalar loop
> costing in vectorizer
>
> Hi All,
Hi All,
With the middle-end providing a way to make vectorization more profitable by
scaling vect-scalar-cost-multiplier this makes a more user friendly option
to make it easier to use.
I propose making it an actual -m option that we document and retain vs using
the parameter name. In the future
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, May 13, 2025 12:08 PM
> To: Richard Sandiford
> Cc: gcc-patches@gcc.gnu.org; Tamar Christina
> Subject: Re: [PATCH][RFC] Add vector_costs::add_vector_cost vector stmt
> grouping hook
>
> On Tue, 13
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, May 13, 2025 1:59 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: Re: [PATCH 1/2]middle-end: Apply loop->unroll directly in vectorizer
>
> On Tue, 13 May 2025, Tamar Chr
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, May 13, 2025 1:36 PM
> To: Jakub Jelinek
> Cc: Tamar Christina ; Jonathan Wakely
> ; gcc-patches@gcc.gnu.org; nd
> Subject: Re: [PATCH 1/4]middle-end: document pragma unroll n
> [PR116140]
>
&
> -Original Message-
> From: Joseph Myers
> Sent: Tuesday, May 13, 2025 12:35 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: Re: [PATCH 2/4][c-frontend]: implement pragma unroll n
> for C [PR116140]
>
> On Tue, 13 May 2025, Tamar Chri
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, May 13, 2025 12:44 PM
> To: Eric Botcazou
> Cc: Tamar Christina ; gcc-patches@gcc.gnu.org; nd
>
> Subject: Re: [PATCH 1/4]middle-end: document pragma unroll n
> [PR116140]
>
> On Tue, 13
> -Original Message-
> From: Jakub Jelinek
> Sent: Tuesday, May 13, 2025 11:49 AM
> To: Tamar Christina
> Cc: Jonathan Wakely ; gcc-patches@gcc.gnu.org; nd
> ; rguent...@suse.de
> Subject: Re: [PATCH 1/4]middle-end: document pragma unroll n
> [PR116140]
>
&
> -Original Message-
> From: Jonathan Wakely
> Sent: Tuesday, May 13, 2025 11:34 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de
> Subject: Re: [PATCH 1/4]middle-end: document pragma unroll n
> [PR116140]
>
> On Tue, 13 May 202
> -Original Message-
> From: Jonathan Wakely
> Sent: Tuesday, May 13, 2025 11:01 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de
> Subject: Re: [PATCH 1/4]middle-end: document pragma unroll n
> [PR116140]
>
> On 13/05/25 10:39 +
Hi All,
In PR116140 it was brought up that adding pragma GCC unroll in std::find makes
it so that you can't use a larger unroll factor if you wanted to. This is
because the value can't be overriden by the other unrolling flags such as
-funroll-loops.
To know whether this should be possible to do
Hi All,
In PR116140 it was brought up that adding pragma GCC unroll in std::find makes
it so that you can't use a larger unroll factor if you wanted to. This is
because the value can't be overriden by the other unrolling flags such as
-funroll-loops.
To know whether this should be possible to do
Hi All,
Consider the loop
void f1 (int *restrict a, int n)
{
#pragma GCC unroll 4 requested
for (int i = 0; i < n; i++)
a[i] *= 2;
}
Which today is vectorized and then unrolled 3x by the RTL unroller due to the
use of the pragma. This is unfortunate because the pragma was intended for the
Hi All,
The vectorizer now tries to maintain the target VF that a user wanted through
uncreasing the unroll factor if the user used pragma GCC unroll and we've
vectorized the loop.
This change makes the AArch64 backend honor this initial value being set by
the vectorizer.
Consider the loop
void
Hi All,
In PR116140 it was brought up that adding pragma GCC unroll in std::find makes
it so that you can't use a larger unroll factor if you wanted to. This is
because the value can't be overriden by the other unrolling flags such as
-funroll-loops.
To know whether this should be possible to do
Hi All,
In PR116140 it was brought up that adding pragma GCC unroll in std::find makes
it so that you can't use a larger unroll factor if you wanted to. This is
because the value can't be overriden by the other unrolling flags such as
-funroll-loops.
To know whether this should be possible to do
Hi All,
With the middle-end providing a way to make vectorization more profitable by
scaling vect-scalar-cost-multiplier this makes a more user friendly option
to make it easier to use.
I propose making it an actual -m option that we document and retain vs using
the parameter name. In the future
Hi All,
This patch adds a new param vect-scalar-cost-multiplier to scale the scalar
costing during vectorization. If the cost is set high enough and when using
the dynamic cost model it has the effect of effectively disabling the
costing vs scalar and assumes all vectorization to be profitable.
> -Original Message-
> From: Richard Biener
> Sent: Monday, May 12, 2025 1:46 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Tamar Christina ; RISC-V CI c...@rivosinc.com>
> Subject: [PATCH] Cleanup internal vectorizer costing API
>
> This tries to cleanup the API ava
> -Original Message-
> From: Richard Biener
> Sent: Friday, May 9, 2025 2:44 PM
> To: Tamar Christina
> Cc: Richard Sandiford ; Pengfei Li
> ; gcc-patches@gcc.gnu.org; ktkac...@nvidia.com
> Subject: RE: [PATCH] vect: Improve vectorization for small-trip-count loops
> -Original Message-
> From: Richard Biener
> Sent: Friday, May 9, 2025 8:31 AM
> To: Pengfei Li
> Cc: gcc-patches@gcc.gnu.org; Richard Sandiford
> Subject: Re: [PATCH v2] match.pd: Fold (x + y) >> 1 into IFN_AVG_FLOOR (x, y)
> for
> vectors
>
> On Thu, 8 May 2025, Pengfei Li wrote:
1 - 100 of 1325 matches
Mail list logo
