From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25972 invoked by alias); 2 Jun 2011 19:25:52 -0000 Received: (qmail 25926 invoked by uid 22791); 2 Jun 2011 19:25:51 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 02 Jun 2011 19:25:23 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p52JPGa2012980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Jun 2011 15:25:16 -0400 Received: from tyan-ft48-01.lab.bos.redhat.com (tyan-ft48-01.lab.bos.redhat.com [10.16.42.4]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p52JPFss032631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jun 2011 15:25:16 -0400 Received: from tyan-ft48-01.lab.bos.redhat.com (localhost.localdomain [127.0.0.1]) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4) with ESMTP id p52JPFBM029313; Thu, 2 Jun 2011 21:25:15 +0200 Received: (from jakub@localhost) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4/Submit) id p52JPEqm029312; Thu, 2 Jun 2011 21:25:14 +0200 Date: Thu, 02 Jun 2011 19:25:00 -0000 From: Jakub Jelinek To: Aldy Hernandez Cc: Andrew MacLeod , "Joseph S. Myers" , Richard Henderson , gcc-patches Subject: Re: __sync_swap* with acq/rel/full memory barrier semantics Message-ID: <20110602192514.GA17079@tyan-ft48-01.lab.bos.redhat.com> Reply-To: Jakub Jelinek References: <4DDAE516.4010307@redhat.com> <4DE3F8ED.6020109@redhat.com> <4DE7E0A6.9070400@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DE7E0A6.9070400@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes 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 X-SW-Source: 2011-06/txt/msg00185.txt.bz2 On Thu, Jun 02, 2011 at 02:12:38PM -0500, Aldy Hernandez wrote: > +/* This function expands a fine grained atomic exchange operation: > + atomically store VAL in MEM and return the previous value in MEM. > + > + MEMMODEL is the memory model variant to use. > + TARGET is an option place to stick the return value. */ > + > +rtx > +expand_sync_mem_exchange (enum memmodel model, rtx mem, rtx val, rtx target) > +{ > + enum machine_mode mode = GET_MODE (mem); > + enum insn_code icode; > + direct_optab op; > + > + switch (model) > + { > + case MEMMODEL_RELAXED: > + /* ?? Eventually we should either just emit the atomic > + instruction without any barriers (and thus allow movements > + and transformations), or emit a relaxed builtin. > + > + It is still not clear whether any transformations are > + permissible on the atomics (for example, CSE might break > + coherence), so we might need to emit a relaxed builtin. > + > + Until we figure this out, be conservative and fall > + through. */ > + case MEMMODEL_SEQ_CST: > + op = sync_mem_exchange_seq_cst_optab; > + break; > + case MEMMODEL_ACQUIRE: > + op = sync_mem_exchange_acq_optab; > + break; > + case MEMMODEL_RELEASE: > + op = sync_mem_exchange_rel_optab; > + break; > + case MEMMODEL_ACQ_REL: > + op = sync_mem_exchange_acq_rel_optab; > + break; Wouldn't it be better to pass the model (as an extra CONST_INT operand) to the expanders? Targets where atomic instructions always act as full barriers could just ignore that argument, other could decide what to do based on the value. Jakub