From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20006 invoked by alias); 30 Jul 2013 12:26:13 -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 19997 invoked by uid 89); 30 Jul 2013 12:26:13 -0000 X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=AWL,BAYES_50,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RDNS_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.1 Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 30 Jul 2013 12:26:12 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r6UCQ2A3009420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Jul 2013 08:26:03 -0400 Received: from [10.10.61.190] (vpn-61-190.rdu2.redhat.com [10.10.61.190]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r6UCQ1Xs029370; Tue, 30 Jul 2013 08:26:01 -0400 Message-ID: <51F7B0D8.8040509@redhat.com> Date: Tue, 30 Jul 2013 12:38:00 -0000 From: Andrew MacLeod User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Joseph S. Myers" CC: gcc-patches , hp@bitrange.com, Richard Henderson Subject: Re: [PATCH] Add atomic type qualifier References: <51F2AEB1.60408@redhat.com> <51F6836F.6080400@redhat.com> <51F6F4EE.20902@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-07/txt/msg01458.txt.bz2 On 07/30/2013 07:41 AM, Joseph S. Myers wrote: > On Mon, 29 Jul 2013, Andrew MacLeod wrote: > >> Ive been poking at this today, and Im wondering what you think of the idea of >> adding a flag to MODIFY_EXPR, >> #define MODIFY_EXPR_IS_COMPOUND(NODE) >> MODIFY_EXPR_CHECK(NODE)->base.asm_written_flag >> >> and set that in the MODIFY_EXPR node when we create it from the "x op= y" form >> in the front end. That flag seems to be free for expressions. > My suggestion is that the IR generated by the front end should make it > completely explicit what may need retrying with a compare-and-exchange, > rather than relying on non-obvious details to reconstruct the semantics > required at gimplification time - there are too many transformations > (folding etc.) that may happen on existing trees and no clear way to be > confident that you can still identify all the operands accurately after > such transformations. That is, an ATOMIC_COMPOUND_MODIFY_EXPR or similar, > whose operands are: the LHS of the assignment; a temporary variable, "old" > in C11 footnote 113; the RHS; and the "old op val" expression complete > with the conversion to the type of the LHS. Gimplification would then > (carry out the effects of stabilize_reference on the LHS and save_expr on > the RHS and) do "old = LHS;" followed by the do-while compare-exchange > loop. In fact, after thinking about it overnight, I came to similar conclusions... I believe it requires new builtin(s) for these operations. Something like __atomic_compound_assign (&atomic_expr, enum atomic_operation_type, blah, blah,...) A call to this builtin would be generated right from the parser when it sees the op= expression, and the built-in can then travel throughout gimple as a normal atomic built-in operation like the rest. During expansion to RTL it can be turned into whatever sequence we happen to need. This is what happens currently with the various __atomic_fetch_op and __atomic_op_fetch. In fact, they are a subset of required operations, so I should be able to combine the implementation of those with this new one. Is C++ planning to match these behaviours in the atomic library? It would need to access this builtin as well so that the C++ template code can invoke it. > A flag on the expression could indicate that the floating-point semantics > are required. I'd guess back ends would need to provide three insn > patterns, corresponding to feholdexcept, feclearexcept and feupdateenv, > that there'd be corresponding built-in functions for these used at > gimplification time, and that a target hook would give the type used for > fenv_t by these built-in functions (*not* necessarily the same as the > fenv_t used by any implementation of the functions in libm). The target > should also be able to declare that there's no support for floating-point > exceptions (e.g. for soft-float) and so floating-point cases don't need > any special handling. > I think the fact that it requires floating point sematics should be determinable from the types of the expressions involved. If there is a floating point somewhere, then we'll need to utilize the patterns. we'll still have the types, although it would certainly be easy enough to add a flag to the builtin... and maybe thats the way to go after all. THis also means that for the 3 floating point operations all we need are RTL insn patterns, no buitin. And as with the other atomics, if the pattern doesnt exist, we just wont emit it. we could add a warning easily enough in this case. I think we're somewhere good now :-) I guess I'll do the same thing for normal references to an atomic variable... issue the atomic load or atomic store directly from the parser... Andrew