Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp929719imm; Tue, 15 May 2018 11:12:45 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqVSXOaHo3Du3BgjWX0BTZEeys4BoSTDvvYg2z3sPhRxxeTKd2Rn8fv05KO4zXzcq+wIWij X-Received: by 2002:a62:2043:: with SMTP id g64-v6mr16276454pfg.12.1526407965760; Tue, 15 May 2018 11:12:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526407965; cv=none; d=google.com; s=arc-20160816; b=dyT4X7PTt26rqDglEf13u+AN1Bn9ophlVfQyNVLG+66Spe+NXCU/xmJFUYL8xYzBNX X4WGau4pLrj3cmDVT5/0ayzMl+SN0oXeB0tGCExyi6Yd+ykGg2M2eJJid31JvndaU1VI ao+0gAB2EPE4xr3PODw52aUBn0Gi43i/qKK+p56FSP44SN9ZVt5qK2Xv7ULpOpY7js8s ffUkMvlMrMqWNDXnHaLfdu21pcKI9VRk/oRImactZzL5afcbHfuBLeLJzibO7/it6AHl QVehHYKgqTh+hoBYqPgK37Gs9rfFWtEqOQvt7Zj46SEzPSdJyOi5qKDYa8loIPypmIsd dKCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=5x6ozvZbUV1Uq/W1L+ybRVKiGbVkUkqo7Hhfo/HZVmo=; b=W/xoKtxYO6p/l3HBNAgIz+GGgXnhxeIKd7aixk/vZIYKGyGU7ZpplzDzwBi6UhvK16 tsZS7enUekZnXnS36W1Zcebni6I4RkS9OpGfAt0dEDrciPqtqtSTC/hUUg5MNuJRs81E yxsBMNXHfH0UpK76fp45aKYdWr20OpAOpujN5F6Na/d715YAPraIsGe5JJz/qcwPs7Bp 2qiP690bGT/afXlrfJbduGLQJJCyrspxh1jfIx54AvMrRrsXcDO0a8hwF/dNIqhlpaBG rFS7BZzKCemjkwj9eoHz455wCDnME5ICKl6IC5UkB+3d4AJ1Qnry3OFSkyjYqJ9nrTuZ d9vw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=bRKjUmTs; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b3-v6si515597pla.505.2018.05.15.11.12.30; Tue, 15 May 2018 11:12:45 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=bRKjUmTs; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752832AbeEOSLv (ORCPT + 99 others); Tue, 15 May 2018 14:11:51 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:36322 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751295AbeEOSLs (ORCPT ); Tue, 15 May 2018 14:11:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=5x6ozvZbUV1Uq/W1L+ybRVKiGbVkUkqo7Hhfo/HZVmo=; b=bRKjUmTsZw5FHZsusi6RY1zyy q+LYs5iMOjLBgPMK+Vw794bRyQHz+ENMMteiIhkf48BDXtAH4FMXGujm4JYRaNn8+ExqL9kj4MSFD YTZqqQpVlMVJVbVOCbCnNDhUH8NYxQ8Y1yjxOgpKOxqP1Y6L0F7e3PeMzy74GrEczZDN1jjwQJtDO Q8+yNro9ht+ZoDyinz/R8sxo3Bgtd49Gkd0C6OJZ1iywguHbABknmXqM6eS0wqIraBe8J6/ENv3Ph nqAg8xEIQ8FH/4q2xJ7SwRMaK7W4DwB45bycyCcP1Sr605RhnZwXG/N+kLgvw1ZX5U74ovGC2qZG0 MpWaGimcQ==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by bombadil.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1fIeQE-00056w-3b; Tue, 15 May 2018 18:11:38 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 719DF2029F86C; Tue, 15 May 2018 20:11:36 +0200 (CEST) Date: Tue, 15 May 2018 20:11:36 +0200 From: Peter Zijlstra To: Mark Rutland Cc: Ingo Molnar , linux-kernel@vger.kernel.org, akpm@linux-foundation.org, will.deacon@arm.com, torvalds@linux-foundation.org, paulmck@linux.vnet.ibm.com, tglx@linutronix.de, hpa@zytor.com, linux-tip-commits@vger.kernel.org Subject: Re: [tip:locking/core] locking/atomics: Simplify the op definitions in atomic.h some more Message-ID: <20180515181136.GR12217@hirez.programming.kicks-ass.net> References: <20180505083635.622xmcvb42dw5xxh@gmail.com> <20180509073327.GE12217@hirez.programming.kicks-ass.net> <20180515083556.GA30420@gmail.com> <20180515114144.GX12217@hirez.programming.kicks-ass.net> <20180515154333.bszh4nuowhocozuc@lakrids.cambridge.arm.com> <20180515171021.GI12217@hirez.programming.kicks-ass.net> <20180515175307.m4xbkbicdrzo4qhb@lakrids.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180515175307.m4xbkbicdrzo4qhb@lakrids.cambridge.arm.com> User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 15, 2018 at 06:53:08PM +0100, Mark Rutland wrote: > On Tue, May 15, 2018 at 07:10:21PM +0200, Peter Zijlstra wrote: > > On Tue, May 15, 2018 at 04:43:33PM +0100, Mark Rutland wrote: > > > I *think* the table can encode enough info to generate atomic-long.h, > > > atomic-instrumented.h, and the atomic.h ordering fallbacks. I'll need to > > > flesh out the table and check that we don't end up clashing with > > > some of the regular fallbacks. > > > > Yes, details details ;-) > > > > > # name meta args... > > > # > > > # Where meta contains a string of: > > > # * B - bool: returns bool, fully ordered > > > # * V - void: returns void, fully ordered > > > > void retuns are relaxed > > How about: > > V - void: returns void, no ordering variants (implicitly relaxed) Works for me. > > > # * I - int: returns base type, all orderings > > > # * R - return: returns base type, all orderings > > > # * F - fetch: returns base type, all orderings > > > # * T - try: returns bool, all orderings > > > > Little more verbose than mine, I think we can get there with X and XB > > instead of I and T, but whatever :-) > > Mhmm. I found it easier to do switch-like things this way, but it works > regardless. I'm a minimalist, but yeah whatever ;-) > > > # Where args contains list of type[:name], where type is: > > > # * v - pointer to atomic base type (atomic or atomic64) > > > # * i - base type (int or long) > > > # * I - pointer to base type (int or long) > > > # > > > add VRF i v > > > sub VRF i v > > > inc VRF v > > > dec VRF v > > > or VF i v > > > and VF i v > > > andnot VF i v > > > xor VF i v > > > xchg I v i > > > cmpxchg I v i:old i:new > > > try_cmpxchg T v I:old i:new > > > add_and_test B i v > > > sub_and_test B i v > > > dec_and_test B v > > > inc_and_test B v we might also want: set V v i set_release V v i read I v read_acquire I v (yes, I did get the set arguments the wrong way around initially)