From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27766 invoked by alias); 24 Jul 2019 11:09:09 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 27757 invoked by uid 89); 24 Jul 2019 11:09:09 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 spammy=quality X-HELO: cvs.linux-mips.org Received: from eddie.linux-mips.org (HELO cvs.linux-mips.org) (148.251.95.138) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 24 Jul 2019 11:09:07 +0000 Received: (from localhost user: 'macro', uid#1010) by eddie.linux-mips.org with ESMTP id S23992363AbfGXLJEMSoO3 (ORCPT ); Wed, 24 Jul 2019 13:09:04 +0200 Date: Wed, 24 Jul 2019 11:11:00 -0000 From: "Maciej W. Rozycki" To: Fredrik Noring cc: Paul Burton , Matthew Fortune , =?UTF-8?Q?J=C3=BCrgen_Urban?= , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] MIPS: Fix GCC `noreorder' for undefined R5900 short loops In-Reply-To: <20190723165446.GA2728@sx9> Message-ID: References: <20190721171726.GA47580@sx9> <20190722155506.GA2726@sx9> <20190723165446.GA2728@sx9> User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg01563.txt.bz2 Fredrik, > > > How can one reasonably prevent the bug when compiling a whole Linux > > > distribution with thousands of packages if GAS merely warns and proceeds > > > in many cases? > > > > I think the tools must not set a policy. By using `.set noreorder' the > > user told the toolchain he knows better and asked to keep its hands away. > > > > As I say you can use `-Werror' for code auditing. And in most cases > > manually scheduled delay slots in handcoded assembly are a sign of a > > problem with the piece of code affected, regardless of the R5900 erratum. > > Well, it seems practical to use unofficial tools and a patched GAS to fix > this assembly bug, then. It's a grave problem for the R5900 and it needs to > be reliably detected. Why? What is wrong with using `-Werror'? Or you could use `-Wa,-fatal-warnings' to limit making warnings fatal to the assembly stage only if you are concerned about bad high-level language code quality interfering with your goal. > > See `nops_for_insn'. However again, as I noted, `.set noreorder' tells > > GAS not to analyse the dependencies for code within. There is no need to > > schedule this delay slot manually, and if this is generated code, then the > > producer (GCC) should have taken care of the hazards, be it architectural > > or errata. If this is manually written code, then the author asked for > > trouble. > > I'm using the principle above to unobtrusively adjust problematic kernel > code, via a short_loop_war macro. Here is one patched instance: > > --- a/arch/mips/boot/compressed/head.S > +++ b/arch/mips/boot/compressed/head.S > @@ -13,6 +13,7 @@ > */ > > #include > +#include > #include > > .set noreorder > @@ -29,6 +30,7 @@ start: > PTR_LA a0, _edata > PTR_LA a2, _end > 1: sw zero, 0(a0) > + short_loop_war(1b) > bne a2, a0, 1b > addiu a0, a0, 4 > > @@ -48,6 +50,7 @@ start: > jr k0 > nop > 3: > + short_loop_war(3b) > b 3b > nop Is it needed here given that the delay slot instruction is a NOP anyway? Also this source does not need `.set noreorder', except for the loop around `1:' where a data dependency is present with the delay slot instruction. And I am surprised that it even assembles as it uses `.cprestore' without the required offset argument (not that this pseudo-op makes any sense here). And it's weird overall, e.g. it loads $ra explicitly rather than using JALR (or JAL even). But these are unrelated problems. > > Well, BogoMIPS is just an arbitrary number. > > So presumably the noreorder BogoMIPS variant can be replaced with a > single reorder variant that works with all MIPS implementations? Sure, BogoMIPS just records how quickly the delay loop runs, and therefore how many iterations are required for a given amount of time to spend twiddling thumbs. Maciej