From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31758 invoked by alias); 15 Sep 2002 14:40:36 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 31751 invoked from network); 15 Sep 2002 14:40:35 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 15 Sep 2002 14:40:35 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17qbVk-0000Xg-00; Sun, 15 Sep 2002 10:40:36 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17qaa1-0007ZY-00; Sun, 15 Sep 2002 10:40:57 -0400 Date: Sun, 15 Sep 2002 09:15:00 -0000 From: Daniel Jacobowitz To: Alexandre Oliva Cc: binutils@sources.redhat.com, echristo@redhat.com Subject: Re: MIPS assembler branch relaxations Message-ID: <20020915144056.GA28751@nevyn.them.org> Mail-Followup-To: Alexandre Oliva , binutils@sources.redhat.com, echristo@redhat.com References: <20020914151121.GA7853@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2002-09/txt/msg00251.txt.bz2 On Sun, Sep 15, 2002 at 01:39:27AM -0300, Alexandre Oliva wrote: > On Sep 14, 2002, Daniel Jacobowitz wrote: > > > If this goes in as-is, I doubt that it'll ever be done the right way. > > I agree. I doubt it's worth doing it the right way. It shouldn't > strike often enough to motivate anyone to do it. > > > Does it happen inside .set nomacro? [I think so - should it? I'd > > say not!] > > I don't see why not. It's not like we're expanding a macro. We're > rather doing relaxation. Does the linker refrain from doing > relaxations on machine code generated from opcodes assembled while > .set nomacro was in effect? This is no different, except that the > relaxation is being performed in the assembler rather than in the > linker. I suppose. But, as I've been discussing with Eric, the eventual goal is for GCC to not emit macros; which will let it have much more precise control over the generated code. That'll make overlong branches significantly less likely, and more interesting to know about. I guess a warning would suffice. > > I think there should be a command-line option to disable this, > > and/or warn about it. > > That would be a nice improvement. Just arrange for whatever option > you come up with to disable this block: > > if (place == NULL > && address_expr > && ((*reloc_type == BFD_RELOC_16_PCREL > && address_expr->X_op != O_constant) > || *reloc_type == BFD_RELOC_16_PCREL_S2) > && (pinfo & INSN_UNCOND_BRANCH_DELAY || pinfo & INSN_COND_BRANCH_DELAY > || pinfo & INSN_COND_BRANCH_LIKELY) > + && !whatever_option_you_come_up_with > && !mips_opts.mips16) > > This will switch all the rest off. Thanks. How about something as simple as -mno-relax-branch? (Or would it be -no-mrelax-branch? Gas is pretty inconsistent.) I suppose warning by default would be a little too harsh, too. With the option to not relax it would be as simple as running a GCC testsuite with unix/-Wa,-mno-relax-branch. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer