From patchwork Tue Feb 28 15:16:11 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Oleg Endo X-Patchwork-Id: 143473 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]) by ozlabs.org (Postfix) with SMTP id 6D86FB6FBB for ; Wed, 29 Feb 2012 02:16:47 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1331047009; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=mcFeZopmjzH85mNVyADqZMpLiLI=; b=vmhlHxM/2/vZE2Z 7VrJf1kJJulJnKNkwB8IfG1On4CszhgnwPoN7JxxLZlljsz+AV7hozHCUgTBNIeY iEXcWCgQSzbVjptW3fNta5aVWhllQyx95obRtJEiXWuW/4U8QSOqac6FgKET9z3I 3lhauxCpDn+ll8k+04Kcr0SEfmhw= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=ByKOwbyA5ktbQKP6xvJIuS+oEanm05m9m/o0A+az5KqANzQFkax253S8yAFa1x 2VJGyBHjhMeIg1vt4FjuaCWTbPSblz6GpTsv4N6lG5oHJhQMzoMljbPBsFpeu9f3 zDy29rWnn5G4Dh4oakqNNzce+fhoO3eD9r0xTkqzBvVBc=; Received: (qmail 11233 invoked by alias); 28 Feb 2012 15:16:39 -0000 Received: (qmail 11218 invoked by uid 22791); 28 Feb 2012 15:16:36 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY X-Spam-Check-By: sourceware.org Received: from mailout06.t-online.de (HELO mailout06.t-online.de) (194.25.134.19) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 28 Feb 2012 15:16:22 +0000 Received: from fwd09.aul.t-online.de (fwd09.aul.t-online.de ) by mailout06.t-online.de with smtp id 1S2Omq-0003eI-Fe; Tue, 28 Feb 2012 16:16:20 +0100 Received: from [192.168.0.104] (rxbYQsZbohhFXEn0HrHTJzAAoSImWqh2wJMO158QGAmjb99Y8WoPF7VwhCBfC-PZ3G@[93.218.158.196]) by fwd09.t-online.de with esmtp id 1S2Omm-1aRVY00; Tue, 28 Feb 2012 16:16:16 +0100 Subject: Re: [m68k, sparc] Fix atomic_test_and_set From: Oleg Endo To: Richard Henderson Cc: GCC Patches In-Reply-To: <4F21D3AC.2030500@redhat.com> References: <4F21D3AC.2030500@redhat.com> Date: Tue, 28 Feb 2012 16:16:11 +0100 Message-ID: <1330442171.2929.150.camel@yam-132-YW-E178-FTW> Mime-Version: 1.0 X-IsSubscribed: yes 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 On Fri, 2012-01-27 at 09:29 +1100, Richard Henderson wrote: > Two of the patches have been posted here before; the libstdc++ > patch was approved by Benjamin. > > All of the patches tested on sparc64-linux, and sanity checked > on x86_64-linux. I've cross-compiled for m68k-linux, but I've > only been able to visually sanity check the code in libstdc++. > > Committed. Hopefully that wraps up the atomic patches... > Wouldn't it make sense to use the value behind TARGET_ATOMIC_TEST_AND_SET_TRUEVAL in optabs.c (expand_atomic_test_and_set) instead of const1_rtx when emitting generated atomic_exchange / atomic_compare_and_swap_exchange_loop? Maybe something like the attached patch? Background: I'm working on a patch to add a new option -menable-tas (independent of the existing -msoft-atomic option) which would allow the compiler to generate SH's tas.b insn. This would allow using the tas.b insn without the other atomic sequences, or in combination with them. The reason behind this is that the tas.b insn might not always be appropriate to use, depending on the particular system hardware/software setup (e.g. dual-core SH4A). On SH the TARGET_ATOMIC_TEST_AND_SET_TRUEVAL has to be defined as 0x80. Having the generated atomic_compare_and_swap / atomic_exchange sequences using 0x01 as the 'set' value might lead to inconsistencies when mixing code that uses the tas.b insn and code that doesn't use it, which should actually be OK to do. Cheers, Oleg Index: gcc/optabs.c =================================================================== --- gcc/optabs.c (revision 184589) +++ gcc/optabs.c (working copy) @@ -7384,6 +7384,7 @@ expand_atomic_test_and_set (rtx target, rtx mem, enum memmodel model) { enum machine_mode mode = GET_MODE (mem); + rtx tas_trueval = GEN_INT (targetm.atomic_test_and_set_trueval); rtx ret; ret = maybe_emit_atomic_test_and_set (target, mem, model); @@ -7395,22 +7396,22 @@ /* If there is no test and set, try exchange, then a compare_and_swap loop, then __sync_test_and_set. */ - ret = maybe_emit_atomic_exchange (target, mem, const1_rtx, model); + ret = maybe_emit_atomic_exchange (target, mem, tas_trueval, model); if (ret) return ret; - ret = maybe_emit_compare_and_swap_exchange_loop (target, mem, const1_rtx); + ret = maybe_emit_compare_and_swap_exchange_loop (target, mem, tas_trueval); if (ret) return ret; - ret = maybe_emit_sync_lock_test_and_set (target, mem, const1_rtx, model); + ret = maybe_emit_sync_lock_test_and_set (target, mem, tas_trueval, model); if (ret) return ret; /* Failing all else, assume a single threaded environment and simply perform the operation. */ emit_move_insn (target, mem); - emit_move_insn (mem, const1_rtx); + emit_move_insn (mem, tas_trueval); return target; }