From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-73078-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 2152 invoked by alias); 2 May 2003 23:08:19 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 2145 invoked from network); 2 May 2003 23:08:19 -0000
Received: from unknown (HELO frothingslosh.sfbay.redhat.com) (12.150.115.200)
  by sources.redhat.com with SMTP; 2 May 2003 23:08:19 -0000
Received: from frothingslosh.sfbay.redhat.com (localhost.localdomain [127.0.0.1])
	by frothingslosh.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id h42N6JNm030421;
	Fri, 2 May 2003 16:06:19 -0700
Received: (from rth@localhost)
	by frothingslosh.sfbay.redhat.com (8.12.8/8.12.8/Submit) id h42N6IRx030419;
	Fri, 2 May 2003 16:06:18 -0700
X-Authentication-Warning: frothingslosh.sfbay.redhat.com: rth set sender to rth@redhat.com using -f
Date: Fri, 02 May 2003 23:08:00 -0000
From: Richard Henderson <rth@redhat.com>
To: Piotr Wyderski <piotr.wyderski@hoga.pl>
Cc: gcc@gcc.gnu.org
Subject: Re: Optimization
Message-ID: <20030502230618.GH2442@redhat.com>
Mail-Followup-To: Richard Henderson <rth@redhat.com>,
	Piotr Wyderski <piotr.wyderski@hoga.pl>, gcc@gcc.gnu.org
References: <000201c310a3$850de5a0$acf84dd5@voltan>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000201c310a3$850de5a0$acf84dd5@voltan>
User-Agent: Mutt/1.4.1i
X-SW-Source: 2003-05/txt/msg00250.txt.bz2

On Fri, May 02, 2003 at 01:32:39PM +0200, Piotr Wyderski wrote:
> Why don't you optimize the "jump to ret" construction?

We do, depending on the target, and the epilogue.

	int foo(int p, int *q, int *r)
	{
	  if (p) *q = 1; else *r = 2;
	}

        movl    4(%esp), %eax
        testl   %eax, %eax
        je      .L2
        movl    8(%esp), %eax
        movl    $1, (%eax)
        ret
        .p2align 2,,3
.L2:
        movl    12(%esp), %eax
        movl    $2, (%eax)
        ret

> I see that there's also a greedy stack frame allocator instead
> of a lazy one. Using the previous example
[...]
> when C is short and can be computed using only the scratch
> registers, i.e. eax, edx and ecx, and D is complex and needs
> to save/restore the remaining GP registers,

Yes, this is called "shrink-wrapping", and we don't implement it.


r~