From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31950 invoked by alias); 7 Nov 2014 09:31:42 -0000 Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org Received: (qmail 31925 invoked by uid 89); 7 Nov 2014 09:31:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 07 Nov 2014 09:31:39 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA79VbVD022694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 7 Nov 2014 04:31:38 -0500 Received: from zebedee.pink (ovpn-113-89.phx2.redhat.com [10.3.113.89]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sA79VZTh030733; Fri, 7 Nov 2014 04:31:35 -0500 Message-ID: <545C9176.6000006@redhat.com> Date: Fri, 07 Nov 2014 09:31:00 -0000 From: Andrew Haley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Andrew MacLeod , Richard Biener , Richard Henderson , gcc-patches CC: Jeff Law , java@gcc.gnu.org Subject: Re: [patch] Provide a can_compare_and_swap_p target hook. References: <5458FE9C.2090409@redhat.com> <54590C19.40208@redhat.com> <54591348.1010904@redhat.com> <545913A4.5010400@redhat.com> <54591B3A.8030908@redhat.com> <70044BE8-9F38-4BDB-B73F-6E2FC9AC2629@gmail.com> <54593352.2000700@redhat.com> <545BB682.9000209@redhat.com> <545BBCA5.7060203@redhat.com> <545BC666.5020007@redhat.com> In-Reply-To: <545BC666.5020007@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2014-11/txt/msg00003.txt.bz2 On 06/11/14 19:05, Andrew MacLeod wrote: > > > 1) Given that the compiler *always* provides support via libatomic now > (even if it is via locks), does that mean that VMSupportsCS8_builtin() > should always return true? > > or should we map to that a call to __atomic_always_lock_free() ? (that > always gets folded to a true or false at compile time) my guess is the > latter? Perhaps so. The problem is that some targets can't do CAS on 64-bit doublewords. > 2) and in compareAndSwapLong_builtin(), thre is a wonky bit: > > /* We don't trust flag_use_atomic_builtins for multi-word compareAndSwap. > Some machines such as ARM have atomic libfuncs but not the multi-word > versions. */ > if (can_compare_and_swap_p (mode, > (flag_use_atomic_builtins > && GET_MODE_SIZE (mode) <= UNITS_PER_WORD))) > <..> /* generate 8 byte CAS */ > > I gather we dont need to do anything special here anymore either? As > an observation of inconsistency, > compareAndSwapObject_builtin doesn't do that check before calling the 8 > byte CAS : I believe that any machine which has 64-bit pointers and can do CAS can do a 64-bit CAS. I'm worried about 32-bit machines trying to do a 64-bit CAS. > 3) And finally, is flag_use_atomic_builtins suppose to turn them off > completely? Right now it is passed in to the second parameter of > can_compare_and_swap_p, which really just says can we compare and swap > without calling a libfunc.. so currently if the flag is 0, but there > is native support, the call is generated anyway. should that condition > really be: > > if (flag_use_atomic_builtins) > { > <...> /* generate atomic call */ > } I'm sorry, I really can't remember. I can't think of any reason to want to turn off builtin support. You have to remember that all this was written when our support for atomic builtins was seriously flaky and we would just punt back to the user anything we hadn't written yet. Andrew.