From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 46A82C433B4 for ; Fri, 9 Apr 2021 19:33:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2593260238 for ; Fri, 9 Apr 2021 19:33:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234705AbhDITd5 (ORCPT ); Fri, 9 Apr 2021 15:33:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39260 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234785AbhDITd4 (ORCPT ); Fri, 9 Apr 2021 15:33:56 -0400 Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A7DEAC061762 for ; Fri, 9 Apr 2021 12:33:42 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id y1so7739044ljm.10 for ; Fri, 09 Apr 2021 12:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=agSy06aIEctwExyBOpH0Av56/yWfK/K39QTHh943O30=; b=M61olKQ5+31eeF6oDsDJTw+9q0ID5tuTA1oUYG7DNLA9oXwHDakqaexMtwt84sWv7N 33Gx+Cc5K/Y5fUsk054bWmOYF8bCHWgrKQ3kq3hdqy4mCDd0VKGeFiAHGCw3WvQDvOLC Xp699j8Fkm5g4NfcWDzStV95Q631jBzoXJkecJ1cKDbQbaDuQ0nqmrgDHCYyxjUX22ox F6p9siNDiI7gvpSSNhzzW0hhOHVw0SyRdSfF5TYyzY0H62S/QXKTnP+Ko+RXVsRafdi3 MUN//rqPiHTS/haFSEN+I8Jb9+NPQrisau42+PhAO42jbiFanzUaf546YuNRsnEQ0m+R bKNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=agSy06aIEctwExyBOpH0Av56/yWfK/K39QTHh943O30=; b=BOO8SXivaz7jiu1X0GfeA8PbFz/HY2LAvG4rR4aNTz0B4p2+e+35D0i3WLMsERwzap kz+CG6mOcX7nQGf1FtpY6YEDTObVw9tHtmBID/orCPSPgGnKoCEt8ymelaywnI+nFtiK 2S7T4HJidVikuj6nqneW2wNRPoaxXXqkNVObd1m6HXPMaFV2yvGZdZhaqK+FHclYdR/g Tsjq9140N22iTyJtyeKIpFX/gy8uUHCOhBtnYGuk1BIgR7GPk6naPvBiTXDIm1o0KuMC 3kz9pXSZYS7S05dhjslhPICjSvO9nILOjhAIIzfeIlOEsvvCrvO/zqHFksekr1Fu6t0e oSVg== X-Gm-Message-State: AOAM533jSy/hv62i4mqsQhQGzLq256DispgVxJYRLd0pMxgh+Ga0LCK5 UI1ngjVfx7/ufWbglCChE3Mh0qNzZTYAC9QbhbLqW6vf+ZtmMA== X-Google-Smtp-Source: ABdhPJy25HpVNFlFcheDTH68HRxhNLAcL4xLp/tawSRz2tdW4Bf4mAWcl+v83N12y/1CeRZ2QgaRFdpDztxZrJQaG78= X-Received: by 2002:a2e:b88d:: with SMTP id r13mr10166764ljp.479.1617996820957; Fri, 09 Apr 2021 12:33:40 -0700 (PDT) MIME-Version: 1.0 References: <877dlbzq09.fsf@oldenburg.str.redhat.com> In-Reply-To: From: Nick Desaulniers Date: Fri, 9 Apr 2021 12:33:29 -0700 Message-ID: Subject: Re: static_branch/jump_label vs branch merging To: Peter Zijlstra Cc: Florian Weimer , Ard Biesheuvel , linux-toolchains@vger.kernel.org, Linux Kernel Mailing List , Josh Poimboeuf , Jason Baron , "Steven Rostedt (VMware)" , Segher Boessenkool , dmalcolm@redhat.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Fri, Apr 9, 2021 at 4:18 AM Peter Zijlstra wrote: > > On Fri, Apr 09, 2021 at 12:55:18PM +0200, Florian Weimer wrote: > > * Ard Biesheuvel: > > > > > Wouldn't that require the compiler to interpret the contents of the > > > asm() block? > > > > Yes and no. It would require proper toolchain support, so in this case > > a new ELF relocation type, with compiler, assembler, and linker support > > to generate those relocations and process them. As far as I understand > > it, the kernel doesn't do things this way. > > I don't think that all is needed. All we need is for the compiler to > recognise that: > > if (cond) { > stmt-A; > } > if (cond) { > stmt-B; > } > > both cond are equivalent and hence can merge the blocks like: > > if (cond) { > stmt-A; > stmt-B; > } > > But because @cond is some super opaque asm crap, the compiler throws up > it's imaginry hands and says it cannot possibly tell and leaves them as > is. Right, because if `cond` has side effects (such as is implied by asm statements that are volatile qualified), suddenly those side effects would only occur once whereas previously they occurred twice. Since asm goto is implicitly volatile qualified, it sounds like removing the implicit volatile qualifier from asm goto might help? Then if there were side effects but you forgot to inform the compiler that there were via an explicit volatile qualifier, and it performed the suggested merge, oh well. -- Thanks, ~Nick Desaulniers