For the following code: class Complex_i { public: int re, im; Complex_i (int r, int i) : re(r), im(i) {} Complex_i () {} }; inline Complex_i operator+ (Complex_i a, Complex_i b) { return Complex_i ( a.re+b.re, a.im+b.im); } void foobar (void) { Complex_i factor (123, 428); factor = factor + factor; } gcc-3.1 -O3 generates: _Z6foobarv: .LLFB4: !#PROLOGUE# 0 add %sp, -144, %sp .LLCFI2: !#PROLOGUE# 1 nop retl sub %sp, -144, %sp the stack adjustment code is useless. Is it possible not to emmit it? Release: gcc-3.1 Environment: sparc-sun-solaris2.7
State-Changed-From-To: open->closed State-Changed-Why: The prologue is always emitted if assembly code is emitted for the function.
From: Hans-Peter Nilsson <hp@bitrange.com> To: ebotcazou@gcc.gnu.org, <dann@godzilla.ics.uci.edu>, <gcc-bugs@gcc.gnu.org>, <gcc-prs@gcc.gnu.org>, <nobody@gcc.gnu.org>, <gcc-gnats@gcc.gnu.org> Cc: Subject: Re: target/6882: [SPARC] Useless stack adjustment code Date: Sun, 30 Mar 2003 23:15:52 -0500 (EST) On 29 Mar 2003 ebotcazou@gcc.gnu.org wrote: > State-Changed-Why: > The prologue is always emitted if assembly code is emitted for the function. No, it seems a valid optimization request to not emit the stack-adjustment code. Could you find a *specific* reason for the stack-adjustment code? (Please state that in the PR.) I'll re-open this PR. brgds, H-P
State-Changed-From-To: closed->open State-Changed-Why: Seems a valid request.
From: Hans-Peter Nilsson <hp@bitrange.com> To: Eric Botcazou <ebotcazou@libertysurf.fr> Cc: dann@godzilla.ics.uci.edu, <gcc-bugs@gcc.gnu.org>, <nobody@gcc.gnu.org>, <gcc-gnats@gcc.gnu.org> Subject: Re: target/6882: [SPARC] Useless stack adjustment code Date: Mon, 31 Mar 2003 07:44:27 -0500 (EST) On Mon, 31 Mar 2003, Eric Botcazou wrote: > > No, it seems a valid optimization request to not emit the > > stack-adjustment code. Could you find a *specific* reason for > > the stack-adjustment code? (Please state that in the PR.) > > No, I don't see a "specific" reason. But: > - functions from the same translation unit that call it (and that appear > after it in normal mode, but the restriction is lifted with > -funit-at-a-time) don't actually emit the call, > - would the benefit be worth it in real life, given that the costly operation > is to call the function itself (for nothing)? I think the real optimization > is not to emit the call at all. Now you're arguing about the *value of the optimization*. I was arguing about *closing the PR for the wrong reason*. It seemed to indicate a misunderstanding about GCC rather than a special need on the SPARC. For example, the CRIS and MMIX targets don't emit that kind of redundant stack frame. Having said that, let's continue to the *new* discussion. You can't optimize out the call from other translation units. Not being a SPARC maintainer I won't try to judge on the benefit, but it looks simple enough and seems worthwhile. C++ tends to generate a lot of small trivial functions. brgds, H-P
From: Eric Botcazou <ebotcazou@libertysurf.fr> To: Hans-Peter Nilsson <hp@bitrange.com> Cc: <dann@godzilla.ics.uci.edu>, <gcc-bugs@gcc.gnu.org>, <nobody@gcc.gnu.org>, <gcc-gnats@gcc.gnu.org> Subject: Re: target/6882: [SPARC] Useless stack adjustment code Date: Mon, 31 Mar 2003 09:37:25 +0200 > No, it seems a valid optimization request to not emit the > stack-adjustment code. Could you find a *specific* reason for > the stack-adjustment code? (Please state that in the PR.) No, I don't see a "specific" reason. But: - functions from the same translation unit that call it (and that appear after it in normal mode, but the restriction is lifted with -funit-at-a-time) don't actually emit the call, - would the benefit be worth it in real life, given that the costly operation is to call the function itself (for nothing)? I think the real optimization is not to emit the call at all. -- Eric Botcazou
From: Falk Hueffner <falk.hueffner@student.uni-tuebingen.de> To: Eric Botcazou <ebotcazou@libertysurf.fr> Cc: Hans-Peter Nilsson <hp@bitrange.com>, <dann@godzilla.ics.uci.edu>, <gcc-bugs@gcc.gnu.org>, <nobody@gcc.gnu.org>, <gcc-gnats@gcc.gnu.org> Subject: Re: target/6882: [SPARC] Useless stack adjustment code Date: 31 Mar 2003 10:50:21 +0200 Eric Botcazou <ebotcazou@libertysurf.fr> writes: > > No, it seems a valid optimization request to not emit the > > stack-adjustment code. Could you find a *specific* reason for > > the stack-adjustment code? (Please state that in the PR.) > > No, I don't see a "specific" reason. But: > - functions from the same translation unit that call it (and that appear > after it in normal mode, but the restriction is lifted with > -funit-at-a-time) don't actually emit the call, > - would the benefit be worth it in real life, given that the costly operation > is to call the function itself (for nothing)? I think the real optimization > is not to emit the call at all. Don't know about SPARC, but on Alpha, this also occurs with non-nop functions: struct s2 { unsigned long a, b; }; unsigned long f8(struct s2 x) { return x.a + x.b; } 0000000000000000 <f8>: 0: 00 04 11 42 addq a0,a1,v0 4: f0 ff de 23 lda sp,-16(sp) 8: 10 00 de 23 lda sp,16(sp) c: 01 80 fa 6b ret While the optimization certainly isn't that important, it also seems to be not too difficult, and the code size saving is also nice. -- Falk
From: Eric Botcazou <ebotcazou@libertysurf.fr> To: Hans-Peter Nilsson <hp@bitrange.com> Cc: dann@godzilla.ics.uci.edu, <gcc-bugs@gcc.gnu.org>, <nobody@gcc.gnu.org>, <gcc-gnats@gcc.gnu.org> Subject: Re: target/6882: [SPARC] Useless stack adjustment code Date: Mon, 31 Mar 2003 16:07:38 +0200 > Now you're arguing about the *value of the optimization*. > I was arguing about *closing the PR for the wrong reason*. Well, you only asked me to give a specific reason for the adjustment code. I agreed that there appears to be no compelling reason for it. But the problem is that the code is emitted anyway. So IMHO the right question is rather: are there strong enough reasons for removing it? Therefore I gave my opinion on this latter question. > Having said that, let's continue to the *new* discussion. You > can't optimize out the call from other translation units. Not > being a SPARC maintainer I won't try to judge on the benefit, > but it looks simple enough and seems worthwhile. C++ tends to > generate a lot of small trivial functions. Maybe. My impression is that, if the optimization was that simple and that worthwhile, it would already have been implemented. But I'm not a SPARC maintainer either, so... -- Eric Botcazou
This is already fixed on the tree-ssa branch so suspending untill that branch gets pulled into the mainline.
Note this is not really target spefic as it happens on every target with -fno-omit-frame- pointer.
Fixed for the tree-ssa so closing.
I still see this for the example given in comment #6 with 3.5-tree-ssa 20031216. Are you sure it's fixed?
The other problems in this bug are target specific bugs so reopening for them.
I think sparc's part gets fixed by: <http://gcc.gnu.org/ml/gcc-patches/2004-06/msg01049.html>.
Investigating.
This is fixed on SPARC thanks to tree-ssa. With the original testcase at -O2: .file "pr6882.cpp" .section ".text" .align 4 .align 4 .global _Z6foobarv .type _Z6foobarv, #function .proc 020 _Z6foobarv: .LLFB9: jmp %o7+8 nop .LLFE9: .size _Z6foobarv, .-_Z6foobarv .ident "GCC: (GNU) 3.5.0 20040705 (experimental)" Falk, the example you gave in comment #6 appears to be specific to Alpha: it doesn't generate epilogue/prologue code on SPARC with 3.4.x or mainline. So I'd suggest to open a specific PR to track the problem. I'm closing this one.