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 BD6E5C433EF for ; Mon, 1 Nov 2021 21:58:17 +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 1167360F3A for ; Mon, 1 Nov 2021 21:58:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1167360F3A 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 AAC0383395; Mon, 1 Nov 2021 22:58:14 +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="Eb2ZkhWc"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 71FD683214; Mon, 1 Nov 2021 22:58:13 +0100 (CET) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 2D88983214 for ; Mon, 1 Nov 2021 22:58:10 +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-x831.google.com with SMTP id v17so17267887qtp.1 for ; Mon, 01 Nov 2021 14:58:10 -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=WKbICcOoRKbRhYP1MZFtQ54mrDHNkskoXOUQXQIP+8I=; b=Eb2ZkhWcQ2sQO9PHzlk6TCcPpHDTPfat5O0qsE8nTfbppvip2XNnF1KI1Zz6NjsnjK f8QfsnC+NCoqR+PykKZmJte/FqlLdkf3BBmllRoPa7tAFiwB+Sg2Vw/d2uBzY6L+C+5E yPQw+UFU44hZgQWNk8N7E1APnbM+pIS7cPqKk= 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=WKbICcOoRKbRhYP1MZFtQ54mrDHNkskoXOUQXQIP+8I=; b=y6ACupiEOfpODgrzvbUxYeNiBfRCF6PDjA9KVMZJ3GTmVUJ2OCqbZHM+KjEb8jV217 bOPUGepVgs9T2CqaVpXll3gOJEM7qrM52qZ4RtDruiFYD4YRQNBCS+KrugGcG2PmMRfh PKXGa/lnS6Wj8ZdAjbKI0MZXIe64uoYRGNOcaWjwi+r95oGZ/YsWsWdbO/fZ5V+g1hh0 GfNZdWCv9g7tQsvKM3luIJlDqrcb/bAd3di6HbG5RufaFF+OUcNgdx118Taqp/4OBs+b 3isRtL+TdLjETLJAEgOgP3JFvncke340JXlIqPMzSfaDN64J4HmboLYytDgpUrr9OgP/ w4IA== X-Gm-Message-State: AOAM530984Y4wOij3KdvJkLHXvByIBHPBt9Y17RT8XnSaSHj+btwDLHh /AKT/B3U+lKwaeOEPqUFmSxHzg== X-Google-Smtp-Source: ABdhPJxd0WS6baBkM9jl5iQhtrBkEScugErx5BY/UuY0lv6uy7jPlmY+Q9VgAjJOJ+g18guDAANdMg== X-Received: by 2002:ac8:5916:: with SMTP id 22mr7368674qty.288.1635803888837; Mon, 01 Nov 2021 14:58:08 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-7d10-4e93-4359-630d.res6.spectrum.com. [2603:6081:7b01:cbda:7d10:4e93:4359:630d]) by smtp.gmail.com with ESMTPSA id b20sm12053741qtx.89.2021.11.01.14.58.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Nov 2021 14:58:07 -0700 (PDT) Date: Mon, 1 Nov 2021 17:58:05 -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: <20211101215805.GN24579@bill-the-cat> References: <20211023232635.9195-1-sjg@chromium.org> <20211023232635.9195-3-sjg@chromium.org> <20211027131340.GT8284@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6pllAmZw5nNZD8Lv" 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 --6pllAmZw5nNZD8Lv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 31, 2021 at 05:46:43PM -0600, Simon Glass wrote: > Hi Tom, >=20 > 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? Shouldn't > > > > this be a completely separate patch? > > > > > > > > Thanks > > > > /Ilias > > > > > > > > On Sun, 24 Oct 2021 at 02:26, Simon Glass wrote: > > > > > > > > > > LTO (Link-Time Optimisation) is an very useful feature which can > > > > > significantly reduce the size of U-Boot binaries. So far it has b= een > > > > > 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 machine, = but 6.7 > > > > > seconds with LTO enabled. > > > > > > > > > > Add a LTO_BUILD=3Dn parameter to the build, so it can be disabled= 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 -fno-s= trict-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=3Dn. > > > > 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 stanza > > in arch/Kconfig. We do not need a whole thing around a CONFIG option > > that can be disabled in the defconfig, or local .config file even. > > >=20 > Cranky time. >=20 > 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 Tom --6pllAmZw5nNZD8Lv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmGAYucACgkQFHw5/5Y0 tywkRwv8DMmVINwsqw3p+rtiqJ4jv8LVxTwPcZmsTCqWfXu7m3Yebp3geCAnTcxq 4vc+vmLZByYmGsfKZThjN1LUsPbvmaw/KNrI/PECssIfVa676XbTBNcbJLVzsMG7 FayG6r0NIjBLXmaWxLFy/f7z2vpTcxd8uRX61Yo4tLu/Hyk6QlK37sBU9aMrYC8R A6HTHJCddRiEp8+TITiOgELEfgnCF2TZCtk8DJfZabmsar4ux6qaw/cvgAFwOMSY N1GaAQYo2JnXlpugf13idfdTbH1eZLyvJ6+xDHhfv6aofRXscbRW6/9pP8a6VmO9 VLInMPhHMypV6+rBlSYbYsWeq9YUGG9MA8yUYYAhTDDwxknLaNTBLU73m8zYhCNq VIQPstNGJ2KRKTtTh+lphehBytsiYXakWKSAQBD97oj9lbY1BkK8tXfzRBnzfyFa Jo+V87NoCyXSTPxr4yflaU9n+Us2AYCCn+DtccQe4rv9wkeUBAV1IPf3NHBwtYm4 M/rOflRF =uj5Z -----END PGP SIGNATURE----- --6pllAmZw5nNZD8Lv--