Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp1219625rwb; Fri, 23 Sep 2022 09:36:08 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6HNu007b/2voQHOXnkxh9CHWTuowhwZsglB3a4KeFuKIj8eRCQi63GL0HIGE5wqdsCROL1 X-Received: by 2002:aa7:c050:0:b0:453:4427:a947 with SMTP id k16-20020aa7c050000000b004534427a947mr9242175edo.172.1663950968393; Fri, 23 Sep 2022 09:36:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663950968; cv=none; d=google.com; s=arc-20160816; b=O5N+pSEDbtaCFrSW8DFIidL7LtnJXI/nQy3XC2vOoN/AfOnOLUt+Q+/qT75ao3IBoa v4B9n6pg+ayBwsXXYTBIKVDc3zq7WmAU+rpsTgneMr/Ts72h8nNByG8Zr2eQK0Gprkos Vu6HaXat0mWwtke/NJBXmDaexb3jTD7a6K4G95IuRFgc8Vyu2KY+Bstb5ks784aBrD+O ozAl27tSnYKRinPWY7XT87abdfWbVIdv0wU+X3Qc/5Zh866Qb1mrLyNWTV7rPN/gwGft WJUOeA+TUK7CnkwUWXP97ehvRrwGOBtEqi4640zAaxwrzOgg8eXgXzUcSYOLI/pFtDPo 6CRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:references:to:from:subject:cc :message-id:date:content-transfer-encoding:mime-version :dkim-signature; bh=IyPY3jNYz1zmj8hC2XWs0gtCQLKsELDuACeXIEucHZQ=; b=F+bQFfVM+JSJ4RLmzIa16A7oXM/slIn72yR+3XjrvYEK8QwMVQ2rvYgRgbFIPJHLF5 s/b1xCroUapowryCBA95INNczptfzsiehDG8tnptbF8BTMtXC/mPHwmFpQiFGgMhCVt+ dHWPL4+kt4X0U1n5L4nGeh1L9IQYFGlnynHfDnGURiNgbDvmvGvEyZkYYlGsLTGp1+YR EkxoY44zv0c5kNiLOtH06Aa1N4JZCXGAaqWq9MPkZFoG7cDw/0nxMqO0lml+OVsP4dUj 3GssbINCZA01qtojpGcXUUs7uzl8NsPVluQ0tI4SaQ8eUC1Y38GtwX7mvnZ9EJLwkBIS 7MKQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=SAiDToSa; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u14-20020a50c04e000000b0044e274977f7si7502485edd.413.2022.09.23.09.35.39; Fri, 23 Sep 2022 09:36:08 -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=@gmail.com header.s=20210112 header.b=SAiDToSa; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232853AbiIWQ1o (ORCPT + 99 others); Fri, 23 Sep 2022 12:27:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59978 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232728AbiIWQ1U (ORCPT ); Fri, 23 Sep 2022 12:27:20 -0400 Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 187EE14D4BD for ; Fri, 23 Sep 2022 09:26:59 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id y136so650989pfb.3 for ; Fri, 23 Sep 2022 09:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date; bh=IyPY3jNYz1zmj8hC2XWs0gtCQLKsELDuACeXIEucHZQ=; b=SAiDToSaHfqFgiQllB+souznfy9cjE7uiCVxu/+FJGJpgekfLf+2ETQzw13CSxgE4W D9ntvAOYdxO6PUNeuaeN40fQ4wwK3Q7qFil1G2HjPAjEl/oDTiogBRI0dFZHgn8DBEYk 2PqoiKAmgBVn3F2ho+OFCFsKsc3GJ9QLxaBNFeUiOBw0jr7nSGrD8ubD1OaH5K/l9z1H rrCK58W+ULROUGDf5NfcudRKbLBDelMEql+ZTk6M7dL6LmEauMKa3/RZBKF8ZxLsAqUF kNqQqWZjcPTpikk+isWJ+fFvgC341oYUzHEqI1Bl/AEPU5ZgODtle9ipNJ93iOLux8fe 4/xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-message-state:from:to :cc:subject:date; bh=IyPY3jNYz1zmj8hC2XWs0gtCQLKsELDuACeXIEucHZQ=; b=sWgbjPeG8lzKNQ0Q3njQpFlYpZhIyZ6yJEMIm+Q6fP24gVCliNSAzWVGYxS7FsEONq aEh+02GHgt+W7ktk2EdqdECurstSL3as8okxFkglcxDY0qi9bFOIgZedlaUo0jOCa7dJ if28CJkf4i/20SGHuBxXA+CjpbsYJ63Dpi2iLRwJFJbOJyn5ZEQdKhzKdtJ4lpGAbkiv JW091De7XFiTrza5U6EbB6er6FRi44/xi7OHdihABqBflFKbpU9FEdHB9VrKwmGq8k1s dN2NI2hIDcewJTyZZPhYZGlZu/zZC1Z4S0mqOSgnOTszM2oKC5GSSbma+dwTvD6JfHE7 cvWg== X-Gm-Message-State: ACrzQf3Nki/hdeXq7sdEwkRq/6wdzl0x7viz8i44fdhw7B8aDEkiDzQV XHeGpuYMVYU05vBDs/EF/bk= X-Received: by 2002:aa7:998f:0:b0:54d:a441:85da with SMTP id k15-20020aa7998f000000b0054da44185damr9782049pfh.20.1663950417459; Fri, 23 Sep 2022 09:26:57 -0700 (PDT) Received: from localhost (27-32-155-116.static.tpgi.com.au. [27.32.155.116]) by smtp.gmail.com with ESMTPSA id v67-20020a622f46000000b0054ee4b632dasm6537845pfv.169.2022.09.23.09.26.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Sep 2022 09:26:56 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Sat, 24 Sep 2022 02:26:52 +1000 Message-Id: Cc: "Christophe Leroy" , "Michael Ellerman" , , Subject: Re: [PATCH] powerpc/irq: Modernise inline assembly in irq_soft_mask_{set,return} From: "Nicholas Piggin" To: "Segher Boessenkool" X-Mailer: aerc 0.11.0 References: <178f30ff62c0317061f019b3dbbc079073f104c3.1663656058.git.christophe.leroy@csgroup.eu> <20220923121829.GL25951@gate.crashing.org> In-Reply-To: <20220923121829.GL25951@gate.crashing.org> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS 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 Fri Sep 23, 2022 at 10:18 PM AEST, Segher Boessenkool wrote: > On Fri, Sep 23, 2022 at 05:08:13PM +1000, Nicholas Piggin wrote: > > On Tue Sep 20, 2022 at 4:41 PM AEST, Christophe Leroy wrote: > > > local_paca is declared as global register asm("r13"), it is therefore > > > garantied to always ever be r13. > > > > > > It is therefore not required to opencode r13 in the assembly, use > > > a reference to local_paca->irq_soft_mask instead. > > > The code matches the changelog AFAIKS. But I don't know where it is > > guaranteed it will always be r13 in GCC and Clang. I still don't know > > where in the specification or documentation suggests this. > > "Global Register Variables" in the GCC manual. > > > There was some assertion it would always be r13, but that can't be a > > *general* rule. e.g., the following code: > >=20 > > struct foo { > > #ifdef BIGDISP > > int array[1024*1024]; > > #endif > > char bar; > > }; > >=20 > > register struct foo *foo asm("r13"); > >=20 > > static void setval(char val) > > { > > asm("stb%X0 %1,%0" : "=3Dm" (foo->bar) : "r" (val)); > > } > >=20 > > int main(void) > > { > > setval(10); > > } > > Just use r13 directly in the asm, if that is what you want! > > > With -O0 this generates stb 9,0(10) for me for GCC 12, and with -O2 > > -DBIGDISP it generates stb 10,0(9). So that makes me nervious. GCC > > does not have some kind of correctness guarantee here, so it must not > > have this in its regression tests etc., and who knows about clang. > > GCC has all kinds of correctness guarantees, here and elsewhere, that is > 90% of a compiler's job. But you don't *tell* it what you consider > "correct" here. Right, that's what I expect. I think the confusion came from here, https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-August/247595.html In any case it is answered now. > You wrote "foo->bar", and this expression was translated to something > that derived from r13. If you made the asm something like > asm("stb%X0 %1,0(%0)" : : "r" (foo), "r" (val) : "memory"); > it would work fine. It would also work fine if you wrote 13 in the > template directly. These things follow the rules, so are guaranteed. > > The most important pieces of doc here may be > * Accesses to the variable may be optimized as usual and the register > remains available for allocation and use in any computations, > provided that observable values of the variable are not affected. > * If the variable is referenced in inline assembly, the type of > access must be provided to the compiler via constraints (*note > Constraints::). Accesses from basic asms are not supported. > but read the whole "Global Register Variables" chapter? I still don't see what clauses guarantees asm("%0" ::"r"(foo)) to give 13. It doesn't say access via inline assembly is special, so if optimized as usual means it could be accessed by any register like access to a usual variable, then asm could also substitute a different register for the access by the letter of it AFAIKS. I think if it was obviously guaranteed then this might be marginally better than explicit r13 in the asm asm volatile( "stb %0,%2(%1)" : : "r" (mask), "r" (local_paca), "i" (offsetof(struct paca_struct, irq_soft_mask)) : "memory"); But as it is I think we should just stick with explicit r13 base in the asm. Thanks, Nick