From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11171 invoked by alias); 26 Jul 2004 12:27:18 -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 11156 invoked from network); 26 Jul 2004 12:27:17 -0000 Received: from unknown (HELO smtp.uk.superh.com) (193.128.105.170) by sourceware.org with SMTP; 26 Jul 2004 12:27:17 -0000 Received: from sh-uk-ex01.uk.w2k.superh.com (sh-uk-ex01 [192.168.16.17]) by smtp.uk.superh.com (8.12.10/8.12.10) with ESMTP id i6QCREaH002018; Mon, 26 Jul 2004 13:27:14 +0100 (BST) Received: from chloe.uk.w2k.superh.com ([192.168.17.40]) by sh-uk-ex01.uk.w2k.superh.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Jul 2004 13:29:28 +0100 Received: (from renneckej@localhost) by chloe.uk.w2k.superh.com (8.11.6/8.11.6) id i6QCU3P23019; Mon, 26 Jul 2004 13:30:03 +0100 From: Joern Rennecke Message-Id: <200407261230.i6QCU3P23019@chloe.uk.w2k.superh.com> Subject: Re: Unreviewed patches To: ebotcazou@libertysurf.fr (Eric Botcazou) Date: Mon, 26 Jul 2004 22:05:00 -0000 Cc: joern.rennecke@superh.com (Joern Rennecke), zack@codesourcery.com (Zack Weinberg), gcc-patches@gcc.gnu.org In-Reply-To: <00d501c47256$12fc6020$709d9c53@magellan> from "Eric Botcazou" at Jul 25, 2004 04:43:14 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jul 2004 12:29:28.0265 (UTC) FILETIME=[31A0F390:01C4730C] X-SW-Source: 2004-07/txt/msg02403.txt.bz2 > > > However, I can tell you now just from looking at the code that > > your proposed change is both unsafe and inappropriate. > > print_slot is used in some places to actually emit a delay slot insn - > > there using 0 would be inappropriate - and in other places it is used > > to emit the delay slot insn before the jump, there it would be unsafe > > to do peepholes. > > Ok, thanks for the clarification. Any plan to get rid of those annoying > peepholes in the near future? ;-) No. They actually have their place, some things you want to do after scheduling and/or branch shortening. Unless you want to add another peephole2 pass and a way to check global variables which pass you are in, of course. Why don't you add another parameter to final_scan_insn?