[Bug rtl-optimization/25505] New: gcc uses way too much stack space for this code

[Bug rtl-optimization/25505] New: gcc uses way too much stack space for this code

[sabre at nondot dot org]

The SelectCode function requires a huge amount of stack space (over 20K on
darwin-PPC with GCC 4.x.  With GCC 3.3 it only took 512 bytes of stack space.

-Chris


-- 
           Summary: gcc uses way too much stack space for this code
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: sabre at nondot dot org


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

[Bug rtl-optimization/25505] gcc uses way too much stack space for this code

[sabre at nondot dot org]

------- Comment #1 from sabre at nondot dot org  2005-12-20 19:57 -------
Created an attachment (id=10537)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10537&action=view)
testcase


-- 


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

[Bug rtl-optimization/25505] gcc uses way too much stack space for this code

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2005-12-20 20:15 -------
At -O0 in 4.2.0, we have:
        stwu r1,-7920(r1)

as the max.  so that is 8k (I have not looked into why there is 8k).


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|4.0.1                       |
      Known to work|3.3                         |


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

[Bug rtl-optimization/25505] gcc uses way too much stack space for this code

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2005-12-20 20:18 -------
3.3 at -O2 -fno-schedule-insns gave:
        stwu r1,-4016(r1)


-- 


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

[Bug rtl-optimization/25505] gcc uses way too much stack space for this code

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2005-12-20 20:20 -------
at -O2 -fno-schedule-insns on the mainline:
        stwu r1,-17088(r1)


-- 


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

[Bug rtl-optimization/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2005-12-20 21:44 -------
Small testcase:
typedef struct a
{
  int f[1000];
} a;
a f(void);
int g(void)
{
  f();
  f();
}

----

Note that the C front-end has always produced bad stack usage.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |missed-optimization
      Known to fail|                            |4.0.0 4.1.0 4.2.0
      Known to work|                            |3.3.3
   Last reconfirmed|0000-00-00 00:00:00         |2005-12-20 21:44:03
               date|                            |
            Summary|gcc uses way too much stack |[4.0/4.1/4.2 Regression] gcc
                   |space for this code         |uses way too much stack
                   |                            |space for this code
   Target Milestone|---                         |4.0.3


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

[Bug rtl-optimization/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code

[sabre at nondot dot org]

------- Comment #6 from sabre at nondot dot org  2005-12-20 21:47 -------
Re: comment #5:

That is a similar testcase, but not an identical one.  A better one would be
something like:

void foo() {
  if (...) {
     std::pair<int, int> = ..
     ...
  }
  if (...) {
     std::pair<int, int> = ..
     ...
  }
  if (...) {
     std::pair<int, int> = ..
     ...
  }
}

Further, a huge amount of the wastage appears to be coming from C++
temporaries, not explicit variable definitions.

-Chris


-- 


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

[Bug rtl-optimization/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2005-12-20 21:50 -------
(In reply to comment #6)
> Re: comment #5:
> 
> That is a similar testcase, but not an identical one.  A better one would be
> something like:

Actually GCC gets the following testcase "correct":
typedef struct a
{
  int f[1000];
} a;


a f(void);

int g(void)
{
 { a t = f();}
 { a t = f();}
}


-- 


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

[Bug rtl-optimization/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code

[pinskia at gcc dot gnu dot org]

------- Comment #8 from pinskia at gcc dot gnu dot org  2005-12-20 21:53 -------
This looks very much related to PR 16269.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |16269


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

[Bug rtl-optimization/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code

[mmitchel at gcc dot gnu dot org]

------- Comment #9 from mmitchel at gcc dot gnu dot org  2006-01-15 22:19 -------
I agree that this looks related to PR 16269.  

In that PR, RTH suggests that the right way to fix this is for the front end to
be more explicit about the lifetime of the temporaries, which definitely seems
the best way to attack the problem.  In theory, the middle-end could notice the
fact that the temporary is no longer used, but that would be much more complex.

I've set this to P2, as it does not result in wrong code.


-- 

mmitchel at gcc dot gnu dot org changed:

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


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

[Bug rtl-optimization/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code

[sabre at nondot dot org]

------- Comment #10 from sabre at nondot dot org  2006-01-15 22:23 -------
Actually, it would be impossible/impractical for the middle end to do this. 
The middle end can't know that the called functions (which are passed the stack
objects by reference) don't hang on to a pointer to these objects.

-Chris


-- 


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

[Bug rtl-optimization/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code

[pinskia at gcc dot gnu dot org]

------- Comment #11 from pinskia at gcc dot gnu dot org  2006-01-30 14:03 -------
Hmm, This works "correctly" on x86_64-linux-gnu.  At least the one in comment
#7.  The one in comment #5 is still bad.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org


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

[Bug middle-end/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code

[pinskia at gcc dot gnu dot org]

------- Comment #12 from pinskia at gcc dot gnu dot org  2006-01-30 14:11 -------
Loooking into fixing comment #5.


-- 


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

[Bug middle-end/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code

[pinskia at gcc dot gnu dot org]

------- Comment #13 from pinskia at gcc dot gnu dot org  2006-01-30 14:25 -------
For comment #5 in the C++ case, the problem comes from the middle-end
(gimplifier) doing:
4065          /* TARGET_EXPR temps aren't part of the enclosing block, so add
it
4066             to the temps list.  */
4067          gimple_add_tmp_var (temp);

The C case is different and I might have a fix.


-- 


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

[Bug middle-end/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code

[pinskia at gcc dot gnu dot org]

------- Comment #14 from pinskia at gcc dot gnu dot org  2006-02-15 18:30 -------
PR 23372 is the other bug which blocks the orginal source.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |23372


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

[Bug middle-end/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code

[mmitchel at gcc dot gnu dot org]

------- Comment #15 from mmitchel at gcc dot gnu dot org  2006-02-24 00:26 -------
This issue will not be resolved in GCC 4.1.0; retargeted at GCC 4.1.1.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.3                       |4.1.1


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

[Bug middle-end/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code

[mmitchel at gcc dot gnu dot org]

------- Comment #16 from mmitchel at gcc dot gnu dot org  2006-05-25 02:33 -------
Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.1.1                       |4.1.2


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

[Bug middle-end/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code

[jconner at apple dot com]

------- Comment #17 from jconner at apple dot com  2006-08-21 23:43 -------
I can reduce the stack size in this example to ~13k by not invoking
mark_temp_addr_taken from expand_call (calls.c).  This allows
compiler-generated temps used to store return values to share stack slots, even
when the function calls are in the same scope.  The validity of this change is
supported by testing against i386-Linux and ppc-Darwin on 4.1 and mainline with
no regressions, but the original importer of this code has some concerns that
this might introduce subtle problems.  See discussion here:
  http://gcc.gnu.org/ml/gcc/2006-08/msg00389.html


-- 

jconner at apple dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jconner at apple dot com


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

[Bug middle-end/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code

[jconner at gcc dot gnu dot org]

------- Comment #18 from jconner at gcc dot gnu dot org  2006-08-31 23:44 -------
Subject: Bug 25505

Author: jconner
Date: Thu Aug 31 23:44:00 2006
New Revision: 116613

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116613
Log:
2006-08-31  Josh Conner  <jconner@apple.com>

        PR c++/25505
        * tree-gimple.c (is_gimple_mem_rhs): Recognize functions
        returning aggregates.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-gimple.c


-- 


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

[Bug middle-end/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code

[jconner at gcc dot gnu dot org]

------- Comment #19 from jconner at gcc dot gnu dot org  2006-09-01 16:56 -------
Subject: Bug 25505

Author: jconner
Date: Fri Sep  1 16:56:14 2006
New Revision: 116633

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116633
Log:
2006-09-01  Josh Conner  <jconner@apple.com>

        PR c++/25505
        * tree-nrv.c (dest_safe_for_nrv_p): New function.
        (execute_return_slot_opt): Use it.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-nrv.c


-- 


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

[Bug middle-end/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code

[jconner at gcc dot gnu dot org]

------- Comment #20 from jconner at gcc dot gnu dot org  2006-09-01 16:56 -------
Subject: Bug 25505

Author: jconner
Date: Fri Sep  1 16:56:45 2006
New Revision: 116634

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116634
Log:
2006-09-01  Josh Conner  <jconner@apple.com>

        PR c++/25505
        gcc.dg/nrv3.c: New test.
        gcc.dg/nrv4.c: New test.
        gcc.dg/nrv5.c: New test.


Added:
    trunk/gcc/testsuite/gcc.dg/nrv3.c
    trunk/gcc/testsuite/gcc.dg/nrv4.c
    trunk/gcc/testsuite/gcc.dg/nrv5.c
Modified:
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code

[jason at gcc dot gnu dot org]

------- Comment #21 from jason at gcc dot gnu dot org  2006-09-06 21:39 -------
I expect that indeed, the test case Kenner mentioned as motivation for the call
to mark_temp_addr_taken doesn't need it any more because of gimplification. 
Any temporary that needs to live longer than a single gimple statement will be
represented in the gimple.  So as he said, we should be able to do away with a
lot of the temporary management code.


-- 


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

[Bug middle-end/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code

[jconner at gcc dot gnu dot org]

------- Comment #22 from jconner at gcc dot gnu dot org  2006-09-20 18:57 -------
Subject: Bug 25505

Author: jconner
Date: Wed Sep 20 18:57:46 2006
New Revision: 117091

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117091
Log:
2006-09-20  Josh Conner  <jconner@apple.com>

        PR middle-end/25505
        * calls.c (expand_call): Allow reuse of structure return stack
        temp.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/calls.c


-- 


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

[Bug middle-end/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code

[pinskia at gcc dot gnu dot org]

------- Comment #23 from pinskia at gcc dot gnu dot org  2006-09-21 04:53 -------
The last patch (on i686), cut the stack space from 11k to 5k.  Maybe there is
more still.


-- 


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

[Bug middle-end/25505] [4.0/4.1/4.2/4.3 Regression] gcc uses way too much stack space for this code

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.1.2                       |4.1.3


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

[Bug middle-end/25505] [4.0/4.1/4.2/4.3 Regression] gcc uses way too much stack space for this code

[howarth at nitro dot med dot uc dot edu]

------- Comment #24 from howarth at nitro dot med dot uc dot edu  2007-04-27 13:26 -------
How many of the changes made so far to trunk (which have reduced the stack
usage from 20K to 5K) have been backported into gcc 4.2?


-- 


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

[Bug middle-end/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code

[jakub at gcc dot gnu dot org]

------- Comment #25 from jakub at gcc dot gnu dot org  2007-11-22 13:05 -------
Don't see the point of keeping this bug open for the trunk:

with g++ -O2 -m32 pr25505.ii from #c1 on ppc64-linux

g++ 3.2.3

sed -n 's/^[[:blank:]]*stwu 1,//p' pr25505.s | sort -nur
-16(1)
-32(1)
-48(1) 
-64(1) 
-80(1) 
-96(1) 
-128(1)
-192(1)
-320(1)
-336(1)
-384(1) 
-512(1)  
-592(1)  
-688(1) 
-7232(1)

g++ 4.1.2

sed -n 's/^[[:blank:]]*stwu 1,//p' pr25505.s | sort -nur
-16(1)
-32(1)
-48(1)
-64(1)
-80(1) 
-96(1) 
-112(1)
-128(1)
-224(1)
-272(1)
-320(1)
-336(1)
-352(1) 
-432(1)  
-1024(1)
-13168(1)

trunk

sed -n 's/^[[:blank:]]*stwu 1,//p' pr25505.s | sort -nur
-16(1)
-32(1)
-48(1)
-64(1) 
-80(1) 
-96(1) 
-112(1)
-144(1)
-208(1)
-224(1)
-336(1)
-400(1) 
-768(1)  


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1/4.2 Regression] gcc
                   |gcc uses way too much stack |uses way too much stack
                   |space for this code         |space for this code


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

[Bug middle-end/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code

[dje at gcc dot gnu dot org]

------- Comment #26 from dje at gcc dot gnu dot org  2007-11-22 14:52 -------
Shall we declare that we won't backport the changes and close the bug?


-- 


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

[Bug middle-end/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code

[sabre at nondot dot org]

------- Comment #27 from sabre at nondot dot org  2007-11-22 21:14 -------
sounds fine to me, thanks


-- 


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

[Bug middle-end/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code

[rguenth at gcc dot gnu dot org]

------- Comment #28 from rguenth at gcc dot gnu dot org  2007-11-22 21:45 -------
Thus, fixed in 4.3, wontfix for earlier releases.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
      Known to work|3.3.3 3.4.0                 |3.3.3 3.4.0 4.3.0
         Resolution|                            |FIXED
   Target Milestone|4.1.3                       |4.3.0


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