This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Potential fix for rdar://4658012


On 8/26/06, Richard Guenther <richard.guenther@gmail.com> wrote:
On 8/26/06, Josh Conner <jconner@apple.com> wrote:
> All -
>
> rdar://4658012 describes a 3.x -> 4.x gcc regression where stack usage
> for a particular C++ function increases by 36x.  I have a relatively
> simple fix that allows the sharing of stack space for temporaries
> generated by the middle-end to hold the result of functions returning
> values in memory.  Unfortunately, this approach is reported to have
> caused an Ada front-end failure at some point in time on Sparc -- see
> thread starting here:
>
>   http://gcc.gnu.org/ml/gcc/2006-08/msg00389.html
>
> So, I went looking for an approach which would fix this in the C++
> front-end instead.  However, I discovered that the C front-end has a
> similar problem.  e.g., this code:
>
>   typedef struct { char x[1000]; } S;
>   S bar (void);
>   void foo (void) {
>     bar();
>     bar();
>   }
>
> eats 2000 bytes of stack, instead of 1000.

Applying the patch doesn't change this. Is the patch you quoted incomplete?

Instead the following patch makes the C testcase above share the stack slot. (completely untested)

Richard.

Index: calls.c
===================================================================
*** calls.c     (revision 116273)
--- calls.c     (working copy)
*************** expand_call (tree exp, rtx target, int i
*** 1985,1991 ****
           /* For variable-sized objects, we must be called with a target
              specified.  If we were to allocate space on the stack here,
              we would have no way of knowing when to free it.  */
!           rtx d = assign_temp (TREE_TYPE (exp), 1, 1, 1);

           mark_temp_addr_taken (d);
           structure_value_addr = XEXP (d, 0);
--- 1985,1991 ----
           /* For variable-sized objects, we must be called with a target
              specified.  If we were to allocate space on the stack here,
              we would have no way of knowing when to free it.  */
!           rtx d = assign_temp (TREE_TYPE (exp), 0, 1, 1);

           mark_temp_addr_taken (d);
           structure_value_addr = XEXP (d, 0);


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]