From patchwork Wed Aug 19 07:45:35 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Simon Kagstrom X-Patchwork-Id: 31635 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bilbo.ozlabs.org (Postfix) with ESMTPS id 9A015B708B for ; Wed, 19 Aug 2009 17:48:32 +1000 (EST) Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.69 #1 (Red Hat Linux)) id 1Mdfrl-0000Gj-VE; Wed, 19 Aug 2009 07:45:54 +0000 Received: from ernst.netinsight.se ([194.16.221.21]) by bombadil.infradead.org with smtp (Exim 4.69 #1 (Red Hat Linux)) id 1Mdfrf-0000Et-KC for linux-mtd@lists.infradead.org; Wed, 19 Aug 2009 07:45:51 +0000 Received: from marrow.netinsight.se (unverified [10.100.3.78]) by ernst.netinsight.se (EMWAC SMTPRS 0.83) with SMTP id ; Wed, 19 Aug 2009 09:45:34 +0200 Date: Wed, 19 Aug 2009 09:45:35 +0200 From: Simon Kagstrom To: Nicolas Pitre Subject: Re: [PATCH] Orion NAND: Make dword load asm volatile to avoid GCC optimizing it away Message-ID: <20090819094535.558dc0df@marrow.netinsight.se> In-Reply-To: References: <20090714164135.65e91b91@marrow.netinsight.se> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.1; i486-pc-linux-gnu) Mime-Version: 1.0 X-Spam-Score: 0.0 (/) Cc: linux-mtd@lists.infradead.org X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org On Tue, 14 Jul 2009 12:40:33 -0400 (EDT) Nicolas Pitre wrote: > On Tue, 14 Jul 2009, Simon Kagstrom wrote: > > > GCC 4.3.3 happily removes the dword load instruction in > > orion_nand_read_buf. This patch makes the inline assembly volatile to > > avoid this situation. > > If GCC does optimize away this inline asm then this is a serious GCC > bug. The inline asm uses an output operand for which a dependency > exists on the very next line. I've been away on vacation, sorry for not replying until now. Anyway, I spoke to the GCC people at gcc-help, and they insist that the inlined assembly is wrong. The problem is that GCC doesn't infer from the instruction that it accesses memory, and it can thereby move it out of the loop. So here comes an updated patch. // Simon --- Orion NAND: Clobber memory to make sure that GCC does not move ldrd GCC 4.3.3 happily removes the dword load instruction in orion_nand_read_buf. This patch clobbers memory, and makes the instruction volatile to avoid the issue. I've discussed this at gcc-help, refer to the thread at http://gcc.gnu.org/ml/gcc-help/2009-08/msg00187.html Signed-off-by: Simon Kagstrom --- drivers/mtd/nand/orion_nand.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/nand/orion_nand.c b/drivers/mtd/nand/orion_nand.c index 7ad9722..845f9a9 100644 --- a/drivers/mtd/nand/orion_nand.c +++ b/drivers/mtd/nand/orion_nand.c @@ -61,7 +61,7 @@ static void orion_nand_read_buf(struct mtd_info *mtd, uint8_t *buf, int len) buf64 = (uint64_t *)buf; while (i < len/8) { uint64_t x; - asm ("ldrd\t%0, [%1]" : "=r" (x) : "r" (io_base)); + asm volatile ("ldrd\t%0, [%1]" : "=&r" (x) : "r" (io_base) : "memory"); buf64[i++] = x; } i *= 8;