> On 1/21/21 7:40 PM, Martin Liška wrote:
> > Most of the changes are in known contexts:
>
> I've made some progress here, but still I'm unable to get a reproducible
> build.
> Now I see difference in:
>
>161/ 649: cp/decl.o: different
>180/ 649: cp/parser.o: different
>262/
> I've just installed the patch.
>
> About the negative total value. Something similar can handle it:
> diff --git a/libgcc/libgcov.h b/libgcc/libgcov.h
> index df08e882dd7..ddc688509bd 100644
> --- a/libgcc/libgcov.h
> +++ b/libgcc/libgcov.h
> @@ -443,7 +443,13 @@ gcov_topn_add_value (gcov_type
> gcc/ChangeLog:
>
> PR gcov-profile/98739
> * common.opt: Add missing sign symbol.
> * value-prof.c (get_nth_most_common_value): Restore handling
> of PROFILE_REPRODUCIBILITY_PARALLEL_RUNS and
> PROFILE_REPRODUCIBILITY_MULTITHREADED.
>
> libgcc/ChangeLog:
>
>
> >
> > I would make this go in separately from the feature itself (it is build
> > machinery change).
>
> All right.
>
> > Especially since you say it does not reach
> > reproducibility anyway until we patch hashtables?
>
> Yep, I'm testing a patch that should improve the reproducible build.
> > It is definitly doable (gcov machinery is quite flexible WRT having more
> > types of counters).
>
> Yes, that would introduce back the dropped TOPN counters which I intentionally
> dropped.
We could bring back topn counters or the easier dominating vlaue ones
and add command line option.
> On Fri, Jan 22, 2021 at 2:42 PM Martin Liška wrote:
> >
> > On 1/22/21 2:38 PM, Jan Hubicka wrote:
> > > This looks like reasonable solution for Linux (i was thinking of it too)
> > > but I wonder what about setups w/o mmap support, like mingw32?
> >
>
> I remember we had issues with streaming running in parallel with
> threads. Can't we get here corruption without atomic updates of nndoes
> and the next pointer?
>
> I also remember that these parlalel updates was pretty bad, because if
> you have multithreaded concurent update of very
> On 1/22/21 2:38 PM, Jan Hubicka wrote:
> > This looks like reasonable solution for Linux (i was thinking of it too)
> > but I wonder what about setups w/o mmap support, like mingw32?
>
> The code still uses malloc approach then.
>
> > I think we need some fa
> diff --git a/Makefile.in b/Makefile.in
> index 247cb9c8711..03785200dc7 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -565,7 +565,7 @@ STAGEprofile_TFLAGS = $(STAGE2_TFLAGS)
> STAGEtrain_CFLAGS = $(filter-out -fchecking=1,$(STAGE3_CFLAGS))
> STAGEtrain_TFLAGS = $(filter-out
> Hello.
>
> AS mentioned here, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461#c25, I
> like
> what Richard suggested. So instead of usage of malloc, we should use mmap
> memory
> chunks that serve as a memory pool for struct gcov_kvp.
>
> Malloc is used as a fallback when mmap is not
> On 1/21/21 8:13 PM, Martin Liška wrote:
> > Yes, it will be a better place!
> >
> > Martin
>
> There's an updated version of the patch.
>
> Thoughts?
> Thanks,
> Martin
> From 0be300d1d69e98624f7be5b54931126965f1436e Mon Sep 17 00:00:00 2001
> From: Martin Liska
> Date: Fri, 22 Jan 2021
> On 1/21/21 2:46 PM, Jan Hubicka wrote:
> > I think easy way to get users of this option is to make profile not
> > reproducible by default and modify packages to use right reproducibility
> > option when reproducible builds are intended. It is not feature that
> >
> On 1/21/21 8:03 PM, Jan Hubicka wrote:
> > What exactly is suggested?
>
> This one.
>
> Martin
> From 22bbf5342f2b73fad6c0286541bba6699c617380 Mon Sep 17 00:00:00 2001
> From: Martin Liska
> Date: Thu, 21 Jan 2021 09:02:31 +0100
> Subject: [PATCH 1/2] Resto
> On Thu, 2021-01-14 at 15:00 +0100, Jan Hubicka wrote:
> > > On Wed, Jan 13, 2021 at 11:04 PM David Malcolm via Gcc-patches
> > > wrote:
> > > > gimple.h has this comment for gimple's uid field:
> > > >
> > > > /* UID of this statement.
> > This will become more common problem for multithreaded profiles where
> > one needs to annotate locking and busy waiting loops in them for example
> > (or the scheduler responsible for executing paralle tasks).
> >
> > I can see this to be practically achievable but we probably want to
> >
> diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
> index b401f0817a3..042c03d819e 100644
> --- a/gcc/cgraphunit.c
> +++ b/gcc/cgraphunit.c
> @@ -1961,8 +1961,9 @@ expand_all_functions (void)
>}
>
>/* First output functions with time profile in specified order. */
> - qsort
> On 1/21/21 7:45 PM, Jan Hubicka wrote:
> > For this reason we merge by computing average, which is stable over
> > reordering the indices
>
> Looking at the implementation, we merge by using minimum value:
>
> /* Time profiles are merged so that minimum from a
> On 1/21/21 3:01 PM, Jan Hubicka wrote:
> > >
> > > Plus I'm planning to send one more patch that will ignore time profile
> > > when -fprofile-reproduce != serial.
> >
> > Why you need to disable time profiling?
>
> Because you can have
artin Jambor
> > ; Richard Sandiford ;
> > luoxhu via Gcc-patches
> > Cc: seg...@kernel.crashing.org; wschm...@linux.ibm.com;
> > li...@gcc.gnu.org; Jan Hubicka ; dje@gmail.com
> > Subject: Re: [PATCH] ipa-inline: Improve growth accumulation for recursive
> > calls
> &g
>
> Plus I'm planning to send one more patch that will ignore time profile when
> -fprofile-reproduce != serial.
Why you need to disable time profiling?
Honza
> On 1/21/21 9:25 AM, Richard Biener wrote:
> > On Wed, Jan 20, 2021 at 5:25 PM Martin Liška wrote:
> > >
> > > On 1/20/21 5:00 PM, Jan Hubicka wrote:
> > > > There are two thinks that I would like to discuss first
> > > >1) I think the
> On 1/20/21 5:00 PM, Jan Hubicka wrote:
> > There are two thinks that I would like to discuss first
> > 1) I think the option is stil used for value profiling of divisors
>
> It's not. Right now the only usage lives in get_nth_most_common_value which
> is a
> On Wed, Jan 20, 2021 at 12:04 PM Martin Liška wrote:
> >
> > Hello.
> >
> > For GCC 11 I've made a change in a way how we track TOP N counters:
> > - dynamic allocation is used for key value pairs
> > - up to 32 values are tracked in parallel
> > - the counters are allocated dynamically and
> On Mon, 18 Jan 2021, Richard Sandiford wrote:
>
> > Jan Hubicka writes:
> > >> >>
> > >> >> Well, in tree-ssa code we do assume these to be either disjoint
> > >> >> objects
> > >> >> or equal (in dec
> >>
> >> Well, in tree-ssa code we do assume these to be either disjoint objects
> >> or equal (in decl_refs_may_alias_p that continues in case
> >> compare_base_decls is -1). I am not sure if we win much by threating
> >> them differently on RTL level. I would preffer staying consistent here.
> This is a repost of:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-February/539763.html
>
> which was initially posted during stage 4. (And yeah, I only just
> missed stage 4 again.)
>
> IMO it would be better to fix the bug directly (as the patch tries
> to do) instead of wait for a
> On Wed, Jan 13, 2021 at 11:04 PM David Malcolm via Gcc-patches
> wrote:
> >
> > gimple.h has this comment for gimple's uid field:
> >
> > /* UID of this statement. This is used by passes that want to
> > assign IDs to statements. It must be assigned and used by each
> > pass. By
> The patch is about not using delete for a memory that
> is allocated by GGC.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> PR jit/98615
> * symtab-clones.h (clone_info::release):
accepted it is probably
all fine :)
Honza
>
> Regards,
> Venkat.
>
> > -Original Message-
> > From: Gcc-patches On Behalf Of
> > Kumar, Venkataramanan via Gcc-patches
> > Sent: Saturday, December 5, 2020 1:09 PM
> > To: Jan Hubicka ; Uros Bizjak
> &
> On Fri, Dec 4, 2020 at 6:50 PM Kumar, Venkataramanan
> wrote:
> >
> > [AMD Public Use]
> >
> > Hi Uros
> >
> > > -Original Message-
> > > From: Uros Bizjak
> > > Sent: Friday, December 4, 2020 2:30 PM
> > > To: Kum
> [AMD Official Use Only - Internal Distribution Only]
>
> Hi Maintainers,
>
> PFA, the patch that enables support for the next generation AMD Zen3 CPU via
> -march=znver3.
> This is a very basic enablement patch. As of now the cost, tuning and
> scheduler changes are kept same as znver2.
>
> On 12/2/20 4:25 PM, Martin Jambor wrote:
> > Hi,
> >
> > On Wed, Dec 02 2020, Jan Hubicka wrote:
> > > > We create an IPA SRA (which has DECL_IS_MALLOC set to false), but later
> > > > IPA pure const propagates malloc attributes. I think we s
> Hello.
>
> We create an IPA SRA (which has DECL_IS_MALLOC set to false), but later
> IPA pure const propagates malloc attributes. I think we should not set
> it for a void returning functions.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be
>
>
> On 11/30/20 7:04 AM, Martin Liška wrote:
> > Hi.
> >
> > It's handy to have symbol table when we dump emergency dump.
> > It's likely next stage1 material.
> >
> > Thoughts?
> > Martin
> >
> > gcc/ChangeLog:
> >
> > Â Â Â Â * passes.c (emergency_dump_function): Dump symtab when
> > Â Â Â
Hi,
thunk_info should be freed with ggc_delete since it is ggc allocated.
Bootstrapped/regtested x86_64-linux,
Honza
PR jit/97867
* symtab-thunks.h (thunk_info::release): Use ggc_delete.
diff --git a/gcc/symtab-thunks.h b/gcc/symtab-thunks.h
index 41a684995b3..0dba2217793 100644
> On Wed, Nov 25, 2020 at 3:14 PM Jan Hubicka wrote:
> >
> > Hi,
> > while looking into structalias I noticed that we ignore EAF flags here.
> > This is pity since we still can apply direct and unused.
> > This patch simply copies logic from normal call handling.
Hi,
ipa-modref tracks only parameters with SSA_NAMES. This makes completely
unused parameters to get no flags, while EAF_UNUSED should be right one.
This patch implements it. I also noticed that EAF_UNUSED implies all
other flags, but we set only EAF_UNUSED. This measn that we should
special
> > On Wed, Nov 25, 2020 at 3:11 PM Jan Hubicka wrote:
> > >
> > > > On Tue, 24 Nov 2020, Jan Hubicka wrote:
> > > >
> > > > > Hi,
> > > > > at the end of processing function body we loop over basic blocks
Hi,
this constructing testcase for the direct escape analysis I noticed that
I forgot to duplicate arg_flags in duplicate hook so we lose track of
that when clonning. I am sure I had it there at some point, but
apparently it got lost while breaking up patches.
Bootstrapped/regtested
> On Wed, Nov 25, 2020 at 3:11 PM Jan Hubicka wrote:
> >
> > > On Tue, 24 Nov 2020, Jan Hubicka wrote:
> > >
> > > > Hi,
> > > > at the end of processing function body we loop over basic blocks and
> > > > free all edges while we do
Hi,
while looking into structalias I noticed that we ignore EAF flags here.
This is pity since we still can apply direct and unused.
This patch simply copies logic from normal call handling. I relaize that
it is bit more expensive by creating callarg and doing transitive
closure there instead of
> On Tue, 24 Nov 2020, Jan Hubicka wrote:
>
> > Hi,
> > at the end of processing function body we loop over basic blocks and
> > free all edges while we do not free the rest. I think this is leftover
> > from time eges was not garbage collected and we was not usi
Hi,
we discussed this patch briefly two weeks ago, but did not reach conclusion and
since I wanted to avoid ICF fixes slipping another release I had chance to
return to it only now. Main limitation of modref is the fact that it does not
track anything in memory. This is intentional - I wanted the
Hi,
at the end of processing function body we loop over basic blocks and
free all edges while we do not free the rest. I think this is leftover
from time eges was not garbage collected and we was not using ggc_free.
It makes more sense to free all associated structures (which is
importnat for WPA
> Hi Honza!
>
> On 2020-11-19T13:33:53+0100, Jan Hubicka wrote:
> > --- a/gcc/ipa-icf-gimple.c
> > +++ b/gcc/ipa-icf-gimple.c
> > @@ -245,6 +245,14 @@ func_checker::hash_operand (const_tree arg,
> > inchash::hash ,
> >break;
> >
Hi,
this patch adds missing gcc_free on agg.items and descriptors and makes
allocations precise. This saves about 316MB WPAing Firefox
Honza
Bootstrapped/regtested x86_64-linux, comitted.
* ipa-prop.c (build_agg_jump_func_from_list,
ipa_read_jump_function): Reserve agg.items
> > On Mon, 23 Nov 2020, Jan Hubicka wrote:
> >
> > > > On Mon, 23 Nov 2020, Jan Hubicka wrote:
> > > >
> > > > > Hi,
> > > > > tree-streamer-in currently calls init_tree_ssa that calls
> > > > > ini
> On Mon, 23 Nov 2020, Jan Hubicka wrote:
>
> > > On Mon, 23 Nov 2020, Jan Hubicka wrote:
> > >
> > > > Hi,
> > > > tree-streamer-in currently calls init_tree_ssa that calls init_ssanames
> > > > that allocates space in ssa_name
> On Mon, 23 Nov 2020, Jan Hubicka wrote:
>
> > Hi,
> > tree-streamer-in currently calls init_tree_ssa that calls init_ssanames
> > that allocates space in ssa_names array for 50 names. Later it streams
> > in the count and calls init_tree_ssa again, this time
Hi,
tree-streamer-in currently calls init_tree_ssa that calls init_ssanames
that allocates space in ssa_names array for 50 names. Later it streams
in the count and calls init_tree_ssa again, this time with correct
count, which is rounded up to 50 and allocated again leaking the first
array.
This
> > I tested this by building and running a bunch of workloads for SVE,
> > with three options:
> >
> > (1) -O2
> > (2) -O2 -ftree-vectorize -fvect-cost-model=very-cheap
> > (3) -O2 -ftree-vectorize [-fvect-cost-model=cheap]
> >
> > All three builds used the default
Hi,
We now determine depnedencies across union fields correctly so 2 instead
of 1 loops are vectorized.
regtsted x86_64-linux, comitted.
* gcc.dg/vect/vect-35-big-array.c: Excpect 2 loops to be vectorized.
* gcc.dg/vect/vect-35.c: Excpect 2 loops to be vectorized.
diff --git
Hi,
another remaining case is that we end up comparing calls with mismatching
number of parameters or with different permutations of them.
This is because we hash decls to nothing. This patch improves that by
hashing decls by their code and parm decls by indexes that are stable.
Also for defualt
> On Thu, Nov 19, 2020 at 03:30:37PM -0700, Jeff Law wrote:
> > > No, the vast majority of people will *not* (consciously) use them,
> > > because the target defaults will set things to useful values.
> > >
> > > The compiler could use saner "generic" defaults perhaps, but those will
> > > still
> On Fri, 20 Nov 2020, Jan Hubicka wrote:
>
> > Hi,
> > one of common remaining reasons for ICF to fail after loading in fuction
> > body is mismatched type of automatic vairable. This is becuase
> > compatible_types_p resorts to checking TYPE_MAIN_VARIANTS for
Hi,
one of common remaining reasons for ICF to fail after loading in fuction
body is mismatched type of automatic vairable. This is becuase
compatible_types_p resorts to checking TYPE_MAIN_VARIANTS for
euqivalence that prevents merging many TBAA compaitle cases. (And thus
is also not reflected
Hi,
Building libxul 400k mismerges are due to THIS parameters of member functions
of polymorphic types that are in anonymous namespaces. We already hash ODR
names of the types, but all anonymous type have name "". These can
be distinguished by TYPE_MAIN_VARIANT that is implemented by this patch.
Hi,
As Jakub reminded me, I introduced OEP_MATCH_SIDE_EFFECTS for cases like
ICF or tail merging where we merge accesses from different code paths.
By default operand_equal_p is designed for accesses from one code path
where we do not want to merge two side effects.
Since compare_ao_refs is
Hi,
doing some further testing and analysis of icf miscompares I noticed tat
my change for hadling OEP_ADDRESS_OF of COMPONENT_REF had last minute
chnage that made it not effective, since flag is cleared before the
conditional. After some exprimenting it seem cleanest to just use
temporary bool.
Hi,
this is variant of patch I comitted (with a mistake fixed by Richard, my
apologizes for it). It turned out that the hunk handling OBJ_TYPE_REF
in operand_compare::hash_operand was on a wrong spot in operand_equal_p
that probably happened during mering the patch.
Also with Ada LTO bootstrap I
Hi,
after fixing few issues I gotto stage where 1.4M icf mismatches are due to
comparing two gimple clobber. The problem is that operand_equal_p match
clobber
case CONSTRUCTOR:
/* In GIMPLE empty constructors are allowed in initializers of
aggregates. */
return !CONSTRUCTOR_NELTS (arg0)
> On 11/16/20 12:20 AM, Jan Hubicka wrote:
> > This is controlled by -fipa-icf-alias-sets
> >
> > The patch drops too early, so we may end up processing function twice.
> > Also if
> > merging is not performed we lose code quality for no win (this is rare
> On 11/13/20 6:50 PM, Jan Hubicka wrote:
> > Bootstrapped/regtested x86_64-linux. I plan to commit it on monday if there
> > are
> > no complains.
>
> Hello Honza.
>
> Thank you very much for the patch set.
> It's a nice improvement and it will eventually f
Hi,
main purpose of obj_type_ref is to hold the type that was used in
virutal call. We do not hash this info in hash_operand that causes a
lot of miscompares at ICF time. With LTO this is quite important for
icf performance and in that case we do have manged type names (for
non-anonymous types)
Hi,
I am testing the following fix. I manually applied a rejected hunk and
for some reaosn managed to reverse the conditonal :(
Honza
* ipa-icf.c (sem_function::hash_stmt): Fix conditional on
variably_modified_type_p.
diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c
index
Hi,
thanks!
>
> So do we want to actually compute alias sets and stream them,
> "freeing up" TYPE_CANONICAL again? We're sort-of taking it away
I am not sure what you mean by freeing up TYPE_CANONICAL again :) but I
was playing with idea of streaming the alias sets from WPA to ltrans. It
may
Hi,
this patch fixes profiledbootstrap failure with LTO enabled.
What happens is that alias_ptr_types_compatible_p relies on the
fact that alias sets are not refined from WPA to ltrans time:
/* This function originally abstracts from simply comparing
get_deref_alias_set so that we are
> On Tue, Nov 17, 2020 at 09:44:26AM +0100, Jan Hubicka wrote:
> > > I think for unused functions we don't even gimplify unused functions, the
> > > cgraph code just throws them away. Even trying just to run the first few
> > > passes (gimplification up to uninit1)
> On Tue, Nov 17, 2020 at 01:33:48AM -0500, Jason Merrill via Gcc-patches wrote:
> > > > Why doesn't the middle-end warning work for inline functions?
> > >
> > > It does but only when they're called (and, as usual, also unless
> > > the uninitialized use is eliminated).
> >
> > Yes, but why? I
> On 11/16/20 1:44 PM, Jan Hubicka wrote:
> > Martin, we collected very many warnings when building with
> > configure --with-build-config=bootstrap-lto.mk
> > This patch fixes some of them, but there are many others, can you take a
> > look?
>
> Hello.
>
>
> >
> > Richi, I think we can add "safe" parameter to gimple_call_arg_flags and
> > bypass this logic when we use it for warnings only (having body that
> > does not use the value is quite strong hint that it is unused by the
> > function).
>
> Eh, please not.
OK, I do not care that much as
> Hello.
>
> This fixes:
>
> FAIL: compiler driver --help=common option(s): "^ +-.*[^:.]$" absent from
> output: " --param=modref-max-depth= Maximum depth of DFS walk used by
> modref escape analysis"
>
> Ready to be installed after tests?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
>
> On Nov 15 2020, Jan Hubicka wrote:
>
> >> See PR97840.
> > Thanks,
> > this is a false positive where we fail to discover that pointed-to type
> > is empty on non-x86_64 targets. This is triggered by better alias
> > analysis caused by non-escape discover
Hi,
this patch implements the logic to drop base alias sets (and thus also access
paths) from memory operands when doing so helps merging. This is done
by extending func_checker::compare_operand to record mismatched pairs
and then processing this in sem_function::equals_private when comparsion
Hi,
one of common cases why we lose track on SSA name in modref propagation
is the situation where name is passed to funtion call and we then thus
continue by propagating through return value.
This patch adds simple logic to track arguments that does not escape to
return value. On cc1plus the
> See PR97840.
Thanks,
this is a false positive where we fail to discover that pointed-to type
is empty on non-x86_64 targets. This is triggered by better alias
analysis caused by non-escape discovery.
While this is not a full fix (I hope someone with more experience on
C++ types and warnings
> On Fri, Nov 13, 2020 at 12:07 AM Richard Biener wrote:
> >
> > On Tue, 10 Nov 2020, Jan Hubicka wrote:
> >
> > > Hi,
> > > here is updaed patch.
> > >
> > > Honza
> > >
> > > Bootstrapped/regtested x86_64-
> Hi Jan,
>
> >> I'm seeing the same on both i386-pc-solaris2.11 and
> >> sparc-sun-solaris2.11, so I don't think there are special configure
> >> flags involved.
> >
> > When I configure with ../configure --enable-languages=go my build
> > eventually finishes fine on curren trunk:
> [...]
> > On
> Hi Jan,
>
> >> This breaks bootstrap with go.
> >>
> >> ../../gcc/go/gofrontend/go-diagnostics.cc: In function 'std::string
> >> expand_message(const char*, va_list)':
> >> ../../gcc/go/gofrontend/go-diagnostics.cc:110:61: error: '' may
> >> be used uninitialized
> This breaks bootstrap with go.
>
> ../../gcc/go/gofrontend/go-diagnostics.cc: In function 'std::string
> expand_message(const char*, va_list)':
> ../../gcc/go/gofrontend/go-diagnostics.cc:110:61: error: '' may be
> used uninitialized [-Werror=maybe-uninitialized]
> 110 |
Hi,
this patch implements the IPA propagation part of EAF flags handling in
ipa-modref. It extends the local analysis to collect lattice consisting of
flags and escape points (SSA name escapes if it is passed directly or
indirectly to a function call)
If useful flags are found for parameter its
Hi,
I have accidentally comitted in the following sanity check that fails
and is discussed in
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558538.html
The current ipa-icf code is conservatively correct because
alias_ptr_types_compatible_p returns false on ref_all_alias_ptr_type_p.
t
../../gcc/ipa-icf-gimple.c:357
This can be compared with:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558773.html
Bootstrapped/regtested x86_64-linux. I plan to commit it on monday if there are
no complains.
Honza
gcc/ChangeLog:
2020-11-13 Jan Hubicka
Martin Li
> Hi,
>
> The new behavior of safe_add triggered an ICE because of one use where
> it had not been used instead of a simple addition. I'll fix it with the
> following obvious patch so that periodic benchmarkers can continue
> working because a proper fix (see below) will need a review.
>
> The
Hi,
this is updated patch. It fixes the comparsion of bitfield where I now
check that they bitsizes and bitoffsets match (and OEP_ADDRESSOF is not
used for bitfield references).
I also noticed problem with dependence clique in ao_refs_may_alias that
I copied here. Instead of base rbase should be
> Hi,
>
> cgraph_node::materialize_clone segfaulted when I tried compiling Tramp3D
> with -fdump-ipa-all because there was no clone_info - IPA-CP created a
> clone only for an aggregate constant, adding a note to its
> transformation summary but not creating any tree_map nor
> param_adjustements.
> On Fri, 2020-10-23 at 21:45 +0200, Jan Hubicka wrote:
> > Hi,
> > this patch moves thunk_info out of cgraph_node into a symbol summary.
> > I also moved it to separate hearder file since cgraph.h became really
> > too
> > fat. I plan to contiue with si
> On Thu, 12 Nov 2020, Jan Hubicka wrote:
>
> > Hi,
> > this is updated patch I am re-testing and plan to commit if it suceeds.
> >
> > * fold-const.c (operand_compare::operand_equal_p): Compare
> > offsets of fields in component_refs when comparing
Hi,
this is updated patch I am re-testing and plan to commit if it suceeds.
* fold-const.c (operand_compare::operand_equal_p): Compare
offsets of fields in component_refs when comparing addresses.
(operand_compare::hash_operand): Likewise.
diff --git a/gcc/fold-const.c
> > * fold-const.c (operand_compare::operand_equal_p): When comparing
> > addresses
> > look info field offsets for COMPONENT_REFs.
> > (operand_compare::hash_operand): Likewise.
> > diff --git a/gcc/fold-const.c b/gcc/fold-const.c
> > index c47557daeba..a4e8cccb1b7 100644
> > ---
> Hi,.
>
> this patch converts the variables that hold time benefits and
> frequencies in IPA-CP from plain integers to sreals, avoiding the need
> to cap them to avoid overflows and also fixing a potential underflows.
>
> Size costs corresponding to individual constants are left as ints so
>
Hi,
here is updated patch that replaces 'C' by '1'...'9' so we still have
place to specify size.
As discussed on IRC, this seems better alternative.
Bootstrapped/regtested x86_64-linux, OK?
Honza
gcc/ChangeLog:
2020-11-12 Jan Hubicka
* attr-fnspec.h: Update topleve comment
> > How is that different from:
> > struct S { long long d; int e; };
> > struct T { long long d; long long e; };
> > s->e vs. t->e ?
> > One thing is comparison of the address (as it is comparing
> > DECL_FIELD_BIT_OFFSET too, it is essentially bit-address), and another thing
> > (unlrelated to
> On Thu, Nov 12, 2020 at 11:39:07AM +0100, Jan Hubicka wrote:
> > > On Thu, Nov 12, 2020 at 11:29:21AM +0100, Jan Hubicka wrote:
> > > > > If OEP_ADDRESS is used also on non-addressable stuff, just to compare
> > > > > that two COMPONENT_REFs a
> On Thu, Nov 12, 2020 at 11:29:21AM +0100, Jan Hubicka wrote:
> > > If OEP_ADDRESS is used also on non-addressable stuff, just to compare
> > > that two COMPONENT_REFs access the same memory, then just comparing
> > > DECL_BIT_FIELD_REPRESENTATIVE is not sufficient,
> On Thu, Nov 12, 2020 at 10:49:40AM +0100, Jan Hubicka wrote:
> > > > + if (!operand_equal_p (DECL_FIELD_OFFSET (field0),
> > > > + DECL_FIELD_OFFSET (field1),
> > > > +
> > + if (!operand_equal_p (DECL_FIELD_OFFSET (field0),
> > + DECL_FIELD_OFFSET (field1),
> > + flags & ~OEP_ADDRESS_OF)
> > + || !operand_equal_p (DECL_FIELD_BIT_OFFSET (field0),
> > +
Hi,
with ipa-icf we often run into problem that operand_equal_p does not
match ADDR_EXPR that take address of fields from two different instances
of same class (at ideantical offsets). Similar problem can also happen
for record types with LTO if they did not get tree merged.
This patch makes
Hi,
this patch iplements new class ao_compare that is derived from operand_compare
and adds a method to compare and hash ao_refs. This is used by ICF to enable
more merging.
Comparsion is done as follows
1) Verify that the memory access will happen at the same address
and will have same
Hi,
here is updaed patch.
Honza
Bootstrapped/regtested x86_64-linux, OK (after the fnspec fixes)?
2020-11-10 Jan Hubicka
* gimple.c: Include ipa-modref-tree.h and ipa-modref.h.
(gimple_call_arg_flags): Use modref to determine flags.
* ipa-modref.c: Include gimple
601 - 700 of 5075 matches
Mail list logo
