From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11552 invoked by alias); 15 Oct 2002 20:04:52 -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 11544 invoked from network); 15 Oct 2002 20:04:52 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 15 Oct 2002 20:04:52 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 181Yrf-0004s0-00; Tue, 15 Oct 2002 16:04:31 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 181Xvv-0002vp-00; Tue, 15 Oct 2002 16:04:51 -0400 Date: Tue, 15 Oct 2002 14:00:00 -0000 From: Daniel Jacobowitz To: Jim Wilson Cc: gcc@gcc.gnu.org, binutils@sources.redhat.com Subject: Re: MIPS gas relaxation still doesn't work Message-ID: <20021015200451.GA11252@nevyn.them.org> Mail-Followup-To: Jim Wilson , gcc@gcc.gnu.org, binutils@sources.redhat.com References: <20021014091649.A29353@lucon.org> <20021014101640.A30133@lucon.org> <20021014105055.B30830@lucon.org> <20021014110118.B30940@lucon.org> <20021014123940.A32333@lucon.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-10/txt/msg00862.txt.bz2 On Tue, Oct 15, 2002 at 03:58:57PM -0400, Jim Wilson wrote: > >Can gcc not to emit nop nor noreorder when it tries to fill the delay > >slot with nop? > > You never want the assembler to try to fill delay slots. Consider a compiler > optimization like software pipelining. The compiler will schedule instructions > inside a loop with full knowledge of the target pipeline to give maximum > performance. Then the assembler picks a random instruction from the loop, > puts it in a branch delay slot, and now your code runs twice as slow because > the assembler introduced pipeline stalls. Of course, gcc isn't good enough > yet to have this problem yet, but we will get there eventually. Meanwhile, we > need to get out of the habit of relying on assembler optimizations. In the > long run, assembler optimizations are bad, and we need to stop using them as > soon as possible. Gcc should emit .set nomacro/noreorder/noat/etc at the > begining of its assembly output, and never turn them on. While I agree with you in theory, how would GCC handle user-written asm("") blocks without an assemble-time jump relaxation of some sort? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer