> Hi,
>
> gcc/ChangeLog:
>
> 2021-06-29 Martin Jambor
>
> * cgraph.h (ipa_replace_map): New field force_load_ref.
> * ipa-prop.h (ipa_param_descriptor): Reduce precision of move_cost,
> aded new flag load_dereferenced, adjusted comments.
> (ipa_get_param_dereferenced):
Jan Hubicka
* ipa-modref.c (struct escape_entry): Use eaf_flags_t.
(dump_eaf_flags): Dump EAF_NOT_RETURNED
(eaf_flags_useful_p): Use eaf_fleags_t; handle const functions
and EAF_NOT_RETURNED.
(modref_summary::useful_p): Likewise.
(modref_summary_lto
Hi,
I have noticed that some entries was incorrectly added to C familly
while they are general improvements and I also think the option renaming
should go to canevats since renaming is hardly an improvement per se.
Since the change is rather obvious I plan to commit it after lunch so we
do not mis
> note that if you wrap foo () into another noinline
> wrap_foo () { foo (); return 1; } function then we need to make
> sure to not DCE this call either even though it only throws
> externally. Now the question is whether this testcase is valid
> (it should not abort). The documentation of 'pure
> Hi,
>
> the node and edge summaries defined in ipa-prop.h are probably the
> oldest in GCC and so it happened that they are the only ones using
> macros to look them up and create them. With Honza and Martin we
> agreed it is ugly and the macros should be removed and the ipa-prop
> summaries sh
> On Thu, Feb 08 2024, Martin Jambor wrote:
> > Hi,
> >
> > PR 113757 shows that the code which was meant to debug-reset and
> > remove SSAs defined by LHSs of calls redirected to
> > __builtin_unreachable can trigger also when speculative
> > devirtualization creates a call to a noreturn function
> [Public]
>
>
> Hi all,
>
>
>
> PFA, the patch that enables support for the next generation AMD Zen5 CPU via
> -march=znver5 with basic znver5 scheduler Model.
>
> We may update the scheduler model going forward.
>
>
>
> Good for trunk?
>
> Thanks and Regards
> Karthiban
>
>
> Patch i
> Hi!
Hi,
>
> On Thu, Feb 15, 2024 at 08:29:24AM +0100, Jakub Jelinek wrote:
> > 2024-02-15 Jakub Jelinek
> >
> > PR middle-end/113907
> > * ipa-icf.cc (sem_item_optimizer::merge_classes): Reset
> > SSA_NAME_RANGE_INFO and SSA_NAME_PTR_INFO on successfully ICF merged
> > functi
>
>
> On 3/11/24 4:38 PM, Eric Botcazou wrote:
> > Hi,
> >
> > this is a regression present on all active branches: the attached Ada
> > testcase
> > triggers an assertion failure when compiled with -O2 -gnatp -flto:
> >
> >/* Initialize the static chain. */
> >p = DECL_STRUCT_FUNCTIO
> On Tue, 12 Mar 2024, Jakub Jelinek wrote:
>
> > On Tue, Mar 12, 2024 at 05:21:58PM +0100, Jakub Jelinek wrote:
> > > On Tue, Mar 12, 2024 at 10:46:42AM +0100, Jan Hubicka wrote:
> > > > I am sorry for delaying this. I made the variant that simply compares
>
> On Wed, Mar 13, 2024 at 10:55:07AM +0100, Jan Hubicka wrote:
> > > > So the ipa_jump_func are I think the only thing that actually can differ
> > > > on the ICF merging candidates from value range POV.
> > >
> > > I agree. Btw, I would have approved
> > int test (int a)
> > {
> > return a>0 ? CST1: CST2;
> > }
> >
> > gets same hash value no matter what CST1/CST2 is. I added hasher and I
> > am re-running stats.
>
> The hash should be commutative here at least.
It needs to match what comparator is doing later, and sadly it does not
try to
> > We have wrong code with LTO, too.
>
> I know.
>
> > The problem is that IPA passes (and
> > not only that, loop analysis too) does analysis at compile time (with
> > value numbers in) and streams the info separately.
>
> And that is desirable, because otherwise it simply couldn't derive any
> > Otherwise
> > I will add your testcase for this patch and commit this one.
> > Statistically we almost never merge functions with different value
> > ranges (three in testsuite, 0 during bootstrap, 1 during LTO bootstrap
> > and probably few in LLVM build - there are 15 cases reported, but some
> > Patch is still OK, but ipa-ICF will only identify the functions if
> > static chain is unused. Perhaps just picking the winning candidate to be
> > version without static chain and making ipa-inline to not ICE when calls
> > with static chain lands to function with no static chain would help us
> > + if (POINTER_TYPE_P (TREE_TYPE (t1)))
> > +{
> > + if (SSA_NAME_PTR_INFO (t1))
> > + {
> > + if (!SSA_NAME_PTR_INFO (t2)
> > + || SSA_NAME_PTR_INFO (t1)->align != SSA_NAME_PTR_INFO (t2)->align
> > + || SSA_NAME_PTR_INFO (t1)->misalign != SSA_NAME_PTR_INFO
> > (
> gcc/ChangeLog:
>
> 2024-03-06 Martin Jambor
>
> PR ipa/108802
> PR ipa/114254
> * ipa-prop.cc (ipa_get_stmt_member_ptr_load_param): Fix case looking
> at COMPONENT_REFs directly from a PARM_DECL, also recognize loads from
> a pointer parameter.
> (ipa_anal
> Hello,
>
> Le 22/02/2024 à 19:29, Anbazhagan, Karthiban a écrit :
> (...)
> > gcc/config/i386/{znver4.md => zn4zn5.md} | 858 +-
>
> looks like the patch pushed to master lost the file rename.
> I get a bootstrap failure caused by the missing zn4zn5.md file.
>
> Can you ha
> __attribute__((noipa)) void
> bar (void)
> {
> __builtin_exit (0);
> }
>
> __attribute__((noipa)) void
> foo (void)
> {
> for (int i = 0; i < 1000; ++i)
> for (int j = 0; j < 1000; ++j)
> for (int k = 0; k < 1000; ++k)
> for (int l = 0; l < 1000; ++l)
> for (int m = 0; m < 1000; ++m)
Hi,
so what goes wrong with the testcase is the fact that after recursive
inliing we have large loop nest and consequently invalid profile since
every loop is predicted to iterate quite a lot. Rebuild_frequences
should take care of the problem, but it doesn't since there is:
if (freq_max < 1
> On Tue, Mar 5, 2024 at 1:45 PM H.J. Lu wrote:
> >
> > We can't instrument an IFUNC resolver nor its callees as it may require
> > TLS which hasn't been set up yet when the dynamic linker is resolving
> > IFUNC symbols.
> >
> > Add an IFUNC resolver caller marker to cgraph_node and set it if the
> > I am bit worried about commonly used functions getting "infected" by
> > being called once from ifunc resolver. I think we only use thread local
> > storage for indirect call profiling, so we may just disable indirect
> > call profiling for these functions.
>
> Will change it.
>
> > Also the
> We can't profile indirect calls to IFUNC resolvers nor their callees as
> it requires TLS which hasn't been set up yet when the dynamic linker is
> resolving IFUNC symbols.
>
> Add an IFUNC resolver caller marker to cgraph_node and set it if the
> function is called by an IFUNC resolver. Disabl
> gcc/ChangeLog:
>
> * builtins.cc (expand_builtin_fork_or_exec): Check
> condition_coverage_flag.
> * collect2.cc (main): Add -fno-condition-coverage to OBSTACK.
> * common.opt: Add new options -fcondition-coverage and
> -Wcoverage-too-many-conditions.
> *
> > > diff --git a/gcc/ipa-inline.cc b/gcc/ipa-inline.cc
> > > index dc120e6da5a..9502a21c741 100644
> > > --- a/gcc/ipa-inline.cc
> > > +++ b/gcc/ipa-inline.cc
> > > @@ -682,7 +682,7 @@ can_early_inline_edge_p (struct cgraph_edge *e)
> > > }
> > > gcc_assert (gimple_in_ssa_p (DECL_STRUCT
> > gcc/ChangeLog:
> >
> > 2024-03-15 Martin Jambor
> >
> > PR ipa/111571
> > * ipa-param-manipulation.cc
> > (ipa_param_body_adjustments::common_initialization): Avoid creating
> > duplicate replacement entries.
> >
> > gcc/testsuite/ChangeLog:
> >
> > 2024-03-15 Martin Jambor
> Hi,
>
> interactions of IPA-CP and IPA-SRA on the same data is a rather big
> source of issues, I'm afraid. PR 113964 is a situation where IPA-CP
> propagates an unsigned short in a union parameter into a function
> which itself calls a different function which has a same union
> parameter and
> + /* When there's a call that might not return the last iteration
> + is possibly partial. This matches what we check in invariant
> + motion.
> + ??? For the call argument evaluation it would be still OK. */
> + if (!may_have_exited
> + && is_g
> The following adjusts -flto option processing in lto-wrapper to have
> link-time -flto override any compile time setting.
>
> LTO-boostrapped on x86_64-unknown-linux-gnu, testing in progress.
>
> OK for trunk and branches? GCC 11 seems to be unaffected by this.
>
> Thanks,
> Richard.
>
>
Hi,
> gcc/ChangeLog:
> * common/config/i386/cpuinfo.h (get_amd_cpu): Recognize znver5.
> * common/config/i386/i386-common.cc (processor_names): Add znver5.
> (processor_alias_table): Likewise.
> * common/config/i386/i386-cpuinfo.h (processor_types): Add new zen
>
> Hi,
>
> In PR 113476 we have discovered that ipcp_param_lattices is no longer
> a POD and should be destructed. This patch does that, calling
> destructor on each element of the array containing them when the
> corresponding summary of a node is freed. An alternative would be to
> change the X
> Believe it or not, even though I have re-worked the internals of the
> lattices completely, the array itself is older than my involvement with
> GCC (or at least with ipa-cp.c ;-).
>
> So it being an array and not a vector is historical coincidence, as far
> as I am concerned :-). But that may
znver5?
> We will combine znver4 and znver5 scheduler descriptions into one
Thanks!
Honza
>
> Thanks and Regards
> Karthiban
>
> -Original Message-
> From: Jan Hubicka
> Sent: Monday, February 12, 2024 9:30 PM
> To: Anbazhagan, Karthiban
> Cc
Hi,
as demonstrated in the testcase, I forgot to check that profile is
present in tree-ssa-loop-split.
Bootstrapped and regtested x86_64-linux, comitted.
PR tree-optimization/111054
gcc/ChangeLog:
* tree-ssa-loop-split.cc (split_loop): Check for profile being present.
gcc/testsu
> On Tue, Feb 13 2024, Martin Jambor wrote:
> > On Mon, Feb 12 2024, Jan Hubicka wrote:
> >>> Believe it or not, even though I have re-worked the internals of the
> >>> lattices completely, the array itself is older than my involvement with
> >>> GCC (o
> Hi!
>
> The profile_count::dump (char *, struct function * = NULL) const;
> method has a single caller, the
> profile_count::dump (FILE *f, struct function *fun) const;
> method and for that going through a temporary buffer is just slower
> and opens doors for buffer overflows, which is exactly
Hello,
> This patch adds support in gcc+gcov for modified condition/decision
> coverage (MC/DC) with the -fcondition-coverage flag. MC/DC is a type of
> test/code coverage and it is particularly important for safety-critical
> applicaitons in industries like aviation and automotive. Notably, MC/DC
> This is a mostly straight port from the gcov-19.c tests from the C test
> suite. The only notable differences from C to D are that D flips the
> true/false outcomes for loop headers, and the D front end ties loop and
> ternary conditions to slightly different locus.
>
> The test for >64 conditio
> Hi!
>
> I'd like to ping 2 patches:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644580.html
>
>
> PR113617 P1 - Handle private COMDAT function symbol reference in
> >
> > The problem is that it doesn't help in this case.
> > If some optimization makes debugging of some function harder, normally it is
> > enough to recompile the translation unit that defines it with -O0/-Og, or
> > add optimize attribute on the function.
> > While in this case, the optimizati
> We can't instrument an IFUNC resolver nor its callees as it may require
> TLS which hasn't been set up yet when the dynamic linker is resolving
> IFUNC symbols. Add an IFUNC resolver caller marker to symtab_node to
> avoid recursive checking.
>
> gcc/ChangeLog:
>
> PR tree-optimization/1
> On Thu, Feb 29, 2024 at 02:31:05PM +0100, Jan Hubicka wrote:
> > I agree that debugability of user core dumps is important here.
> >
> > I guess an ideal solution would be to change codegen of noreturn functions
> > to callee save all registers. Performance of prolog
> On Thu, Feb 29, 2024 at 5:39 AM Jan Hubicka wrote:
> >
> > > We can't instrument an IFUNC resolver nor its callees as it may require
> > > TLS which hasn't been set up yet when the dynamic linker is resolving
> > > IFUNC symbols. Add an
> > I am worried about scenario where ifunc selector calls function foo
> > defined locally and foo is also used from other places possibly in hot
> > loops.
> > >
> > > > So it is not really reliable fix (though I guess it will work a lot of
> > > > common code). I wonder what would be alternativ
> On Thu, Feb 29, 2024 at 03:15:30PM +0100, Jan Hubicka wrote:
> > I am not wed to the idea (just it appeared to me as an option to
> > disabling this optimization by default). I still think it may make sense.
>
> Maybe I misunderstood your idea.
> So, you are basical
testcases).
Bootstrapped/regtested x86_64-linux, will commit it tomorrow if there are
no complains.
2024-01-17 Jan Hubicka
Jakub Jelinek
PR tree-optimization/110852
gcc/ChangeLog:
* predict.cc (expr_expected_value_1):
(get_predictor_value
> > +falign-all-functions
> > +Common Var(flag_align_all_functions) Optimization
> > +Align the start of functions.
>
> all functions
>
> or maybe "of every function."?
Fixed, thanks!
> > +@opindex falign-all-functions=@var{n}
> > +@item -falign-all-functions
> > +Specify minimal alignment for f
value. */
>
> s/determinging/determining/
Fixed. I am re-testing the following and will commit if it succeeds (on
x86_64-linux)
2024-01-17 Jan Hubicka
Jakub Jelinek
PR tree-optimization/110852
gcc/ChangeLog:
* predict.cc (expr_expected_
>
> I meant the new option might be named -fmin-function-alignment=
> rather than -falign-all-functions because of how it should
> override all other options.
I was also pondering about both names. -falign-all-functions has the
advantage that it is similar to all the other alignment flags that a
> On Wed, 17 Jan 2024, Jan Hubicka wrote:
>
> > >
> > > I meant the new option might be named -fmin-function-alignment=
> > > rather than -falign-all-functions because of how it should
> > > override all other options.
> >
> > I was also
> Can we backport the patch(at least the generic part) to
> GCC11/GCC12/GCC13 release branch?
Yes, the periodic testers has took the change and as far as I can tell,
there are no surprises.
Thanks,
Honza
> > > >
> > > > /* X86_TUNE_AVOID_512FMA_CHAINS: Avoid creating loops with tight
> > > > 51
Hi,
I have noticed quite bad pasto in handling of X86_TUNE_AVOID_512FMA_CHAINS. At
the
moment it is ignored, but X86_TUNE_AVOID_256FMA_CHAINS controls 512FMA too.
This patch fixes it, we may want to re-check how that works on AVX512 machines.
Bootstrapped/regtested x86_64-linux, will commit it s
Hi,
I managed to commit a hack setting offset to 0 in
ipa_polymorphic_call_context::set_by_invariant. This makes it to give up on
multiple
inheritance, but most likely won't give bad code since the ohter base will be of
different type.
Bootstrapped/regtested x86_64-linux, comitted.
gcc/Change
> I compared GCC master branch bootstrap and test times on a slow machine
> with 6.6 Linux kernels compiled with the original GCC 13 and the GCC 13
> with the backported patch. The performance data isn't precise since the
> measurements were done on different days with different GCC sources under
> Hi,
>
> When the check for exceeding param_ipa_cp_value_list_size limit was
> modified to be ignored for generating values from self-recursive
> calls, it should have been changed from equal to, to equals toor is
> greater than. This omission manifests itself as PR 113490.
>
> When I examined
> Hi,
>
> PR 108007 is another manifestation where we rely on DCE to clean-up
> after IPA-SRA and if the user explicitely switches DCE off, IPA-SRA
> can leave behind statements which are fed uninitialized values and
> trap, even though their results are themselves never used.
>
> I have already
> > The diffrerence is that Cores understand the fact that fmadd does not need
> > all three parameters to start computation, while Zen cores doesn't.
> >
> > Since this seems noticeable win on zen and not loss on Core it seems like
> > good
> > default for generic.
> >
> > I plan to commit the pa
> gcc/ChangeLog:
>
> * builtins.cc (expand_builtin_fork_or_exec): Check
> condition_coverage_flag.
> * collect2.cc (main): Add -fno-condition-coverage to OBSTACK.
> * common.opt: Add new options -fcondition-coverage and
> -Wcoverage-too-many-conditions.
> *
Hi,
> Bootstrapped/regtested on x86_64-pc-linux-gnu
>
> gcc/ChangeLog:
>
> * lto-opts.cc (lto_write_options): Skip OPT_fltrans_output_list_.
OK,
thanks,
Honza
> ---
> gcc/lto-opts.cc | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/gcc/lto-opts.cc b/gcc/lto-opts.cc
> index c9bee9d
> Bootstrapped/regtested on x86_64-pc-linux-gnu
>
> gcc/ChangeLog:
>
> * lto-streamer.cc (lto_get_section_name): Remove random_seed in WPA.
This is also OK. (since it lacks explanation - the random suffixes are
added for ld -r to work. This never happens between WPA and ltrans, so
they on
Hi,
> This patch implements lockfile used for incremental LTO.
>
> Bootstrapped/regtested on x86_64-pc-linux-gnu
>
> gcc/ChangeLog:
>
> * Makefile.in: Add lockfile.o.
> * lockfile.cc: New file.
> * lockfile.h: New file.
I can't approve it, but overall it looks good to me.
We a
> Hi Honza,
Hi,
>
> I wasn't sure what to do here so I figured I'd ask.
>
> In adding support for multiple exits to the vectorizer I didn't know how to
> update this bit:
>
> https://github.com/gcc-mirror/gcc/blob/master/gcc/tree-vect-loop-manip.cc#L3363
>
> Essentially, if skip_vector (i.e. n
> > This seems good. Profile-arcs is rarely used by itself - most of time it
> > is implied by -fprofile-generate and -ftest-coverage and since
> > condition coverage is more associated to the second, I guess
> > -fcondition-coverage is better name.
> >
> > Since -fcondition-coverage now affects g
Hi,
this patch adds new option -falign-all-functions which works like
-falign-functions, but applies to all functions including those in cold
regions. As discussed in the PR log, this is needed for atomically
patching function entries in the kernel.
An option would be to make -falign-function man
> On Nov 22, 2023, Jan Hubicka wrote:
>
> > I wonder why you use same body aliases, which are kind of special to C++
> > frontend (and come with fixup code working around its quirks you had to
> > disable above).
>
> TBH, I don't recall whether I had any reaso
> On Nov 30, 2023, Jan Hubicka wrote:
>
> >> + if (VAR_P (replaced))
> >> + varpool_node::create_alias (sym_node->decl, replacement);
> >> + else
> >> + cgraph_node::create_alias (sym_node->decl, replacement);
>
> Unfortunate
Hi,
I am sorry for sending this late. I think the ipa changes are generally
fine. There are few things which was not clear to me.
> for gcc/ChangeLog
>
> * Makefile.in (OBJS): Add ipa-strub.o.
> (GTFILES): Add ipa-strub.cc.
> * builtins.def (BUILT_IN_STACK_ADDRESS): New.
>
> The following adds no_icf handling for variables where the attribute
> was rejected. It also fixes the check for no_icf by checking both
> the source and the targets decl.
>
> Bootstrap / regtest running on x86_64-unknown-linux-gnu.
>
> This would solve the AVR issue with merging of "progmem"
> On Dec 7, 2023, Alexandre Oliva wrote:
>
> > Thanks for raising the issue. Maybe there should be at least a comment
> > there, and perhaps some asserts to check that pointer and reference
> > types don't make to indirect_parms.
>
> Document why attribute access doesn't need the same treatmen
Hi,
this patch disables use of FMA in matrix multiplication loop for generic (for
x86-64-v3) and zen4. I tested this on zen4 and Xenon Gold Gold 6212U.
For Intel this is neutral both on the matrix multiplication microbenchmark
(attached) and spec2k17 where the difference was within noise for Core
>
> This came up in a separate thread as well, but when doing reassoc of a
> chain with
> multiple dependent FMAs.
>
> I can't understand how this uarch detail can affect performance when
> as in the testcase
> the longest input latency is on the multiplication from a memory load.
> Do we actuall
Hi,
this patch implements very basic propaation of return value ranges from VRP
pass. This helps std::vector's push_back since we work out value range of
allocated block. This propagates only within single translation unit. I hoped
we will also do the propagation at WPA stage, but that needs mor
> > +Wsuggest-attribute=returns_nonnull
>
> - or _?
>
> (If changing it, needs adjustment in rest of patch too.)
I was thinking of this and I am not sure what is better.
Sure _ in command line option looks odd, but this is an identifier
and it is returns_nonnull and not returns-nonnull.
I am not
Hi,
this is updated version which also adds testuiste compensation
I lost earlier while maintaining the patch in my testing tree.
There are quite few testcases that use constant return values to hide
something from optimizer.
Bootstrapped/regtested x86_64-linux.
gcc/ChangeLog:
* cgraph.cc
Hi,
this patch speeds up the push_back at -O3 significantly by making the
reallocation to be inlined by default. _M_realloc_insert is general
insertion that takes iterator pointing to location where the value
should be inserted. As such it contains code to move other entries around
that is quite
>
> On 11/18/23 20:21, Jan Hubicka wrote:
> > Hi,
> > this patch implements very basic propaation of return value ranges from VRP
> > pass. This helps std::vector's push_back since we work out value range of
> > allocated block. This propagates only within sin
> > + // RAII type to destroy initialized elements.
>
> There's only one initialized element, not "elements".
>
> > + struct _Guard_elts
> > + {
> > + pointer _M_first, _M_last; // Elements to destroy
>
> We only need to store one pointer here, call it
> Hi!
>
> On 2023-11-19T16:05:42+0100, Jan Hubicka wrote:
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/tree-ssa/return-value-range-1.c
> > @@ -0,0 +1,22 @@
> > +/* { dg-do ling } */
>
> ERROR: gcc.dg/tree-ssa/return-value-range-1.c: 1: syntax error
> > + // RAII type to destroy initialized elements.
>
> There's only one initialized element, not "elements".
>
> > + struct _Guard_elts
> > + {
> > + pointer _M_first, _M_last; // Elements to destroy
>
> We only need to store one pointer here, call it
> After this patch in addition to the problem already reported about
> vlda1.c and return-value-range-1.c, we have noticed these regressions
> on aarch64:
> Running gcc:gcc.target/aarch64/aarch64.exp ...
> FAIL: gcc.target/aarch64/movk.c scan-assembler movk\tx[0-9]+, 0x4667, lsl 16
> FAIL: gcc.targ
Hi,
this patch turns memmove to memcpy where we can and also avoids extra
guard checking if block is non-empty. This does not show as performance
improvement in my push_back micro-benchmark because vector rellocation
does not happen that often. In general, however, we optimize memcpy better
then m
Hi,
it seems that interface to symbol table is fairly minimal here reduced
to...
> (create_sym_alias_decl, create_sym_alias_decls): New.
> * cgraphunit.cc (cgraph_node::analyze): Create alias_target
> node if needed.
called from here...
> (analyze_functions): Fixup visibilit
> On Sunday, 19 November 2023 22:53:37 CET Jan Hubicka wrote:
> > Sadly it is really hard to work out this
> > from IPA passes, since we basically care whether the iterator points to
> > the same place as the end pointer, which are both passed by reference.
> > Thi
> > On Sunday, 19 November 2023 22:53:37 CET Jan Hubicka wrote:
> > > Sadly it is really hard to work out this
> > > from IPA passes, since we basically care whether the iterator points to
> > > the same place as the end pointer, which are both passed by referenc
Hi,
so if I understand it right, it should be safe to simply replace memmove
by memcpy. I wonder if we can get rid of the count != 0 check at least
for glibc systems. In general push_back now need inline-insns-auto to
be 33 to be inlined at -O2
jh@ryzen4:/tmp> cat ~/tt.C
#include
typedef unsig
> With my changes at -O3 we now inline push_back, so we could optimize the
> first loop to the second. However with
> ~/trunk-install/bin/gcc -O3 auto.C -S -fdump-tree-all-details
> -fno-exceptions -fno-store-merging -fno-tree-slp-vectorize
> the fist problem is right at the begining:
>
>[
> On Tue, 28 Nov 2023, Martin Jambor wrote:
>
> > On Tue, Nov 28 2023, Richard Biener wrote:
> > > On Mon, 27 Nov 2023, Martin Jambor wrote:
> > >
> > >> Hi,
> > >>
> > >> The enhancement to address PR 109849 contained an importsnt thinko,
> > >> and that any reference that is passed to a functio
>
>
> > Am 28.11.2023 um 17:59 schrieb Jan Hubicka :
> >
> >
> >>
> >>> On Tue, 28 Nov 2023, Martin Jambor wrote:
> >>>
> >>> On Tue, Nov 28 2023, Richard Biener wrote:
> >>>> On Mon, 27 Nov 2023, Martin Jam
> Hi,
>
> On Tue, Nov 28 2023, Jan Hubicka wrote:
> >> On Tue, 28 Nov 2023, Martin Jambor wrote:
> >>
> >> > On Tue, Nov 28 2023, Richard Biener wrote:
> >> > > On Mon, 27 Nov 2023, Martin Jambor wrote:
> >> > >
> >> &
> >> gcc/ChangeLog:
> >>
> >> 2023-08-18 Martin Jambor
> >>
> >>PR ipa/110378
> >>* ipa-param-manipulation.cc
> >>(ipa_param_body_adjustments::mark_dead_statements): Verify that any
> >>return uses of PARAM will be removed.
> >>(ipa_param_body_adjustments::mark_clobbers_dead)
> >> PR 108007 is another manifestation where we rely on DCE to clean-up
> >> after IPA-SRA and if the user explicitely switches DCE off, IPA-SRA
> >> can leave behind statements which are fed uninitialized values and
> >> trap, even though their results are themselves never used.
> >>
> >> I have
> > gcc/ChangeLog:
> >
> > * auto-profile.cc (afdo_calculate_branch_prob): Fix count
> > comparisons
> > * ipa-utils.cc (ipa_merge_profiles): Guard against zero count when
> > computing probabilities
> > * tree-vect-loop-manip.cc (vect_do_peeling): Guard against zer
> Currently unaligned YMM and ZMM load and store costs are cheaper than
> aligned which causes the vectorizer to purposely mis-align accesses
> by adding an alignment prologue. It looks like the unaligned costs
> were simply left untouched from znver3 where they equate the aligned
> costs when twe
Hi,
while building more testcases for ipa-icf I noticed that there are two places
in aliasing code where we still compare TYPE_MAIN_VARIANT for pointer equality.
This is not good idea for LTO since type merging may not happen for example
when in one unit pointed to type is forward declared while in
> This patch removes suffixes from section names during LTO linking.
>
> These suffixes were originally added for ld -r to work (PR lto/44992).
> They were added to all LTO object files, but are only useful before WPA.
> After that they waste space, and if kept random, make LTO caching
> impossibl
> This patch implements Incremental LTO as ltrans cache.
>
> The cache is active when directory $GCC_LTRANS_CACHE is specified and exists.
> Stored are pairs of ltrans input/output files and input file hash.
> File locking is used to allow multiple GCC instances to use to same cache.
>
> Bootstra
> gcc/ChangeLog:
>
> * common.opt: Add cache partitioning.
> * flag-types.h (enum lto_partition_model): Likewise.
>
> gcc/lto/ChangeLog:
>
> * lto-partition.cc (new_partition): Use new_partition_no_push.
> (new_partition_no_push): New.
> (free_ltrans_partition): New
> Replaces "lto_priv.$clone_number" by
> "lto_priv.$partition_hash.$partition_specific_clone_number".
> To reduce divergence for incremental LTO.
>
> Bootstrapped/regtested on x86_64-pc-linux-gnu
OK,
thanks!
Honza
>
> gcc/lto/ChangeLog:
>
> * lto-partition.cc (set_clone_partition_name_chec
> This patch squashes order of symbols in individual partitions, so that
> their relative order is conserved, but is not influenced by symbols in
> other partitions.
> Order of cloned symbols is set to 0. This should be fine because order
> specifies order of symbols in input files, which cloned sy
Hi,
TARGET_MEM_REF can be used to offset constant base into a memory object (to
produce lea instruction). This confuses points_to_local_or_readonly_memory_p
which treats the constant address as a base of the access.
Bootstrapped/regtsted x86_64-linux, comitted.
Honza
gcc/ChangeLog:
PR i
401 - 500 of 5425 matches
Mail list logo
