[Bug tree-optimization/40436] New: [4.5 regression] 0.5% code size regression caused by r147852

[Bug tree-optimization/40436] New: [4.5 regression] 0.5% code size regression caused by r147852

[rearnsha at gcc dot gnu dot org]

Rev 147852, which claims (according to
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00812.html) to improve code size,
really makes things worse by ~0.5% for ARM, thumb and thumb2 code when building
CSiBE.


-- 
           Summary: [4.5 regression] 0.5% code size regression caused by
                    r147852
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rearnsha at gcc dot gnu dot org
GCC target triplet: arm-eabi


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2009-06-13 22:51 -------
*** Bug 40437 has been marked as a duplicate of this bug. ***


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2009-06-13 23:07 -------
Hmm, the measurements are most likely on x86 which might have slight
differences when it comes to code size differences than arm.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
           Severity|major                       |normal
           Keywords|                            |missed-optimization


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[rearnsha at gcc dot gnu dot org]

------- Comment #3 from rearnsha at gcc dot gnu dot org  2009-06-13 23:10 -------
For ARM -Os 114 files in CSiBE increase in size (total increase 21449 bytes)
20 files decrease in size (total decreases 1039 bytes); over all increase 20410
bytes)

Worst single increase is from bzip2/compress (increase from 12495 to 19463
bytes).


-- 

rearnsha at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |major
           Keywords|missed-optimization         |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[rearnsha at gcc dot gnu dot org]

-- 

rearnsha at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |normal
           Keywords|                            |missed-optimization
           Priority|P3                          |P2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[ramana at gcc dot gnu dot org]

------- Comment #4 from ramana at gcc dot gnu dot org  2009-06-19 00:00 -------
Confirmed that the problem exists.


-- 

ramana at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-06-19 00:00:34
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[ramana at gcc dot gnu dot org]

------- Comment #5 from ramana at gcc dot gnu dot org  2009-06-19 23:14 -------
The difference essentially is because all functions getting inlined into
BZ2_Compress_Block with the newer heuristics. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[hubicka at gcc dot gnu dot org]

------- Comment #6 from hubicka at gcc dot gnu dot org  2009-06-30 12:44 -------
Created an attachment (id=18100)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18100&action=view)
Proposed patch

The problem is that early inliner allows to increase code size estimate by
inlining single function by up to 12 instructions.  This is higher than on
pretty-ipa branch still, since we are not that good on early optimizing yet and
some C++ benchmarks (tramp/botan/boost) degrade when reduced to 7 as used by
tramp3d. In tramp3d it is mostly caused by dead loops in constructors, and I
hope that merging IPA-SRA and CD-DCE improvements will care this on all three
benchmarks. At -O2 early inliner needs to be somewhat speculative since it
don't know the function profiles yet. It however seems stupid to allow code
size growth at -Os in general.

This patch changes it reducing compress.o from 14k to 9k on i386. I guess I
will need to give it full CSiBE run since it is question whether little
speculative inlining won't result in better overall score.

Honza


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[hubicka at ucw dot cz]

------- Comment #7 from hubicka at ucw dot cz  2009-06-30 12:46 -------
Subject: Re:  [4.5 regression] 0.5% code size regression caused by r147852

> The problem is that early inliner allows to increase code size estimate by
> inlining single function by up to 12 instructions.  This is higher than on
> pretty-ipa branch still, since we are not that good on early optimizing yet and
> some C++ benchmarks (tramp/botan/boost) degrade when reduced to 7 as used by
> tramp3d. In tramp3d it is mostly caused by dead loops in constructors, and I
  ^^^^^^ pretty-ipa :)
> hope that merging IPA-SRA and CD-DCE improvements will care this on all three
> benchmarks. At -O2 early inliner needs to be somewhat speculative since it
> don't know the function profiles yet. It however seems stupid to allow code
> size growth at -Os in general.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[steven at gcc dot gnu dot org]

------- Comment #8 from steven at gcc dot gnu dot org  2009-06-30 13:14 -------
Honza, I can take care of the CSiBE run if you want.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[hubicka at gcc dot gnu dot org]

------- Comment #9 from hubicka at gcc dot gnu dot org  2009-06-30 13:41 -------
I can schedule it for nightly testing today, but if you have easier setup for
CSiBE, it would help :)

Thanks!
Honza


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[steven at gcc dot gnu dot org]

------- Comment #10 from steven at gcc dot gnu dot org  2009-06-30 19:55 -------
I see no effect whatsoever of the patch for for CSiBE on arm-elf-unknown.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[hubicka at ucw dot cz]

------- Comment #11 from hubicka at ucw dot cz  2009-06-30 23:36 -------
Subject: Re:  [4.5 regression] 0.5% code size regression caused by r147852

> I see no effect whatsoever of the patch for for CSiBE on arm-elf-unknown.
At -Os?

Honza


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[steven at gcc dot gnu dot org]

------- Comment #12 from steven at gcc dot gnu dot org  2009-07-01 05:41 -------
Yes, at -Os.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[hubicka at ucw dot cz]

------- Comment #13 from hubicka at ucw dot cz  2009-07-02 10:10 -------
Subject: Re:  [4.5 regression] 0.5% code size regression caused by r147852

OK, on i386 it has some effect according to our nightly tester
it is 3524421->3510754.  The size used to be as low as 3431090
so it is just small improvement.  I guess I will commit the patch anyway
as it is quite obvious fix.

The other problem might be the "likely_eliminated_by_inlining_p"
predicate that is very optimisitic.

This predicate makes inliner to believe that all indirect reads and
writes to/from pointers passed to function or function parameters will
be optimized out.  This is important to allow inlining of methods and
SRAing out objects in C++ and devirtualizing calls, but for C code it is
bit too optimistic.

Partly this can be cured by IPA-SRA and Martin has WIP patch for
clonning that contains more fine grained analysis of function body size
specialized for given parameters. I however doubt they will catch all
the cases we need for C++.  Perhaps simply disabling the predicate for
-Os or making it just weak hint (removing some percentage of estimated
cost) is best way to go, I am just re-testing it on vangelis with size
estimates ignoring it.

Honza


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[ramana at gcc dot gnu dot org]

------- Comment #14 from ramana at gcc dot gnu dot org  2009-12-09 17:09 -------
(In reply to comment #13)

> I am just re-testing it on vangelis with size
> estimates ignoring it.

Honza - Any updates on this ?

Ramana
> 
> Honza
> 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[hubicka at gcc dot gnu dot org]

------- Comment #15 from hubicka at gcc dot gnu dot org  2010-03-07 20:37 -------
I've been discussing this on IRC a while ago with Richard Guenther, but forgot
to add a record.

It seems that for 4.5, it is best to leave inlining heruistics as it is.  THe
code size regression come mainly from bzip that is excercising kind of typical
"bad luck" scenario.  Other known problem in 4.5 inlining is tramp3d where we
now deliver worse than best known performance, but still not worse than one of
4.4.

I spent some time playing with this and only way to get 4.5 inliner to solve
these faults is to add new parameter that allows early inlining to inline
forwarder functions that do increase code size estimates by small amount.  This
helps to solve both tramp3d and bzip problems but also cause code size issues
in some benchmarks (mostly not regressions over 4.4) and is quite ugly.

Since re-tunning heuristics needs significant amount of effort and it was done
earlier in stage1 of 4.5 after merging changes from pretty-ipa, it seems better
to leave as it is now. Also after LTO merge it seems, according to results
posted by Vladimir Marakov, that the inliner is actually perfomring very well
compared to other compilers.

For 4.6 I do have number of plans. With FRE in early optimization queue we
invalidate need for some of early inlining and also IPA stuff should be making
us less dependent on inling overall.

But I would propose this PR to be wontfix for 4.5.

Honza


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[rguenth at gcc dot gnu dot org]

------- Comment #16 from rguenth at gcc dot gnu dot org  2010-03-28 15:46 -------
(In reply to comment #15)
> I've been discussing this on IRC a while ago with Richard Guenther, but forgot
> to add a record.
> 
> It seems that for 4.5, it is best to leave inlining heruistics as it is.  THe
> code size regression come mainly from bzip that is excercising kind of typical
> "bad luck" scenario.  Other known problem in 4.5 inlining is tramp3d where we
> now deliver worse than best known performance, but still not worse than one of
> 4.4.
> 
> I spent some time playing with this and only way to get 4.5 inliner to solve
> these faults is to add new parameter that allows early inlining to inline
> forwarder functions that do increase code size estimates by small amount.  This
> helps to solve both tramp3d and bzip problems but also cause code size issues
> in some benchmarks (mostly not regressions over 4.4) and is quite ugly.
> 
> Since re-tunning heuristics needs significant amount of effort and it was done
> earlier in stage1 of 4.5 after merging changes from pretty-ipa, it seems better
> to leave as it is now. Also after LTO merge it seems, according to results
> posted by Vladimir Marakov, that the inliner is actually perfomring very well
> compared to other compilers.
> 
> For 4.6 I do have number of plans. With FRE in early optimization queue we
> invalidate need for some of early inlining and also IPA stuff should be making
> us less dependent on inling overall.
> 
> But I would propose this PR to be wontfix for 4.5.

Indeed.

There is also some miscounting of overall unit size, Micha has a patch for
that (but it completely chokes tramp3d results).  There is also the
early inliner cleanups I have done at some point.  Thus, I suppose we can
look at this early during 4.6 development again.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org, matz at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[hubicka at ucw dot cz]

------- Comment #17 from hubicka at ucw dot cz  2010-03-28 16:33 -------
Subject: Re:  [4.5 regression] 0.5% code size
        regression caused by r147852

> Indeed.
> 
> There is also some miscounting of overall unit size, Micha has a patch for
> that (but it completely chokes tramp3d results).  There is also the

Where is the patch?

> early inliner cleanups I have done at some point.  Thus, I suppose we can
> look at this early during 4.6 development again.

Well, those should not affect the resulting inlining, right?

Honza


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[rguenther at suse dot de]

------- Comment #18 from rguenther at suse dot de  2010-03-28 16:43 -------
Subject: Re:  [4.5 regression] 0.5% code size
 regression caused by r147852

On Sun, 28 Mar 2010, hubicka at ucw dot cz wrote:

> ------- Comment #17 from hubicka at ucw dot cz  2010-03-28 16:33 -------
> Subject: Re:  [4.5 regression] 0.5% code size
>         regression caused by r147852
> 
> > Indeed.
> > 
> > There is also some miscounting of overall unit size, Micha has a patch for
> > that (but it completely chokes tramp3d results).  There is also the
> 
> Where is the patch?

Somewhere - you have to as Micha.

> > early inliner cleanups I have done at some point.  Thus, I suppose we can
> > look at this early during 4.6 development again.
> 
> Well, those should not affect the resulting inlining, right?

In theory not.  In practice it removes the iteration if I remember
correctly.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[hubicka at ucw dot cz]

------- Comment #19 from hubicka at ucw dot cz  2010-03-28 16:56 -------
Subject: Re:  [4.5 regression] 0.5% code size
        regression caused by r147852

> > > There is also some miscounting of overall unit size, Micha has a patch for
> > > that (but it completely chokes tramp3d results).  There is also the
> > 
> > Where is the patch?
> 
> Somewhere - you have to as Micha.

I think I saw one but it was wrong.  I would be interested to at least know
what this patch is about :)
> 
> 
> In theory not.  In practice it removes the iteration if I remember
> correctly.

Yes, but that should not affect the metrics (hopefully)
Anyway the 4.6 inliner will probably again behave quite differently - I want to
get FRE
early, possibly get partial inlining done and we will have IPA AA that all
affects effectivity
of inlining.

Honza


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[rguenther at suse dot de]

------- Comment #20 from rguenther at suse dot de  2010-03-28 17:00 -------
Subject: Re:  [4.5 regression] 0.5% code size
 regression caused by r147852

On Sun, 28 Mar 2010, hubicka at ucw dot cz wrote:

> ------- Comment #19 from hubicka at ucw dot cz  2010-03-28 16:56 -------
> Subject: Re:  [4.5 regression] 0.5% code size
>         regression caused by r147852
> 
> > > > There is also some miscounting of overall unit size, Micha has a patch for
> > > > that (but it completely chokes tramp3d results).  There is also the
> > > 
> > > Where is the patch?
> > 
> > Somewhere - you have to as Micha.
> 
> I think I saw one but it was wrong.  I would be interested to at least know
> what this patch is about :)

It's about not accounting static called once functions twice when
decreasing overall unit size.

> > In theory not.  In practice it removes the iteration if I remember
> > correctly.
> 
> Yes, but that should not affect the metrics (hopefully)
> Anyway the 4.6 inliner will probably again behave quite differently - I want to
> get FRE
> early, possibly get partial inlining done and we will have IPA AA that all
> affects effectivity
> of inlining.

Of course.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[hubicka at ucw dot cz]

------- Comment #21 from hubicka at ucw dot cz  2010-03-28 17:30 -------
Subject: Re:  [4.5 regression] 0.5% code size
        regression caused by r147852

> > I think I saw one but it was wrong.  I would be interested to at least know
> > what this patch is about :)
> 
> It's about not accounting static called once functions twice when
> decreasing overall unit size.
Ah, I saw that one and I think it was wrong (and that is also why it regressed
on tramp3d).  I will dig it out.

Honza


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[hubicka at ucw dot cz]

------- Comment #23 from hubicka at ucw dot cz  2010-04-03 21:02 -------
Subject: Re:  [4.5 regression] 0.5% code size
        regression caused by r147852

> 1) overall_size is reduced twice for the same function, once in
>    cgraph_clone_inlined_nodes, once in cgraph_mark_inline_edge (which calls
>    the former), this leads to double accounting

Hmm, yep, it is bug here and I guess it makes tramp3d unhappy since it relies
on
the overall unit growth.  I will try to fix this and retune to see if this can
be
used to help the CSiBE regression that also might be related to this thinko.

> 2) cgraph_check_inline_limits checks the wrong size against the 
>    PARAM_LARGE_FUNCTION_INSNS parameter, it needs to use the original size,
>    not the one estimated after inlining.
Well, PARAM_LARGE_FUNCTION_INSNS was meant to let small functions to grow as
much
as they want until the threshold is hit, so size after inlining makes sense
here.

Honza


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[rguenther at suse dot de]

------- Comment #24 from rguenther at suse dot de  2010-04-03 21:13 -------
Subject: Re:  [4.5 regression] 0.5% code size
 regression caused by r147852

On Sat, 3 Apr 2010, hubicka at ucw dot cz wrote:

> ------- Comment #23 from hubicka at ucw dot cz  2010-04-03 21:02 -------
> Subject: Re:  [4.5 regression] 0.5% code size
>         regression caused by r147852
> 
> > 1) overall_size is reduced twice for the same function, once in
> >    cgraph_clone_inlined_nodes, once in cgraph_mark_inline_edge (which calls
> >    the former), this leads to double accounting
> 
> Hmm, yep, it is bug here and I guess it makes tramp3d unhappy since it relies
> on
> the overall unit growth.  I will try to fix this and retune to see if this can
> be
> used to help the CSiBE regression that also might be related to this thinko.
> 
> > 2) cgraph_check_inline_limits checks the wrong size against the 
> >    PARAM_LARGE_FUNCTION_INSNS parameter, it needs to use the original size,
> >    not the one estimated after inlining.
> Well, PARAM_LARGE_FUNCTION_INSNS was meant to let small functions to grow as
> much
> as they want until the threshold is hit, so size after inlining makes sense
> here.

But the the code as-is allows unlimited growth of a function (well,
by PARAM_LARGE_FUNCTION_GROWTH for each inlining; the limit is
basically PARAM_LARGE_FUNCTION_INSNS * (1 + 
PARAM_LARGE_FUNCTION_GROWTH/100) ^ n with n being the number of
functions we inline into the function).  So it's not really a
limit of the growth but of the growth rate ;)

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[hubicka at ucw dot cz]

------- Comment #25 from hubicka at ucw dot cz  2010-04-03 21:19 -------
Subject: Re:  [4.5 regression] 0.5% code size
        regression caused by r147852

> But the the code as-is allows unlimited growth of a function (well,
> by PARAM_LARGE_FUNCTION_GROWTH for each inlining; the limit is
> basically PARAM_LARGE_FUNCTION_INSNS * (1 + 
> PARAM_LARGE_FUNCTION_GROWTH/100) ^ n with n being the number of

Size after inlining decide whether we want to apply PARAM_LARGE_FUNCTION_GROWTH
or not.  When we decide so (based on overall function size), the limit is
computed based on size without inlining.

So PARAM_LARGE_FUNCTION_INSNS only adds a buffer for small functions, but
should
not interfere with the growth limits once function gets bigger than that.
(at least it is intended to work this way, I will double check the
implementation after returning)

Honza


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[hubicka at ucw dot cz]

------- Comment #26 from hubicka at ucw dot cz  2010-04-03 21:20 -------
Subject: Re:  [4.5 regression] 0.5% code size
        regression caused by r147852

As for history, I oriignally had only the perentage limits at place, but then
found that they behave really erratically on small units and small functions.
(especially in kernel source where you have tiny units with two functions that
needs to be inlined one to other).  So I added this large function/unit
thresholds.  They should be symmetric for functions and units.

Honza


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[hubicka at ucw dot cz]

------- Comment #27 from hubicka at ucw dot cz  2010-04-03 21:39 -------
Subject: Re:  [4.5 regression] 0.5% code size
        regression caused by r147852

And after checking the code, I think it is correct. I.e. limit is computed on
size before inlining of caller or callee (this is to allow large callees to be
inlined into tiny wrappers).

So overall limit for size after inlininig is  max(LARGE_FUNCTION_INSNS,
orig_size + orig_size * LARGE_FUNCTION_GROWTH) that seems sane to me.

Thinking more about the double accounting bug, it probably should not affect
the -Os compilation too much since we should not be inlining anything large at
first place.  Still will make a fix at monday and probably try to push it at
least to 4.5.1 or so.  It definitly allows to construct units where we let a
lot more growth than we are supposed so.

Honza


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[matz at gcc dot gnu dot org]

------- Comment #28 from matz at gcc dot gnu dot org  2010-04-06 10:34 -------
I don't think we should fix the double-accounting bug for the 4.5 series,
when we tried it on SPEC it caused several regression, meaning we would need
much more fine-tuning.  We have time for that for 4.6.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[hubicka at ucw dot cz]

------- Comment #29 from hubicka at ucw dot cz  2010-04-06 10:46 -------
Subject: Re:  [4.5 regression] 0.5% code size
        regression caused by r147852

> I don't think we should fix the double-accounting bug for the 4.5 series,
> when we tried it on SPEC it caused several regression, meaning we would need
> much more fine-tuning.  We have time for that for 4.6.

Well, we need to compensate for overall unit growth then, I will do so at
pretty-ipa so it will get some testing and see how much trouble it causes.
I am fine with this not being fixed in 4.5.x as long as we won't run into
real world testcase where double counting causes explosion of unit size.

Honza


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[steven at gcc dot gnu dot org]

------- Comment #30 from steven at gcc dot gnu dot org  2010-04-06 10:56 -------
I think it is a really, really bad signal if a bug like this, where the
revision that introduced the issue was identified >9 months ago, remains
unfixed for GCC 4.5.

I, for one, wouldn't care hunting down revisions that introduce regressions in
stage1 anymore, if component maintainers and release managers just postpone
fixing the issue until it is too late to fix for a release.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[rguenther at suse dot de]

------- Comment #31 from rguenther at suse dot de  2010-04-06 11:00 -------
Subject: Re:  [4.5 regression] 0.5% code size
 regression caused by r147852

On Tue, 6 Apr 2010, steven at gcc dot gnu dot org wrote:

> ------- Comment #30 from steven at gcc dot gnu dot org  2010-04-06 10:56 -------
> I think it is a really, really bad signal if a bug like this, where the
> revision that introduced the issue was identified >9 months ago, remains
> unfixed for GCC 4.5.
> 
> I, for one, wouldn't care hunting down revisions that introduce regressions in
> stage1 anymore, if component maintainers and release managers just postpone
> fixing the issue until it is too late to fix for a release.

Well, the fix doesn't fix this bug.  There's no patch to fix this
bug (yet).  Also 0.5% code size increase doesn't look important
enough to me.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[hubicka at ucw dot cz]

------- Comment #32 from hubicka at ucw dot cz  2010-04-06 11:05 -------
Subject: Re:  [4.5 regression] 0.5% code size
        regression caused by r147852

> I think it is a really, really bad signal if a bug like this, where the
> revision that introduced the issue was identified >9 months ago, remains
> unfixed for GCC 4.5.

This particular bug should not affect -Os scores at all as discussed earlier.
Overall unit growth limits will never hit at -Os since we never enlarge unit
size. 

I spent fair amount of time tracking down the individual CSiBE code size
increases and fixed most of them.  At the moment, I believe, the only remaining
issue is bzip2 size growth.  The inlining decisions here are sane at the local
level as inliner sees them, just the resulting binary gets bigger. Inling is a
heuristic even at -Os and we can't expect it to work in all cases.  Here the
old inliner got lucky by simply not accounting any stores/loads as real
instructions allowing the functions to be inlined at letting later optimizers
to produce smaller code.

Honza


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[matz at gcc dot gnu dot org]

------- Comment #33 from matz at gcc dot gnu dot org  2010-04-06 11:09 -------
Steven, please note that this PR was proposed WONTFIX for 4.5 already in
comment #15.  The discussion after that was about something that is only
slightly related to this bug, something that wouldn't actually affect this
very bug.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[steven at gcc dot gnu dot org]

------- Comment #35 from steven at gcc dot gnu dot org  2010-04-06 11:32 -------
If your discussions are only slightly related to this bug and don't affect -Os,
then why are you having that discussion here?

Anyway. If this is WONTFIX for GCC 4.5, then it should be marked as such
(remove "4.5 regression" from subject, open new PR for other issue, whatever).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[rguenth at gcc dot gnu dot org]

------- Comment #34 from rguenth at gcc dot gnu dot org  2010-04-06 11:20 -------
GCC 4.5.0 is being released.  Deferring to 4.5.1.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.5.0                       |4.5.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436

[Bug tree-optimization/40436] [4.5/4.6 regression] 0.5% code size regression caused by r147852

[rguenth at gcc dot gnu dot org]

------- Comment #36 from rguenth at gcc dot gnu dot org  2010-07-31 09:29 -------
GCC 4.5.1 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.5.1                       |4.5.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436