From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6DB58ECF for ; Sun, 9 Mar 2025 10:23:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741515798; cv=none; b=AIjPfQHSM2GtxICrgminPTxD0SNLAYVAdA+Zv1GuZvxIryjE/5tE2fDU+q3PoUuSHflFCdZ+pclbjUthEwm0Ud+za6UrtZoi5yMCir+NVPTSWM9dpyp4eOMzOa3uACEW4gO2iIa1DIGmsmtK8+bGJBBtOkeeYQcfz8b7lrerqxs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741515798; c=relaxed/simple; bh=iPcGYSG8X5xwOD70QJav+rFZeT8t7y6pb+RIl+F6H+k=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=XULFYFjI28yUClNZrczAUzyCJqOcS76rSyYmYHQVA60TeO1gzdKyxyKWbgFzMFDdUhd0/maUxgyf/Az7Ntji9soMzJF4RML2MJI3G7odwbQNPFVqfvf03/fYturnCRSGXNXjG1xLCoN3iOOcx2L8IOmVo84NcEzeVYP8eKEZA8E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=BxRBlECN; arc=none smtp.client-ip=209.85.128.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BxRBlECN" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-43cf680d351so528685e9.0 for ; Sun, 09 Mar 2025 03:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741515795; x=1742120595; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=jOrSY62ly9MyAZzU/mRzG/6yK32MDIUREu5DDgJTTrs=; b=BxRBlECNyHYRq8pJHkad2PCLrI1ffl6cexKKk+fLrbatquNIw8vP7HSB32rQbl5PtH +U6pWlE3jScayGYUeBAY0QjRLc8bdc0VDc8Nt7A8TNOJyJB1Rq97FktsesYZvDT13z06 RO8Eu9X4YUVngR1ykouZFDZul2gMJjLGJ538SSDtDMbaVQIUfsuCvrI8hs3I0By1gYaK KRDMrj8H2opQPz/k82+B9M+Vo3nPyD4L6vx+zqt18uCt/2Yo/Elwszpcj/oa8fMe1S26 lI+ssAyuchh1ZYxiOgLrKTWFvoFcPQme+igvjBxWTMBMHrHjqTaXexo4Ss1NczVQa3gZ wT1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741515795; x=1742120595; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jOrSY62ly9MyAZzU/mRzG/6yK32MDIUREu5DDgJTTrs=; b=W//0JSpj7nlKId74qXCaUdHFv2f/QLNgbkncQBFy0yiSVvux5FtKdW2i1iKoQY7/35 iHkAQbu+FdfpTOx/JE+iUdod8kxBjMeTEeGJdhISs4C13taQS9RtmliuOUhvLsKaCauU 5HnOBw/BP8TncMWBm01dl10xWEBFaefyBAw77tXuKjAS8F9zHKDk5aofAenQVVM7343k DQfZWXgJYhkz8bZ7qkLIzCZHQGDkSeFdctJNLV80ZQR79tFYRrpqt2aQNtjm7+cw7ItC ZS0y2OrRZxcvQkWUPO9vwoUewzreS5DuICOct+bWrIk/CPYT6b2JZHBf0o+mxIelUtme 2oTg== X-Forwarded-Encrypted: i=1; AJvYcCXkmMmWMAd2p2s3D6hX0TnPIXFIEnbL06cfGr/9eiVMoG2p+9UVdboMECXXREdEAi9JDu3irogXT7VVWe8=@vger.kernel.org X-Gm-Message-State: AOJu0YzIijHiUtbjtuaPiCO8E6kRoxQ1WXiY7UQ7NtkwHvdtW9KrwmyC yvGlftQNi0vlWW1bWfOXMq/IFzmrX4kloDj2eJchGgf9G9tnFCC6 X-Gm-Gg: ASbGncs1m1wBjiwC4sN8zk6T9XqKBaxZUngyyal27gL5YcRch4qo5YQn8l/ahI+QgfJ PjhKKVR9+lmDdhM7MVbcDMAlmWAkB3DtQ2PJWQwlYrKY4Ep9Tk9+3QGMsGILu8F8iHJoEoNaDLh b5aZC1YEJeA79Wg7P8yVfq+mhcMp9yXBLGInhdsTYsoX2ccYEEdrgFij5ipwEwIxFU3a5dMKHN6 Ai/dqw5GocCZTZKumUjTM3yknGk2w8CZyWP2BvpeIF/CMayiO0r9PcAz02EWSUeEmC0RhzuuehD apK0TCcIusVWhHUDnFo7yVdciNu8Zy5qq5hruPUhOh75xcuww1Mz4BQrsnlOexuwAMypGI4+Gy6 Ed7q02Ek= X-Google-Smtp-Source: AGHT+IHbscHwInTJT24NNcdcbyXR3Qc8dNdzXdp1UDpEDUqPcYTQseTkyV6/M+R7pmGC6z1uWCUoyw== X-Received: by 2002:a05:600c:754:b0:43b:bfa7:c7d with SMTP id 5b1f17b1804b1-43ce4aa8771mr34972875e9.2.1741515794376; Sun, 09 Mar 2025 03:23:14 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43cf0c42eb6sm21134605e9.16.2025.03.09.03.23.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Mar 2025 03:23:13 -0700 (PDT) Date: Sun, 9 Mar 2025 10:23:12 +0000 From: David Laight To: Vincent Mailhol Cc: Yury Norov , Lucas De Marchi , Rasmus Villemoes , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Andrew Morton , linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, Andi Shyti , David Laight , Dmitry Baryshkov , Andy Shevchenko Subject: Re: [PATCH v5 1/7] bits: split the definition of the asm and non-asm GENMASK() Message-ID: <20250309102312.4ff08576@pumpkin> In-Reply-To: <20250309015853.01412484@pumpkin> References: <20250306-fixed-type-genmasks-v5-0-b443e9dcba63@wanadoo.fr> <20250306-fixed-type-genmasks-v5-1-b443e9dcba63@wanadoo.fr> <20250306192331.2701a029@pumpkin> <20250309015853.01412484@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 9 Mar 2025 01:58:53 +0000 David Laight wrote: > On Fri, 7 Mar 2025 18:58:08 +0900 > Vincent Mailhol wrote: > > > On 07/03/2025 at 04:23, David Laight wrote: > > > On Thu, 06 Mar 2025 20:29:52 +0900 > > > Vincent Mailhol via B4 Relay wrote: > > > > > >> From: Vincent Mailhol > > >> > > >> In an upcoming change, GENMASK() and its friends will indirectly > > >> depend on sizeof() which is not available in asm. > > >> > > >> Instead of adding further complexity to __GENMASK() to make it work > > >> for both asm and non asm, just split the definition of the two > > >> variants. > > > ... > > >> +#else /* defined(__ASSEMBLY__) */ > > >> + > > >> +#define GENMASK(h, l) __GENMASK(h, l) > > >> +#define GENMASK_ULL(h, l) __GENMASK_ULL(h, l) > > > > > > What do those actually expand to now? > > > As I've said a few times both UL(0) and ULL(0) are just (0) for __ASSEMBLY__ > > > so the expansions of __GENMASK() and __GENMASK_ULL() contained the > > > same numeric constants. > > > > Indeed, in asm, the UL(0) and ULL(0) expands to the same thing: 0. > > > > But the two macros still expand to something different on 32 bits > > architectures: > > > > * __GENMASK: > > > > (((~(0)) << (l)) & (~(0) >> (32 - 1 - (h)))) > > > > * __GENMASK_ULL: > > > > (((~(0)) << (l)) & (~(0) >> (64 - 1 - (h)))) > > > > On 64 bits architecture these are the same. > > I've just fed those into godbolt (https://www.godbolt.org/z/Ter6WE9qE) as: > int fi(void) > { > int v; > asm("mov $(((~(0)) << (8)) & (~(0) >> (32 - 1 - (15)))),%0": "=r" (v)); > return v -(((~(0u)) << (8)) & (~(0u) >> (32 - 1 - (15)))); > } > > gas warns: > :4: Warning: 0xffffffffff00 shortened to 0xffffff00 > > unsigned long long fll(void) > { > unsigned long long v; > asm("mov $(((~(0)) << (8)) & (~(0) >> (64 - 1 - (15)))),%0": "=r" (v)); > return v -(((~(0ull)) << (8)) & (~(0ull) >> (64 - 1 - (15)))); > } > > (for other architectures you'll need to change the opcode) > > For x86 and x86-32 the assembler seems to be doing 64bit maths with unsigned > right shifts - so the second function (with the 64 in it) generates 0xff00. > I doubt a 32bit only assembler does 64bit maths, but the '>> 48' above > might get masked to a '>> 16' by the cpu and generate the correct result. > > So __GENMASK() is likely to be broken for any assembler that supports 64bits > when generating 32bit code. > __GENMASK_ULL() works (assuming all have unsigned >>) on 64bit assemblers > (even when generating 32bit code). It may work on some 32bit assemblers. I've remembered my 'pi' has a 32bit userspace (on a 64bit kernel). I quick test of "mov %0,#(...)" and bits 11..8 gives the correct output for size '32' but the error message: /tmp/ccPB7bWh.s:26: Warning: shift count out of range (56 is not between 0 and 31) with size '64'. Assuming that part of the gnu assembler is consistent across architectures you can't use either GENMASK in asm for 32bit architectures. Any change (probably including removing the asm support for the uapi) isn't going to make things worse! David > > Since most uses in the header files will be GENMASK() I doubt (hope) no > asm code actually uses the values! > The headers assemble - but that is about all that can be said. > > Bags of worms :-) > > David >