From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9457 invoked by alias); 21 Oct 2003 12:00:29 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 9449 invoked from network); 21 Oct 2003 12:00:25 -0000 Received: from unknown (HELO kirk.baltic.net) (193.189.247.10) by sources.redhat.com with SMTP; 21 Oct 2003 12:00:25 -0000 Received: (qmail 12896 invoked from network); 21 Oct 2003 11:57:32 -0000 Received: from waldorf.gecko.de (HELO kermit.int.gecko.de) (193.189.247.200) by kirk.baltic.net with SMTP; 21 Oct 2003 11:57:32 -0000 Received: from lorien.int.gecko.de (lorien [192.168.120.159]) by kermit.int.gecko.de (8.10.1/8.10.1) with ESMTP id h9LC2n719362; Tue, 21 Oct 2003 14:02:49 +0200 (MET DST) Received: from lorien.int.gecko.de (localhost [127.0.0.1]) by lorien.int.gecko.de (8.12.9/8.12.9) with ESMTP id h9LC0UqR031435; Tue, 21 Oct 2003 14:00:30 +0200 (MEST) (envelope-from munk@lorien.int.gecko.de) Received: (from munk@localhost) by lorien.int.gecko.de (8.12.9/8.12.9/Submit) id h9LC0UJb031434; Tue, 21 Oct 2003 14:00:30 +0200 (MEST) Date: Tue, 21 Oct 2003 14:38:00 -0000 From: Gunther Nikl To: Bernardo Innocenti Cc: GCC Mailing List , Richard Henderson Subject: Re: Testing m68k changes on AmigaOS and Linux/m68k Message-ID: <20031021120030.GA31365@lorien.int.gecko.de> References: <3F88BBCF.7090106@develer.com> <20031013152223.GA45308@lorien.int.gecko.de> <3F8BAED0.70004@develer.com> <20031014113756.GA1899@lorien.int.gecko.de> <3F8C28AE.4060301@develer.com> <20031015093247.GA41502@lorien.int.gecko.de> <20031015164848.GA7684@lorien.int.gecko.de> <3F8D97C6.5020406@develer.com> <20031016133157.GA14232@lorien.int.gecko.de> <3F8ECE9E.1080500@develer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F8ECE9E.1080500@develer.com> User-Agent: Mutt/1.4.1i X-SW-Source: 2003-10/txt/msg00948.txt.bz2 On Thu, Oct 16, 2003 at 07:00:14PM +0200, Bernardo Innocenti wrote: > Hmmm... with regargs, there are no pushes on the stack making things more > complicated. Why does that make thinks more complicate? I would say its the opposite. > IIRC, GCC knows how to accumulate pushes from multiple function calls and > should optimize then the control flow ends into the epilogue where unlink > can take care of it. This is probably a missed optimization case. > > Yes, with framepointer it was ok. I guess that the FP can't be eliminated > > because that would change the offset into the frame and tracking that is > > probably hard. > > The old SAS/C knew how to do that pretty well :-) SAS/C started to use SP-only with version 6 and they needed several subreleases to squeeze the last bugs out for it to work reliable according to their releasenotes. > It could even inline varargs functions, something that GCC still can't do. > It was pretty useful for inline stubs such as DoMethod() or Printf(). Printf() is handled by a pragma, but indeed DoMethod() can be inlined. > Could you please post the revised patch to gcc-patches for approval? > GCC's front page still says that 3.4 is in stage 2. If we're lucky we > can still get this in without opening a PR :-) 3.4 is in stage 3. Does that mean that a PR is required now? The attached patch fixes the regressions caused by the switch to always use the computed values from m68k_compute_frame_layout. Gunther --cut-- 2003-10-21 Gunther Nikl * config/m68k/m68k.c (m68k_compute_frame_layout): swap reg_mask and reg_rev_mask computation * config/m68k/m68k.c (m68k_output_function_prologue): Fix usage of current_frame (one typo and one missing); use reg_rev_mask not reg_mask * config/m68k/m68k.c (m68k_output_function_epilogue): Fix usage of current_frame; use fpu_rev_mask not fpu_mask --- m68k.c.orig Tue Oct 21 13:31:13 2003 +++ m68k.c Tue Oct 21 13:32:35 2003 @@ -358,8 +358,8 @@ m68k_compute_frame_layout (void) for (regno = 16; regno < 24; regno++) if (m68k_save_reg (regno, interrupt_handler)) { - mask |= 1 << (23 - regno); - rmask |= 1 << (regno - 16); + mask |= 1 << (regno - 16); + rmask |= 1 << (23 - regno); saved++; } current_frame.foffset = saved * 12 /* (TARGET_CFV4E ? 8 : 12) */; @@ -616,7 +616,7 @@ m68k_output_function_prologue (FILE *str #ifdef MOTOROLA asm_fprintf (stream, "\tfmovm %I0x%x,-(%Rsp)\n", current_frame.fpu_mask); #else - asm_fprintf (stream, "\tfmovem %I0x%x,%Rsp@-\n", current_frmae.fpu_mask); + asm_fprintf (stream, "\tfmovem %I0x%x,%Rsp@-\n", current_frame.fpu_mask); #endif if (dwarf2out_do_frame ()) { @@ -651,8 +651,8 @@ m68k_output_function_prologue (FILE *str else if (GET_CODE (stack_limit_rtx) != SYMBOL_REF) warning ("stack limit expression is not supported"); } - - if (num_saved_regs <= 2) + + if (current_frame.reg_no <= 2) { /* Store each separately in the same order moveml uses. Using two movel instructions instead of a single moveml @@ -701,9 +701,9 @@ m68k_output_function_prologue (FILE *str else { #ifdef MOTOROLA - asm_fprintf (stream, "\tmovm.l %I0x%x,-(%Rsp)\n", current_frame.reg_mask); + asm_fprintf (stream, "\tmovm.l %I0x%x,-(%Rsp)\n", current_frame.reg_rev_mask); #else - asm_fprintf (stream, "\tmoveml %I0x%x,%Rsp@-\n", current_frame.reg_mask); + asm_fprintf (stream, "\tmoveml %I0x%x,%Rsp@-\n", current_frame.reg_rev_mask); #endif } if (dwarf2out_do_frame ()) @@ -928,7 +928,7 @@ m68k_output_function_epilogue (FILE *str #else asm_fprintf (stream, "\tmoveml %s@(-%wd),%I0x%x\n", reg_names[FRAME_POINTER_REGNUM], - offset + fsize, + current_frame.offset + fsize, current_frame.reg_mask); #endif } @@ -1007,7 +1007,7 @@ m68k_output_function_epilogue (FILE *str asm_fprintf (stream, "\tfmovm -%wd(%s),%I0x%x\n", current_frame.foffset + fsize, reg_names[FRAME_POINTER_REGNUM], - current_frame.fpu_mask); + current_frame.fpu_rev_mask); #else asm_fprintf (stream, "\tfmovem %s@(-%wd),%I0x%x\n", reg_names[FRAME_POINTER_REGNUM], --cut--