From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11983 invoked by alias); 12 Nov 2007 19:39:10 -0000 Received: (qmail 11974 invoked by uid 22791); 12 Nov 2007 19:39:09 -0000 X-Spam-Check-By: sourceware.org Received: from smtp.nildram.co.uk (HELO smtp.nildram.co.uk) (195.112.4.54) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 12 Nov 2007 19:39:07 +0000 Received: from firetop.home (84-12-20-70.dyn.gotadsl.co.uk [84.12.20.70]) by smtp.nildram.co.uk (Postfix) with ESMTP id 101222B6D53; Mon, 12 Nov 2007 19:39:00 +0000 (GMT) Received: from richard by firetop.home with local (Exim 4.63) (envelope-from ) id 1Irf7R-0006pC-O7; Mon, 12 Nov 2007 19:38:53 +0000 From: Richard Sandiford To: "Maciej W. Rozycki" Mail-Followup-To: "Maciej W. Rozycki" ,Paul Koning , iant@google.com, binutils@sources.redhat.com, macro@linux-mips.org, rsandifo@nildram.co.uk Cc: Paul Koning , iant@google.com, binutils@sources.redhat.com, macro@linux-mips.org Subject: Re: [RFD] MIPS/gas: Optimisation cannot be set to 0 References: <18228.40767.174954.650280@pkoning-laptop.equallogic.com> <873avdxbxw.fsf@firetop.home> Date: Mon, 12 Nov 2007 19:39:00 -0000 In-Reply-To: (Maciej W. Rozycki's message of "Mon\, 12 Nov 2007 18\:06\:48 +0000 \(GMT\)") Message-ID: <87hcjrw8xi.fsf@firetop.home> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2007-11/txt/msg00126.txt.bz2 "Maciej W. Rozycki" writes: > On Sun, 11 Nov 2007, Richard Sandiford wrote: >> Right. There's not really any point doing it for MIPS16 code. The only >> kind of reordering you get is when GAS fills a delay slot that GCC didn't >> know how to fill, so ".set noreorder" would mean "don't make this >> function as small as you can". That'd be a bit perverse on a target >> where size is really the only thing that matters. (In contrast, >> GCC might have had good reasons to do what it did for non-MIPS16 code, >> especially on targets like the VR413x.) > > Obviously ".set noreorder" would make sense here only if GCC had > scheduled the delay slot itself already. My point was that on targets with alignment-sensitive pipelines like the VR413x's, GCC effectively schedules _all_ delay slots, even if it leaves some unfilled which GAS thinks could be filled. So it makes sense for the whole function to be ".set noreorder" in that case. In contrast, MIPS16 code is only ".set noreorder" in cases where GCC has managed to do something useful with a delay slot. Richard