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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C3DDBC433EF for ; Thu, 4 Nov 2021 14:55:38 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B5A67610FC for ; Thu, 4 Nov 2021 14:55:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B5A67610FC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 55D4582D95; Thu, 4 Nov 2021 15:55:35 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="d6JHuevg"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 8AE578029E; Thu, 4 Nov 2021 15:55:33 +0100 (CET) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 4BE958029E for ; Thu, 4 Nov 2021 15:55:29 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qt1-x82a.google.com with SMTP id 8so4310565qty.10 for ; Thu, 04 Nov 2021 07:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=QPPVVjLNuHrGwcGecXFiYr7egnrVGgU+lyebL6elGis=; b=d6JHuevgZFIZnAfSFm59rMnadkhdL8sc7uADJVHVDqT5HdpA+3ZThSgi+4w4H0Wyk/ JwBrp50EhJAqbRnfSDmWhizAzEJ1FDUGoWdXk4INRYuTulHrczpac30GFA6rtxCfrO1g ip7fwp02W0vzKAnn7WOJtsblEqfFyaSQshHAc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=QPPVVjLNuHrGwcGecXFiYr7egnrVGgU+lyebL6elGis=; b=01mNzNQkdXB/ozDhuR2ImwDpb2Dl3PsVrdYbBupQNYS1uzC+SrA+GY7d29oGtq4v3s COKB33QfyZlJhF432sfuKbBwgv9FUcCEw/U1whGGIEX5MxFKwKI5233imo0mR7yfxHHt tDVuYtXtk9gHOkN1UptR3M5Luw4j4G+8PolFPZ/Z3Vb1o1pPA8RGiL3l4BLFwCq2EC/2 f1pBtR43fCpqXcHPYkKltAQAft+Yz0sR24x6KMtC/8qhsK82E/bE2p6ZDPpOP3GJN0S4 2tk6QJEdk/kG1RQ3Zfunk5F86H1/3piRxb61etPdudVjBcXocCDcM7nWJIw/5wQBl+pd j0vg== X-Gm-Message-State: AOAM532dL4psKMSCCH2iU1D43q/wQTj61hBNfg5nMswX3DsypBF8i5N3 25VSJv7JZoUgXS9p3QKOvRSnOQ== X-Google-Smtp-Source: ABdhPJyhGHxYIuhf4RGWbygzgs1Hvyt0JIsR1+TipGyQPv0j76+qD9v0Dy9WOE9zwVkgjdzwtXcowQ== X-Received: by 2002:ac8:5c48:: with SMTP id j8mr47282076qtj.317.1636037728001; Thu, 04 Nov 2021 07:55:28 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-e134-a4dd-2b9a-4388.res6.spectrum.com. [2603:6081:7b01:cbda:e134:a4dd:2b9a:4388]) by smtp.gmail.com with ESMTPSA id t23sm4384433qtc.12.2021.11.04.07.55.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Nov 2021 07:55:27 -0700 (PDT) Date: Thu, 4 Nov 2021 10:55:25 -0400 From: Tom Rini To: Simon Glass Cc: Heinrich Schuchardt , U-Boot Mailing List , Michal Simek , Daniel Schwierzeck , Steffen Jaeckel , Marek =?iso-8859-1?Q?Beh=FAn?= , Lukas Auer , Dennis Gilmore , Masahiro Yamada , Ilias Apalodimas , Heinrich Schuchardt Subject: Re: [PATCH v2 02/41] Makefile: Allow LTO to be disabled for a build Message-ID: <20211104145525.GM24579@bill-the-cat> References: <20211023232635.9195-1-sjg@chromium.org> <20211023232635.9195-3-sjg@chromium.org> <20211027131340.GT8284@bill-the-cat> <20211101215805.GN24579@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pZtAG9wM4xcPQMtr" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean --pZtAG9wM4xcPQMtr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 03, 2021 at 08:49:01PM -0600, Simon Glass wrote: > Hi Tom, >=20 > On Mon, 1 Nov 2021 at 15:58, Tom Rini wrote: > > > > On Sun, Oct 31, 2021 at 05:46:43PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Wed, 27 Oct 2021 at 07:13, Tom Rini wrote: > > > > > > > > On Wed, Oct 27, 2021 at 02:21:17PM +0200, Heinrich Schuchardt wrote: > > > > > > > > > > > > > > > On 10/27/21 10:50, Ilias Apalodimas wrote: > > > > > > Hi Simon > > > > > > > > > > > > How does this patch related to the standard boot series? Should= n't > > > > > > this be a completely separate patch? > > > > > > > > > > > > Thanks > > > > > > /Ilias > > > > > > > > > > > > On Sun, 24 Oct 2021 at 02:26, Simon Glass wr= ote: > > > > > > > > > > > > > > LTO (Link-Time Optimisation) is an very useful feature which = can > > > > > > > significantly reduce the size of U-Boot binaries. So far it h= as been > > > > > > > made available for selected ARM boards and sandbox. > > > > > > > > > > > > > > However, incremental builds are much slower when LTO is used.= For example, > > > > > > > an incremental build of sandbox takes 2.1 seconds on my machi= ne, but 6.7 > > > > > > > seconds with LTO enabled. > > > > > > > > > > > > > > Add a LTO_BUILD=3Dn parameter to the build, so it can be disa= bled during > > > > > > > development if needed, for faster builds. > > > > > > > > > > > > > > Add some documentation about LTO while we are here. > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > --- > > > > > > > > > > > > > > (no changes since v1) > > > > > > > > > > > > > > Makefile | 18 +++++++++++++----- > > > > > > > arch/arm/config.mk | 4 ++-- > > > > > > > arch/arm/include/asm/global_data.h | 2 +- > > > > > > > doc/build/gcc.rst | 17 +++++++++++++++++ > > > > > > > 4 files changed, 33 insertions(+), 8 deletions(-) > > > > > > > > > > > > > > diff --git a/Makefile b/Makefile > > > > > > > index b79b2319ff6..7057723e046 100644 > > > > > > > --- a/Makefile > > > > > > > +++ b/Makefile > > > > > > > @@ -434,6 +434,9 @@ KBUILD_CFLAGS +=3D -fshort-wchar -f= no-strict-aliasing > > > > > > > KBUILD_AFLAGS :=3D -D__ASSEMBLY__ > > > > > > > KBUILD_LDFLAGS :=3D > > > > > > > > > > > > > > +# Set this to "n" use of LTO for this build, e.g. LTO_BUILD= =3Dn > > > > > > > +LTO_BUILD ?=3D y > > > > > > > > > > This does not allow LTO_BUILD=3Dy to enable LTO for CONFIG_LTO=3D= n. > > > > > > > > I don't understand why we need this patch at all. If you want to > > > > disable LTO, disable LTO. Yes, LTO makes linking take longer which= can > > > > be annoying on iterative development. I have a few different "HACK= : DO > > > > NOT PUSH: ..." things I git am at the start of a branch, depending= on > > > > needs. You can just do that to drop "imply LTO" from the SANDBOX s= tanza > > > > in arch/Kconfig. We do not need a whole thing around a CONFIG opti= on > > > > that can be disabled in the defconfig, or local .config file even. > > > > > > > > > > Cranky time. > > > > > > Of course we don't *need* it. I could just buy a slower build machine > > > and type with two fingers. There are lots of ways to slow things down > > > and LTO is one of them. I change branches at least a dozen times a day > > > and am always trying things out from patchwork. I am sure others do > > > too. LTO dramatically slows down builds. Having a way to easily do > > > this from the build system saves time. > > > > Maybe the answer is that LTO just isn't appropriate for sandbox. We're > > not doing any specific tests for LTO anywhere (nor does that seem > > appropriate), and we do have platforms in CI that run tests other than > > building, with LTO. >=20 > It has value as a test, I presume, and a demo of how it works. Also it > runs most of the tests. >=20 > But I'm happy to disable it if that helps. >=20 > Still, it doesn't really solve the issue. The same thing happens when > building real boards. Well, a big part of the problem here is I strongly disagree with a make-line flag to override a CONFIG option. I also hear your use case of "I build this platform so frequently per development session it's a noticeable slowdown and a 'LOCAL:' commit will also screw up my workflow". So where do we go? LTO is a size versus speed trade-off (and -ffunction-sections/-fdata-sections/--gc-unused is a much smaller speed trade-off) that's more important on real hardware (and also not used as often as it might be, at least so far). On real boards, there's less of a "just turn it off" option because it's required to be small enough to use on the hardware. Since that's not the case on sandbox, maybe we just need to turn it on in more QEMU platforms (to get broader test coverage in CI) and off in sandbox. --=20 Tom --pZtAG9wM4xcPQMtr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmGD9FYACgkQFHw5/5Y0 tyw/7wwAiv+aZMFvtUhFODsnGpCU+qkPwSaMcGJR4z+pS/2nzjB0IHA8YtVBLflv 3+tMIGr0KplP169Ts7zfzknRb08aoFzAWbz7b2bAZqgft4uYoRHKAiBrOs1fy9Jm oUqwaNOhHZZ3tnLj/otY0AhqMNUXDftTO8T4ssQa7yyF4NuAmTOuYv0dkJAyZzaI +Oz6/H7oyeIkCIzmbFWycCP4foTp/3r5Zx7tmm5zaRF8PE6cX0p02K7wH6NklST3 FlwSnZ+/VcdFfYvXahLVW+fSRETutOPwrGc+ZhxXXR7YTMU1xyvIyFWUt9bvL0N8 u3sR9k6mS8XzxuVk3x+rH+zlPYlxmSaMHTAABOf3JkhKjpQl4DP4NN5oktRENMJZ rWX8ZP68r2u7I/krA9J7SUhQ+w2gshTsybiAM8rtGsk/MKK/7hkSYhiXMM+Dp74y 4G8vLQTBsnZi+cpcr5xNL3xBf/CFsWfs7DV/DkJjUIsH0C/n0/Nb143mzyEHvIvo FohIiFk9 =Ml42 -----END PGP SIGNATURE----- --pZtAG9wM4xcPQMtr--