> -Original Message-
> From: Robin Dapp
> Sent: Thursday, September 11, 2025 1:03 PM
> To: Richard Biener ; Tamar Christina
>
> Cc: rdapp@gmail.com; gcc-patches@gcc.gnu.org;
> rdsandif...@googlemail.com
> Subject: Re: New optabs and IFN required for early br
> 70a27555d900caf71932a2c794d9a77d06048b6a..b677a5308fb3498314cbbfc1
> 865eae6bf1c815b9 100644
> > --- a/gcc/doc/md.texi
> > +++ b/gcc/doc/md.texi
> > @@ -6087,6 +6087,25 @@ vectors with N signed/unsigned elements of size
> S@. Find the absolute
> > difference between operands 1 and 2 and widen t
> -Original Message-
> From: Wilco Dijkstra
> Sent: Thursday, September 4, 2025 4:32 PM
> To: Kyrylo Tkachov ; Alex Coplan
> ; Tamar Christina ; Andrew
> Pinski ; Alice Carlotti
> Cc: GCC Patches
> Subject: [PATCH] AArch64: Add isnan expander [PR 66462]
>
This email is to discuss the optabs and IFNs that I will need to finish off the
early break optimizations in GCC 16 and to minimize respins on the final
patches.
Optabs only, These will be handled through expand rewriting them if the targets
supports them:
-- cbranch
At the moment we model vect
> -Original Message-
> From: Wilco Dijkstra
> Sent: Wednesday, September 10, 2025 5:25 PM
> To: Tamar Christina ; GCC Patches patc...@gcc.gnu.org>
> Cc: Kyrylo Tkachov ; Alex Coplan
> ; Andrew Pinski ; Alice Carlotti
>
> Subject: Re: [PATCH] AArch64: Add
> -Original Message-
> From: Kyrylo Tkachov
> Sent: Wednesday, September 3, 2025 11:40 AM
> To: GCC Patches
> Cc: Tamar Christina ; Richard Earnshaw
> ; Alex Coplan ; Andrew
> Pinski
> Subject: [PATCH] aarch64: PR target/121749: Use correct predicate for
>
Given a sequence such as
int foo ()
{
#pragma GCC unroll 4
for (int i = 0; i < N; i++)
if (a[i] == 124)
return 1;
return 0;
}
where a[i] is long long, we will unroll the loop and use an OR reduction for
early break on Adv. SIMD. Afterwards the sequence is followed by a compression
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, September 2, 2025 3:08 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: RE: [PATCH v2 3/3]middle-end: Use addhn for compression instead of
> inclusive OR when reducing comparison valu
> -Original Message-
> From: Richard Biener
> Sent: Friday, August 29, 2025 12:41 PM
> To: gcc-patches@gcc.gnu.org
> Cc: RISC-V CI ; Tamar Christina
>
> Subject: [PATCH 4/4] Eliminate some STMT_VINFO_REDUC_IDX for
> SLP_TREE_REDUC_IDX
>
> The following us
> -Original Message-
> From: Kyrylo Tkachov
> Sent: Tuesday, September 2, 2025 12:03 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; ktkac...@gcc.gnu.org; Richard Sandiford
> ; Alex Coplan ;
> andrew.pin...@oss.qualcomm.com
&
> -Original Message-
> From: Jakub Jelinek
> Sent: Tuesday, September 2, 2025 10:00 AM
> To: Alex Coplan ; Richard Earnshaw
> ; Tamar Christina ;
> Kyrylo Tkachov ; Christophe Lyon
> ; Spencer Abson
> Cc: gcc-patches@gcc.gnu.org
> Subject: [PATCH] aarch64: A
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, September 3, 2025 8:36 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: RE: [PATCH v2 3/3]middle-end: Use addhn for compression instead of
> inclusive OR when reducing comparison
Given a sequence such as
int foo ()
{
#pragma GCC unroll 4
for (int i = 0; i < N; i++)
if (a[i] == 124)
return 1;
return 0;
}
where a[i] is long long, we will unroll the loop and use an OR reduction for
early break on Adv. SIMD. Afterwards the sequence is followed by a compression
This implements the new vector optabs vec_addh_narrow
adding support for in-vectorizer use for early break.
Bootstrapped Regtested on aarch64-none-linux-gnu,
arm-none-linux-gnueabihf, x86_64-pc-linux-gnu
-m32, -m64 and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
* config/aar
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, September 2, 2025 3:45 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: RE: [PATCH v2 3/3]middle-end: Use addhn for compression instead of
> inclusive OR when reducing comparison valu
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, September 2, 2025 1:44 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: Re: [PATCH 1/3]middle-end: clear the user unroll flag if the cost
> model has
> overriden it
>
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, September 2, 2025 1:30 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: Re: [PATCH v2 3/3]middle-end: Use addhn for compression instead of
> inclusive OR when reducing comparison valu
her than overriding it after vectorization.
Tamar
From: Richard Biener
Sent: Tuesday, September 2, 2025 12:10 PM
To: Tamar Christina
Cc: gcc-patches@gcc.gnu.org ; nd
Subject: Re: [PATCH 1/3]middle-end: clear the user unroll flag if the cost
model has overriden it
On Tue,
Given a sequence such as
int foo ()
{
#pragma GCC unroll 4
for (int i = 0; i < N; i++)
if (a[i] == 124)
return 1;
return 0;
}
where a[i] is long long, we will unroll the loop and use an OR reduction for
early break on Adv. SIMD. Afterwards the sequence is followed by a compression
> -Original Message-
> From: Tamar Christina
> Sent: Tuesday, September 2, 2025 12:15 PM
> To: Kyrylo Tkachov
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; ktkac...@gcc.gnu.org; Richard Sandiford
> ; Alex Coplan ;
> andrew.pin...@oss.qualcomm.com
&
This implements the new vector optabs vec_addh_narrow
adding support for in-vectorizer use for early break.
Bootstrapped Regtested on aarch64-none-linux-gnu,
arm-none-linux-gnueabihf, x86_64-pc-linux-gnu
-m32, -m64 and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
* config/aar
If the user has requested loop unrolling through pragma GCC unroll then at the
moment we only set LOOP_VINFO_USER_UNROLL if the vectorizer has not overrode the
unroll factor (through backend costing) or if the VF made the requested unroll
factor be 1.
But of these events are costing related, and s
> -Original Message-
> From: Jennifer Schmitz
> Sent: Friday, August 29, 2025 1:17 PM
> To: GCC Patches
> Cc: Alex Coplan ; Kyrylo Tkachov
> ; Tamar Christina ; Richard
> Earnshaw ; Andrew Pinski
> Subject: [PATCH][PR121602] aarch64: Force vector when folding sv
> -Original Message-
> From: Richard Biener
> Sent: Friday, August 29, 2025 12:40 PM
> To: gcc-patches@gcc.gnu.org
> Cc: RISC-V CI ; Tamar Christina
>
> Subject: [PATCH 2/4] Separate reduction info and associate it with SLP nodes
>
> The following s
The 08/20/2025 16:52, Jennifer Schmitz wrote:
>
>
> > On 5 Aug 2025, at 09:25, Tamar Christina wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > Hi Jennifer,
> >
> > This part is new to me so I'm just
> -Original Message-
> From: Richard Biener
> Sent: Friday, August 29, 2025 9:15 AM
> To: Andrew Pinski
> Cc: Tamar Christina ; gcc-patches@gcc.gnu.org; RISC-
> V CI
> Subject: Re: [PATCH] Pass reduction var to vectorize_fold_left_reduction
> directly
>
&g
> -Original Message-
> From: Wilco Dijkstra
> Sent: Wednesday, August 27, 2025 6:32 PM
> To: GCC Patches
> Cc: Kyrylo Tkachov ; Alex Coplan
> ; Tamar Christina ; Andrew
> Pinski ; Alice Carlotti
> Subject: [PATCH] AArch64: Add isfinite expander [PR 66462]
>
> -Original Message-
> From: Wilco Dijkstra
> Sent: Wednesday, August 27, 2025 6:04 PM
> To: Kyrylo Tkachov
> Cc: GCC Patches ; Alex Coplan
> ; Tamar Christina ; Andrew
> Pinski ; Alice Carlotti
> Subject: [PATCH v2] AArch64: Add isinf expander [PR 66462]
>
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, August 27, 2025 2:56 PM
> To: gcc-patches@gcc.gnu.org
> Cc: RISC-V CI ; Tamar Christina
>
> Subject: [PATCH] Pass reduction var to vectorize_fold_left_reduction directly
>
> Instead of going vi
> -Original Message-
> From: soum...@nvidia.com
> Sent: Monday, August 25, 2025 12:00 PM
> To: gcc-patches@gcc.gnu.org
> Cc: ktkac...@nvidia.com; rdsandif...@googlemail.com; pins...@gmail.com
> Subject: [v3 PATCH 0/6] aarch64: Support for user-defined aarch64 tuning
>
> From: Soumya AR
>
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, August 26, 2025 8:59 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Tamar Christina
> Subject: [PATCH][aarch64] Compute vect_reduc_type off SLP node instead of
> stmt-info
>
> The following changes the vec
> -Original Message-
> From: Richard Biener
> Sent: Thursday, August 21, 2025 1:17 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; rdsandif...@googlemail.com; nd
> Subject: RE: [PATCH 1/5]middle-end: Add scaffolding to support narrowing IFNs
>
> On
> -Original Message-
> From: Richard Biener
> Sent: Thursday, August 21, 2025 11:55 AM
> To: Tamar Christina
> Cc: Richard Biener ; gcc-patches@gcc.gnu.org; nd
>
> Subject: RE: [PATCH 2/5]middle-end: Add detection for add halfing and
> narrowing
> instructi
> -Original Message-
> From: Richard Biener
> Sent: Thursday, August 21, 2025 11:51 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; rdsandif...@googlemail.com; nd
> Subject: RE: [PATCH 1/5]middle-end: Add scaffolding to support narrowing IFNs
>
> On
In case there's any confusion, this patch is technically independent of the
first one.
Just sent together because I noticed the first one while fixing this.
So this still needs a review regardless of patch 1.
Tamar
> -Original Message-
> From: Tamar Christina
> Sent: Wed
> -Original Message-
> From: Richard Sandiford
> Sent: Wednesday, August 20, 2025 11:13 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; ktkac...@gcc.gnu.org; Alex Coplan
> ; andrew.pin...@oss.qualcomm.com;
> rguent...@suse.de
&
Consider the example:
void
f (int *restrict x, int *restrict y, int *restrict z, int n)
{
for (int i = 0; i < 4; ++i)
{
int res = 0;
for (int j = 0; j < 100; ++j)
res += y[j] * z[i];
x[i] = res;
}
}
we currently vectorize as
f:
moviv30.4s, 0
To avoid double counting scalar instructions when doing inner-loop costing the
vectorizer uses vect_prologue as the kind instead of vect_body.
However doing this results in our throughput based costing to think the scalar
loop issues in 0 cycles (rounded up to 1.0). The latency costs however are
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, August 20, 2025 1:48 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; rdsandif...@googlemail.com; nd
> Subject: Re: [PATCH 1/5]middle-end: Add scaffolding to support narrowing IFNs
>
> On
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, August 20, 2025 1:48 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de
> Subject: Re: [PATCH 2/5]middle-end: Add detection for add halfing and
> narrowing
> instruction
&
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, August 19, 2025 8:31 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: Re: [PATCH 2/3]middle-end: Fix costing hooks of various
> vectorizable_*
> [PR121536]
>
> On Tue
This adds scaffolding for supporting narrowing IFNs inside the vectorizer in a
similar way as how widening is supported. However because narrowing operations
always have the same number of elements as the input and output we need to be
able to combine the results. One way this could have been don
Given a sequence such as
int foo ()
{
#pragma GCC unroll 4
for (int i = 0; i < N; i++)
if (a[i] == 124)
return 1;
return 0;
}
where a[i] is long long, we will unroll the loop and use an OR reduction for
early break on Adv. SIMD. Afterwards the sequence is followed by a compression
This implements the new vector optabs vec_addh_narrow_hi_,
vec_addh_narrow_lo_, vec_addh_narrow adding support for
in-vectorizer recognition of addhn.
The existing codegen tests will now recognize the instructions through the
optabs
rather than combine.
Bootstrapped Regtested on aarch64-none-lin
If the user has requested loop unrolling through pragma GCC unroll then at the
moment we only set LOOP_VINFO_USER_UNROLL if the vectorizer has not overrode the
unroll factor (through backend costing) or if the VF made the requested unroll
factor be 1.
But of these events are costing related, and s
commit g:1786be14e94bf1a7806b9dc09186f021737f0227 stops storing in
STMT_VINFO_VECTYPE the vectype of the current stmt being vectorized and instead
requires the use of SLP_TREE_VECTYPE for everything but data-refs.
This means that STMT_VINFO_VECTYPE (stmt_info) will always be NULL and so
aarch64_bo
This adds support for detectioon of the ADDHN pattern in the vectorizer.
Concretely try to detect
_1 = (W)a
_2 = (W)b
_3 = _1 + _2
_4 = _3 >> (precision(a) / 2)
_5 = (N)_4
where
W = precision (a) * 2
N = precision (a) / 2
Bootstrapped Regtested on aarch64-none-linux-gnu,
arm-none-l
commit g:1786be14e94bf1a7806b9dc09186f021737f0227 stops storing in
STMT_VINFO_VECTYPE the vectype of the current stmt being vectorized and instead
requires the use of SLP_TREE_VECTYPE for everything but data-refs.
However contrary to what the commit says not all usages of STMT_VINFO_VECTYPE
have b
commit g:fb59c5719c17a04ecfd58b5e566eccd6d2ac583a stops passing the scalar type
(confusingly named vectype) to the costing hook when doing scalar costing.
As a result, we could no longer distinguish between FPR and GPR scalar stmts.
A later commit also removed STMT_VINFO_VECTYPE from stmt_info.
T
> -Original Message-
> From: Richard Sandiford
> Sent: Monday, August 18, 2025 11:30 AM
> 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: Yury Khrustalev
> Sent: Thursday, August 14, 2025 4:18 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Sandiford ; Tamar Christina
> ; Andrew Pinski
> Subject: [PATCH 0/1] aarch64: Adapt unwinder to linux's SME signal behaviou
> -Original Message-
> From: Yury Khrustalev
> Sent: Friday, August 8, 2025 2:53 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Sandiford ; Tamar Christina
> ; Andrew Pinski
> Subject: [PATCH 0/1] aarch64: Adapt unwinder to linux's SME signal behaviou
> -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
1 - 100 of 1377 matches
Mail list logo
