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
> 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
> 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
> 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):
> 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.
>
>
> 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
>
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
> >
> > For JSON output I suppose there's a way to "grep" without the line oriented
> > issue? I suppose we could make the JSON more hierarchical by adding
> > an outer function object?
>
> Absolutely, yes, this is much less useful for JSON. The filtering works,
> which may be occasionally
Hi,
I realize that I am late for the release (sorry for that). But here are
few things which I think may be added to changes.html at least for those
who will look later.
OK?
Honza
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index ca5174de..b390db51 100644
---
Hi,
this adds Cauldron2024 to main page. OK?
diff --git a/htdocs/index.html b/htdocs/index.html
index aa4683da..de5cca7b 100644
--- a/htdocs/index.html
+++ b/htdocs/index.html
@@ -54,6 +54,9 @@ mission statement.
News
+https://gcc.gnu.org/wiki/cauldron2024;>GNU Tools Cauldron
2024
+
Hi,
we have:
-ftree-loop-distribute-patterns
Perform loop distribution of patterns that can be code generated
with calls to a library. This flag is enabled by default at -O2 and higher,
and by -fprofile-use and -fauto-profile.
This pass distributes the
>
> Ah, you're right.
> If I compile (the one line modified) pr113208_0.C with
> -O -fno-early-inlining -fdisable-ipa-inline -std=c++20
> it does have just _ZN6vectorI12QualityValueEC2ERKS1_ in
> _ZN6vectorI12QualityValueEC2ERKS1_
> comdat and no _ZN6vectorI12QualityValueEC1ERKS1_
> and
>
> I've tried to see what actually happens during linking without LTO, so
> compiled
> pr113208_0.C with -O1 -fkeep-inline-functions -std=c++20 with vanilla trunk
> (so it has those 2 separate comdats, one for C2 and one for C1), though I've
> changed the
> void m(k);
> line to
>
> Hi!
Hello,
> The reason the optimization doesn't trigger when the constructor is
> constexpr is that expand_or_defer_fn is called in that case much earlier
> than when it is not constexpr; in the former case it is called when we
> try to constant evaluate that constructor. But
> 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.
>
>
> + /* 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
> + &&
> 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
> > 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
> > > 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
> 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.
> *
> 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.
> > 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
> 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
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 <
> __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;
> 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
> 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.
>
> > + 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
> >
> > 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
> > 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
> > 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
> > 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
> 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 app
> 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 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 =
> 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
> >
> [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
> 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
> 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 ba
> > 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
> 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 IFUNC r
> 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
> 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
> >
> > 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
> 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
> 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
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
> 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
> 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,
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.
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
> 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
> 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
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,
>
> 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
> 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
> 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,
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.
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
> 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
> > > >
> 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
>
> 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
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_
> > +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
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
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
> > 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
> 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.
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
> 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
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
> 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.
> *
> > 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
>
> 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
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
> 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
> 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"
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.
>
> 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
> 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 reason
> 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:
> >> > >
> >>
>
>
> > 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
> 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
> 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:
>
>
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
> > 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
> 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
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
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
> 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:
> > + // 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
> > + // 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
>
> 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 single t
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
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:
*
> > +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
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
> > > + output_data_to_object_file (1, 0);
> > > + output_data_to_object_file (1, 0);
> >
> > So this basically renames dw2_asm_output_data to
> > output_data_to_object_file and similarly for other output functions.
> >
> > What would be main problems of making dw2_asm_* functions to do the
> >
Hello,
thanks for the patch.
Overall it looks in right direction except for the code duplication in
output_die and friends.
> +/* Given a die and id, produce the appropriate abbreviations
> + directly to lto object file */
> +
> +static void
> +output_die_abbrevs_to_object_file(unsigned long
1 - 100 of 5074 matches
Mail list logo
