On Thu, Nov 13, 2014 at 2:17 PM, H.J. Lu wrote:
> On Wed, Oct 15, 2014 at 10:03 AM, Martin Liška wrote:
>>
>> Hello
>>
>> There's final version of the patch I'm going to commit tomorrow in the
>> morning (CEST).
>> Thank you Honza for the review.
>>
>> Martin
>
> This caused:
>
> https://gcc.gnu.
On Wed, Oct 15, 2014 at 10:03 AM, Martin Liška wrote:
>
> Hello
>
> There's final version of the patch I'm going to commit tomorrow in the
> morning (CEST).
> Thank you Honza for the review.
>
> Martin
This caused:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63856
--
H.J.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63747 is likely caused by
> this patch. compare_gimple_switch does not check CASE_LOW and
> CASE_HIGH, resulting merging functions not identical.
>
> Interestingly in the first a few versions of this patch CASE_LOW/HIGH
> were checked. But last versio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63747 is likely caused by
this patch. compare_gimple_switch does not check CASE_LOW and
CASE_HIGH, resulting merging functions not identical.
Interestingly in the first a few versions of this patch CASE_LOW/HIGH
were checked. But last versions only chec
PR 63574 ICE building libjava (segfault) on arm-linux-gnueabihf is
caused by this commit.
from the backtrace, the ICF pass is trying to compare two label tree
node without type info.
while looks like "compare_operand" expect the type info always be not
empty before invoking "func_checker::compati
On 10/14/2014 06:04 PM, Jan Hubicka wrote:
diff --git a/gcc/cgraph.h b/gcc/cgraph.h
index fb41b01..2de98b4 100644
--- a/gcc/cgraph.h
+++ b/gcc/cgraph.h
@@ -172,6 +172,12 @@ public:
/* Dump referring in list to FILE. */
void dump_referring (FILE *);
+ /* Get number of references for thi
> diff --git a/gcc/cgraph.h b/gcc/cgraph.h
> index fb41b01..2de98b4 100644
> --- a/gcc/cgraph.h
> +++ b/gcc/cgraph.h
> @@ -172,6 +172,12 @@ public:
>/* Dump referring in list to FILE. */
>void dump_referring (FILE *);
>
> + /* Get number of references for this node. */
> + inline unsi
On 10/11/2014 02:05 AM, Martin Liška wrote:
On 09/26/2014 09:46 PM, Jan Hubicka wrote:
Hi,
this is on ipa-icf-gimple.c
@@ -2827,11 +2829,19 @@ cgraph_node::verify_node (void)
{
if (verify_edge_corresponds_to_fndecl (e, decl))
> >
> >35% means that 35% of all function bodies are compared with something else?
> >That feels pretty high.
> >but overall numbers are not so terrible.
>
> Currently, the pass is able to merge 32K functions. As you know, we group
> functions to so called classes.
> According to stats, average
On 10/11/2014 10:19 AM, Jan Hubicka wrote:
After few days of measurement and tuning, I was able to get numbers to the
following shape:
Execution times (seconds)
phase setup : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall
1412 kB ( 0%) ggc
phase opt and generate : 27.
>
> Hello.
>
> Yeah, you are right. But even Richard advised me to put it to a single place.
> Maybe we are a bit
> more strict than it would be necessary. But I hope that's fine ;)
OK, lets do extra checking now and play with this incrementally.
>
> Good point. Do you mean cases like, foo (al
> > +/* Verifies for given GIMPLEs S1 and S2 that
> > + goto statements are semantically equivalent. */
> > +
> > +bool
> > +func_checker::compare_gimple_goto (gimple g1, gimple g2)
> > +{
> > + tree dest1, dest2;
> > +
> > + dest1 = gimple_goto_dest (g1);
> > + dest2 = gimple_goto_dest (g2);
>
> After few days of measurement and tuning, I was able to get numbers to the
> following shape:
> Execution times (seconds)
> phase setup : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%)
> wall1412 kB ( 0%) ggc
> phase opt and generate : 27.83 (59%) usr 0.66 (19%) sys 28
On 09/26/2014 11:27 PM, Jan Hubicka wrote:
>> diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c
>> new file mode 100644
>> index 000..f3472fe
>> --- /dev/null
>> +++ b/gcc/ipa-icf.c
>> @@ -0,0 +1,2841 @@
>> +/* Interprocedural Identical Code Folding pass
>> + Copyright (C) 2014 Free Software Foundat
On 09/26/2014 09:46 PM, Jan Hubicka wrote:
> Hi,
> this is on ipa-icf-gimple.c
>
> @@ -2827,11 +2829,19 @@ cgraph_node::verify_node (void)
> {
> if (verify_edge_corresponds_to_fndecl (e, decl))
> {
> -
On 09/28/2014 03:20 AM, Jan Hubicka wrote:
>>
>> Hi.
>>
>> Thank you Markus for presenting numbers, it corresponds with I measured. If
>> I see correctly, IPA ICF pass takes about 7 seconds,
>> the rest is distributed in verifier (not interesting for release version of
>> the compiler) and 'phase
On 09/28/2014 04:20 AM, Jan Hubicka wrote:
>>
>> Hi.
>>
>> Thank you Markus for presenting numbers, it corresponds with I measured. If
>> I see correctly, IPA ICF pass takes about 7 seconds,
>> the rest is distributed in verifier (not interesting for release version of
>> the compiler) and 'phase
>
> Hi.
>
> Thank you Markus for presenting numbers, it corresponds with I measured. If I
> see correctly, IPA ICF pass takes about 7 seconds,
> the rest is distributed in verifier (not interesting for release version of
> the compiler) and 'phase opt and generate'. No idea
> what can make the
On 09/27/2014 09:47 AM, Markus Trippelsdorf wrote:
> On 2014.09.27 at 07:59 +0200, Markus Trippelsdorf wrote:
>>
>>> It seems that in this case we reject too many of equality candidates?
>>> It think the original numbers was about 4-5% but later some equivalences was
>>> disabled because of devirt/
On 09/27/2014 07:59 AM, Markus Trippelsdorf wrote:
> On 2014.09.27 at 01:27 +0200, Jan Hubicka wrote:
>>> While a plain Firefox -flto build works fine. LTO/PGO build fails with:
>>>
>>> lto1: internal compiler error: in ipa_merge_profiles, at ipa-utils.c:540
>>> 0x7d6165 ipa_merge_profiles(cgraph_n
On 09/27/2014 01:27 AM, Jan Hubicka wrote:
>> While a plain Firefox -flto build works fine. LTO/PGO build fails with:
>>
>> lto1: internal compiler error: in ipa_merge_profiles, at ipa-utils.c:540
>> 0x7d6165 ipa_merge_profiles(cgraph_node*, cgraph_node*)
>> ../../gcc/gcc/ipa-utils.c:540
>>
On 2014.09.27 at 07:59 +0200, Markus Trippelsdorf wrote:
>
> > It seems that in this case we reject too many of equality candidates?
> > It think the original numbers was about 4-5% but later some equivalences was
> > disabled because of devirt/aliasing issues. Do you compare it with gold ICF
> >
On 2014.09.27 at 01:27 +0200, Jan Hubicka wrote:
> > While a plain Firefox -flto build works fine. LTO/PGO build fails with:
> >
> > lto1: internal compiler error: in ipa_merge_profiles, at ipa-utils.c:540
> > 0x7d6165 ipa_merge_profiles(cgraph_node*, cgraph_node*)
> > ../../gcc/gcc/ipa-ut
> While a plain Firefox -flto build works fine. LTO/PGO build fails with:
>
> lto1: internal compiler error: in ipa_merge_profiles, at ipa-utils.c:540
> 0x7d6165 ipa_merge_profiles(cgraph_node*, cgraph_node*)
> ../../gcc/gcc/ipa-utils.c:540
> 0xf10c41 ipa_icf::sem_function::merge(ipa_icf::
> diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c
> new file mode 100644
> index 000..f3472fe
> --- /dev/null
> +++ b/gcc/ipa-icf.c
> @@ -0,0 +1,2841 @@
> +/* Interprocedural Identical Code Folding pass
> + Copyright (C) 2014 Free Software Foundation, Inc.
> +
> + Contributed by Jan Hubicka and
Hi,
this is on ipa-icf-gimple.c
@@ -2827,11 +2829,19 @@ cgraph_node::verify_node (void)
{
if (verify_edge_corresponds_to_fndecl (e, decl))
{
- error ("edge points to wrong decl
On 2014.09.26 at 14:20 +0200, Martin Liška wrote:
> After couple of weeks I spent with fixing new issues connected to the
> pass: 1) Inliner failed in case I created a thunk and release body of
> a function. In such situation we need to preserve DECL_ARGUMENTS. I
> added new argument for: cgraph_no
On 07/17/2014 05:05 PM, Martin Liška wrote:
On 07/06/2014 12:53 AM, Jan Hubicka wrote:
On Fri, 20 Jun 2014, Trevor Saunders wrote:
+@item -fipa-icf
+@opindex fipa-icf
+Perform Identical Code Folding for functions and read-only variables.
I would perhaps explicitly say that the optimizations r
> On Fri, 20 Jun 2014, Trevor Saunders wrote:
> >> +@item -fipa-icf
> >> +@opindex fipa-icf
> >> +Perform Identical Code Folding for functions and read-only variables.
I would perhaps explicitly say that the optimizations reduce code size
and may disturb unwind stacks by replacing a function by eq
On Fri, 20 Jun 2014, Trevor Saunders wrote:
>> +@item -fipa-icf
>> +@opindex fipa-icf
>> +Perform Identical Code Folding for functions and read-only variables.
>> +Behavior is similar to Gold Linker ICF optimization. Symbols proved
>> +as semantically equivalent are redirected to corresponding symb
> diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c
> new file mode 100644
> index 000..8a13dca
> --- /dev/null
> +++ b/gcc/ipa-icf.c
> +/* Itializes internal structures according to given number of
initialize
> + if (is_a_helper::test (node))
shouldn't you just use is_a (node) ?
> +sem_item_
On 06/26/14 12:46, Jan Hubicka wrote:
So you've added this at -O2, what is the general compile-time
impact? Would it make more sense to instead have it be part of -O3,
particularly since ICF is rarely going to improve performance (sans
icache issues).
I think code size optimization not sacrify
Jeff,
thanks for review! I did some passes over the patch before it got to the ML, I
am
happy to have independent opinion.
> >+@item -fipa-icf
> >+@opindex fipa-icf
> >+Perform Identical Code Folding for functions and read-only variables.
> >+Behavior is similar to Gold Linker ICF optimization. S
On 06/24/2014 10:31 PM, Jeff Law wrote:
On 06/13/14 04:44, mliska wrote:
Hello,
this is core of IPA ICF patchset. It adds new pass and registers all needed
stuff related to a newly introduced interprocedural optimization.
Algorithm description:
In LGEN, we visit all read-only variables
On 06/13/14 04:44, mliska wrote:
Hello,
this is core of IPA ICF patchset. It adds new pass and registers all needed
stuff related to a newly introduced interprocedural optimization.
Algorithm description:
In LGEN, we visit all read-only variables and functions. For each symbol, a
hash v
35 matches
Mail list logo
