[Bug tree-optimization/10474] gcc should be able to delay the setup of the frame pointer (patrial outlining)

[Bug tree-optimization/10474] gcc should be able to delay the setup of the frame pointer (patrial outlining)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |scovich at gmail dot com

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> 2011-05-18 04:59:54 UTC ---
*** Bug 49035 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/10474] gcc should be able to delay the setup of the frame pointer (patrial outlining)

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> 2011-12-02 02:46:40 UTC ---
The original testcase is not shrink wrapped because we need an extra copyprop
before shrinkwrap can be done as mentioned in
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00380.html.

[Bug middle-end/10474] shrink wrapping for functions

[jamborm at gcc dot gnu.org]

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

Martin Jambor <jamborm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jamborm at gcc dot gnu.org
          Component|tree-optimization           |middle-end

--- Comment #11 from Martin Jambor <jamborm at gcc dot gnu.org> 2013-04-17 15:52:44 UTC ---
I've submitted a patch that actually makes shrink wrapping happen, at
least on x86_64.  It would be great if someone checked whether it
helps on other platforms:

http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01033.html

(I'm also changing the component to to middle end as this is hardly a
tree-optimization matter.)

[Bug rtl-optimization/10474] shrink wrapping for functions

[jamborm at gcc dot gnu.org]

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

--- Comment #12 from Martin Jambor <jamborm at gcc dot gnu.org> ---
I have submitted a different patch that addresses this issue, this
time by splitting live ranges of pseudos representing the formal
parameters of a function.  The patch is pending review/approval and
the current version is at
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02183.html

[Bug rtl-optimization/10474] shrink wrapping for functions

[jamborm at gcc dot gnu.org]

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

--- Comment #13 from Martin Jambor <jamborm at gcc dot gnu.org> ---
Author: jamborm
Date: Wed Oct 30 12:01:46 2013
New Revision: 204205

URL: http://gcc.gnu.org/viewcvs?rev=204205&root=gcc&view=rev
Log:
2013-10-30  Martin Jambor  <mjambor@suse.cz>

    PR rtl-optimization/10474
    * ira.c (find_moveable_pseudos): Do not calculate dominance info
    nor df analysis.
    (interesting_dest_for_shprep): New function.
    (split_live_ranges_for_shrink_wrap): Likewise.
    (ira): Calculate dominance info and df analysis. Call
    split_live_ranges_for_shrink_wrap.

testsuite/
    * gcc.dg/pr10474.c: New testcase.
    * gcc.dg/ira-shrinkwrap-prep-1.c: Likewise.
    * gcc.dg/ira-shrinkwrap-prep-2.c: Likewise.


Added:
    trunk/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-1.c
    trunk/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-2.c
    trunk/gcc/testsuite/gcc.dg/pr10474.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ira.c
    trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/10474] shrink wrapping for functions

[jamborm at gcc dot gnu.org]

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

--- Comment #15 from Martin Jambor <jamborm at gcc dot gnu.org> ---
Author: jamborm
Date: Tue Nov 12 12:53:53 2013
New Revision: 204698

URL: http://gcc.gnu.org/viewcvs?rev=204698&root=gcc&view=rev
Log:
2013-11-12  Martin Jambor  <mjambor@suse.cz>

    PR rtl-optimization/10474
    * ira.c (interesting_dest_for_shprep): New function.
    (split_live_ranges_for_shrink_wrap): Likewise.
    (find_moveable_pseudos): Move calculation of dominance info,
    df_analysios and the final anlyses to...
    (ira): ...here, call split_live_ranges_for_shrink_wrap.

testsuite/
    * gcc.dg/pr10474.c: New testcase.
    * gcc.dg/ira-shrinkwrap-prep-1.c: Likewise.
    * gcc.dg/ira-shrinkwrap-prep-2.c: Likewise.


Added:
    trunk/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-1.c
    trunk/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-2.c
    trunk/gcc/testsuite/gcc.dg/pr10474.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ira.c
    trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/10474] shrink wrapping for functions

[law at gcc dot gnu.org]

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

--- Comment #16 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Author: law
Date: Fri Nov 22 19:37:00 2013
New Revision: 205281

URL: http://gcc.gnu.org/viewcvs?rev=205281&root=gcc&view=rev
Log:
    PR rtl-optimization/10474
    * ira.c (interesting_dest_for_shprep_1): New function.
    (interesting_dest_for_shprep): Use interesting_dest_for_shprep_1,
    also check parallels.

testsuite/
    * gcc.dg/pr10474.c: Also test ppc64.
    * gcc.dg/ira-shrinkwrap-prep-1.c: Also tes ppc64, changed all ints
        to longs.
    * gcc.dg/ira-shrinkwrap-prep-2.c: Likewise.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ira.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-1.c
    trunk/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-2.c
    trunk/gcc/testsuite/gcc.dg/pr10474.c

[Bug rtl-optimization/10474] shrink wrapping for functions

[jamborm at gcc dot gnu.org]

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

Martin Jambor <jamborm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |ramana.r at gmail dot com
         Resolution|---                         |FIXED

--- Comment #17 from Martin Jambor <jamborm at gcc dot gnu.org> ---
The testcase is now shrink-wrapped on ppc64 and x86_64, it is not on
others such as i?86 because parameter-passing ABI basically prevents
it.  If any of the three testcases pass also on any other platform
(e.g. Ramana claimed it also works on AArch32 [1]), feel free to add
it to the dg target in the testcase(s).

For my part, I now consider this to be fixed.

[1] http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02726.html

[Bug rtl-optimization/10474] shrink wrapping for functions

[scovich at gmail dot com]

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

--- Comment #18 from Ryan Johnson <scovich at gmail dot com> ---
(In reply to Martin Jambor from comment #17)
> The testcase is now shrink-wrapped on ppc64 and x86_64, it is not on
> others such as i?86 because parameter-passing ABI basically prevents
> it.  If any of the three testcases pass also on any other platform
> (e.g. Ramana claimed it also works on AArch32 [1]), feel free to add
> it to the dg target in the testcase(s).
> 
> For my part, I now consider this to be fixed.
> 
> [1] http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02726.html

Great! Does this mean shrink-wrapping will be in gcc-4.9, at least for x86_64
and ppc64?

[Bug rtl-optimization/10474] shrink wrapping for functions

[jamborm at gcc dot gnu.org]

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

--- Comment #19 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to Ryan Johnson from comment #18)
> Great! Does this mean shrink-wrapping will be in gcc-4.9, at least for
> x86_64 and ppc64?

Well, a fairly basic (but not altogether unreasonable) shrink-wrapping
"was" in gcc 4.8 (and earlier versions) too and that has not changed
at all.  The problem with this and similar testcases was that the
register allocator made decisions which made shrink-wrapping
impossible (or at least too difficult to perform).  The change I
committed and which will be a part of gcc 4.9 fixes this for a class
of pseudo-registers which commonly result in this problem but other
cases will still remain unresolved, for example PR 51982.  For some
statistics about what impact the implemented technique has, see the
email accompanying the first submission of the patch:
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01719.html

If you find another similar example which is important and clearly
possible to shrink-wrap but we don't do it, feel free to submit a
new missed-optimization bug and CC me.

[Bug rtl-optimization/10474] shrink wrapping for functions

[scovich at gmail dot com]

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

--- Comment #20 from Ryan Johnson <scovich at gmail dot com> ---
Hi Martin,

(PM reply because I don't have up-to-date information to file a proper 
bug report with)

On 25/11/2013 9:57 AM, jamborm at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10474
>
> --- Comment #19 from Martin Jambor <jamborm at gcc dot gnu.org> ---
> (In reply to Ryan Johnson from comment #18)
>> Great! Does this mean shrink-wrapping will be in gcc-4.9, at least for
>> x86_64 and ppc64?
> Well, a fairly basic (but not altogether unreasonable) shrink-wrapping
> "was" in gcc 4.8 (and earlier versions) too and that has not changed
> at all.  The problem with this and similar testcases was that the
> register allocator made decisions which made shrink-wrapping
> impossible (or at least too difficult to perform).  The change I
> committed and which will be a part of gcc 4.9 fixes this for a class
> of pseudo-registers which commonly result in this problem but other
> cases will still remain unresolved, for example PR 51982.  For some
> statistics about what impact the implemented technique has, see the
> email accompanying the first submission of the patch:
> http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01719.html
>
> If you find another similar example which is important and clearly
> possible to shrink-wrap but we don't do it, feel free to submit a
> new missed-optimization bug and CC me.
>
One that comes to mind right off, but is from several years ago and 
possibly no longer true: on platforms like solaris/sparc, accesses to 
thread-local storage require a function call to retrieve the base of 
thread-local storage; the compiler seems to emit the call once, in the 
function prologue. I strongly suspect (but can't confirm, since I no 
longer have access to Solaris/sparc) that such a 
function-call-in-prologue would confound subsequent efforts at shrink 
wrapping. I don't know how often this sort of scenario arises any more, 
though. It may be that the new emutls stuff has changed everything, 
because on cygwin and gcc-4.8 I now see separate calls into emutls for 
every TLS access.

As for PR 51982, it looks like having flow-sensitive local analysis 
could go a long way: just as it can be useful know that an "escaped" 
pointer has not *yet* escaped (e.g. PR 50346), here it would be useful 
to know that the stack frame, though perhaps eventually needed, is not 
needed just yet. Then, generation of the stack frame can be pushed down 
to the first basic block(s) where the need for a stack frame is 
undisputed, after any conditions that gate it. But I've been told that 
teaching gcc to think that way would not be easy...

In any case, thanks for the improvement to a hairy problem.

Regards,
Ryan