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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 9131AC433E0 for ; Wed, 10 Mar 2021 22:31:01 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 276C664FBB for ; Wed, 10 Mar 2021 22:31:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 276C664FBB Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=nUpgmfqigQYXShh1+Exo4pzfeJEpxoNLfEcbFjHYD8Q=; b=SsAO0HiIviAv/hjqrDMRhWixV GT1Er7aXUZyYB0dNt9DLTOF0/ixxCh2bSVczeQzQaHObdApPlmaZt9amai2Q1FIAX1HUWULH6L11Y u8tFBEdiCfrPBqT2kHAyF1xZ/8MrjE0T2Y7pMs8W7i8aVM3tdAUzf9U1DSF/RfZyM39w9QFhFbKr7 Mq4GVm/kqsLswvDYRPU5MFmzt9tLQDws+bDGoSLUZiVsyKDj+hfXhcbSr/9oEirXrQJXyUVc+H043 /TENtvaYmxaqaYtpnwkOoNAPbuQfaz44V+Q9TMu7YeItDoDgqN8mQFG20wv/G1xv8FLOa8Sk/BZQ9 t/pBa8yug==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lK7Kg-007uYk-Ec; Wed, 10 Mar 2021 22:29:34 +0000 Received: from mail-pg1-x52a.google.com ([2607:f8b0:4864:20::52a]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lK7Kb-007uXy-UA for linux-arm-kernel@lists.infradead.org; Wed, 10 Mar 2021 22:29:32 +0000 Received: by mail-pg1-x52a.google.com with SMTP id w34so11289027pga.8 for ; Wed, 10 Mar 2021 14:29:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=M1LQocdyrILdN3y2ftG88hya3R5bASNZBW6DmO/mx8w=; b=rRAmlYnwokFCMZCfoI41jeWTl58ratOsNSgKi9c2hJ4iln8AOVIAJ1+sWavIS+bF9F RNOplYoZJCumLg3mMmS5S4WrbITN/O4aM04wtiU6Qz6YkQsLI0wt/IeoUK5gv+P/fya5 bBUBJ450uOGclJLMkLxutYWB/fEU3nJq+32Dia7+h4lbgtaxaaHz28VRIWPclkq29NC+ BtIusP4jp19RDVX3/94PKsfLZK53vRlitB2aaxPhIKHyLsrK6rJRZtDGSl/LufXIYep8 nz41na5a5VlyNaQ5NZHTo/NFqcoQA8LcEXueAQLmQHr6xurHFzhRZbLkEAsEHVKBGHsa TJEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=M1LQocdyrILdN3y2ftG88hya3R5bASNZBW6DmO/mx8w=; b=Yg8UIs0TsSTc+Xw2K7YHbdPKHGtk5joO9bloB85n+neJdc1cO7IHvAZgBFBzmrvFcm bgBVEG6HmOaDXipE0tUPfVTeQoVxBoKjCYeyYF5loSpec3UA0G3mtToWTrpZtMflC1IL M6HPBkSOrOT3vcvC7Hwc7Il7fLC1Guv/1+3pMQttPAOtrGDhVYXUmI9C2maJ9aGgqWxm S8XxLEwzxnGqdtjIomwy/nntxeFdAMnpQRVkjYuYlNUmpcbW/q54QaEcDmdpvEIvKReG 1rvO383QC/VZTznhL+qnGnhiRjQtMomEhNp59rykoQn0nUHMTbWL8gcDxK3/bK/s5aDo M//Q== X-Gm-Message-State: AOAM53358OHBJP+Q/qJQBpgsjciXfNNfcJs7ZBzBABzHzks6Ea9UdXjv ERQjsBT1Va2DtszRts9WeNbGNg== X-Google-Smtp-Source: ABdhPJwpjGZgnpdrKpm/0s9dytIZYfRa0f6S1OLEGLXaeGLYa/sHF51cyL2rnC+D4J9/KhIpJB2jrQ== X-Received: by 2002:a63:170e:: with SMTP id x14mr4600946pgl.245.1615415366310; Wed, 10 Mar 2021 14:29:26 -0800 (PST) Received: from google.com ([2620:15c:2ce:0:6ded:c9f:3996:6bc8]) by smtp.gmail.com with ESMTPSA id j21sm450003pfc.114.2021.03.10.14.29.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Mar 2021 14:29:25 -0800 (PST) Date: Wed, 10 Mar 2021 14:29:21 -0800 From: Fangrui Song To: Arnd Bergmann , Masahiro Yamada Cc: Nicholas Piggin , Ard Biesheuvel , Andrew Scull , Mark Brown , Catalin Marinas , clang-built-linux , David Brazdil , Geert Uytterhoeven , Ionela Voinescu , Kees Cook , Kristina Martsenko , Linux ARM , "linux-kernel@vger.kernel.org" , Mark Rutland , Marc Zyngier , Nathan Chancellor , Nick Desaulniers , Vincenzo Frascino , Will Deacon , Nicolas Pitre Subject: Re: [PATCH] [RFC] arm64: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION Message-ID: <20210310222921.t7tf7cjr7po5dlay@google.com> References: <20210225112122.2198845-1-arnd@kernel.org> <20210226211323.arkvjnr4hifxapqu@google.com> <1614559739.p25z5x88wl.astroid@bobo.none> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210310_222930_177188_4ED8896F X-CRM114-Status: GOOD ( 20.02 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2021-03-10, Arnd Bergmann wrote: >On Wed, Mar 10, 2021 at 9:50 PM Masahiro Yamada wrote: >> On Mon, Mar 1, 2021 at 10:11 AM Nicholas Piggin wrote: >> > Excerpts from Arnd Bergmann's message of February 27, 2021 7:49 pm: > >> >> masahiro@oscar:~/ref/linux$ echo 'void this_func_is_unused(void) {}' >> >> kernel/cpu.c >> masahiro@oscar:~/ref/linux$ export >> CROSS_COMPILE=/home/masahiro/tools/powerpc-10.1.0/bin/powerpc-linux- >> masahiro@oscar:~/ref/linux$ make ARCH=powerpc defconfig >> masahiro@oscar:~/ref/linux$ ./scripts/config -e EXPERT >> masahiro@oscar:~/ref/linux$ ./scripts/config -e LD_DEAD_CODE_DATA_ELIMINATION >> masahiro@oscar:~/ref/linux$ >> ~/tools/powerpc-10.1.0/bin/powerpc-linux-nm -n vmlinux | grep >> this_func >> c000000000170560 T .this_func_is_unused >> c000000001d8d560 D this_func_is_unused >> masahiro@oscar:~/ref/linux$ grep DEAD_CODE_ .config >> CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION=y >> CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y >> >> >> If I remember correctly, >> LD_DEAD_CODE_DATA_ELIMINATION dropped unused functions >> when I tried it last time. --gc-sections drops unused sections. If the unused function is part of a larger section which is retained due to other symbols (-fno-function-sections), the unused section will be retained as well. >> >> >> I also tried arm64 with a HAVE_LD_DEAD_CODE_DATA_ELIMINATION hack. >> The result was the same. >> >> >> >> Am I missing something? > >It's possible that it only works in combination with CLANG_LTO now >because something broke. I definitely saw a reduction in kernel >size when both options are enabled, but did not try a simple test >case like you did. > >Maybe some other reference gets created that prevents the function >from being garbage-collected unless that other option is removed >as well? > > Arnd I believe with LLVM regular LTO, --gc-sections has very little benefit on compiler generated sections. It is still useful for assembly generated sections (but most such sections are probably needed): * Target specific optimizations can drop references on constants (e.g. `memcpy(..., &constant, sizeof(constant));`) * Due to phase ordering issues some definitions are not discarded by the optimizer. For ThinLTO there are more compiler generated sections discarded by `--gc-sections`: * ThinLTO can cause a definition to be imported to other modules. The original definition may be unneeded after imports. * The definition may survive after intra-module optimization. After imports, a round of (inter-module) IR optimizations after `computeDeadSymbolsWithConstProp` may make the definition unneeded. * Symbol resolution is conservative. Regarding symbol resolution, symbol resolution happens before LTO and LTO happens before --gc-sections. The symbol resolution process may be conservative: it may communicate to LTO that some symbols are referenced by regular object files while in the GC stage the references turn out to not exist because of discarded sections with more precise GC roots. (I've added the above points to my https://maskray.me/blog/2021-02-28-linker-garbage-collection#link-time-optimization ) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel