> -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:
> -Original Message-
> From: Richard Biener
> Sent: Friday, May 9, 2025 11:08 AM
> To: Richard Sandiford
> Cc: Pengfei Li ; gcc-patches@gcc.gnu.org;
> ktkac...@nvidia.com
> Subject: Re: [PATCH] vect: Improve vectorization for small-trip-count loops
> using
> subvectors
>
> On Fri, 9 May
>
> This is an example on how I'd like to see cleanup for SLP happening
> in the vectorizable_* and related functions. While this example,
> vectorizable_conversion, is quite straight-forward it helps to
> isolate errors. I've done this in 3 steps:
Happy to help with this if you let me know whi
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, May 6, 2025 9:51 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Tamar Christina ; RISC-V CI c...@rivosinc.com>
> Subject: [PATCH] tree-optimization/120089 - force all PHIs live for
> early-break vect
>
&g
> -Original Message-
> From: Jennifer Schmitz
> Sent: Monday, April 28, 2025 11:40 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Sandiford ; Tamar Christina
>
> Subject: Re: [PATCH] aarch64: Optimize SVE extract last to Neon lane extract
> for
> 128-bit
Hi All,
When the input is already a subreg and we try to make a paradoxical
subreg out of it for copysign this can fail if it violates the subreg
relationship.
Use force_lowpart_subreg instead of lowpart_subreg to then force the
results to a register instead of ICEing.
Bootstrapped Regtested on
Hi All,
The following testcase shows an incorrect masked codegen:
#define N 512
#define START 1
#define END 505
int x[N] __attribute__((aligned(32)));
int __attribute__((noipa))
foo (void)
{
int z = 0;
for (unsigned int i = START; i < END; ++i)
{
z++;
if (x[i] > 0)
> -Original Message-
> From: Richard Sandiford
> Sent: Friday, April 25, 2025 6:55 PM
> To: Jennifer Schmitz
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] AArch64: Fold LD1/ST1 with ptrue to LDR/STR for 128-bit
> VLS
>
> Jennifer Schmitz writes:
> > If -msve-vector-bits=128, SVE
> -Original Message-
> From: Richard Sandiford
> Sent: Friday, April 25, 2025 4:45 PM
> To: Jennifer Schmitz
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] aarch64: Optimize SVE extract last to Neon lane extract
> for
> 128-bit VLS.
>
> Jennifer Schmitz writes:
> > For the test c
> -Original Message-
> From: Jakub Jelinek
> Sent: Wednesday, April 23, 2025 10:39 AM
> To: Tamar Christina
> Cc: Richard Biener ; Andi Kleen
> ; GCC Patches
> Subject: Re: [PATCH] Add a bootstrap-native build config
>
> On Wed, Apr 23, 2025 at 09:36:11AM +
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, April 23, 2025 9:37 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Sandiford
>
> Subject: Re: [PATCH]middle-end: Add new "max" vector cost model
>
> On Wed, 23 Apr
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, April 23, 2025 9:19 AM
> To: Andi Kleen ; GCC Patches
> Subject: Re: [PATCH] Add a bootstrap-native build config
>
> On Tue, Apr 22, 2025 at 5:43 PM Andi Kleen wrote:
> >
> > On 2025-04-22 13:22, Richard Biener wrote:
> > >
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, April 23, 2025 10:14 AM
> To: Tamar Christina
> Cc: Richard Sandiford ; gcc-patches@gcc.gnu.org;
> nd
> Subject: RE: [PATCH]middle-end: Add new "max" vector cost model
>
> On We
> -Original Message-
> From: Richard Sandiford
> Sent: Wednesday, April 23, 2025 9:45 AM
> To: Tamar Christina
> Cc: Richard Biener ; gcc-patches@gcc.gnu.org; nd
>
> Subject: Re: [PATCH]middle-end: Add new "max" vector cost model
>
> Tamar Christin
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, April 23, 2025 9:46 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Sandiford
>
> Subject: RE: [PATCH]middle-end: Add new "max" vector cost model
>
> On We
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, April 23, 2025 9:31 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Sandiford
>
> Subject: Re: [PATCH]middle-end: Add new "max" vector cost model
>
> On We
Hi All,
This patch proposes a new vector cost model called "max". The cost model is an
intersection between two of our existing cost models. Like `unlimited` it
disables the costing vs scalar and assumes all vectorization to be profitable.
But unlike unlimited it does not fully disable the vect
Hi All,
This documents the PFA support in GCC-15.
Ok for master?
Thanks,
Tamar
---
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index
f03e29c8581f2749a968e592eae2e40ce3ca8521..7fb70b993c56ff43c09aeb7bfaa4479385679dec
100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs
Hi All,
I had missed this one during the AMDGCN test failures.
Like vect-early-break_18.c this test is also scalaring the
loads and thus leading to unexpected vectorization for this
testcase.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Cross checked the failing case on amdgc
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, April 22, 2025 2:28 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw ;
> ktkac...@nvidia.com
> Subject: Re: [PATCH] Document AArch64 changes for GCC 15
>
> Tamar Christina
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, April 22, 2025 1:31 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; ktkac...@nvidia.com;
> Tamar Christina
> Subject: [PATCH] Document AArch64 changes for GCC 15
>
> The list i
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, April 16, 2025 9:57 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: Re: [PATCH]middle-end: fix masking for partial vectors and early
> break
> [PR119351]
>
> On Wed, 16 A
Hi All,
The given test is intended to test vectorization of a strided access done by
having a step of > 1.
GCN target doesn't support load lanes, so the testcase is expected to fail,
other targets create a permuted load here which we then then reject.
However some GCN arch don't seem to support
Hi All,
The following testcase shows an incorrect masked codegen:
#define N 512
#define START 1
#define END 505
int x[N] __attribute__((aligned(32)));
int __attribute__((noipa))
foo (void)
{
int z = 0;
for (unsigned int i = START; i < END; ++i)
{
z++;
if (x[i] > 0)
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, April 15, 2025 12:50 PM
> To: Tamar Christina
> Cc: Richard Sandiford ; gcc-patches@gcc.gnu.org;
> nd
> Subject: RE: [PATCH]middle-end: Fix incorrect codegen with PFA and VLS
> [PR119351]
>
&
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, April 15, 2025 12:49 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: Re: [PATCH]middle-end: Fix incorrect codegen with PFA and VLS
> [PR119351]
>
> On Tue, 15 Apr 2025, Tamar
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, April 15, 2025 10:52 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de
> Subject: Re: [PATCH]middle-end: Fix incorrect codegen with PFA and VLS
> [PR119351]
>
> Tamar
Hi All,
The following example:
#define N 512
#define START 2
#define END 505
int x[N] __attribute__((aligned(32)));
int __attribute__((noipa))
foo (void)
{
for (signed int i = START; i < END; ++i)
{
if (x[i] == 0)
return i;
}
return -1;
}
generates incorrect code with
Ping
> -Original Message-
> From: Tamar Christina
> Sent: Tuesday, July 23, 2024 3:30 PM
> To: Jonathan Wakely ; Filip Kastl
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: RE: [PATCH][contrib]: support json output from check_GNU_style_lib.py
>
> Hi Both,
>
> -Original Message-
> From: Kyrylo Tkachov
> Sent: Monday, March 31, 2025 1:43 PM
> To: i...@sandoe.co.uk
> Cc: Tamar Christina ; GCC Patches patc...@gcc.gnu.org>; Alice Carlotti ; Richard
> Sandiford
> ; s...@gentoo.org
> Subject: Re: [PATCH v2] aarch64, Dar
1 - 100 of 1296 matches
Mail list logo
