From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13312 invoked by alias); 18 May 2011 10:32:15 -0000 Received: (qmail 13304 invoked by uid 22791); 18 May 2011 10:32:14 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (194.98.77.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 18 May 2011 10:32:00 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 17AE3CB01F7; Wed, 18 May 2011 12:31:59 +0200 (CEST) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbMPP1PoAJ8S; Wed, 18 May 2011 12:31:56 +0200 (CEST) Received: from [192.168.1.2] (bon31-9-83-155-120-49.fbx.proxad.net [83.155.120.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mel.act-europe.fr (Postfix) with ESMTP id CD90FCB016C; Wed, 18 May 2011 12:31:51 +0200 (CEST) From: Eric Botcazou To: Laurent =?iso-8859-1?q?Roug=E9?= Subject: Re: Reintroduce -mflat option on SPARC Date: Wed, 18 May 2011 14:36:00 -0000 User-Agent: KMail/1.9.9 Cc: gcc-patches@gcc.gnu.org References: <4D64F83B.5060704@menta.fr> <4DA73D99.5000800@menta.fr> <201105171251.20272.ebotcazou@adacore.com> In-Reply-To: <201105171251.20272.ebotcazou@adacore.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <201105181231.21495.ebotcazou@adacore.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-05/txt/msg01271.txt.bz2 > Another question: why does the model hijack %i7 to use it as frame pointer, > instead of just using %fp? AFAICS both are kept as fixed registers by the > code so the model seems to be wasting 1 register (2 without frame pointer). Related question: why saving the Local and In registers in the frame instead of at their standard location, right above the stack pointer? It would seem to me that the layout of the frame can be identical to the standard one. -- Eric Botcazou