Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp1180157rwi; Thu, 27 Oct 2022 12:16:15 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7COzr1SvhfaGs8LH7IzL9EPNNvqYUcYVlbR2fEnS9GBz72jhFlmRtfKRdwNd80ddFJnNDg X-Received: by 2002:a17:906:8a65:b0:7ad:88f8:7ecc with SMTP id hy5-20020a1709068a6500b007ad88f87eccmr5376269ejc.535.1666898175217; Thu, 27 Oct 2022 12:16:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666898175; cv=none; d=google.com; s=arc-20160816; b=z+X5iWG8K4fwy3KghsCIW6z1rLoOpd5n9ApHtOEZ3fK5QL2sOAeSXxm0qgpjmLVgVl QNPtwDdSeEmUHaRuEdFBos9M/c0B1IwGlmBmPOgt5YVjSE9B0TxuE5ZT8PpGp2GUp9AJ okL0m7LgMYeWqE1cjyQdJHs7VIMT3GL9t0anJXRgUsTd0UL2rYExqHWziXmMmhAWiYnJ rDhU333cu0ViCEOguxAxrlitsIyJVAEsppZ1pApS4q0sgjFRuyGKapoJ+T+EgiWdvdyq 4U8U4t1r4Hqv0LuOJgOFgcJsTMXKxWj/Pm7MSp2Ik3gKWM1+9l3p6H1XfcCzo5YVw5cb DlTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:in-reply-to :subject:cc:to:from:message-id:date:dkim-signature; bh=+xfnxhk+tEq/SCRP/9pblAOGMvmrOJii9Kom3L9Bjtc=; b=QlI95YZsEqkAZkWbJnfAq0194m2S35jDNGVs3Wg49YntKGYRaJJ611sbCMCEBvOs6g vM9mkPGYpt1+MqdK8dkjURERWxxR+rAoRtvZW0ZR+lEFZ+KZecCinG5sSN2ZrskVUxrm Pry+wPIc/uZDme3RLt/1OvXP/g9FFTSwkJH8q64XKHzvL0GO5TxNiJ98p0J32IPc4ZDA M+yQ3s9OZPzD4TF/cmLQOKviJq1qHC6R+NBXcRwzIjhx4nmLVz5uwUy/pNEeK3fMUi7s RMX4tLnHkuUmy3MfGI46HQX4UCZyjJK0qqkZHx2vIzhAAoxVaA++L4u4yWpx5WMZBn6h Tu1A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="S/Dk/lAB"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id jo1-20020a170906f6c100b007829f6fed9dsi1067660ejb.232.2022.10.27.12.15.49; Thu, 27 Oct 2022 12:16:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="S/Dk/lAB"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235273AbiJ0SdG (ORCPT + 99 others); Thu, 27 Oct 2022 14:33:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59394 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234493AbiJ0SdE (ORCPT ); Thu, 27 Oct 2022 14:33:04 -0400 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D3BDB900CF for ; Thu, 27 Oct 2022 11:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1666895583; x=1698431583; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=bmQm0hnsktZC10zjzfxP6GEGbTeq9P7+PpzgV6BS8Nk=; b=S/Dk/lABFRFIxKqlRasppRKBqmi0FlsqZYfL1yqyL11MxhZgTDn69CMS SRqx67YJyvjgDBM9wvGNX04FoXI+uUuL8bbzv4brAWlN1Kg5P9nZsiRJk yPz0bYQX/CfiSanOSz8toCgljMhRjHxX3W+YVYq2WBhVmfTnGwcjeOPbu ZHhLNqEe2TDJx+2oIM2b8vqrzIA4ARbryFMJ0hUVCt2xoDibVccaZX2vd G76OP71aQVaozN7HcrjMCBU76mLiLxJ0whP0257enmrNxqGUnabNVAl9g rl0PU4K5REwDD6sAcylwODYDsQj709jd1eGaiL2om4zCcRyKcICB2Z4no A==; X-IronPort-AV: E=McAfee;i="6500,9779,10513"; a="309397291" X-IronPort-AV: E=Sophos;i="5.95,218,1661842800"; d="scan'208";a="309397291" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Oct 2022 11:32:55 -0700 X-IronPort-AV: E=McAfee;i="6500,9779,10513"; a="610468871" X-IronPort-AV: E=Sophos;i="5.95,218,1661842800"; d="scan'208";a="610468871" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.209.68.192]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Oct 2022 11:32:54 -0700 Date: Thu, 27 Oct 2022 11:32:54 -0700 Message-ID: <875yg5xgkp.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Nick Desaulniers Cc: Gwan-gyeong Mun , anshuman.gupta@intel.com, intel-gfx@lists.freedesktop.org, llvm@lists.linux.dev, linux-kernel@vger.kernel.org, Andi Shyti Subject: Re: [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler In-Reply-To: References: <20221024210953.1572998-1-gwan-gyeong.mun@intel.com> <87mt9kppb6.wl-ashutosh.dixit@intel.com> <87ilk7pwrw.wl-ashutosh.dixit@intel.com> <877d0lxl6s.wl-ashutosh.dixit@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 27 Oct 2022 10:16:47 -0700, Nick Desaulniers wrote: > Hi Nick, > Thanks, I can repro now. > > I haven't detangled the macro soup, but I noticed: > > 1. FIELD_PREP is defined in include/linux/bitfield.h which has the > following comment: > 18 * Mask must be a compilation time constant. I had comments about this here: https://lore.kernel.org/intel-gfx/87ilk7pwrw.wl-ashutosh.dixit@intel.com/ The relevant part being: ---- {quote} ---- > > > ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK' > > > BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) > \ So clang seems to break here at this line in __BF_FIELD_CHECK (note ~0ull also occurs here): BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) > \ __bf_cast_unsigned(_reg, ~0ull), \ _pfx "type of reg too small for mask"); \ So it goes through previous checks including the "mask is not constant" check. As Nick Desaulniers mentions "__builtin_constant_p is evaluated after most optimizations have run" so by that time both compilers (gcc and clang) have figured out that even though _mask is coming in as function argument it is really the constant below: #define PKG_PWR_LIM_1 REG_GENMASK(14, 0) But it is not clear why clang chokes on this "type of reg too small for mask" check (and gcc doesn't) since everything is u32. ---- {end quote} ---- > > 2. hwm_field_scale_and_write only has one callsite. > > The following patch works: If we need to fix it at our end yes we can come up with one of these patches. But we were hoping someone from clang/llvm can comment about the "type of reg too small for mask" stuff. If this is something which needs to be fixed in clang/llvm we probably don't want to hide the issue. > > ``` > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c > b/drivers/gpu/drm/i915/i915_hwmon.c > index 9e9781493025..6ac29d90b92a 100644 > --- a/drivers/gpu/drm/i915/i915_hwmon.c > +++ b/drivers/gpu/drm/i915/i915_hwmon.c > @@ -101,7 +101,7 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, > i915_reg_t rgadr, > > static void > hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr, > - u32 field_msk, int nshift, > + int nshift, > unsigned int scale_factor, long lval) > { > u32 nval; > @@ -111,8 +111,8 @@ hwm_field_scale_and_write(struct hwm_drvdata > *ddat, i915_reg_t rgadr, > /* Computation in 64-bits to avoid overflow. Round to nearest. */ > nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor); > > - bits_to_clear = field_msk; > - bits_to_set = FIELD_PREP(field_msk, nval); > + bits_to_clear = PKG_PWR_LIM_1; > + bits_to_set = FIELD_PREP(PKG_PWR_LIM_1, nval); > > hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr, > bits_to_clear, bits_to_set); > @@ -406,7 +406,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 > attr, int chan, long val) > case hwmon_power_max: > hwm_field_scale_and_write(ddat, > hwmon->rg.pkg_rapl_limit, > - PKG_PWR_LIM_1, > hwmon->scl_shift_power, > SF_POWER, val); > return 0; > ``` > Though I'm not sure if you're planning to add further callsites of > hwm_field_scale_and_write with different field_masks? I have reasons for keeping it this way, it's there in the link above if you are interested. > > Alternatively, (without the above diff), > > ``` > diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h > index c9be1657f03d..6f40f12bcf89 100644 > --- a/include/linux/bitfield.h > +++ b/include/linux/bitfield.h > @@ -8,6 +8,7 @@ > #define _LINUX_BITFIELD_H > > #include > +#include > #include > > /* > @@ -62,7 +63,7 @@ > > #define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx) \ > ({ \ > - BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask), \ > + BUILD_BUG_ON_MSG(!__is_constexpr(_mask), \ > _pfx "mask is not constant"); \ > BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero"); \ > BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ? \ > ``` > will produce: > error: call to __compiletime_assert_407 declared with 'error' > attribute: FIELD_PREP: mask is not constant > > I haven't tested if that change is also feasible (on top of fixing > this specific instance), but I think it might help avoid more of these > subtleties wrt. __builtin_constant_p that depende heavily on compiler, > compiler version, optimization level. Not disagreeing, can do something here if needed. Thanks. -- Ashutosh