From patchwork Tue Nov 18 13:37:13 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Bennett X-Patchwork-Id: 412041 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 23250140174 for ; Wed, 19 Nov 2014 00:37:26 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:content-type :content-transfer-encoding:mime-version; q=dns; s=default; b=Cfj Yxf+bQIiaDWznnaDu1wAgaaD5VrZ491uSrXMVqZaNH2zrXuZIEW4oX6K12JaJhen txwSZMr13z6T1tnKGhEGRDL0tjMiKxCYOOivR/QECMZgCg8GTn+QSYyXUu0QIC2W BpE0kpIdRiBednA79DYwh23TI+XrWD7EpqpaKUio= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:content-type :content-transfer-encoding:mime-version; s=default; bh=zZ2KZzbtK QKmTavmcufYjU4aUXc=; b=QhRM/WyR/yWvL+hmIrgCEvSFKnFJXVFll/VfywPBl 2YxQhVpQjou7h8Uj5/R/52umevbJ2AHVrLf16s5h8nhKYFt6eazft73Y5vRL5sA7 JoRFQcG29a44S1j9B4d667kcQfSN0GsllNeHDtKgF1h+7CKr5ArRjVxnes+DUiYz Rc= Received: (qmail 25617 invoked by alias); 18 Nov 2014 13:37:19 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 25605 invoked by uid 89); 18 Nov 2014 13:37:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL, BAYES_00, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 18 Nov 2014 13:37:18 +0000 Received: from KLMAIL01.kl.imgtec.org (unknown [192.168.5.35]) by Websense Email Security Gateway with ESMTPS id F29B1F92361D7 for ; Tue, 18 Nov 2014 13:37:12 +0000 (GMT) Received: from KLMAIL02.kl.imgtec.org (10.40.60.222) by KLMAIL01.kl.imgtec.org (192.168.5.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 18 Nov 2014 13:37:15 +0000 Received: from LEMAIL01.le.imgtec.org (192.168.152.62) by klmail02.kl.imgtec.org (10.40.60.222) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 18 Nov 2014 13:37:15 +0000 Received: from LEMAIL01.le.imgtec.org ([fe80::5ae:ee16:f4b9:cda9]) by LEMAIL01.le.imgtec.org ([fe80::5ae:ee16:f4b9:cda9%17]) with mapi id 14.03.0210.002; Tue, 18 Nov 2014 13:37:14 +0000 From: Andrew Bennett To: "gcc-patches@gcc.gnu.org" Subject: [PATCH] If using branch likelies in MIPS sync code fill the delay slot with a nop Date: Tue, 18 Nov 2014 13:37:13 +0000 Message-ID: <0DA23CC379F5F945ACB41CF394B9827720F331A8@LEMAIL01.le.imgtec.org> MIME-Version: 1.0 X-IsSubscribed: yes Hi, The atomic-compare-exchange-3.c and atomic-op-3.c tests are failing when using the -mfix-r10000 option. This is due to the fact that the delay slot of the branch instruction that checks if the atomic operation was not successful can be filled with an operation that returns the output result. For the branch likely case this operation can not go in the delay slot because it wont execute when the atomic operation was successful and therefore the wrong result will be returned. This patch forces a nop to be placed in the delay slot if a branch likely is used. The fix is as simple as possible; it does cause a second nop to be introduced after the branch instruction in the branch likely case. As this option is rarely used, it makes more sense to keep the code readable than trying to optimise it. The atomic tests now pass successfully. The ChangeLog and patch are below. Ok to commit? Many thanks, Andrew gcc/ * config/mips/mips.c (mips_process_sync_loop): Place a nop in the delay slot of the branch likely instruction. diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c index 02268f3..6dd3728 100644 --- a/gcc/config/mips/mips.c +++ b/gcc/config/mips/mips.c @@ -12997,7 +12997,12 @@ mips_process_sync_loop (rtx_insn *insn, rtx *operands) This will sometimes be a delayed branch; see the write code below for details. */ mips_multi_add_insn (is_64bit_p ? "scd\t%0,%1" : "sc\t%0,%1", at, mem, NULL); - mips_multi_add_insn ("beq%?\t%0,%.,1b", at, NULL); + + /* We can not put the NEWVAL = $TMP3 or CMP = 1 operations in the delay slot + of the branch if it is a branch likely because they will not execute when + the atomic operation is successful, so place a NOP in there instead. */ + + mips_multi_add_insn ("beq%?\t%0,%.,1b%~", at, NULL); /* if (INSN1 != MOVE && INSN1 != LI) NEWVAL = $TMP3 [delay slot]. */ if (insn1 != SYNC_INSN1_MOVE && insn1 != SYNC_INSN1_LI && tmp3 != newval)