Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp2243478pxa; Mon, 24 Aug 2020 09:00:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJypLrA5JvtZ2LX3yP57G+WCKjhZdzRZOEX50KM4kNO5o2PJTNt/Qd1ce6a7ll+H7RpykYCC X-Received: by 2002:a17:906:3cc:: with SMTP id c12mr3149416eja.333.1598284804525; Mon, 24 Aug 2020 09:00:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598284804; cv=none; d=google.com; s=arc-20160816; b=HwqwGMKPktK/lq9Kmu77A6Wxi2PeqfDRF8CcDdchiwByWZbNxOt+v+lJ/THCsMwu8N s/+qiOF1Oyl/gQJQVX1LKAtSC/u0muHDEuadfbUV5sXdqrjwP4C8bZgumTNFn9kvD2av t0hKi525S2WSMPqWs1iEfWbS4wFRm2NmQIWiQVuqrQDTKpMyq/FzgfxMsUD6k1b5rzva 5tmTy7lkHREPVwId01WYwmUE8Xq7AJMITlxKIVstjEBidZj0VMEfXAXb5md95psMVl/e mmi1CFEnmrwWjZuj5FM71m3IKuL6KU7XZ1ovFm+TjUjlxBflgrofaSZkyslXphqoY0vH Y7lw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature:dkim-filter; bh=Ya6WAqf3qWKePGzzyVqFBPTs2/RY7mac2cuoBTwLsr4=; b=CLc9L3TxHX2e8GOdjdd6Ao7HsjSW5vJ5m9NoSfI7GfrhIevhtvC0/1TZ/0wrP812JE HsTEcx8zNVswzyZjkaNYjbRFdBzfgUESRQsRrqHWyGKTRu3QXSzbIl0FOb0Y7e9lCx6z 9MpNi1fmCMPYMZiakgwV61mUMa06HlP1oHaR65wlvvEzoR7CduhAIfxqBtMKXgVWCKaL ZVc9tHgb/nouScPHE7To29Vrm5UrqXqkrHft2Q3UwmUrNEr6FsbbuHqhJFfcVTrOpSja RtBzXmfHq/bPBp3ndtqlekNR54enBZ+De7HWpNG9xN5QAIvCsbtal7Plzob4FZHoLHMX uESA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=JWHS6WXD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gs14si7029183ejb.615.2020.08.24.08.59.41; Mon, 24 Aug 2020 09:00:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=JWHS6WXD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727046AbgHXP6b (ORCPT + 99 others); Mon, 24 Aug 2020 11:58:31 -0400 Received: from conssluserg-05.nifty.com ([210.131.2.90]:18750 "EHLO conssluserg-05.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726413AbgHXP6T (ORCPT ); Mon, 24 Aug 2020 11:58:19 -0400 Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) (authenticated) by conssluserg-05.nifty.com with ESMTP id 07OFw0El032105; Tue, 25 Aug 2020 00:58:01 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-05.nifty.com 07OFw0El032105 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1598284681; bh=Ya6WAqf3qWKePGzzyVqFBPTs2/RY7mac2cuoBTwLsr4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=JWHS6WXDmrw1vNT2G4VzLtt+Na8Tg2XMpgeYm9VLI3FJfR9IP8FndgFwq2FRnM7Bz kyPYcY6gSOtRgXSWPWHCmfNWhqWwPmSVFQRPvLCGPTcsTo/NzBwjiJYaJfD12ggNrW Az0S8QOtELjrtdxcEdh7/k/70nFIAlzqyQJuZfaj9KXaBVCvjPAB3ehoAhjVOw5uY3 UEBgyv2aPuGkglK8p6UAOyaH6UuzpJAWfaBnfQPrCSVIO4mIT9laXqFeBUDnjx73ec ZUpQcqu7WOo8vi2K5cLq2hm2lfa4NYi2B8FITZJUb1bAuw202x/h3QZyn6/0QKthUh DV34FACYcKDbQ== X-Nifty-SrcIP: [209.85.217.48] Received: by mail-vs1-f48.google.com with SMTP id v138so4709413vsv.7; Mon, 24 Aug 2020 08:58:01 -0700 (PDT) X-Gm-Message-State: AOAM530tx6OYvxVIpjVSFCkO9wqf1BJGdZWqvni6rdI/kI6q/MgwMgxz SGrglZdr4zFIVHgr4b1XVXFCgHZIPs0snEDzLro= X-Received: by 2002:a05:6102:7ac:: with SMTP id x12mr2940671vsg.181.1598284680097; Mon, 24 Aug 2020 08:58:00 -0700 (PDT) MIME-Version: 1.0 References: <20200817220212.338670-1-ndesaulniers@google.com> <76071c24-ec6f-7f7a-4172-082bd574d581@zytor.com> <20200818202407.GA3143683@rani.riverdale.lan> <20200818214146.GA3196105@rani.riverdale.lan> In-Reply-To: <20200818214146.GA3196105@rani.riverdale.lan> From: Masahiro Yamada Date: Tue, 25 Aug 2020 00:57:22 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/4] -ffreestanding/-fno-builtin-* patches To: Arvind Sankar Cc: Nick Desaulniers , =?UTF-8?B?RMOhdmlkIEJvbHZhbnNrw70=?= , Eli Friedman , Linus Torvalds , "H. Peter Anvin" , Andrew Morton , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Michal Marek , Linux Kbuild mailing list , LKML , Kees Cook , Tony Luck , Dmitry Vyukov , Michael Ellerman , Joe Perches , Joel Fernandes , Daniel Axtens , Andy Shevchenko , Alexandru Ardelean , Yury Norov , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Ard Biesheuvel , "Paul E . McKenney" , Daniel Kiper , Bruce Ashfield , Marco Elver , Vamshi K Sthambamkadi Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 19, 2020 at 6:41 AM Arvind Sankar wrote: > > On Tue, Aug 18, 2020 at 01:58:51PM -0700, Nick Desaulniers wrote: > > On Tue, Aug 18, 2020 at 1:27 PM Nick Desaulniers > > wrote: > > > > > > On Tue, Aug 18, 2020 at 1:24 PM Arvind Sankar wrote: > > > > > > > > On Tue, Aug 18, 2020 at 12:13:22PM -0700, Linus Torvalds wrote: > > > > > On Tue, Aug 18, 2020 at 12:03 PM H. Peter Anvin wrote: > > > > > > > > > > > > I'm not saying "change the semantics", nor am I saying that playing > > > > > > whack-a-mole *for a limited time* is unreasonable. But I would like to go back > > > > > > to the compiler authors and get them to implement such a #pragma: "this > > > > > > freestanding implementation *does* support *this specific library function*, > > > > > > and you are free to call it." > > > > > > > > > > I'd much rather just see the library functions as builtins that always > > > > > do the right thing (with the fallback being "just call the standard > > > > > function"). > > > > > > > > > > IOW, there's nothing wrong with -ffreestanding if you then also have > > > > > __builtin_memcpy() etc, and they do the sane compiler optimizations > > > > > for memcpy(). > > > > > > > > > > What we want to avoid is the compiler making *assumptions* based on > > > > > standard names, because we may implement some of those things > > > > > differently. > > > > > > > > > > > > > -ffreestanding as it stands today does have __builtin_memcpy and > > > > friends. But you need to then use #define memcpy __builtin_memcpy etc, > > > > which is messy and also doesn't fully express what you want. #pragma, or > > > > even just allowing -fbuiltin-foo options would be useful. > > > > I do really like the idea of -fbuiltin-foo. For example, you'd specify: > > > > -ffreestanding -fbuiltin-bcmp > > > > as an example. `-ffreestanding` would opt you out of ALL libcall > > optimizations, `-fbuiltin-bcmp` would then opt you back in to > > transforms that produce bcmp. That way you're informing the compiler > > more precisely about the environment you'd be targeting. It feels > > symmetric to existing `-fno-` flags (clang makes -f vs -fno- pretty > > easy when there is such symmetry). And it's already convention that > > if you specify multiple conflicting compiler flags, then the latter > > one specified "wins." In that sense, turning back on specific > > libcalls after disabling the rest looks more ergonomic to me. > > > > Maybe Eli or David have thoughts on why that may or may not be as > > ergonomic or possible to implement as I imagine? > > > > Note that -fno-builtin-foo seems to mean slightly different things in > clang and gcc. From experimentation, clang will neither optimize a call > to foo, nor perform an optimization that introduces a call to foo. gcc > will avoid optimizing calls to foo, but it can still generate new calls > to foo while optimizing something else. Which means that > -fno-builtin-{bcmp,stpcpy} only solves things for clang, not gcc. It's > just that gcc doesn't seem to have implemented those optimizations. To prevent transformation from foo() into bar(), there are two ways in Clang to do that; -fno-builtin-foo, and -fno-builtin-bar. There is only one in GCC; -fno-buitin-foo. Is this correct? I just played the optimization from printf("helloworld\n") to puts("helloworld"). https://godbolt.org/z/5s4ded -fno-builtin-puts cannot prevent clang from emitting puts. Is it because clang does not support -fno-builtin-puts? It is not clear to find out which -fno-builtin-* is supported because compilation succeeds anyway... -- Best Regards Masahiro Yamada