On Wed, 3 Apr 2024, Chung-Lin Tang wrote:
> Hi Richard, Thomas,
>
> On 2023/10/30 8:46 PM, Richard Biener wrote:
> >>
> >> What Chung-Lin's first patch does is mark the OMP clause for 'x' (not the
> >> 'x' decl itself!) as 'readonly', via a new
On Fri, Apr 12, 2024 at 5:07 AM HAO CHEN GUI wrote:
>
> Hi,
> This patch adds an optab for __builtin_isfinite. The finite check can be
> implemented on rs6000 by a single instruction. It needs an optab to be
> expanded to the certain sequence of instructions.
>
> The subsequent patches will
On Fri, Apr 12, 2024 at 10:10 AM HAO CHEN GUI wrote:
>
> Hi,
> This patch adds an optab for __builtin_isnormal. The normal check can be
> implemented on rs6000 by a single instruction. It needs an optab to be
> expanded to the certain sequence of instructions.
>
> The subsequent patches will
On Thu, May 16, 2024 at 8:50 AM Tamar Christina wrote:
>
> > -Original Message-
> > From: pan2...@intel.com
> > Sent: Thursday, May 16, 2024 5:06 AM
> > To: gcc-patches@gcc.gnu.org
> > Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; Tamar Christina
> > ; richard.guent...@gmail.com;
Now that we handle pt.null conservatively we can implement the missing
tracking of constant pool entries (aka STRING_CST) and handle
ptr-ptr compares using points-to info in ptrs_compare_unequal.
Bootstrapped on x86_64-unknown-linux-gnu, (re-)testing in progress.
Richard.
PR
e riscv specific part of course needs riscv approval.
> Pan
>
> -Original Message-
> From: Richard Biener
> Sent: Thursday, May 16, 2024 4:10 PM
> To: Li, Pan2
> Cc: Tamar Christina ; gcc-patches@gcc.gnu.org;
> juzhe.zh...@rivai.ai; kito.ch...@gmail.com; Liu, Hongtao
The following fixes points-to analysis which ignores the fact that
volatile qualified refs can result in any pointer.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
Btw, I noticed this working on ptr-vs-ptr compare simplification
using points-to info and running into
On Fri, Apr 5, 2024 at 8:14 PM Andrew Pinski wrote:
>
> On Fri, Apr 5, 2024 at 5:28 AM Manolis Tsamis wrote:
> >
> > If we consider code like:
> >
> > if (bar1 == x)
> > return foo();
> > if (bar2 != y)
> > return foo();
> > return 0;
> >
> > We would like the ifcombine
On Sun, May 12, 2024 at 3:40 PM Peter Damianov wrote:
>
> Currently, commands like:
> gcc -o file.c -lm
> will delete the user's code.
>
> This patch makes the linker write executables to a temp file, and then renames
> the temp file if successful. This fixes the case above, but has limitations.
On Tue, May 14, 2024 at 10:58 AM Manolis Tsamis wrote:
>
> New patch with the requested changes can be found below.
>
> I don't know how much this affects SCEV, but I do believe that we
> should incorporate this change somehow. I've seen various cases of
> suboptimal address calculation codegen
On Wed, May 15, 2024 at 1:36 PM Li, Pan2 wrote:
>
> > LGTM but you'll need an OK from Richard,
> > Thanks for working on this!
>
> Thanks Tamar for help and coaching, let's wait Richard for a while,!
OK.
Thanks for the patience,
Richard.
> Pan
>
> -Original Message-
> From: Tamar
DSE currently gives up when the path we analyze forks. This leads
to multiple missed dead store elimination PRs. The following fixes
this by recursing for each path and maintaining the visited bitmap
to avoid visiting CFG re-merges multiple times. The overall cost
is still limited by the same
On Thu, May 16, 2024 at 8:25 AM Hongyu Wang wrote:
>
> Hi,
>
> In ix86_override_options_after_change, calls to ix86_default_align
> and ix86_recompute_optlev_based_flags will cause mismatched target
> opt_set when doing cl_optimization_restore. Move them back to
> ix86_option_override_internal to
DSE currently gives up when the path we analyze forks. This leads
to multiple missed dead store elimination PRs. The following fixes
this by recursing for each path and maintaining the visited bitmap
to avoid visiting CFG re-merges multiple times. The overall cost
is still limited by the same
On Wed, 15 May 2024, Jakub Jelinek wrote:
> On Wed, May 15, 2024 at 01:41:04PM +0200, Richard Biener wrote:
> > PR middle-end/111422
> > * cfgexpand.cc (add_scope_conflicts_2): Handle PHIs
> > by recursing to their arguments.
> > ---
The gcc.c-torture/execute/pr111422.c testcase after installing the
sink pass improvement reveals that we also need to handle
_65 = + _58; _44 = + _43;
# _59 = PHI <_65, _44>
*_59 = 8;
g = {v} {CLOBBER(eos)};
...
n[0] =
*_59 = 8;
g = {v} {CLOBBER(eos)};
where we fail to
On Wed, May 15, 2024 at 12:29 PM Tamar Christina
wrote:
>
> Hi All,
>
> Some Neoverse Software Optimization Guides (SWoG) have a clause that state
> that for predicated operations that also produce a predicate it is preferred
> that the codegen should use a different register for the destination
and then invoke
'autoconf' from each directory.
At least that's how I do it. But my question was whether upstream
libtool has your fix or
whether this is a downstream patch against libtool.m4 which we need to carry.
Richard.
>
> From: Richard Biener
> Sent: Wednesday, May
The following removes the profile based heuristic limiting sinking
and instead uses post-dominators to avoid sinking to places that
are executed under the same conditions as the earlier location which
the profile based heuristic should have guaranteed as well.
To avoid regressing this moves the
since we updated libtool, is this fixed in libtool
upstream in the
same way? You are missing a ChangeLog entry which should indicate which
files were just re-generated and which ones you edited (and what part).
Richard.
> ____
> From: Richard Biener
> Sent: Wedne
On Wed, May 15, 2024 at 4:15 AM Hongtao Liu wrote:
>
> On Mon, May 13, 2024 at 3:40 PM Richard Biener
> wrote:
> >
> > On Mon, May 13, 2024 at 4:29 AM liuhongt wrote:
> > >
> > > As testcase in the PR, O3 cunrolli may prevent vectorization for the
>
On Tue, May 14, 2024 at 5:52 PM Andrew Pinski wrote:
>
> When I was checking to making sure that all of the bugs dealing
> with the case where gimple_can_duplicate_bb_p would return false was fixed,
> I noticed that the code which was checking if a call statement was
> returns_twice was checking
On Tue, May 14, 2024 at 10:27 PM trcrsired wrote:
>
> From: trcrsired
>
> When building native GCC for the x86_64-w64-mingw32 host, the compiler copies
> its library DLLs to the `bin` directory. However, in the case of a multilib
> configuration, both 32-bit and 64-bit libraries end up in the
On Tue, 14 May 2024, Qing Zhao wrote:
>
>
> > On May 14, 2024, at 13:14, Richard Biener wrote:
> >
> > On Tue, 14 May 2024, Qing Zhao wrote:
> >
> >>
> >>
> >>> On May 14, 2024, at 10:29, Richard Biener wrote:
> >>>
On Tue, 14 May 2024, Kees Cook wrote:
> On Tue, May 14, 2024 at 02:17:16PM +, Qing Zhao wrote:
> > The current major issue with the warning is: the constant index value 4
> > is not in the source code, it’s a compiler generated intermediate value
> > (even though it’s a correct value -:)).
On Tue, 14 May 2024, Qing Zhao wrote:
>
>
> > On May 14, 2024, at 10:29, Richard Biener wrote:
> >
[...]
> > It would of course
> > need experimenting since we can end up moving stmts and merging blocks
> > though the linear traces created by jump
On Tue, May 14, 2024 at 6:30 PM Andi Kleen wrote:
>
> > Looks generally OK though does this mean people can debug
> > programs using [[gnu::musttail]] only with optimized builds? It
> > seems to me we should try harder to make [[gnu::musttail]] work
> > at -O0 and generally behave the same at
The following revisits the fix for PR99954 which was observed as
causing missed memcpy recognition and instead using memmove for
non-aliasing copies. While the original fix mitigated bogus
recognition of memcpy the root cause was not properly identified.
The root cause is dr_analyze_indices
On Tue, 14 May 2024, Qing Zhao wrote:
>
>
> > On May 14, 2024, at 09:08, Richard Biener wrote:
> >
> > On Mon, 13 May 2024, Qing Zhao wrote:
> >
> >> -Warray-bounds is an important option to enable linux kernal to keep
> >> the
On Sat, May 4, 2024 at 5:06 PM Ben Boeckel wrote:
>
> The initial P1689 patches were written in 2019 and ended up having code
> move around over time ended up introducing a `struct` keyword to the
> implementation of `cpp_finish`. Remove it to match the rest of the file
> and its declaration in
On Sun, May 5, 2024 at 8:16 PM Andi Kleen wrote:
>
> gcc/ChangeLog:
>
> * doc/extend.texi: Document [[musttail]]
> ---
> gcc/doc/extend.texi | 22 --
> 1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index
On Sun, May 5, 2024 at 8:16 PM Andi Kleen wrote:
>
> - Give error messages for all causes of non sibling call generation
> - Don't override choices of other non sibling call checks with
> must tail. This causes ICEs. The must tail attribute now only
> overrides flag_optimize_sibling_calls
On Wed, May 8, 2024 at 9:37 PM Iain Sandoe wrote:
>
> Hi Folks,
>
> I’d like to land a viable solution to this issue if possible, (it is a show-
> stopper for the aarch64-darwin development branch).
I was looking as to how we handle __builtin_trap (whether we have an
optab for it) - we seem to
On Mon, May 6, 2024 at 4:49 PM wrote:
>
> From: Pan Li
>
> This patch depends on below scalar enabling patch:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650822.html
>
> For vectorize, we leverage the existing vect pattern recog to find
> the pattern similar to scalar and let the
On Mon, May 6, 2024 at 4:48 PM wrote:
>
> From: Pan Li
>
> This patch would like to add the middle-end presentation for the
> saturation add. Aka set the result of add to the max when overflow.
> It will take the pattern similar as below.
>
> SAT_ADD (x, y) => (x + y) | (-(TYPE)((TYPE)(x + y) <
; +{
> + int *val = >vals[index]; /* { dg-bogus "is above array bounds" } */
> +
> + assign(0,ptr, index);
> + assign(*val, ptr, index);
> +}
> diff --git a/gcc/tree-ssa-threadupdate.cc b/gcc/tree-ssa-threadupdate.cc
> index fa61ba9512b7..9f338dd4d54d 100644
> --- a/gcc/tree-ssa-threadupdate.cc
> +++ b/gcc/tree-ssa-threadupdate.cc
> @@ -2371,6 +2371,17 @@ back_jt_path_registry::adjust_paths_after_duplication
> (unsigned curr_path_num)
> }
> }
>
> +/* Set all the stmts in the basic block BB as IS_SPLITTED. */
> +
> +static void
> +set_stmts_in_bb_is_splitted (basic_block bb)
> +{
> + gimple_stmt_iterator gsi;
> + for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next ())
> +gimple_set_is_splitted (gsi_stmt (gsi), true);
> + return;
> +}
> +
> /* Duplicates a jump-thread path of N_REGION basic blocks.
> The ENTRY edge is redirected to the duplicate of the region.
>
> @@ -2418,6 +2429,10 @@ back_jt_path_registry::duplicate_thread_path (edge
> entry,
>basic_block *region_copy = XNEWVEC (basic_block, n_region);
>copy_bbs (region, n_region, region_copy, , 1, _copy, loop,
> split_edge_bb_loc (entry), false);
> + /* Mark all the stmts in both original and copied basic blocks
> + as IS_SPLITTED. */
> + set_stmts_in_bb_is_splitted (*region);
> + set_stmts_in_bb_is_splitted (*region_copy);
>
>/* Fix up: copy_bbs redirects all edges pointing to copied blocks. The
> following code ensures that all the edges exiting the jump-thread path
> are
>
--
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, May 13, 2024 at 8:28 PM Jan-Benedict Glaw wrote:
>
> On Mon, 2024-05-13 20:19:42 +0200, Jan-Benedict Glaw
> wrote:
> > On Tue, 2024-04-30 17:24:15 -0400, Andrew MacLeod
> > wrote:
> > > Bootstrapped on x86_64-pc-linux-gnu with no regressions. pushed.
> >
> > Starting with this patch
_ref1))
> - != TYPE_MAIN_VARIANT (TREE_TYPE (end_struct_ref2)))
> + && same_type_for_tbaa (TREE_TYPE (end_struct_ref1),
> + TREE_TYPE (end_struct_ref2)) != 1)
> return flags | ACCESS_PATH;
>
>/* Now compare all handled components of the access path.
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
its = vector_element_bits (ret_type); unsigned
> + int arg_elt_bits = vector_element_bits (arg_type); if (ret_elt_bits <
> + arg_elt_bits)
> +modifier = NARROW;
> + else if (ret_elt_bits > arg_elt_bits)
> +modifier = WIDEN;
> +
> + if (((code == FIX_TRUNC_EXPR && !flag_trappi
The following revisits the fix for PR99954 which was observed as
causing missed memcpy recognition and instead using memmove for
non-aliasing copies. While the original fix mitigated bogus
recognition of memcpy the root cause was not properly identified.
The root cause is dr_analyze_indices
On Mon, May 13, 2024 at 4:14 PM Robin Dapp wrote:
>
> > What happens if we simply remove all of the force_reg here?
>
> On x86 I bootstrapped and tested the attached without fallout
> (gcc188, so it's no avx512-native machine and therefore limited
> coverage). riscv regtest is unchanged.
> For
When enabling single-lane SLP and not splitting groups the fix for
PR60276 is no longer effective since it for unknown reason exempted
pure SLP. The following removes this exemption, making
gcc.dg/vect/pr60276.c PASS even with --param vect-single-lane-slp=1
Bootstrapped and tested on
The following refactors a bit how we perform SLP reduction group
discovery possibly making it easier to have multiple reduction
groups later, esp. with single-lane SLP.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-vect-slp.cc (vect_analyze_slp_instance): Remove
On Mon, 13 May 2024, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Friday, May 10, 2024 2:07 PM
> > To: Richard Biener
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: [PATCH] Allow patterns in SLP reductions
>
+
> +struct S
> +bar (T x)
> +{
> + W z = (W) x + 132;
> + return (struct S) { z >> B, (T) z };
> +}
> +
> +struct S
> +baz (T x, unsigned short y)
> +{
> + W z = (W) x + y;
> + return (struct S) { z >> B, (T) z };
> +}
> +
> +struct S
> +qux (unsigned short x, T y)
> +{
> + W z = (W) x + y;
> + return (struct S) { z >> B, (T) z };
> +}
> +
> +struct S
> +corge (T x, T y)
> +{
> + T w = x + y;
> + W z = (W) x + y;
> + return (struct S) { z >> B, w };
> +}
> +
> +struct S
> +garple (T x, T y)
> +{
> + W z = (W) x + y;
> + T w = x + y;
> + return (struct S) { z >> B, w };
> +}
> +
> +/* { dg-final { scan-tree-dump-times "ADD_OVERFLOW" 6 "widening_mul" {
> target { i?86-*-* x86_64-*-* } } } } */
>
> Jakub
>
>
--
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, May 13, 2024 at 8:18 AM Robin Dapp wrote:
>
> > How does this make a difference in the end? I'd expect say forwprop to
> > fix things?
>
> In general we try to only add the masking "boilerplate" of our
> instructions at split time so fwprop, combine et al. can do their
> work uninhibited
On Mon, May 13, 2024 at 4:29 AM liuhongt wrote:
>
> As testcase in the PR, O3 cunrolli may prevent vectorization for the
> innermost loop and increase register pressure.
> The patch removes the 1/3 reduction of unr_insn for innermost loop for UL_ALL.
> ul != UR_ALL is needed since some small loop
On Mon, May 13, 2024 at 3:39 AM Kewen.Lin wrote:
>
> Hi Joseph and Richi,
>
> Thanks for the suggestions and comments!
>
> on 2024/5/10 14:31, Richard Biener wrote:
> > On Thu, May 9, 2024 at 9:12 PM Joseph Myers wrote:
> >>
> >> On Wed, 8 May 2024, K
When loop distribution releases a PHI node of the original IL it
can end up clobbering memory that's re-used when it upon releasing
its RDG resets all stmt UIDs back to -1, even those that got released.
The fix is to avoid resetting UIDs based on stmts in the RDG but
instead reset only those
On Fri, May 10, 2024 at 3:18 PM Robin Dapp wrote:
>
> Hi,
>
> this only forces the first comparison operator into a register if it is
> not already suitable.
>
> Bootstrap and regtest is running on x86 and aarch64, successful on p10.
> Regtested on riscv.
How does this make a difference in the
On Fri, Mar 1, 2024 at 10:21 AM Richard Biener wrote:
>
> The following removes the over-broad rejection of patterns for SLP
> reductions which is done by removing them from LOOP_VINFO_REDUCTIONS
> during pattern detection. That's also insufficient in case the
> patte
On Fri, May 10, 2024 at 12:55 PM Di Zhao OS
wrote:
>
> This patch tries to fix pr114760 by checking for the
> variants explicitly. When recognizing bit counting idiom,
> include pattern "x * 2" for "x << 1", and "x / 2" for
> "x >> 1" (given x is unsigned).
>
> Bootstrapped and tested on
On Fri, May 10, 2024 at 12:54 PM Segher Boessenkool
wrote:
>
> On Fri, May 10, 2024 at 12:19:35PM +0200, Richard Biener wrote:
> > On Fri, May 10, 2024 at 11:06 AM Segher Boessenkool
> > wrote:
> > > *All* code using a cost will have to be inspected and possibly a
On Fri, May 10, 2024 at 11:24 AM Aldy Hernandez wrote:
>
> There are various calls into fold_range() that have the wrong type
> associated with the range temporary used to hold the result. This
> used to work, because we could store either integers or pointers in a
> Value_Range, but is no
On Fri, May 10, 2024 at 11:06 AM Segher Boessenkool
wrote:
>
> On Fri, May 10, 2024 at 04:50:10PM +0800, HAO CHEN GUI wrote:
> > Hi Richard,
> > Thanks for your comments.
> >
> > 在 2024/5/10 15:16, Richard Biener 写道:
> > > But if targets return sth
On Fri, May 10, 2024 at 10:54 AM John Paul Adrian Glaubitz
wrote:
>
> Hello Rainer,
>
> On Fri, 2024-05-10 at 10:20 +0200, Rainer Orth wrote:
> > > > Support for Solaris 11.3 had already been obsoleted in GCC 13. However,
> > > > since the only Solaris system in the cfarm was running 11.3, I've
On Fri, May 10, 2024 at 4:25 AM HAO CHEN GUI wrote:
>
> Hi,
>The cost return from set_src_cost might be zero. Zero for
> pattern_cost means unknown cost. So the regularization converts the zero
> to COSTS_N_INSNS (1).
>
>// pattern_cost
>cost = set_src_cost (SET_SRC (set), GET_MODE
On Thu, 9 May 2024, Jakub Jelinek wrote:
> On Thu, May 09, 2024 at 12:14:43PM +0200, Jakub Jelinek wrote:
> > On Thu, May 09, 2024 at 12:04:38PM +0200, Rainer Orth wrote:
> > > I just noticed that gcc/DATESTAMP wasn't updated yesterday and today,
> > > staying at 20240507.
> >
> > I think it is
computations out of loops.
> > -The pass is located in @file{tree-ssa-loop.cc} and described by
> > +The pass is located in @file{tree-ssa-loop-im.cc} and described by
> > @code{pass_lim}.
> >
> > -@item Loop nest optimizations
> > -
> > -This is a family of loop transformations that works on loop nests. It
> > -includes loop interchange, scaling, skewing and reversal and they are
> > -all geared to the optimization of data locality in array traversals
> > -and the removal of dependencies that hamper optimizations such as loop
> > -parallelization and vectorization. The pass is located in
> > -@file{tree-loop-linear.c} and described by
> > -@code{pass_linear_transform}.
> > -
> > -@item Removal of empty loops
> > -
> > -This pass removes loops with no code in them. The pass is located in
> > -@file{tree-ssa-loop-ivcanon.cc} and described by
> > -@code{pass_empty_loop}.
> > -
> > @item Unrolling of small loops
> >
> > This pass completely unrolls loops with few iterations. The pass
>
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
On Thu, May 9, 2024 at 9:12 PM Joseph Myers wrote:
>
> On Wed, 8 May 2024, Kewen.Lin wrote:
>
> > to widen IFmode to TFmode. To make build_common_tree_nodes
> > be able to find the correct mode for long double type node,
> > it introduces one hook mode_for_longdouble to offer target
> > a way to
On Fri, Mar 29, 2024 at 8:02 PM Jørgen Kvalsvik wrote:
>
> This is a prototype for --include/--exclude flags, and I would like a
> review of both the approach and architecture, and the implementation,
> plus feedback on the feature itself. I did not update the manuals or
> carefully extend
On Wed, Mar 13, 2024 at 2:56 PM Ajit Agarwal wrote:
>
> Hello Richard:
>
> Currently, code sinking will sink code at the use points with loop having same
> nesting depth. The following patch improves code sinking by placing the sunk
> code in begining of the block after the labels.
>
> For
For pointer reductions we need to convert the initial value to
the vector component integer type.
Re-bootstrap and regtest running on x86_64-unknown-linux-gnu.
I've ran into this latent bug on the force-slp branch.
Richard.
* tree-vect-loop.cc (get_initial_defs_for_reduction): Convert
When we have a non-grouped access we bogously multiply by zero.
This shows most with single-lane SLP but also happens with
the multi-lane splat case.
Re-bootstrap & regtest running on x86_64-unknown-linux-gnu.
I've ran into this latent bug on the force-slp branch.
Richard.
*
On Wed, May 8, 2024 at 9:56 AM Stefan Schulze Frielinghaus
wrote:
>
> On s390 the following tests fail
>
> FAIL: gcc.dg/vect/pr109011-1.c -flto -ffat-lto-objects scan-tree-dump-times
> optimized " = .CLZ (vect" 1
> FAIL: gcc.dg/vect/pr109011-1.c -flto -ffat-lto-objects scan-tree-dump-times
When insert_updated_phi_nodes_for tries to skip pruning the IDF to
blocks dominated by the nearest common dominator of the set of
definition blocks it compares against ENTRY_BLOCK but that's never
going to be the common dominator. In fact if it ever were the code
fails to copy IDF to PRUNED_IDF,
case '_':
> + case '+':
> + a = *x;
> + x++;
> + continue;
> + default:
> + break;
> + }
> + break;
> +}
> + if (a == '0' || a == '+')
> +__builtin_abort ();
> +}
> +
> +int
> +main ()
> +{
> + foo ("_");
> +}
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
On Wed, May 8, 2024 at 7:50 AM Kewen.Lin wrote:
>
> Hi,
>
> As the discussion in PR112980, although the current
> implementation for -fpatchable-function-entry* conforms
> with the documentation (making N NOPs be consecutive),
> it's inefficient for both kernel and userspace livepatching
> (see
On Wed, May 8, 2024 at 5:25 AM Andrew Pinski wrote:
>
> We can optimize `a == nonnegative ? a : ABS`, `a > nonnegative ? a :
> ABS`
> and `a >= nonnegative ? a : ABS` into `ABS`. This allows removal of
> some extra comparison and extra conditional moves in some cases.
> I don't remember where I
On Tue, May 7, 2024 at 10:56 PM Andrew Pinski wrote:
>
> On Tue, May 7, 2024 at 1:45 PM Jeff Law wrote:
> >
> >
> >
> > On 4/30/24 9:21 PM, Andrew Pinski wrote:
> > > This adds a few more of what is currently done in phiopt's
> > > value_replacement
> > > to match. I noticed this when I was
hdr
> members from struct flex now (f->hdr.foo instead of f->foo). Sometimes
> this can be avoided by using a union, as I did in a recent refactoring
> in Linux: [4]
>
> For more complex cases in Linux we've handled this by using our
> "struct_group"[5] macro, which allows for a union and tagged struct to
> be constructed:
>
> struct flex {
> __struct_group(flex_hdr, hdr,,
> int foo;
> int bar;
> );
> char data[];
> };
> struct mid_flex { struct flex_hdr hdr; int n; int o; };
>
> Then struct flex member names don't have to change, but if anything is
> trying to get at struct flex::data through struct mid_flex::hdr, that'll
> need casting. But it _shouldn't_ since it has "n" and "o".
>
> -Kees
>
> [1] https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620122.html
> [2] https://github.com/RTEMS/rtems
> [3]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/container_of.h#n10
> [4] https://git.kernel.org/linus/896880ff30866f386ebed14ab81ce1ad3710cfc4
> [5]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/stddef.h?h=v6.8#n11
>
>
--
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 7, 2024 at 10:44 PM Joseph Myers wrote:
>
> On Fri, 3 May 2024, Richard Biener wrote:
>
> > So what I do not necessarily agree with is that we need to preserve
> > the multiplication with -fsignaling-nans. Do we consider a program doing
> >
> >
> Am 07.05.2024 um 18:02 schrieb Jakub Jelinek :
>
> Hi!
>
> The HF and BF modes have the same size/precision and neither is
> a subset nor superset of the other.
> So, using either __extendhfbf2 or __trunchfbf2 is weird.
> The expansion apparently emits __extendhfbf2, but on the libgcc side
> Am 07.05.2024 um 17:54 schrieb Jakub Jelinek :
>
> Hi!
>
> In r9-5742 we've started allowing to inline always_inline functions into
> functions which have disabled e.g. address sanitization even when the
> always_inline function is implicitly from command line options sanitized.
>
> This
When insert_updated_phi_nodes_for tries to skip pruning the IDF to
blocks dominated by the nearest common dominator of the set of
definition blocks it compares against ENTRY_BLOCK but that's never
going to be the common dominator, instead it will be at most its single
successor.
Re-bootstrap and
The following avoids re-allocating the var map BB vector by
pre-allocating it to the exact size needed when operating on the
whole function.
Re-bootstrap and regtest running on x86_64-unknown-linux-gnu.
* tree-ssa-live.cc (init_var_map): Pre-allocate vec_bbs vector
to the correct
This replaces a >= 0 block index check with the appropriate NUM_FIXED_BLOCKs,
the check is from times ENTRY_BLOCK was negative.
Re-bootstrap and regtest running on x86_64-unknown-linux-gnu.
* tree-into-ssa.cc (insert_updated_phi_nodes_for): Fix block
index check.
---
This avoids a tempoary when gimplifying reg = a ? b : c, re-using
the LHS of an assignment if that's a register.
Re-bootstrap and regtest running on x86_64-unknown-linux-gnu.
PR middle-end/27800
* gimplify.cc (gimplify_modify_expr_rhs): For a COND_EXPR
avoid a temporary
operand_equal_p already has checking code to verify the hash
is equal, avoid doing that again in gimplify_hasher::equal.
Re-bootstrap & regtest running on x86_64-unknown-linux-gnu.
* gimplify.cc (gimplify_hasher::equal): Remove redundant
checking.
---
gcc/gimplify.cc | 4
1
On Mon, 6 May 2024, Martin Uecker wrote:
> Am Montag, dem 06.05.2024 um 11:07 +0200 schrieb Richard Biener:
> > On Mon, 6 May 2024, Martin Uecker wrote:
> >
> > > Am Montag, dem 06.05.2024 um 09:00 +0200 schrieb Richard Biener:
> > > > On
On Fri, Jan 26, 2024 at 7:26 PM Roger Sayle wrote:
>
>
> This patch addresses a missed optimization opportunity in the RTL
> optimization passes. The function simplify_const_binary_operation
> will constant fold binary operators with two CONST_INT operands,
> and those with two CONST_VECTOR
On Tue, May 7, 2024 at 10:58 AM Stefan Schulze Frielinghaus
wrote:
>
> Ping. Ok for mainline?
OK.
Thanks,
Richard.
> On Thu, Apr 25, 2024 at 09:26:45AM +0200, Stefan Schulze Frielinghaus wrote:
> > Bitcount operations popcount, clz, and ctz are emulated for narrow modes
> > in case an
We're currently using size_t but at the same time storing them into
bitmaps which only support unsigned int index. The following makes
it unsigned int throughout, saving memory as well.
Re-bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
* cfgexpand.cc
Status
==
The GCC 14.1 release tarballs have been created, the releases/gcc-14
branch is open again for regression and documentation bugfixing.
GCC 14.2 can be expected in about two months unless something serious
changes the plans.
Quality Data
Priority # Change
On Mon, May 6, 2024 at 11:28 PM Andrew Pinski wrote:
>
> Like was done for -ffast-math in r0-105946-ga570fc16fa8056, we should
> document that -Ofast enables -fmath-errno, -funsafe-math-optimizations,
> -finite-math-only, -fno-trapping-math in their documentation.
>
> Note this changes the
The following implements the gist of the PR100923 fix in a leaner
(and more complete) way by realizing that all ao_ref_init_from_vn_reference
uses need to have an SSA name in the base valueized with availability
in mind. Instead of re-valueizing the whole chain of operands we can
simply only and
This makes sure we can create ao_refs from all VN operands we create.
Bootstrapped and tested on x86_64-unknown-linux-gnu. Will push later.
Richard.
* tree-ssa-sccvn.cc (ao_ref_init_from_vn_reference): Add
TARGET_MEM_REF support. Handle more bases.
---
gcc/tree-ssa-sccvn.cc |
The following further strengthens the check which convert expressions
we allow to vectorize as simple copy by resorting to
tree_nop_conversion_p on the vector components.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
PR tree-optimization/114921
*
On Mon, May 6, 2024 at 10:29 AM Peter0x44 wrote:
>
> On Mon May 6, 2024 at 8:14 AM BST, Richard Biener wrote:
> > On Sat, May 4, 2024 at 9:36 PM Peter Damianov wrote:
> > >
> > > Currently, commands like:
> > > gcc -o file.c -lm
> > > will delete
ptimization opportunities. */
> if (access_has_children_p (lacc))
> - generate_subtree_copies (lacc->first_child, rhs, lacc->offset,
> - 0, 0, gsi, true, true, loc);
> + {
> + generate_subtree_copies (lacc->first_c
On Mon, 6 May 2024, Martin Uecker wrote:
> Am Montag, dem 06.05.2024 um 09:00 +0200 schrieb Richard Biener:
> > On Sat, 4 May 2024, Martin Uecker wrote:
> >
> > > Am Freitag, dem 03.05.2024 um 21:16 +0200 schrieb Jakub Jelinek:
> > > > > On Fri, May 03,
On Sun, 5 May 2024, Rainer Orth wrote:
> Rainer Orth writes:
>
> >> On Fri, May 03, 2024 at 09:31:08AM -0400, David Malcolm wrote:
> >>> Jakub, Richi, Rainer: this is a non-trivial change that cleans up
> >>> analyzer C++ testsuite results on Solaris, but has a slight risk of
> >>> affecting
On Sat, May 4, 2024 at 9:36 PM Peter Damianov wrote:
>
> Currently, commands like:
> gcc -o file.c -lm
> will delete the user's code.
Since there's an error from the linker in the end (missing 'main'), I wonder if
the linker can avoid truncating/opening the output file instead? A trivial
On Sat, 4 May 2024, Sebastian Huber wrote:
> On 07.08.23 16:22, Qing Zhao via Gcc-patches wrote:
> > Hi,
> >
> > This is the 2nd version of the patch.
> > Comparing to the 1st version, the only change is to address Richard's
> > comment on refering a warning option for diagnosing deprecated
t; causes all sorts of problems with the Fortran frontend. */
> > > if (TREE_CODE (type1) == ARRAY_TYPE
> > > && TREE_CODE (type2) == ARRAY_TYPE)
> > > return -1;
> > > ...
> > > and later compares alias sets and the like.
> > > So
> Am 03.05.2024 um 20:37 schrieb Martin Uecker :
>
> Am Freitag, dem 03.05.2024 um 20:18 +0200 schrieb Jakub Jelinek:
>>> On Fri, May 03, 2024 at 08:04:18PM +0200, Martin Uecker wrote:
>>> A change that is not optimal but would avoid a lot of trouble is to
>>> only use the tag of the struct
> Am 03.05.2024 um 17:33 schrieb Martin Uecker :
>
> Am Freitag, dem 03.05.2024 um 14:13 +0200 schrieb Richard Biener:
>> TYPE_STRUCTURAL_EQUALITY_P is part of our type system so we have
>> to make sure to include that into the type unification done via
>> type
TYPE_STRUCTURAL_EQUALITY_P is part of our type system so we have
to make sure to include that into the type unification done via
type_hash_canon. This requires the flag to be set before querying
the hash which is the biggest part of the patch.
Bootstrapped and tested on x86_64-unknown-linux-gnu
On Thu, May 2, 2024 at 11:40 PM Andrew Pinski wrote:
>
> When we have :
> `void f (int y, int z) { int x = ( z++,y); }`
>
> This would have printed the decl's initializer without
> parentheses which can confusion if you think that is defining
> another variable rather than the compound
On Thu, May 2, 2024 at 11:40 PM Andrew Pinski wrote:
>
> Right now we don't print that a DECL_EXPR and we get
> basically double output of the decls and it looks confusing.
> This fixes that.
> for the simple example:
> `void foo () { int result = 0;}`
> This gives:
> ```
> {
> int result = 0;
1 - 100 of 25218 matches
Mail list logo
