From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15312 invoked by alias); 21 Nov 2003 23:40:12 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 15297 invoked from network); 21 Nov 2003 23:40:11 -0000 Received: from unknown (HELO localhost.localdomain) (24.7.123.142) by sources.redhat.com with SMTP; 21 Nov 2003 23:40:11 -0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hALNeKce017037; Fri, 21 Nov 2003 15:40:21 -0800 Subject: Re: avoid unnecessary register saves for setjmp From: Jim Wilson To: Geoff Keating Cc: gcc-patches@gcc.gnu.org, Daniel Jacobowitz In-Reply-To: References: <1069393614.1023.66.camel@leaf.tuliptree.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sat, 22 Nov 2003 00:20:00 -0000 Message-Id: <1069458021.1020.89.camel@leaf.tuliptree.org> Mime-Version: 1.0 X-SW-Source: 2003-11/txt/msg01775.txt.bz2 On Fri, 2003-11-21 at 12:11, Geoff Keating wrote: > I've looked at this some time in the past (I don't remember the exact > circumstances). I came to the same conclusion as you, except in the > case when NON_SAVING_SETJMP is defined, when we do need to save any > call-saved registers. There is code in final_start_function to do this. However, this can only work if you aren't using register elimination, and if you are emitting assembly language prologues instead of using RTL patterns in the md file. So this could only work for old ports. Checking, I see that the only port that uses NON_SAVING_SETJMP is the x86 svr3 port, and I am fairly certain that is a dead port. Yes, I see it on Nathanael Nerode's obsolete list for 3.4. Actually, it looks like this is the only target that ever used this macro. If we really need this to work, then we can move the code from final_start_function to reload. This will give code very similar to what I just deleted, except that it tests NON_SAVING_SETJMP. Or we can just obsolete all of the NON_SAVING_SETJMP support, as I believe we don't need it anymore. It seems very unlikely that we need gcc to support systems with a broken setjmp() library function. The original definition of the macro might even have been based on a misunderstanding of what setjmp does. I think dropping the NON_SAVING_SETJMP support is the more sensible solution. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com