From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9585 invoked by alias); 31 Mar 2003 08:56:02 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 9459 invoked by uid 71); 31 Mar 2003 08:56:01 -0000 Date: Mon, 31 Mar 2003 09:47:00 -0000 Message-ID: <20030331085601.9390.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Falk Hueffner Subject: Re: target/6882: [SPARC] Useless stack adjustment code Reply-To: Falk Hueffner X-SW-Source: 2003-03/txt/msg02093.txt.bz2 List-Id: The following reply was made to PR target/6882; it has been noted by GNATS. From: Falk Hueffner To: Eric Botcazou Cc: Hans-Peter Nilsson , , , , Subject: Re: target/6882: [SPARC] Useless stack adjustment code Date: 31 Mar 2003 10:50:21 +0200 Eric Botcazou 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 : 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