On Sun, Jun 1, 2025 at 12:54 PM Eric Botcazou wrote:
>
> > If one wants to look up something in symbol table during late optimization
> > one is supposed to check that ::get does not return NULL and be conservative
> > otheriwse. So your change for PR120156 was OK with me, but I did not
> > expli
On Sun, Jun 1, 2025 at 9:14 AM H.J. Lu wrote:
>
> Move get_call_rtx_from to final.c and call call_from_call_insn.
>
> PR other/120493
> * final.cc (call_from_call_insn): Change the argument type to
> const rtx_call_insn *.
> (get_call_rtx_from): New.
> * rtl.h (is_a_helper ::test): New.
> (get_cal
On Sat, May 31, 2025 at 8:41 PM Andrew Pinski wrote:
>
> Currently gimple_folder::convert_and_fold calls create_tmp_var; that means
> while in ssa form,
> the pass which calls fold_stmt will always have to update the ssa (via
> TODO_update_ssa or otherwise).
> This seems not very useful since we
> Am 01.06.2025 um 04:16 schrieb Andrew Pinski :
>
> There are two places which forwprop replaces an original load to a few
> different loads.
> Both can set the vuse manually instead of relying on update_ssa.
> One is doing a complex load followed by REAL/IMAG_PART only
> And the other is ve
> Am 31.05.2025 um 18:29 schrieb Andrew Pinski :
>
> SSA form is kept up to date except for VOPs when CFG was removed
> so only set update ssa TODO if the CFG has changed. This is still
> sets the TODO in more cases than it is needed but it reduces enough
> to make difference.
>
> Bootstrappd
On Sat, May 31, 2025 at 11:07 AM Andrew Pinski wrote:
>
> Right now the only place where CCP needs to have the virtual op renamed is
> after inserting clobbers which come right before __builtin_stack_restore.
> So let's manually do the correct thing so we can remove the TODO_update_ssa
> todo.
O
On Sat, May 31, 2025 at 4:17 AM Andrew Pinski wrote:
>
> This is a follow up to the patch set starting at
> https://gcc.gnu.org/pipermail/gcc-patches/2014-April/386650.html.
>
> Currently TODO_verify_{il,all} is set by a few passes as TODOs afterwards but
> we don't need to do that any more. Thos
The following makes sure we are not lowering single-element interleaving
schemes in a way that defeats load vectorizing later but allows the
VMAT_ELEMENTWISE fallback to be used.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/120457
* tree-vect-s
When doing early break vectorization of a loop with a conditional
reduction the epilog creation code is confused as to before which exit
to insert the conditional reduction induction IV update. The
following make sure this is done before the main IV exit.
Bootstrapped and tested on x86_64-unknown
The following fixes conditional store elimination and store motion
so they consider stores to STRING_CSTs as trapping.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/120341
* tree-ssa-loop-im.cc (can_sm_ref_p): STRING_CSTs are readonly.
*
On Fri, May 30, 2025 at 11:30 AM Jan Hubicka wrote:
>
> Hi,
> > >
> > > Hi,
> > >
> > > the attached Ada testcase compiled with -O2 -gnatn makes the compiler
> > > crash in
> > > vect_can_force_dr_alignment_p during SLP vectorization:
> > >
> > > if (decl_in_symtab_p (decl)
> > > && !symt
On Fri, May 23, 2025 at 10:49 PM Qing Zhao wrote:
>
> Hi, Richard,
>
> Thanks a lot for your comments and questions.
> Please see my answers embedded below:
>
> > On May 19, 2025, at 06:44, Richard Biener
> > wrote:
> >
> > On Fri, May 16, 2025 at 3
On Fri, May 30, 2025 at 3:53 AM Andrew Pinski wrote:
>
> Only have cleanup cfg happen if scc copy did some proping.
> This should be a small compile time improvement by not doing cleanup
> cfg if scc copy does nothing.
>
> Also removes TODO_update_ssa since it should not be needed.
OK.
Richard.
On Thu, May 29, 2025 at 11:48 PM Andrew Pinski wrote:
>
> On Tue, May 27, 2025 at 5:14 AM Richard Biener
> wrote:
> >
> > On Tue, May 27, 2025 at 5:02 AM Andrew Pinski
> > wrote:
> > >
> > > This was noticed in the review of copy propagation for ag
On Wed, May 28, 2025 at 6:55 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Thu, May 22, 2025 at 12:19 PM Richard Sandiford
> > wrote:
> >>
> >> As the rtl.texi documentation of RTX_AUTOINC expressions says:
> >>
> >> If
On Thu, May 29, 2025 at 11:38 AM Eric Botcazou wrote:
>
> Hi,
>
> the attached Ada testcase compiled with -O2 -gnatn makes the compiler crash in
> vect_can_force_dr_alignment_p during SLP vectorization:
>
> if (decl_in_symtab_p (decl)
> && !symtab_node::get (decl)->can_increase_alignment_p
On Thu, May 29, 2025 at 12:27 PM Konstantinos Eleftheriou
wrote:
>
> Hi Richard, thanks for the response.
>
> On Mon, May 26, 2025 at 11:55 AM Richard Biener wrote:
> >
> > On Mon, 26 May 2025, Konstantinos Eleftheriou wrote:
> >
> > > In `store_bit_field_
On Thu, May 29, 2025 at 8:06 AM Kito Cheng wrote:
>
> `--enable-default-pie` is an option to specify whether to enable
> position-independent executables by default for `target`.
>
> However c++tools is build for `host`, so it should just follow
> `--enable-host-pie` option to determine whether to
> Am 29.05.2025 um 08:28 schrieb Jakub Jelinek :
>
> On Tue, Apr 22, 2025 at 01:27:34PM +0200, Richard Biener wrote:
>> This is OK for trunk after we've released GCC 15.1.
>
> This change broke build on non-USING_MMAP hosts.
> I don't have access to one, so
xpand_vec_cmp_expr_p (TREE_TYPE (@1), type, LT_EXPR
> (lt @c0 (convert @1)))
> ```
> ...applied across all expressions?
Yes, this is what I would suggest.
Richard.
> Kind Regards,
> Icen
>
>
> From: Richard Biener
> Sent:
On Wed, 28 May 2025, Thomas Schwinge wrote:
> Hi!
>
> On 2025-05-28T09:18:29+0200, Richard Biener wrote:
> > On Tue, 27 May 2025, Thomas Schwinge wrote:
> >> "'GIMPLE_RETURN' vs. 'RESULT_DECL' if 'aggregate_value_p'" isn't ac
On Tue, May 27, 2025 at 6:02 PM Robin Dapp wrote:
>
> This removes the non-SLP paths that were made unreachable in the
> previous patch.
This short series is OK. Please squash the two commits before pushing.
Thanks,
Richard.
> gcc/ChangeLog:
>
> * tree-vect-stmts.cc (vectorizable_load)
On Tue, 27 May 2025, Thomas Schwinge wrote:
> Hi!
>
> On 2025-05-23T17:01:31+0200, Richard Biener wrote:
> > Am 23.05.2025 um 16:49 schrieb Thomas Schwinge :
> >> This fell out of me looking into PR119835. This doesn't resolve the
> >> underlying
>
\\s*,\\s*\\{\\s*0(,\\s*0){3}\\s*\\}\\s*>\\s*;"
> "original" } } */
> +/* { dg-final { scan-tree-dump
> ".*\\*tD\\.\\d+\\s*=\\s*\\{\\s*0(,\\s*0){3}\\s*\\}\\s*;" "original" } } */
> +/* { dg-final { scan-tree-dump
> ".*\\*zD\\.\\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){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){3}\\s*\\}\\s*>\\s*;"
> "original" } } */
> +/* { dg-final { scan-tree-dump
> ".*\\*zD\\.\\d+\\s*=\\s*\\{\\s*-1(,\\s*-1){3}\\s*\\}\\s*;" "original" } } */
> +/* { dg-final { scan-tree-dump
> ".*\\*tD\\.\\d+\\s*=\\s*\\{\\s*0(,\\s*0){3}\\s*\\}\\s*;" "original" } } */
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
The PR shows that when using std::clamp from the C++ standard library
and there is surrounding code using exceptions then phiprop can fail
to simplify the code so phiopt can turn the clamping into efficient
min/max operations.
The validation code is needlessly complicated, steming from the
time we
On Tue, May 27, 2025 at 2:53 PM Robin Dapp wrote:
>
> > On Tue, May 27, 2025 at 2:44 PM Robin Dapp wrote:
> >>
> >> > This mangles in the non-SLP path removal, can you please separate that
> >> > out?
> >>
> >> So should patch 1/2 do more than it does, i.e. fully remove the non-slp
> >> paths rat
On Tue, May 27, 2025 at 2:44 PM Robin Dapp wrote:
>
> > This mangles in the non-SLP path removal, can you please separate that
> > out?
>
> So should patch 1/2 do more than it does, i.e. fully remove the non-slp
> paths rather than just if (0) them?
There should be a separate 2/3 that does this,
On Tue, May 27, 2025 at 2:40 PM Martin Jambor wrote:
>
> Hi,
>
> On Wed, May 21 2025, Eric Botcazou wrote:
> > Hi,
> >
> > IPA-SRA generally works fine in the presence of reverse Scalar_Storage_Order
> > by propagating the relevant flag onto the newly generated MEM_REFs. However
> > we have been
_p condition looks redundant -
neither the type of the result nor the type of the predicate
are changing. So you can drop this here I think.
Thanks,
Richard.
> (for cnd (cond vec_cond)
> /* (a != b) ? (a - b) : 0 -> (a - b) */
> (simplify
>
--
Richard Biener
SUSE Software S
On Tue, 20 May 2025, Jakub Jelinek wrote:
> Hi!
>
> The following patch fixes
> FAIL: gcc.dg/dfp/bitint-1.c (test for excess errors)
> FAIL: gcc.dg/dfp/bitint-2.c (test for excess errors)
> FAIL: gcc.dg/dfp/bitint-3.c (test for excess errors)
> FAIL: gcc.dg/dfp/bitint-4.c (test for excess errors)
On Wed, May 21, 2025 at 6:05 PM MCC CS wrote:
>
> Dear Richard,
>
> Thank you so much for your reply. I submitted the patch for the third case to
> LLVM before I've received your reply, and they said the same thing,
> that it would probably be used outside of loops as well and it would inflict
> a
On Tue, May 20, 2025 at 11:35 AM Robin Dapp wrote:
>
> This patch enables strided loads for VMAT_STRIDED_SLP. Instead of
> building vectors from scalars or other vectors we can use strided loads
> directly when applicable.
>
> The current implementation limits strided loads to cases where we can
On Tue, May 27, 2025 at 5:02 AM Andrew Pinski wrote:
>
> As part of the review of copy prop for aggregates, it was
> mentioned there should be some statistics added, and I noticed
> the memcpy->memset was missing the statistics too. So this adds
> that.
OK.
> gcc/ChangeLog:
>
> * tree-ss
On Tue, May 27, 2025 at 5:02 AM Andrew Pinski wrote:
>
> This was noticed in the review of copy propagation for aggregates
> patch, instead of checking for a NULL or a non-ssa name of vuse,
> we should instead check if it the vuse is a default name and stop
> then.
>
> Bootstrapped and tested on x
On Mon, May 26, 2025 at 4:27 PM Jason Merrill wrote:
>
> Tested x86_64-pc-linux-gnu, OK for trunk?
LGTM.
Richard.
> Iain, will you verify that one of your coroutine testcases breaks without this
> fix? I don't think lambda or anonymous union uses of DECL_VALUE_EXPR can
> break
> in the same w
On Tue, May 27, 2025 at 3:06 AM liuhongt wrote:
>
> > > It's https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119181
> >
> > Please mention that in the changelog. Also ...
>
> Changed.
>
> > Please put this condition in the set of conds we test in the else branch of
> > ...
> >
> > > > /*
TODO: Consider assigning different costs to different scalar
> statements. */
>
> - scalar_single_iter_cost = loop_vinfo->scalar_costs->total_cost ();
> + scalar_single_iter_cost = (loop_vinfo->scalar_costs->total_cost ()
> + * param_vect_scalar_cost_multiplier) / 100;
>
>/* Add additional cost for the peeled instructions in prologue and epilogue
> loop. (For fully-masked loops there will be no peeling.)
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
oll = 0;
> +
>/* Free SLP instances here because otherwise stmt reference counting
> won't work. */
>slp_instance instance;
> diff --git a/gcc/tree-vectorizer.h b/gcc/tree-vectorizer.h
> index
> a2f33a5ecd60288fe7f28ee639ff8b6a77667796..8fd8c10ec64f7241d6b09749
On Mon, May 19, 2025 at 10:42 AM Li Xu wrote:
>
> From: xuli
>
> This patch would like to support vector SAT_ADD when one of the op
> is singed IMM.
>
> void __attribute__((noinline)) \
> vec_sat_s_add_imm_##T##_fmt_1##_##INDEX (T *out, T *op_1, unsigned limi
On Mon, May 19, 2025 at 10:41 AM Li Xu wrote:
>
> From: xuli
>
> This patch would like to support .SAT_ADD when IMM=-1.
>
> Form1:
> T __attribute__((noinline)) \
> sat_s_add_imm_##T##_fmt_1##_##INDEX (T x) \
> {\
> T sum
On Sun, May 18, 2025 at 10:58 PM Andrew Pinski wrote:
>
> This implements a simple copy propagation for aggregates in the similar
> fashion as we already do for copy prop of zeroing.
>
> Right now this only looks at the previous vdef statement but this allows us
> to catch a lot of cases that show
On Fri, May 16, 2025 at 4:05 AM Hongtao Liu wrote:
>
> It's https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119181
Please mention that in the changelog. Also ...
> On Fri, May 16, 2025 at 10:02 AM liuhongt wrote:
> >
> > The patch tries to solve miss vectorization for below case.
> >
> > void
> >
The following adjusts the expected messages after -fopt-info-vec
was improved for (masked) epilogues.
Pushed.
* gcc.target/i386/vect-epilogues-5.c: Adjust.
---
gcc/testsuite/gcc.target/i386/vect-epilogues-5.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/tests
bject, or storing
> diff --git a/gcc/testsuite/gcc.target/i386/pr118873.c
> b/gcc/testsuite/gcc.target/i386/pr118873.c
> new file mode 100644
> index ..3a07c7cc87f9
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr118873.c
> @@ -0,0 +1,33 @@
> +/* { dg-d
On Fri, May 23, 2025 at 2:31 PM Alexander Monakov wrote:
>
> In PR 105965 we accepted a request to form FMA instructions when the
> source code is using a narrow generic vector that contains just one
> element, corresponding to V1SF or V1DF mode, while the backend does not
> expand fma patterns fo
> Am 23.05.2025 um 17:35 schrieb Hans-Peter Nilsson :
>
> The 6.7 version is what's in Debian 11. I'll commit this as
> obvious in a few hours.
Thanks- I’ve also seen this on SLES and ppenSUSE Leap.
Richard
> -- >8 --
> Commit r16-833-gfbb7f1cb5d3c8b appears to have broken builds with
> m
> Am 23.05.2025 um 16:49 schrieb Thomas Schwinge :
>
> This fell out of me looking into PR119835. This doesn't resolve the
> underlying
> issue, but instead of failing GIMPLE semantics verification just by chance in
> the 'GIMPLE pass: nrv' context, it makes the issue observable generally.
>
Status
==
The GCC 14 branch is open again for regression and documentation fixes.
Quality Data
Priority # Change from last report
--- ---
P10- 1
P2 603- 15
P3 133+ 23
P4
On Fri, 23 May 2025, Richard Biener wrote:
> The following makes update_web_docs_git work on branches without
> libgdiagnostic.
>
> I'm re-running update_web_docs_git with this, OK if it succeeds now?
One more bit, the find command also fails.
OK
The following makes update_web_docs_git work on branches without
libgdiagnostic.
I'm re-running update_web_docs_git with this, OK if it succeeds now?
Thanks,
Richard.
maintainer_scripts/
* update_web_docs_git: Conditionalize libgdiagnostic processing
on presence.
---
maintainer-
On Thu, May 22, 2025 at 3:11 AM Jeff Law wrote:
>
>
>
> On 5/18/25 10:38 AM, Andrew Pinski wrote:
> > While working on improving forwprop and removal of
> > forward_propagate_into_gimple_cond/forward_propagate_into_comparison,
> > I came cross a case where we end up with SSA_NAME in the resulting
On Thu, May 22, 2025 at 12:19 PM Richard Sandiford
wrote:
>
> As the rtl.texi documentation of RTX_AUTOINC expressions says:
>
> If a register used as the operand of these expressions is used in
> another address in an insn, the original value of the register is
> used. Uses of the register
> Am 22.05.2025 um 09:31 schrieb Jakub Jelinek :
>
> On Wed, May 21, 2025 at 12:48:21PM +0200, Jakub Jelinek wrote:
>> 2025-05-21 Jakub Jelinek
>>
>>* gimple-lower-bitint.cc (bitint_extended): New variable.
>>(bitint_large_huge::lower_shift_stmt): For LSHIFT_EXPR with
>>bitint_
On Wed, May 21, 2025 at 3:44 AM Andrew Pinski wrote:
>
> This was introduced by r15-1797-gd8fe4f05ef448e . I had missed that
> the LHS of the cabs call could be NULL. This seems to only happen at -O0,
> I tried to produce one that happens at -O1 but needed many different
> options to prevent the r
On Wed, May 21, 2025 at 12:30 AM Segher Boessenkool
wrote:
>
> On Mon, May 12, 2025 at 06:35:15PM -0400, Michael Meissner wrote:
> > On Mon, May 12, 2025 at 01:24:04PM +0530, Surya Kumari Jangala wrote:
> > > Hi Mike,
> > > Irrespective of whether -Ofast is used or not, should’nt we generate
> >
On Thu, May 15, 2025 at 10:29 AM MCC CS wrote:
>
> Dear all,
>
> Here's my patch for PR120265. Bootstrapped and tested on aarch64 that it
> causes no regressions. I also added a testcase. I'd be grateful
> if you could commit it.
>
> Otherwise, feedback to improve it is welcome.
>
> Many thanks
>
On Thu, May 15, 2025 at 10:04 AM liuhongt wrote:
>
> 1) Optimize (a >> 1) + (b >> 1) + ((a | b) & 1) to .AVG_CEIL (a, b)
> 2) Optimize (a | b) - ((a ^ b) >> 1) to .AVG_CEIL (a, b)
>
> Prof is at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118994#c6
>
> Bootstrapped and regtested on x86_64-pc-linu
On Mon, 19 May 2025, Richard Sandiford wrote:
Richard Biener writes:
On Fri, 16 May 2025, Richard Sandiford wrote:
The simple prototype below uses a separate flag from the epilogue
mode, but I wonder how we want to more generally want to handle
whether to use masking or not when iterating
> Am 20.05.2025 um 08:48 schrieb Jakub Jelinek :
>
> Hi!
>
> When adding _BitInt support I was hoping all or most of arches would
> implement it already for GCC 14. That didn't happen and with
> new hosts adding support for _BitInt for GCC 16 (s390x-linux and as was
> posted today loongarch-
On Mon, 19 May 2025, Jakub Jelinek wrote:
Hi!
The big-endian _BitInt support in libgcc was written without any
testing and so I haven't discovered I've made one mistake in it
(in multiple places).
The bitint_reduce_prec function attempts to optimize inputs
which have some larger precision but a
On Mon, 19 May 2025, Jakub Jelinek wrote:
Hi!
On s390x-linux I've run into the gcc.dg/torture/bitint-27.c test ICEing in
build_nonstandard_integer_type called from convert_affine_scev (not sure
why it doesn't trigger on x86_64/aarch64).
The problem is clear, when ct is a BITINT_TYPE with some l
On Mon, 19 May 2025, Tamar Christina wrote:
-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
OK
On Tue, May 20, 2025 at 6:20 AM Alexandre Oliva wrote:
>
>
> Some tsvc tests add vect_early_break options without requiring the
> feature to be available. Add the requirements.
>
> Regstrapped on x86_64-linux-gnu. Also tested with gcc-14 on aarch64-,
> arm-, x86-, and x86_64-vxworks7r2. Ok
On Mon, May 19, 2025 at 4:14 PM Konstantinos Eleftheriou
wrote:
>
> This patch adds the `bitmap_is_range_set_p` function in sbitmap,
> which checks if all the bits in a range are set. This function
> calls `bitmap_bit_in_range_p_1`, which has been updated to use
> the `any_inverted` parameter. Whe
On Fri, May 16, 2025 at 3:34 PM Qing Zhao wrote:
>
> Control this with a new option -fdiagnostics-details.
>
> $ cat t.c
> extern void warn(void);
> static inline void assign(int val, int *regs, int *index)
> {
> if (*index >= 4)
> warn();
> *regs = val;
> }
> struct nums {int vals[4];};
>
> Am 18.05.2025 um 08:26 schrieb Andrew Pinski :
>
> Right now phiopt has the same code as mark_lhs_in_seq_for_dce
> inlined into match_simplify_replacement. Instead let's use the
> function in gimple-fold that does the same thing.
>
> Bootstrapped and tested on x86_64-linux-gnu.
Ok
Richard
> Am 16.05.2025 um 19:37 schrieb Richard Sandiford :
>
> genemit has traditionally used open-coded gen_rtx_FOO sequences
> to build up the instruction pattern. This is now the source of
> quite a bit of bloat in the binary, and also a source of slow
> compile times.
>
> Two obvious ways of t
On Wed, May 14, 2025 at 5:01 PM Andrew Pinski wrote:
>
> As sugguested in
> https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681507.html,
> this adds the aliasing walk limit.
OK for both.
Thanks,
Richard.
> gcc/ChangeLog:
>
> * tree-ssa-forwprop.cc (optimize_memcpy_to_memset): Add
On Fri, 16 May 2025, Richard Sandiford wrote:
> Richard Biener writes:
> > 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 th
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
setting.
The simple pr
On Mon, May 12, 2025 at 11:24 AM Eric Botcazou wrote:
>
> Hi,
>
> the function accepts all handled_component_p expressions and decodes them by
> means of get_inner_reference as expected, but bails out on bitfields:
>
> /* TODO: We can extract value of the small expression via shifting even
>
On Fri, May 9, 2025 at 5:00 AM Andrew Pinski wrote:
>
> This removes the ability to follow statements that can throw internally.
> This was suggested in bug report as a way to solve the issue here.
> The overhead is not that high since without non-call exceptions turned
> on, there is an early exi
On Tue, Apr 15, 2025 at 8:27 AM Eikansh Gupta wrote:
>
> The patterns can be simplified as shown below:
>
> (a != b) & ((a|b) != 0) -> (a != b)
> (a != b) | ((a|b) != 0) -> ((a|b) != 0)
>
> The similar simplification can be there for (a == b). This patch adds
> simplification for above patterns.
On Thu, May 15, 2025 at 5:55 AM Andrew Pinski wrote:
>
> On Wed, May 14, 2025 at 7:39 PM Andrew Pinski
> wrote:
> >
> > This is the next step in removing forward_propagate_into_comparison
> > and forward_propagate_into_gimple_cond; In the case of `((int)(a cmp b)) !=
> > 0`
> > we want to do th
On Wed, May 14, 2025 at 7:28 AM liuhongt wrote:
>
> So it won't do the unsafe truncation for double(1.001) to
> float(1.0)
> since there's precision loss.
> It's guarded by testcase pr103771-6.c
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for trunk?
>
> REAL_CST
On Wed, May 14, 2025 at 4:06 PM Spencer Abson wrote:
>
> Floating-point to integer conversions can be inexact or invalid (e.g., due to
> overflow or NaN). However, since users of operation_could_trap_p infer the
> bool FP_OPERATION argument from the expression's type, FIX_TRUNC_EXPR is
> consider
On Tue, May 13, 2025 at 12:47 AM Andrew Pinski wrote:
>
> With some functions, there might be the case where every stack variable is a
> live at the end of a
> basic block. If that is the case then it is known that all stack variables
> will conflict with each
> other so there is no reason to go
On Fri, May 16, 2025 at 1:05 AM Jeff Law wrote:
>
>
>
> On 5/15/25 11:18 AM, Richard Sandiford wrote:
> > The start_sequence/end_sequence interface was a big improvement over
> > the previous state, but one slightly awkward thing about it is that
> > you have to call get_insns before end_sequence
On Thu, May 15, 2025 at 8:22 PM Andrew Pinski wrote:
>
> I noticed that fowprop does not dump when forward_propagate_into_comparison
> did a change to the assign statement.
> I am actually using it to help guide changing/improving/add match patterns
> instead of depending on doing a tree "combiner
On Thu, May 15, 2025 at 7:02 PM Andrew MacLeod wrote:
>
> Recent changes to get_range_from_bitmask can sometimes turn a small
> range into an undefined one if the bitmask indicates the bits make all
> values impossible.
>
> range_cast () was not expecting this and checks for UNDEFINED before
> pef
Status
==
The GCC 14 branch is now frozen for the GCC 14.3 release, a release
candidate is being prepared.
All changes to the branch require release manager approval.
Previous Report
===
https://gcc.gnu.org/pipermail/gcc/2025-April/245990.html
d data dependencies, or the loop is being
> @@ -1094,6 +1098,7 @@ public:
> #define LOOP_VINFO_CHECK_UNEQUAL_ADDRS(L) (L)->check_unequal_addrs
> #define LOOP_VINFO_CHECK_NONZERO(L)(L)->check_nonzero
> #define LOOP_VINFO_LOWER_BOUNDS(L) (L)->lower_bounds
> +#def
On Wed, 14 May 2025, Tamar Christina wrote:
> > -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 vecto
On Tue, 13 May 2025, Tamar Christina wrote:
> > -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: [PATC
On Mon, 12 May 2025, Richard Sandiford wrote:
> Richard Biener writes:
> > The following moves vector lowering to before vectorization - in fact
> > to before DCE/forwprop and CSE. This gets us the chance to re-vectorize
> > the lowered form eventually. Note that when the
On Wed, May 14, 2025 at 9:34 PM Andrew Pinski wrote:
>
> This is the followup based on the review at
> https://inbox.sourceware.org/gcc-patches/cafiyyc3xeg75dswaf63zbu5uelpeaeohwgfogavydwouuj7...@mail.gmail.com/
> .
> We should put ADDR_EXPR last instead of just is_gimple_invariant_address ones.
>
On Wed, 14 May 2025, Richard Sandiford wrote:
> Richard Biener writes:
> > The following includes whether we vectorize an epilogue, whether
> > we use loop masking and what vectorization factor (unroll factor)
> > we use. So it's now
> >
> > t.c:4:21: op
On Wed, May 14, 2025 at 6:29 PM James K. Lowden
wrote:
>
> On Wed, 14 May 2025 11:04:50 +0200
> Rainer Orth wrote:
>
> > Work around what appears to be a GNU make bug handling MAKEFLAGS
>
> Before I say Yes, could someone please tell me why this rumored bug is
> responsible for so much boilerplat
On Wed, May 14, 2025 at 5:25 AM Kyle Huey wrote:
>
> For a debugger to display statically-allocated[0] TLS variables the compiler
> must communicate information[1] that can be used in conjunction with knowledge
> of the runtime enviroment[2] to calculate a location for the variable for
> each thre
The following includes whether we vectorize an epilogue, whether
we use loop masking and what vectorization factor (unroll factor)
we use. So it's now
t.c:4:21: optimized: loop vectorized using 64 byte vectors and unroll factor 32
t.c:4:21: optimized: epilogue loop vectorized using masked 64 byte
With the avx512_two_epilogues tuning enabled for zen4 and zen5
the gcc.target/i386/vect-epilogues-5.c testcase below regresses
and ends up using AVX2 sized vectors for the masked epilogue
rather than AVX512 sized vectors. The following patch rectifies
this and adds coverage for the intended behavi
The vect_get_{load,store}_cost API is used from both vectorizable_*
where we've done SLP analysis and from alignment peeling analysis
with is done before this and thus only stmt_vec_infos are available.
The following patch makes sure we pick the vector type relevant
for costing from the SLP node wh
The following changes the record_stmt_cost calls in
vectorizable_load/store to only pass the SLP node when costing
vector stmts. For now we'll still pass the stmt_vec_info,
determined from SLP_TREE_REPRESENTATIVE, so this merely cleans up
the API.
v2 does away with the idea to use stmt_info and n
On Wed, May 14, 2025 at 3:41 PM Alexander Monakov wrote:
>
> As a followup to PAREN_EXPR verification, let's ensure that CONJ_EXPR is
> only used with COMPLEX_TYPE. While at it, move the whole block towards
> the end of the switch, because unlike the other entries it needs to
> break out of the s
On Wed, May 14, 2025 at 3:24 PM Qing Zhao wrote:
>
> Hi,
>
> This patch set has been waiting for the Middle-end review for a very long
> time since last year.
>
> Could you Please take a look and let me know whether it’s ready for GCC16?
I plan to look at this next week while idling on a train.
On Wed, May 14, 2025 at 3:20 PM Andreas Schwab wrote:
Looks obvious to me.
Richard.
> * libiberty.h (mkstemps): Remove duplicate.
> ---
> include/libiberty.h | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/include/libiberty.h b/include/libiberty.h
> index d4e8791b14b..4ec9b
+return;
> > +
> > +for (int i = 0; i < 3; i++)
> > +{
> > +int res = c[i];
> > +int t = b[i * stride];
> > +if (a[i] != 0)
> > +res = t * d[i];
> > +c[i] = res;
> > +}
> > +}
> > +
> > +/* { dg-final { scan-tree-dump "vectorized 1 loops in function" "vect" } }
> > */
> > diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
> > index
> > fe6f3cf188e40396b299ff9e814cc402bc2d4e2d..b1b0a3682d450cc43250c20a4
> > 9983c1c30a986ad 100644
> > --- a/gcc/tree-vect-loop.cc
> > +++ b/gcc/tree-vect-loop.cc
> > @@ -4646,7 +4646,8 @@ vect_estimate_min_profitable_iters (loop_vec_info
> > loop_vinfo,
> > TODO: Consider assigning different costs to different scalar
> > statements. */
> >
> > - scalar_single_iter_cost = loop_vinfo->scalar_costs->total_cost ();
> > + scalar_single_iter_cost = loop_vinfo->scalar_costs->total_cost ()
> > + * (param_vect_scalar_cost_multiplier / 100);
> >
> >/* Add additional cost for the peeled instructions in prologue and
> > epilogue
> > loop. (For fully-masked loops there will be no peeling.)
> >
> >
> > --
>
--
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, May 13, 2025 at 7:23 PM Andrew Pinski wrote:
>
> When moving the optimize_memcpy_to_memset optimization to forwprop from
> fold_stmt, the marking
> of the bb to purge for eh cleanup was not happening for the local
> optimizations but only after
> the fold_stmt, this causes g++.dg/torture
> Am 14.05.2025 um 03:12 schrieb Andrew Pinski :
>
> We have code later on that verifies the code is a comparison. So let's
> try to catch it earlier. So it is easier to debug where the incorrect code
> gets set.
>
> Bootstrapped and tested on x86_64-linux-gnu.
Ok
> gcc/ChangeLog:
>
>*
> Am 14.05.2025 um 03:13 schrieb Andrew Pinski :
>
> Since the merge of the tuples branch (r0-88576-g726a989a8b74bf), the
> if:
> ```
> if (TREE_CODE_CLASS (gimple_cond_code (stmt)) != tcc_comparison)
> ```
> Will always be false so let's change it into an assert.
Ok
Richard
> gcc/ChangeL
1 - 100 of 3112 matches
Mail list logo