From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16992 invoked by alias); 1 Nov 2002 23:37:37 -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 16943 invoked from network); 1 Nov 2002 23:37:35 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 1 Nov 2002 23:37:35 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id gA1NFHw16502; Fri, 1 Nov 2002 18:15:17 -0500 Received: from porcupine.cygnus.com (vpn50-35.rdu.redhat.com [172.16.50.35]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id gA1NbPf18048; Fri, 1 Nov 2002 18:37:25 -0500 Received: from porcupine (law@localhost) by porcupine.cygnus.com (8.12.5/8.12.5/Submit) with ESMTP id gA1Nm0uM031783; Fri, 1 Nov 2002 16:48:03 -0700 Message-Id: <200211012348.gA1Nm0uM031783@porcupine.cygnus.com> To: Joern Rennecke cc: tm , kkojima@gcc.gnu.org, gcc-patches@gcc.gnu.org Reply-To: law@redhat.com Subject: Re: PATCH: reorg branch displacement fix In-Reply-To: Your message of "Fri, 01 Nov 2002 23:21:38 GMT." <3DC30C82.89D0FFEC@superh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Nov 2002 15:37:00 -0000 From: Jeff Law X-SW-Source: 2002-11/txt/msg00052.txt.bz2 In message <3DC30C82.89D0FFEC@superh.com>, Joern Rennecke writes: >It used to be possible to hide these spurious redirection 'opportunities', >but reorg has become more aggressive in this aspect. Which means that your backend is abusing the facilities in the generic parts of the compiler. > We are not talking >about a problem of making an optimization in reorg, but about avoiding invali >d transformations there. Reorg has always been designed to not worry about the potential of lengthening branches. Those are for shorten-branches and the backend to deal with. reorg has always worked under the assumption that it can thread a branch and not worry about if that lengthens the branch. In fact that's part of its fundamental design. >There is no such thing as a conditional branch with an infinite offset on the > SH, Similarly for the PA, sparc and various other ports. >Are you suggesting I should disable the putatively machine-independent delay >slot >scheduling for the SH and instead roll my own in the SH backend? I'm suggesting you fix your backend to work within the framework and assumptions made by the generic parts of the compiler. jeff