On Tue, Jul 15, 2025 at 12:03 AM David Faust wrote:
>
> The btf_decl_tag and btf_type_tag attributes provide a means to annotate
> declarations and types respectively with arbitrary user provided
> strings. These strings are recorded in debug information for
> post-compilation uses, and despite t
On Tue, Jul 15, 2025 at 4:54 PM Karl Meakin wrote:
>
> The function `vect_check_gather_scatter` requires the `base` of the load
> to be loop-invariant and the `off`set to be not loop-invariant. When faced
> with a scenario where `base` is not loop-invariant, instead of giving up
> immediately we c
On Fri, Jul 11, 2025 at 11:03 AM Robin Dapp wrote:
>
> This patch adds simple misalignment checks for gather/scatter
> operations. Previously, we assumed that those perform element accesses
> internally so alignment does not matter. The riscv vector spec however
> explicitly states that vector o
On Fri, Jul 11, 2025 at 11:03 AM Robin Dapp wrote:
>
> This patch adds an is_gather_scatter argument to the
> support_vector_misalignment hook. All targets but riscv do not care
> about alignment for gather/scatter so return true for is_gather_scatter.
OK.
> gcc/ChangeLog:
>
> * config/
On Fri, Jul 11, 2025 at 11:03 AM Robin Dapp wrote:
>
> This encapsulates the IFN and the builtin-function way of handling
> gather/scatter via three defines:
>
> GATHER_SCATTER_IFN_P
> GATHER_SCATTER_LEGACY_P
> GATHER_SCATTER_EMULATED_P
>
> and introduces a helper define for SLP operand hand
On Fri, Jul 11, 2025 at 11:03 AM Robin Dapp wrote:
>
> This patch adds access helpers for the gather/scatter offset and scale
> parameters.
OK.
> gcc/ChangeLog:
>
> * internal-fn.cc (expand_scatter_store_optab_fn): Use new
> function.
> (expand_gather_load_optab_fn): Ditt
On Thu, 17 Jul 2025, Filip Kastl wrote:
> On Thu 2025-07-17 11:48:33, Richard Biener wrote:
> > On Thu, 17 Jul 2025, Filip Kastl wrote:
> >
> > > On Thu 2025-07-17 10:00:01, Richard Biener wrote:
> > > > On Thu, 17 Jul 2025, Filip Kastl wrote:
> > &g
The following moves rejecting loop vectorization with vector(1)
typed vectors from the initial vector type determining to after
SLP discovery when we can check whether there's any instance
with other than vector(1) vectors. For RVV at least vector(1)
instances serve as a limited way to support par
On Thu, 17 Jul 2025, Filip Kastl wrote:
> On Thu 2025-07-17 10:00:01, Richard Biener wrote:
> > On Thu, 17 Jul 2025, Filip Kastl wrote:
> >
> > > Hi,
> > >
> > > This patch cuts out the solver from tree-ssa-structalias.cc. Soon, I'd
> >
When VN iterates we can end up with unreachable inserted expressions
in the expression tables which in turn will not be added to their
value by PREs compute_avail. This will later ICE when we pick
them up and want to generate them. Deal with this by giving up.
Bootstrap and regtest running on x8
The following makes us never consider vector(1) T types for
vectorization and ensures this during SLP build. This is a
long-standing issue for BB vectorization and when we remove
early loop vector type setting we lose the single place we have
that rejects this for loops.
Once we implement partial
When having a _BitInt induction we should make sure to not create
the step vector elements as _BitInts but as vector element typed.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
Richard.
PR tree-optimization/121116
* tree-vect-loop.cc (vectorizable_induction): Use
The following disables loop masking when we are using an even/odd
widening operation in a reduction because the loop mask then aligns
to the wrong elements.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
If a target implements both even/odd and hi/lo widening we might
want to change s
On Mon, Jul 14, 2025 at 11:01 PM Andrew Pinski wrote:
>
> While starting to improve if-conv, I noticed that predicated
> was only being set once inside a loop and accessed right below.
> This became this way due to r14-8869-g8636c538b68068 and before
> it was needed since it was accessed via 2 loo
On Mon, Jul 14, 2025 at 11:00 PM Andrew Pinski wrote:
>
> This is a small compile time optimization, as match and simplify will generate
> the same thing but with rhs and lhs being the same we can return early instead
> of having to go through match and simplify. This might not show up that much
>
On Mon, Jul 14, 2025 at 7:04 PM Andrew Pinski wrote:
>
> For possible reductions, ifconv currently handles if the addition
> is on one side of the if. But in the case of PR 119920, the reduction
> addition is on both sides of the if.
> E.g.
> ```
> if (_27 == 0)
> goto ; [50.00%]
> else
>
When we opportunistically mask an operand of a AND with an already
available loop mask we need to query that set with the correct number
of masks we expect.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/121059
* tree-vect-stmts.cc (vectorizable_
On Tue, Jul 15, 2025 at 11:32 AM Robin Dapp wrote:
>
> Hi,
>
> r16-2175-g5aa21765236730 introduced an assert for floating-point modes
> when expanding an RDIV_EXPR but forgot fixed-point modes. This patch
> adds ALL_FIXED_POINT_MODE_P to the assert.
>
> Bootstrap and regtest running on x86, aarch
On Mon, Jul 14, 2025 at 10:58 PM Qing Zhao wrote:
>
>
> > On Jul 7, 2025, at 13:07, Qing Zhao wrote:
> >
> > As I mentioned in the latest email I replied to the thread, the original
> > implementation of the counted_by for pointer was implemented without the
> > additional indirection.
> > But
On Mon, 14 Jul 2025, Richard Sandiford wrote:
> Richard Biener writes:
> > For loop masking we need to mask a mask AND operation with the loop
> > mask. The following makes sure we have a corresponding mask
> > available. There's no good way to distinguish loop ma
For loop masking we need to mask a mask AND operation with the loop
mask. The following makes sure we have a corresponding mask
available. There's no good way to distinguish loop masking from
len masking here, so assume we have recorded a mask for the operands
mask producers.
Bootstrap and regt
On Sat, Jul 12, 2025 at 10:59 AM wrote:
>
> From: Pan Li
>
> The widen mul will have source type from N-bits to
> dest type 2N-bits. The previous check only focus on
> the HOST_WIDE_INT but not working for QI => HI, HI => SI
> and SI to DImode. Thus, refine the widen mul precision
> check as de
On Fri, Jul 11, 2025 at 8:27 PM Siddhesh Poyarekar wrote:
>
> The test ends up writing a byte beyond bounds of the buffer, which gets
> trapped on some targets when the test is run with
> -fstack-protector-strong.
>
> testsuite/ChangeLog:
>
> * gcc.dg/vect/pr116125.c (mem_overlap): Reduce
The following makes us never consider vector(1) T types for
vectorization and ensures this during SLP build. This is a
long-standing issue for BB vectorization and when we remove
early loop vector type setting we lose the single place we have
that rejects this for loops.
Once we implement partial
The following fixes the loop following the reduction chain to
properly visit all SLP nodes involved and makes the stmt info
and the SLP node we track match.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/121034
* tree-vect-loop.cc (vectorizable_r
The releases/gcc-15 branch is open for regression and documentation fixes.
This is now the time to prepare for the GCC 15.2 release - a release
candidate is planned for Friday Aug 1st, three weeks from now, with
the GCC 15.2 release following a week after that.
Please go over reported regression
On Thu, 10 Jul 2025, Richard Sandiford wrote:
> Richard Biener writes:
> > The following removes an optimization that wrongly triggers right now
> > because it accesses LOOP_VINFO_COST_MODEL_THRESHOLD which might not be
> > computed yet.
> >
> > Testing on x
= last ? gimple_location (last) : UNKNOWN_LOCATION;
> - if (locus == UNKNOWN_LOCATION)
> - continue;
> -
> - expanded_location locus_e = expand_location (locus);
> -
> - FOR_EACH_EDGE (e, ei, bb->succs)
> - {
> - gimple *first = first_non_labe
widen-mul could also be a QImode x QImode -> HImode operation, or a
QImode x QImode -> SImode
operation. The only restriction is the result is at least twice as
wide as the inputs.
Richard.
>
> Pan
>
> -Original Message-
> From: Richard Biener
> Sent: Frid
On Thu, 10 Jul 2025, Richard Biener wrote:
> On Thu, 10 Jul 2025, Jan Hubicka wrote:
>
> > > The x86 add_stmt_hook relies on the passed vectype to determine
> > > the mode and whether it is FP for a scalar operation. This is
> > > unreliable now for stmts inv
The GCC 12 branch is now closed, no further changes can be pushed
there.
On Fri, Jul 11, 2025 at 6:51 AM wrote:
>
> From: Pan Li
>
> The widen mul has different source type for differnt platform,
> like rv32 or rv64. For rv32, the source of widen mul is 32-bits
> while 64-bits in rv64. Thus, leverage HOST_WIDE_INT is not that
> correct and result in the pattern matc
> +foo (struct S x, int y, int z)
> +{
> + return x.a + y + z;
> +}
> +
> +[[gnu::noinline]] static int
> +bar (struct S x, int y, int z)
> +{
> + [[gnu::musttail]] return foo ((struct S) { x.a, 0 }, y, 1);
> +}
> +
> +int
> +baz (int x)
> +{
> + retu
On Thu, 10 Jul 2025, Tamar Christina wrote:
> > -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: [
> Am 10.07.2025 um 16:27 schrieb Tamar Christina :
>
>
>>
>> -Original Message-----
>> From: Richard Biener
>> Sent: Thursday, July 10, 2025 3:09 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; Richard Sandiford ;
>> RI
On Thu, 10 Jul 2025, Tamar Christina wrote:
> > -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: [PATC
REE_TYPE (lhs));
> > + }
> Makes sense to me, but perhaps it would be good idea to add a comment,
> since it looks odd at first glance?
Like
/* When we are costing a scalar stmt use the scalar stmt to get at the
type of the operation. */
?
Richard.
> Honza
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
The x86 add_stmt_hook relies on the passed vectype to determine
the mode and whether it is FP for a scalar operation. This is
unreliable now for stmts involving patterns and in the future when
there is no vector type passed for scalar operations.
To be least disruptive I've kept using the vector
The following removes an optimization that wrongly triggers right now
because it accesses LOOP_VINFO_COST_MODEL_THRESHOLD which might not be
computed yet.
Testing on x86_64 didn't reveal any testsuite coverage.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
OK?
PR tree-optimizatio
The following makes us never consider vector(1) T types for
vectorization and ensures this during SLP build. This is a
long-standing issue for BB vectorization and when we remove
early loop vector type setting we lose the single place we have
that rejects this for loops.
Once we implement partial
SLP analysis of early break conditions asserts pattern recognition
canonicalized all of them. But the pattern can fail, for example
when vector types cannot be computed. So be graceful here, so
we don't ICE when we didn't yet compute vector types.
Bootstrapped and tested on x86_64-unknown-linux-
The following adjusts how we set SLP_TREE_VECTYPE for the conversion
node we build when fixing up the reduction with conversion SLP instance.
This should probably see more TLC, but the following avoids relying
on STMT_VINFO_VECTYPE for this.
* tree-vect-slp.cc (vect_build_slp_instance): D
When analyzing the reduction cycle we look to determine the
reduction input vector type, for lane-reducing ops we look
at the input but instead of using vect_is_simple_use which
is problematic for SLP we should simply get at the SLP
operands vector type. If that's not set and we make up one
we sho
This isn't the required refactoring of vect_check_gather_scatter
but it avoids a now unnecessary call to vect_is_simple_use which
is problematic because it looks at STMT_VINFO_VECTYPE which we
want to get rid of. SLP build already ensures vect_is_simple_use
on all lane defs, so all we need is to p
On Thu, Jul 10, 2025 at 12:38 PM Robin Dapp wrote:
>
> Hi,
>
> this patch adds asserts that ensure we only expand an RDIV_EXPR with
> actual float mode. It also replaces the RDIV_EXPR in setting a
> vectorized loop's length by EXACT_DIV_EXPR. The code in question is
> only used with length-contr
The following arranges vector reduction costs to hand down the
SLP node (of the reduction stmt) to the cost hooks, not only the
stmt_info. This also avoids accessing STMT_VINFO_VECTYPE of an
unrelated stmt to the node that is subject to code generation.
* tree-vect-loop.cc (vect_model_red
After vect_analyze_loop_operations is gone we can clean up
vect_analyze_stmt as it is no longer called out of SLP context.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-vectorizer.h (vect_analyze_stmt): Remove stmt-info
and need_to_vectorize arguments.
On Thu, Jul 10, 2025 at 8:13 AM Jakub Jelinek wrote:
>
> Hi!
>
> While I'm not a native English speaker, I believe all the uses
> of bellow (roar/bark/...) in comments in gcc are meant to be
> below (beneath/under/...).
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK
On Wed, Jul 9, 2025 at 10:16 PM Robert Dubner wrote:
>
> From 069bf2fe31e99f0415ddb6acaf76cfb6eee8bb6a Mon Sep 17 00:00:00 2001
> From: Robert Dubner mailto:rdub...@symas.com
> Date: Wed, 9 Jul 2025 12:24:38 -0400
> Subject: [PATCH] cobol: Development round-up. [PR120765, PR119337,
> PR120794]
>
>
On Wed, Jul 9, 2025 at 4:05 PM Richard Sandiford
wrote:
>
> While working on a new testcase that uses the RTL frontend,
> I hit a bug where a (reg ...) that spans multiple hard registers
> had REG_NREGS set to 1. This caused various things to misbehave.
> For example, if the (reg ...) in question
This function dissolves DR groups that are not subject to SLP. Which
means it is no longer necessary.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
* tree-vect-loop.cc (vect_dissolve_slp_only_groups): Remove.
(vect_analyze_loop_2): Do not call it.
---
gcc/tree-vect-
This removes the remains of vect_analyze_loop_operations. All the
checks it does still on LC PHIs of inner loops in outer loop
vectorization should be handled by vectorizable_lc_phi.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
* tree-vect-loop.cc (vect_active_double_reduct
The following removes the VF determining step from non-SLP stmts.
For now we keep setting STMT_VINFO_VECTYPE for all stmts, there are
too many places to fix, including some more complicated ones, so
this is defered for a followup.
Along this removes vect_update_vf_for_slp, merging the check for
pr
On Wed, Jul 9, 2025 at 3:06 PM Jeff Law wrote:
>
>
>
> On 7/9/25 6:53 AM, Richard Biener wrote:
> > On Wed, Jul 9, 2025 at 2:16 PM Jeff Law wrote:
> >>
> >>
> >>
> >> On 7/9/25 12:27 AM, Richard Biener wrote:
> >>> The followi
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: [PATCH 1/3]middle-end: support vec_cbranch_any and
> v
On Wed, Jul 9, 2025 at 2:16 PM Jeff Law wrote:
>
>
>
> On 7/9/25 12:27 AM, Richard Biener wrote:
> > The following changes the percentage that determines how many
> > stmts are allowed for backwards jump threading from 50 to 54,
> > enabling the missed jump
On Wed, 9 Jul 2025, Jan Hubicka wrote:
> > The following changes the percentage that determines how many
> > stmts are allowed for backwards jump threading from 50 to 54,
> > enabling the missed jump threading observed in PR109893.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu. It
On Wed, 9 Jul 2025, Tamar Christina wrote:
> > -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
applied? So cbranch_cond_{all,any} would be a better
fit? Though 'cond_' elsewhere suggests there is an else value, instead
cbranch_mask_{all,any}? Or would that not capture things exactly?
cbranch is compare-and-branch, so masked-compare-and-branch aka
mcbranch[_{all,any}]?
And writing th
The following changes noinline to noipa to avoid having IPA-CP clones
confusing the vectorized loop counting.
Tested on x86_64-unknown-linux-gnu, pushed.
PR testsuite/120093
* gcc.dg/vect/pr101145.c: Use noipa instead of noinline
attribute.
---
gcc/testsuite/gcc.dg/vect/p
The following fixes up two places we access STMT_VINFO_VECTYPE that's
not covered by the fixup in vect_analyze/transform_stmt to set that
from SLP_TREE_VECTYPE.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-vect-loop.cc (vectorizable_reduction): Get the
outpu
On Wed, Jul 9, 2025 at 4:37 AM Alex (Waffl3x) wrote:
>
LGTM.
Richard.
On Wed, Jul 9, 2025 at 4:37 AM Alex (Waffl3x) wrote:
>
/* Nonzero in a _DECL if the use of the name is defined as an
unavailable feature by __attribute__((unavailable)). */
#define TREE_UNAVAILABLE(NODE) \
- ((NODE)->base.u.bits.unavailable_flag)
+ ((TREE_CHECK_BITS_AVAILABLE (NODE))->ba
On Wed, Jul 9, 2025 at 4:36 AM Alex (Waffl3x) wrote:
>
Adding extra checks like this is OK.
Thanks,
Richard.
The following changes the percentage that determines how many
stmts are allowed for backwards jump threading from 50 to 54,
enabling the missed jump threading observed in PR109893.
Bootstrapped and tested on x86_64-unknown-linux-gnu. It seems that
at least backward threading is prone to profile m
Currently we scale the number of stmts allowed for forward
jump threading to limit those for backwards jump threading
by applying a factor of two to the counted stmts. That doesn't
allow fine-grained adjustments, like by a single stmt as needed
for PR109893. The following changes the factor to be
On Tue, Jul 8, 2025 at 12:46 AM Robert Dubner wrote:
>
>
>
> > -Original Message-
> > From: Rainer Orth
> > Sent: Monday, July 7, 2025 18:08
> > To: Robert Dubner
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: [PATCH] cobol: Implement CXXFLAGS_FOR_COBOL.
> >
> > Hi Robert,
> >
> > > I
On Tue, Jul 8, 2025 at 3:45 PM Robert Dubner wrote:
>
> > -Original Message-
> > From: Andreas Schwab
> > Sent: Tuesday, July 8, 2025 03:16
> > To: Robert Dubner
> > Cc: Rainer Orth ; gcc-patches@gcc.gnu.org
> > Subject: Re: [PATCH] cobol: Implement CXXFLAGS_FOR_COBOL.
> >
> > On Jul 07
On Tue, Jul 8, 2025 at 3:25 PM Jason Merrill wrote:
>
> On 7/8/25 4:35 AM, Richard Biener wrote:
> > On Mon, Jul 7, 2025 at 11:33 PM H.J. Lu wrote:
> >>
> >> On Tue, Jul 8, 2025 at 5:02 AM H.J. Lu wrote:
> >>>
> >>> On Mon, Jul 7, 2025 at 11
The following avoids inlining the actual main() (renamed to
guality_main) into the guality plumbing. This can cause
jump threading opportunities to appear and generally increase
the chance what we actually test isn't what we think. Likewise
make guality_check noipa instead of just noinline.
Boot
+ const_vf,
> + TYPE_SIGN (type)));
> + set_range_info (niters_vector, vr);
> + }
> + else if (niters_no_overflow)
> {
> int_range<1> vr (type,
>
n be TYPE_MAX_VALUE so
>we have to represent the vector niter TYPE_MAX_VALUE + 1 / vf. */
> - if (stmts != NULL && const_vf > 0)
> + if (stmts != NULL
> + && const_vf > 0
> + && !LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo))
>
es changed, 122 insertions(+), 11 deletions(-)
> create mode 100644 gcc/testsuite/gcc.target/aarch64/vector-compare-5.c
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
On Tue, Jul 8, 2025 at 12:48 PM H.J. Lu wrote:
>
> aba3b9d3a48a0703fd565f7c5f0caf604f59970b is the first bad commit
> commit aba3b9d3a48a0703fd565f7c5f0caf604f59970b
> Author: H.J. Lu
> Date: Fri May 9 07:17:07 2025 +0800
>
> x86: Extend the remove_redundant_vector pass
>
> which removed no
On Tue, 8 Jul 2025, Icen Zeyada wrote:
>
>
> From: Richard Biener
> Sent: 08 July 2025 10:01
> To: Icen Zeyada
> Cc: gcc-patches@gcc.gnu.org ; jeffreya...@gmail.com
> ; i...@airs.com ; Richard Earnshaw
> ; pins...@gmail.com ; Victor
*\\{\\s*0(,\\s*0){3}\\s*\\}\\s*>\\s*;"
> "original" } } */
> +/* { dg-final { scan-tree-dump
> ".*\\*tD\\.\\d+\\s*=\\s*VEC_COND_EXPR\\s*<\\s*\\*xD\\.\\d+\\s*<\\s*VIEW_CONVERT_EXPR\\(\\*yD\\.\\d+\\)\\s*,\\s*\\{\\s*-1(,\\s*-1){3}\\s*\\}\\s*,\\s*\\{\\s*0(,\\s*0){
lop, optab_vector)
I think the transform is sensible for arbitrary @2/@3 though
in that case with :s on the vec_conds.
Richard.
> +
> /* (c ? a : b) op d --> c ? (a op d) : (b op d) */
> (simplify
>(op (vec_cond:s @0 @1 @2) @3)
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
On Mon, Jul 7, 2025 at 11:33 PM H.J. Lu wrote:
>
> On Tue, Jul 8, 2025 at 5:02 AM H.J. Lu wrote:
> >
> > On Mon, Jul 7, 2025 at 11:08 PM Jason Merrill wrote:
> > >
> > > On 7/1/25 5:36 PM, H.J. Lu wrote:
> > > > On Tue, Jul 1, 2025 at 9:37 PM Jason Merrill wrote:
> > > >>
> > > >> On 6/30/25 7:
On Mon, Jul 7, 2025 at 11:08 PM H.J. Lu wrote:
>
> On Mon, Jul 7, 2025 at 11:08 PM Jason Merrill wrote:
> >
> > On 7/1/25 5:36 PM, H.J. Lu wrote:
> > > On Tue, Jul 1, 2025 at 9:37 PM Jason Merrill wrote:
> > >>
> > >> On 6/30/25 7:03 PM, H.J. Lu wrote:
> > >>> On Mon, Jun 30, 2025 at 10:36 PM Ja
> Am 08.07.2025 um 07:21 schrieb Jakub Jelinek :
>
> On Mon, Jul 07, 2025 at 07:51:52PM -0400, Siddhesh Poyarekar wrote:
>>> On 2025-07-07 17:47, Jakub Jelinek wrote:
>>> Even 6 arguments is IMHO too much.
>>> /* Expand the IFN_ACCESS_WITH_SIZE function:
>>>ACCESS_WITH_SIZE (REF_TO_OBJ, RE
When we compute the constraint for something like
MEM[(const struct QStringView &)&tok2 + 32] we go and compute
what (const struct QStringView &)&tok2 + 32 points to and then
add subvariables to its dereference that possibly fall in the
range of the access according to the original refs size. In
d
On Mon, 7 Jul 2025, Tamar Christina wrote:
> > -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 used ao_ref_init_from_ptr_and_size for .MASK_STORE but
alias-analysis will use the specified size to disambiguate
against smaller objects. For .MASK_STORE we instead have to
make the access size unspecified but we can still constrain
the access extent based on the maximum size possible.
Boots
On Mon, 7 Jul 2025, Hongtao Liu wrote:
> On Mon, Jul 7, 2025 at 3:18 PM Hongtao Liu wrote:
> >
> > On Fri, Jul 4, 2025 at 5:45 PM Richard Biener wrote:
> > >
> > > The following adds a x86 tuning to enable the use of AVX512 masked
> > > epilogues in cas
On Sat, Jul 5, 2025 at 2:10 PM Siddhesh Poyarekar wrote:
>
> On 2025-07-05 07:23, Richard Biener wrote:
> >> OK, should I revert right away or can we wait till Qing returns on Monday?
> >
> > Monday is OK with me.
> >
>
> Thanks, so I thought about th
On Fri, 4 Jul 2025, Richard Sandiford wrote:
> Richard Biener writes:
> > @@ -1738,8 +1738,13 @@ protected:
> >unsigned int m_suggested_unroll_factor;
> >
> >/* The suggested mode to be used for a vectorized epilogue or VOIDmode,
> >
> Am 06.07.2025 um 23:23 schrieb Andrew Pinski :
>
> These builtins requires a constant integer for the third argument but
> currently
> there is assert rather than error. This fixes that and updates the
> documentation too.
> Uses the same terms as was being used for the __builtin_prefetch
> Am 06.07.2025 um 02:22 schrieb Andrew Pinski :
>
> For GIMPLE_SINGLE_RHS, we don't currently test LHS for some invalid cases.
> In this case all constants and ADDR_EXPR should be invalid on the LHS.
> Also for vector (non-empty) constructors, the LHS needs to be an
> is_gimple_reg.
>
> Thi
> Am 05.07.2025 um 17:41 schrieb Andrew Pinski :
>
> The cdce code introduces a test for a NaN using the EQ_EXPR code.
> The problem is EQ_EXPR can cause an exception with non-call exceptions
> and signaling nans turned on. This is now correctly rejected by the verfier
> since r16-241-g4c40e3d
> Am 05.07.2025 um 12:19 schrieb Siddhesh Poyarekar :
>
> On 2025-07-05 02:45, Richard Biener wrote:
>>>> Am 04.07.2025 um 19:57 schrieb Siddhesh Poyarekar :
>>>
>>> On 2025-07-04 08:12, Siddhesh Poyarekar wrote:
>>>>> On 2025-07-0
> Am 04.07.2025 um 19:57 schrieb Siddhesh Poyarekar :
>
> On 2025-07-04 08:12, Siddhesh Poyarekar wrote:
>>> On 2025-07-04 08:08, Siddhesh Poyarekar wrote:
>>> gcc/ChangeLog:
>>>
>> I forgot to add the PR number to the ChangeLog entries, I've fixed it in my
>> commit message.
>>> * tree-
> Am 04.07.2025 um 23:19 schrieb H.J. Lu :
>
> On Fri, Jul 4, 2025 at 6:07 PM Richard Biener
> wrote:
>>
>>> On Fri, Jul 4, 2025 at 10:33 AM H.J. Lu wrote:
>>>
>>> On Fri, Jul 4, 2025 at 4:28 PM Richard Biener
>>> wrote:
>
> Am 04.07.2025 um 18:57 schrieb Richard Sandiford :
>
> In the tree codes and optabs, the "hi" in a vector hi/lo pair means
> "most significant" and the "lo" means "least significant", with
> sigificance following GCC's normal endian expectations. Thus on
> big-endian targets, the hi part ha
The following avoids translating expressions through volatile
copies.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/120944
* tree-ssa-sccvn.cc (vn_reference_lookup_3): Gate optimizations
invalid when volatile is involved.
* gcc.
On Fri, Jul 4, 2025 at 10:33 AM H.J. Lu wrote:
>
> On Fri, Jul 4, 2025 at 4:28 PM Richard Biener
> wrote:
> >
> > On Fri, Jul 4, 2025 at 10:21 AM H.J. Lu wrote:
> > >
> > > On Fri, Jul 4, 2025 at 4:10 PM H.J. Lu wrote:
> > > >
&g
On Wed, Jul 2, 2025 at 7:31 AM wrote:
>
> From: Pan Li
>
> This patch would like to try to match the SAT_MUL during
> widening-mul pass, aka below pattern.
>
> NT __attribute__((noinline))
> sat_u_mul_##NT##_fmt_1 (NT a, NT b)
> {
> uint128_t x = (uint128_t)a * (uint128_t)b;
> NT ma
On Wed, Jul 2, 2025 at 7:31 AM wrote:
>
> From: Pan Li
>
> This patch would like to add the middle-end presentation for the
> unsigend saturation mul. Aka set the result of mul to the max
> when overflow.
>
> Take uint8_t as example, we will have:
>
> * SAT_MUL (1, 127) => 127.
> * SAT_MUL (2,
The following adds a x86 tuning to enable the use of AVX512 masked
epilogues in cases we heuristically determine it to be not detrimental
by high chance. Basically problematic cases are when there are
data streams that are both stored and loaded from and an outer loop
could end up executing only t
Targets recently got the ability to request the vector mode to be
used for a vector epilogue (or the epilogue of a vector epilogue). The
following adds the ability for it to indicate the epilogue should use
loop masking, irrespective of the --param vect-partial-vector-usage
default setting.
The p
On Fri, Jul 4, 2025 at 10:21 AM H.J. Lu wrote:
>
> On Fri, Jul 4, 2025 at 4:10 PM H.J. Lu wrote:
> >
> > On Fri, Jul 4, 2025 at 4:09 PM H.J. Lu wrote:
> > >
> > > On Fri, Jul 4, 2025 at 4:02 PM Richard Biener
> > > wrote:
>
> > > >
1 - 100 of 3388 matches
Mail list logo
