Re: [PATCH v2 02/13] Makefile: Allow LTO to be disabled for a build
On Wed, Mar 16, 2022 at 10:15:17AM +1300, Simon Glass wrote: > Hi Tom, > > On Mon, 14 Mar 2022 at 16:42, Tom Rini wrote: > > > > On Mon, Mar 14, 2022 at 03:43:05PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Mon, 14 Mar 2022 at 14:23, Tom Rini wrote: > > > > > > > > On Mon, Mar 14, 2022 at 02:18:14PM -0600, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Mon, 14 Mar 2022 at 13:45, Tom Rini wrote: > > > > > > > > > > > > On Mon, Mar 14, 2022 at 01:21:02PM -0600, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Mon, 14 Mar 2022 at 12:29, Tom Rini wrote: > > > > > > > > > > > > > > > > On Mon, Mar 14, 2022 at 12:24:42PM -0600, Simon Glass wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > On Mon, 14 Mar 2022 at 06:49, Tom Rini > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Sat, Mar 12, 2022 at 10:58:44AM -0700, Simon Glass wrote: > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > > > > > On Mon, 7 Mar 2022 at 07:33, Tom Rini > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Mar 04, 2022 at 08:42:57AM -0700, 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 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 machine, but 6.7 > > > > > > > > > > > > > seconds with LTO enabled. > > > > > > > > > > > > > > > > > > > > > > > > > > Add a LTO_BUILD=n 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 > > > > > > > > > > > > > > > > > > > > > > > > We don't need this since you can do: > > > > > > > > > > > > make EXTRA_CFLAGS="-fno-lto" EXTRA_LDFLAGS="-fno-lto" > > > > > > > > > > > > to pass -fno-lto to compile/linking and disable lto and > > > > > > > > > > > > per > > > > > > > > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905 this > > > > > > > > > > > > has been working > > > > > > > > > > > > for some time. > > > > > > > > > > > > > > > > > > > > > > Thanks for that, it is a big pain point for me, picking > > > > > > > > > > > up this patch > > > > > > > > > > > for every series I write. The incremental build time for > > > > > > > > > > > sandbox goes > > > > > > > > > > > from 3 seconds to 27 seconds on my laptop with LTO, which > > > > > > > > > > > is > > > > > > > > > > > intolerable. > > > > > > > > > > > > > > > > > > > > Yeah, I noticed it's visible on my laptop, but not at all > > > > > > > > > > on my desktop > > > > > > > > > > (i7 vs Ryzen 7). > > > > > > > > > > > > > > > > > > > > > The EXTRA_CFLAGS says it is for 'Backward compatibility' > > > > > > > > > > > and it still > > > > > > > > > > > does the various LTO things (i.e. it changes the build > > > > > > > > > > > logic). It > > > > > > > > > > > > > > > > > > > > We're unlikely to move to newer Linux kernel kbuild logic > > > > > > > > > > so this isn't > > > > > > > > > > going away, and there's not much in the way of logic that's > > > > > > > > > > changed for > > > > > > > > > > LTO that I see. > > > > > > > > > > > > > > > > > > > > > seems odd to me to enable the option and then disable it > > > > > > > > > > > later in the > > > > > > > > > > > command line. It is therefore not quite equivalent. But > > > > > > > > > > > it seems to > > > > > > > > > > > work well enough for me fom a small amount of testing. If > > > > > > > > > > > you are > > > > > > > > > > > really set on not having a special option for it, I can > > > > > > > > > > > live with it > > > > > > > > > > > for now. I'm also not convinced that my patch entirely > > > > > > > > > > > removes the LTO > > > > > > > > > > > stuff in a consistent way. > > > > > > > > > > > > > > > > > > > > Yeah, I really don't want to go down the path of overriding > > > > > > > > > > CONFIG > > > > > > > > > > options via make/environment logic. I'm also open to > > > > > > > > > > turning off LTO on > > > > > > > > > > sandbox and on with qemu-* so it gets wider CI testing. > > > > > > > > > > > > > > > > > > Yes you did mention that, but the problem is that LTO is very > > > > > > > > > handy > > > > > > > > > with sandbox, to test the strange things that happen. For > > > > > > > > > example, I > > >
Re: [PATCH v2 02/13] Makefile: Allow LTO to be disabled for a build
Hi Tom, On Mon, 14 Mar 2022 at 16:42, Tom Rini wrote: > > On Mon, Mar 14, 2022 at 03:43:05PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Mon, 14 Mar 2022 at 14:23, Tom Rini wrote: > > > > > > On Mon, Mar 14, 2022 at 02:18:14PM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Mon, 14 Mar 2022 at 13:45, Tom Rini wrote: > > > > > > > > > > On Mon, Mar 14, 2022 at 01:21:02PM -0600, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Mon, 14 Mar 2022 at 12:29, Tom Rini wrote: > > > > > > > > > > > > > > On Mon, Mar 14, 2022 at 12:24:42PM -0600, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > On Mon, 14 Mar 2022 at 06:49, Tom Rini > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Sat, Mar 12, 2022 at 10:58:44AM -0700, Simon Glass wrote: > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > > > On Mon, 7 Mar 2022 at 07:33, Tom Rini > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > On Fri, Mar 04, 2022 at 08:42:57AM -0700, 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 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 > > > > > > > > > > > > machine, but 6.7 > > > > > > > > > > > > seconds with LTO enabled. > > > > > > > > > > > > > > > > > > > > > > > > Add a LTO_BUILD=n 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 > > > > > > > > > > > > > > > > > > > > > > We don't need this since you can do: > > > > > > > > > > > make EXTRA_CFLAGS="-fno-lto" EXTRA_LDFLAGS="-fno-lto" > > > > > > > > > > > to pass -fno-lto to compile/linking and disable lto and > > > > > > > > > > > per > > > > > > > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905 this > > > > > > > > > > > has been working > > > > > > > > > > > for some time. > > > > > > > > > > > > > > > > > > > > Thanks for that, it is a big pain point for me, picking up > > > > > > > > > > this patch > > > > > > > > > > for every series I write. The incremental build time for > > > > > > > > > > sandbox goes > > > > > > > > > > from 3 seconds to 27 seconds on my laptop with LTO, which is > > > > > > > > > > intolerable. > > > > > > > > > > > > > > > > > > Yeah, I noticed it's visible on my laptop, but not at all on > > > > > > > > > my desktop > > > > > > > > > (i7 vs Ryzen 7). > > > > > > > > > > > > > > > > > > > The EXTRA_CFLAGS says it is for 'Backward compatibility' > > > > > > > > > > and it still > > > > > > > > > > does the various LTO things (i.e. it changes the build > > > > > > > > > > logic). It > > > > > > > > > > > > > > > > > > We're unlikely to move to newer Linux kernel kbuild logic so > > > > > > > > > this isn't > > > > > > > > > going away, and there's not much in the way of logic that's > > > > > > > > > changed for > > > > > > > > > LTO that I see. > > > > > > > > > > > > > > > > > > > seems odd to me to enable the option and then disable it > > > > > > > > > > later in the > > > > > > > > > > command line. It is therefore not quite equivalent. But it > > > > > > > > > > seems to > > > > > > > > > > work well enough for me fom a small amount of testing. If > > > > > > > > > > you are > > > > > > > > > > really set on not having a special option for it, I can > > > > > > > > > > live with it > > > > > > > > > > for now. I'm also not convinced that my patch entirely > > > > > > > > > > removes the LTO > > > > > > > > > > stuff in a consistent way. > > > > > > > > > > > > > > > > > > Yeah, I really don't want to go down the path of overriding > > > > > > > > > CONFIG > > > > > > > > > options via make/environment logic. I'm also open to turning > > > > > > > > > off LTO on > > > > > > > > > sandbox and on with qemu-* so it gets wider CI testing. > > > > > > > > > > > > > > > > Yes you did mention that, but the problem is that LTO is very > > > > > > > > handy > > > > > > > > with sandbox, to test the strange things that happen. For > > > > > > > > example, I > > > > > > > > found the bug where LTO was dropping a linker-list item, using > > > > > > > > sandbox. We could perhaps make one of the sandbox builds not > > > > > > > > use LTO, > > > > > > > > e.g. sandbox_flattree ? > > > > > > > > > > > > > > Well, the big issue with LTO+sandbox is that it
Re: [PATCH v2 02/13] Makefile: Allow LTO to be disabled for a build
On Mon, Mar 14, 2022 at 03:43:05PM -0600, Simon Glass wrote: > Hi Tom, > > On Mon, 14 Mar 2022 at 14:23, Tom Rini wrote: > > > > On Mon, Mar 14, 2022 at 02:18:14PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Mon, 14 Mar 2022 at 13:45, Tom Rini wrote: > > > > > > > > On Mon, Mar 14, 2022 at 01:21:02PM -0600, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Mon, 14 Mar 2022 at 12:29, Tom Rini wrote: > > > > > > > > > > > > On Mon, Mar 14, 2022 at 12:24:42PM -0600, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Mon, 14 Mar 2022 at 06:49, Tom Rini wrote: > > > > > > > > > > > > > > > > On Sat, Mar 12, 2022 at 10:58:44AM -0700, Simon Glass wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > On Mon, 7 Mar 2022 at 07:33, Tom Rini > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Fri, Mar 04, 2022 at 08:42:57AM -0700, 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 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 > > > > > > > > > > > machine, but 6.7 > > > > > > > > > > > seconds with LTO enabled. > > > > > > > > > > > > > > > > > > > > > > Add a LTO_BUILD=n 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 > > > > > > > > > > > > > > > > > > > > We don't need this since you can do: > > > > > > > > > > make EXTRA_CFLAGS="-fno-lto" EXTRA_LDFLAGS="-fno-lto" > > > > > > > > > > to pass -fno-lto to compile/linking and disable lto and per > > > > > > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905 this has > > > > > > > > > > been working > > > > > > > > > > for some time. > > > > > > > > > > > > > > > > > > Thanks for that, it is a big pain point for me, picking up > > > > > > > > > this patch > > > > > > > > > for every series I write. The incremental build time for > > > > > > > > > sandbox goes > > > > > > > > > from 3 seconds to 27 seconds on my laptop with LTO, which is > > > > > > > > > intolerable. > > > > > > > > > > > > > > > > Yeah, I noticed it's visible on my laptop, but not at all on my > > > > > > > > desktop > > > > > > > > (i7 vs Ryzen 7). > > > > > > > > > > > > > > > > > The EXTRA_CFLAGS says it is for 'Backward compatibility' and > > > > > > > > > it still > > > > > > > > > does the various LTO things (i.e. it changes the build > > > > > > > > > logic). It > > > > > > > > > > > > > > > > We're unlikely to move to newer Linux kernel kbuild logic so > > > > > > > > this isn't > > > > > > > > going away, and there's not much in the way of logic that's > > > > > > > > changed for > > > > > > > > LTO that I see. > > > > > > > > > > > > > > > > > seems odd to me to enable the option and then disable it > > > > > > > > > later in the > > > > > > > > > command line. It is therefore not quite equivalent. But it > > > > > > > > > seems to > > > > > > > > > work well enough for me fom a small amount of testing. If you > > > > > > > > > are > > > > > > > > > really set on not having a special option for it, I can live > > > > > > > > > with it > > > > > > > > > for now. I'm also not convinced that my patch entirely > > > > > > > > > removes the LTO > > > > > > > > > stuff in a consistent way. > > > > > > > > > > > > > > > > Yeah, I really don't want to go down the path of overriding > > > > > > > > CONFIG > > > > > > > > options via make/environment logic. I'm also open to turning > > > > > > > > off LTO on > > > > > > > > sandbox and on with qemu-* so it gets wider CI testing. > > > > > > > > > > > > > > Yes you did mention that, but the problem is that LTO is very > > > > > > > handy > > > > > > > with sandbox, to test the strange things that happen. For > > > > > > > example, I > > > > > > > found the bug where LTO was dropping a linker-list item, using > > > > > > > sandbox. We could perhaps make one of the sandbox builds not use > > > > > > > LTO, > > > > > > > e.g. sandbox_flattree ? > > > > > > > > > > > > Well, the big issue with LTO+sandbox is that it slows down your > > > > > > workflow, so I would think you want the inverse, one platform does > > > > > > enable it? > > > > > > > > > > It slows down all boards that use it, actually, so I normally don't > > > > > want it enabled for my IDE. This is not sandbox-specific. > > > > > > > > The degree of slowdown depends on what
Re: [PATCH v2 02/13] Makefile: Allow LTO to be disabled for a build
Hi Tom, On Mon, 14 Mar 2022 at 14:23, Tom Rini wrote: > > On Mon, Mar 14, 2022 at 02:18:14PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Mon, 14 Mar 2022 at 13:45, Tom Rini wrote: > > > > > > On Mon, Mar 14, 2022 at 01:21:02PM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Mon, 14 Mar 2022 at 12:29, Tom Rini wrote: > > > > > > > > > > On Mon, Mar 14, 2022 at 12:24:42PM -0600, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Mon, 14 Mar 2022 at 06:49, Tom Rini wrote: > > > > > > > > > > > > > > On Sat, Mar 12, 2022 at 10:58:44AM -0700, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > On Mon, 7 Mar 2022 at 07:33, Tom Rini > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Fri, Mar 04, 2022 at 08:42:57AM -0700, 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 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 > > > > > > > > > > machine, but 6.7 > > > > > > > > > > seconds with LTO enabled. > > > > > > > > > > > > > > > > > > > > Add a LTO_BUILD=n 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 > > > > > > > > > > > > > > > > > > We don't need this since you can do: > > > > > > > > > make EXTRA_CFLAGS="-fno-lto" EXTRA_LDFLAGS="-fno-lto" > > > > > > > > > to pass -fno-lto to compile/linking and disable lto and per > > > > > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905 this has > > > > > > > > > been working > > > > > > > > > for some time. > > > > > > > > > > > > > > > > Thanks for that, it is a big pain point for me, picking up this > > > > > > > > patch > > > > > > > > for every series I write. The incremental build time for > > > > > > > > sandbox goes > > > > > > > > from 3 seconds to 27 seconds on my laptop with LTO, which is > > > > > > > > intolerable. > > > > > > > > > > > > > > Yeah, I noticed it's visible on my laptop, but not at all on my > > > > > > > desktop > > > > > > > (i7 vs Ryzen 7). > > > > > > > > > > > > > > > The EXTRA_CFLAGS says it is for 'Backward compatibility' and it > > > > > > > > still > > > > > > > > does the various LTO things (i.e. it changes the build logic). > > > > > > > > It > > > > > > > > > > > > > > We're unlikely to move to newer Linux kernel kbuild logic so this > > > > > > > isn't > > > > > > > going away, and there's not much in the way of logic that's > > > > > > > changed for > > > > > > > LTO that I see. > > > > > > > > > > > > > > > seems odd to me to enable the option and then disable it later > > > > > > > > in the > > > > > > > > command line. It is therefore not quite equivalent. But it > > > > > > > > seems to > > > > > > > > work well enough for me fom a small amount of testing. If you > > > > > > > > are > > > > > > > > really set on not having a special option for it, I can live > > > > > > > > with it > > > > > > > > for now. I'm also not convinced that my patch entirely removes > > > > > > > > the LTO > > > > > > > > stuff in a consistent way. > > > > > > > > > > > > > > Yeah, I really don't want to go down the path of overriding CONFIG > > > > > > > options via make/environment logic. I'm also open to turning off > > > > > > > LTO on > > > > > > > sandbox and on with qemu-* so it gets wider CI testing. > > > > > > > > > > > > Yes you did mention that, but the problem is that LTO is very handy > > > > > > with sandbox, to test the strange things that happen. For example, I > > > > > > found the bug where LTO was dropping a linker-list item, using > > > > > > sandbox. We could perhaps make one of the sandbox builds not use > > > > > > LTO, > > > > > > e.g. sandbox_flattree ? > > > > > > > > > > Well, the big issue with LTO+sandbox is that it slows down your > > > > > workflow, so I would think you want the inverse, one platform does > > > > > enable it? > > > > > > > > It slows down all boards that use it, actually, so I normally don't > > > > want it enabled for my IDE. This is not sandbox-specific. > > > > > > The degree of slowdown depends on what you're building on. I see > > > several seconds of link time on my laptop and nothing on my desktop > > > (which isn't that high end either, it's not an EPYC or anything) when > > > LTO is/isn't enabled. > > > > For me, on 16-core AMD desktop, incremental build > > > > LTO: real 0m7.744s > > No LTO: real 0m3.172s > > > > On
Re: [PATCH v2 02/13] Makefile: Allow LTO to be disabled for a build
On Mon, Mar 14, 2022 at 02:18:14PM -0600, Simon Glass wrote: > Hi Tom, > > On Mon, 14 Mar 2022 at 13:45, Tom Rini wrote: > > > > On Mon, Mar 14, 2022 at 01:21:02PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Mon, 14 Mar 2022 at 12:29, Tom Rini wrote: > > > > > > > > On Mon, Mar 14, 2022 at 12:24:42PM -0600, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Mon, 14 Mar 2022 at 06:49, Tom Rini wrote: > > > > > > > > > > > > On Sat, Mar 12, 2022 at 10:58:44AM -0700, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Mon, 7 Mar 2022 at 07:33, Tom Rini wrote: > > > > > > > > > > > > > > > > On Fri, Mar 04, 2022 at 08:42:57AM -0700, 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 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 > > > > > > > > > machine, but 6.7 > > > > > > > > > seconds with LTO enabled. > > > > > > > > > > > > > > > > > > Add a LTO_BUILD=n 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 > > > > > > > > > > > > > > > > We don't need this since you can do: > > > > > > > > make EXTRA_CFLAGS="-fno-lto" EXTRA_LDFLAGS="-fno-lto" > > > > > > > > to pass -fno-lto to compile/linking and disable lto and per > > > > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905 this has > > > > > > > > been working > > > > > > > > for some time. > > > > > > > > > > > > > > Thanks for that, it is a big pain point for me, picking up this > > > > > > > patch > > > > > > > for every series I write. The incremental build time for sandbox > > > > > > > goes > > > > > > > from 3 seconds to 27 seconds on my laptop with LTO, which is > > > > > > > intolerable. > > > > > > > > > > > > Yeah, I noticed it's visible on my laptop, but not at all on my > > > > > > desktop > > > > > > (i7 vs Ryzen 7). > > > > > > > > > > > > > The EXTRA_CFLAGS says it is for 'Backward compatibility' and it > > > > > > > still > > > > > > > does the various LTO things (i.e. it changes the build logic). It > > > > > > > > > > > > We're unlikely to move to newer Linux kernel kbuild logic so this > > > > > > isn't > > > > > > going away, and there's not much in the way of logic that's changed > > > > > > for > > > > > > LTO that I see. > > > > > > > > > > > > > seems odd to me to enable the option and then disable it later in > > > > > > > the > > > > > > > command line. It is therefore not quite equivalent. But it seems > > > > > > > to > > > > > > > work well enough for me fom a small amount of testing. If you are > > > > > > > really set on not having a special option for it, I can live with > > > > > > > it > > > > > > > for now. I'm also not convinced that my patch entirely removes > > > > > > > the LTO > > > > > > > stuff in a consistent way. > > > > > > > > > > > > Yeah, I really don't want to go down the path of overriding CONFIG > > > > > > options via make/environment logic. I'm also open to turning off > > > > > > LTO on > > > > > > sandbox and on with qemu-* so it gets wider CI testing. > > > > > > > > > > Yes you did mention that, but the problem is that LTO is very handy > > > > > with sandbox, to test the strange things that happen. For example, I > > > > > found the bug where LTO was dropping a linker-list item, using > > > > > sandbox. We could perhaps make one of the sandbox builds not use LTO, > > > > > e.g. sandbox_flattree ? > > > > > > > > Well, the big issue with LTO+sandbox is that it slows down your > > > > workflow, so I would think you want the inverse, one platform does > > > > enable it? > > > > > > It slows down all boards that use it, actually, so I normally don't > > > want it enabled for my IDE. This is not sandbox-specific. > > > > The degree of slowdown depends on what you're building on. I see > > several seconds of link time on my laptop and nothing on my desktop > > (which isn't that high end either, it's not an EPYC or anything) when > > LTO is/isn't enabled. > > For me, on 16-core AMD desktop, incremental build > > LTO: real 0m7.744s > No LTO: real 0m3.172s > > On 4-core laptop: > > No LTO: real 0m2.429s > LTO: real 0m15.650s > > Perhaps the disconnect here is that you just don't see any difference? > What times are you seeing? My 16 core desktop is 14 seconds without, 15 seconds with (full build, not just the link time) and I don't recall what my laptop was but since it's longer than the
Re: [PATCH v2 02/13] Makefile: Allow LTO to be disabled for a build
Hi Tom, On Mon, 14 Mar 2022 at 13:45, Tom Rini wrote: > > On Mon, Mar 14, 2022 at 01:21:02PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Mon, 14 Mar 2022 at 12:29, Tom Rini wrote: > > > > > > On Mon, Mar 14, 2022 at 12:24:42PM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Mon, 14 Mar 2022 at 06:49, Tom Rini wrote: > > > > > > > > > > On Sat, Mar 12, 2022 at 10:58:44AM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Mon, 7 Mar 2022 at 07:33, Tom Rini wrote: > > > > > > > > > > > > > > On Fri, Mar 04, 2022 at 08:42:57AM -0700, 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 > > > > > > > > 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 > > > > > > > > machine, but 6.7 > > > > > > > > seconds with LTO enabled. > > > > > > > > > > > > > > > > Add a LTO_BUILD=n 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 > > > > > > > > > > > > > > We don't need this since you can do: > > > > > > > make EXTRA_CFLAGS="-fno-lto" EXTRA_LDFLAGS="-fno-lto" > > > > > > > to pass -fno-lto to compile/linking and disable lto and per > > > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905 this has been > > > > > > > working > > > > > > > for some time. > > > > > > > > > > > > Thanks for that, it is a big pain point for me, picking up this > > > > > > patch > > > > > > for every series I write. The incremental build time for sandbox > > > > > > goes > > > > > > from 3 seconds to 27 seconds on my laptop with LTO, which is > > > > > > intolerable. > > > > > > > > > > Yeah, I noticed it's visible on my laptop, but not at all on my > > > > > desktop > > > > > (i7 vs Ryzen 7). > > > > > > > > > > > The EXTRA_CFLAGS says it is for 'Backward compatibility' and it > > > > > > still > > > > > > does the various LTO things (i.e. it changes the build logic). It > > > > > > > > > > We're unlikely to move to newer Linux kernel kbuild logic so this > > > > > isn't > > > > > going away, and there's not much in the way of logic that's changed > > > > > for > > > > > LTO that I see. > > > > > > > > > > > seems odd to me to enable the option and then disable it later in > > > > > > the > > > > > > command line. It is therefore not quite equivalent. But it seems to > > > > > > work well enough for me fom a small amount of testing. If you are > > > > > > really set on not having a special option for it, I can live with it > > > > > > for now. I'm also not convinced that my patch entirely removes the > > > > > > LTO > > > > > > stuff in a consistent way. > > > > > > > > > > Yeah, I really don't want to go down the path of overriding CONFIG > > > > > options via make/environment logic. I'm also open to turning off LTO > > > > > on > > > > > sandbox and on with qemu-* so it gets wider CI testing. > > > > > > > > Yes you did mention that, but the problem is that LTO is very handy > > > > with sandbox, to test the strange things that happen. For example, I > > > > found the bug where LTO was dropping a linker-list item, using > > > > sandbox. We could perhaps make one of the sandbox builds not use LTO, > > > > e.g. sandbox_flattree ? > > > > > > Well, the big issue with LTO+sandbox is that it slows down your > > > workflow, so I would think you want the inverse, one platform does > > > enable it? > > > > It slows down all boards that use it, actually, so I normally don't > > want it enabled for my IDE. This is not sandbox-specific. > > The degree of slowdown depends on what you're building on. I see > several seconds of link time on my laptop and nothing on my desktop > (which isn't that high end either, it's not an EPYC or anything) when > LTO is/isn't enabled. For me, on 16-core AMD desktop, incremental build LTO: real 0m7.744s No LTO: real 0m3.172s On 4-core laptop: No LTO: real 0m2.429s LTO: real 0m15.650s Perhaps the disconnect here is that you just don't see any difference? What times are you seeing? Regards, SImon
Re: [PATCH v2 02/13] Makefile: Allow LTO to be disabled for a build
On Mon, Mar 14, 2022 at 01:21:02PM -0600, Simon Glass wrote: > Hi Tom, > > On Mon, 14 Mar 2022 at 12:29, Tom Rini wrote: > > > > On Mon, Mar 14, 2022 at 12:24:42PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Mon, 14 Mar 2022 at 06:49, Tom Rini wrote: > > > > > > > > On Sat, Mar 12, 2022 at 10:58:44AM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Mon, 7 Mar 2022 at 07:33, Tom Rini wrote: > > > > > > > > > > > > On Fri, Mar 04, 2022 at 08:42:57AM -0700, 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 > > > > > > > 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 machine, > > > > > > > but 6.7 > > > > > > > seconds with LTO enabled. > > > > > > > > > > > > > > Add a LTO_BUILD=n 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 > > > > > > > > > > > > We don't need this since you can do: > > > > > > make EXTRA_CFLAGS="-fno-lto" EXTRA_LDFLAGS="-fno-lto" > > > > > > to pass -fno-lto to compile/linking and disable lto and per > > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905 this has been > > > > > > working > > > > > > for some time. > > > > > > > > > > Thanks for that, it is a big pain point for me, picking up this patch > > > > > for every series I write. The incremental build time for sandbox goes > > > > > from 3 seconds to 27 seconds on my laptop with LTO, which is > > > > > intolerable. > > > > > > > > Yeah, I noticed it's visible on my laptop, but not at all on my desktop > > > > (i7 vs Ryzen 7). > > > > > > > > > The EXTRA_CFLAGS says it is for 'Backward compatibility' and it still > > > > > does the various LTO things (i.e. it changes the build logic). It > > > > > > > > We're unlikely to move to newer Linux kernel kbuild logic so this isn't > > > > going away, and there's not much in the way of logic that's changed for > > > > LTO that I see. > > > > > > > > > seems odd to me to enable the option and then disable it later in the > > > > > command line. It is therefore not quite equivalent. But it seems to > > > > > work well enough for me fom a small amount of testing. If you are > > > > > really set on not having a special option for it, I can live with it > > > > > for now. I'm also not convinced that my patch entirely removes the LTO > > > > > stuff in a consistent way. > > > > > > > > Yeah, I really don't want to go down the path of overriding CONFIG > > > > options via make/environment logic. I'm also open to turning off LTO on > > > > sandbox and on with qemu-* so it gets wider CI testing. > > > > > > Yes you did mention that, but the problem is that LTO is very handy > > > with sandbox, to test the strange things that happen. For example, I > > > found the bug where LTO was dropping a linker-list item, using > > > sandbox. We could perhaps make one of the sandbox builds not use LTO, > > > e.g. sandbox_flattree ? > > > > Well, the big issue with LTO+sandbox is that it slows down your > > workflow, so I would think you want the inverse, one platform does > > enable it? > > It slows down all boards that use it, actually, so I normally don't > want it enabled for my IDE. This is not sandbox-specific. The degree of slowdown depends on what you're building on. I see several seconds of link time on my laptop and nothing on my desktop (which isn't that high end either, it's not an EPYC or anything) when LTO is/isn't enabled. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 02/13] Makefile: Allow LTO to be disabled for a build
Hi Tom, On Mon, 14 Mar 2022 at 12:29, Tom Rini wrote: > > On Mon, Mar 14, 2022 at 12:24:42PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Mon, 14 Mar 2022 at 06:49, Tom Rini wrote: > > > > > > On Sat, Mar 12, 2022 at 10:58:44AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Mon, 7 Mar 2022 at 07:33, Tom Rini wrote: > > > > > > > > > > On Fri, Mar 04, 2022 at 08:42:57AM -0700, 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 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 machine, > > > > > > but 6.7 > > > > > > seconds with LTO enabled. > > > > > > > > > > > > Add a LTO_BUILD=n 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 > > > > > > > > > > We don't need this since you can do: > > > > > make EXTRA_CFLAGS="-fno-lto" EXTRA_LDFLAGS="-fno-lto" > > > > > to pass -fno-lto to compile/linking and disable lto and per > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905 this has been > > > > > working > > > > > for some time. > > > > > > > > Thanks for that, it is a big pain point for me, picking up this patch > > > > for every series I write. The incremental build time for sandbox goes > > > > from 3 seconds to 27 seconds on my laptop with LTO, which is > > > > intolerable. > > > > > > Yeah, I noticed it's visible on my laptop, but not at all on my desktop > > > (i7 vs Ryzen 7). > > > > > > > The EXTRA_CFLAGS says it is for 'Backward compatibility' and it still > > > > does the various LTO things (i.e. it changes the build logic). It > > > > > > We're unlikely to move to newer Linux kernel kbuild logic so this isn't > > > going away, and there's not much in the way of logic that's changed for > > > LTO that I see. > > > > > > > seems odd to me to enable the option and then disable it later in the > > > > command line. It is therefore not quite equivalent. But it seems to > > > > work well enough for me fom a small amount of testing. If you are > > > > really set on not having a special option for it, I can live with it > > > > for now. I'm also not convinced that my patch entirely removes the LTO > > > > stuff in a consistent way. > > > > > > Yeah, I really don't want to go down the path of overriding CONFIG > > > options via make/environment logic. I'm also open to turning off LTO on > > > sandbox and on with qemu-* so it gets wider CI testing. > > > > Yes you did mention that, but the problem is that LTO is very handy > > with sandbox, to test the strange things that happen. For example, I > > found the bug where LTO was dropping a linker-list item, using > > sandbox. We could perhaps make one of the sandbox builds not use LTO, > > e.g. sandbox_flattree ? > > Well, the big issue with LTO+sandbox is that it slows down your > workflow, so I would think you want the inverse, one platform does > enable it? It slows down all boards that use it, actually, so I normally don't want it enabled for my IDE. This is not sandbox-specific. Regards, Simon
Re: [PATCH v2 02/13] Makefile: Allow LTO to be disabled for a build
On Mon, Mar 14, 2022 at 12:24:42PM -0600, Simon Glass wrote: > Hi Tom, > > On Mon, 14 Mar 2022 at 06:49, Tom Rini wrote: > > > > On Sat, Mar 12, 2022 at 10:58:44AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Mon, 7 Mar 2022 at 07:33, Tom Rini wrote: > > > > > > > > On Fri, Mar 04, 2022 at 08:42:57AM -0700, 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 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 machine, but > > > > > 6.7 > > > > > seconds with LTO enabled. > > > > > > > > > > Add a LTO_BUILD=n 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 > > > > > > > > We don't need this since you can do: > > > > make EXTRA_CFLAGS="-fno-lto" EXTRA_LDFLAGS="-fno-lto" > > > > to pass -fno-lto to compile/linking and disable lto and per > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905 this has been working > > > > for some time. > > > > > > Thanks for that, it is a big pain point for me, picking up this patch > > > for every series I write. The incremental build time for sandbox goes > > > from 3 seconds to 27 seconds on my laptop with LTO, which is > > > intolerable. > > > > Yeah, I noticed it's visible on my laptop, but not at all on my desktop > > (i7 vs Ryzen 7). > > > > > The EXTRA_CFLAGS says it is for 'Backward compatibility' and it still > > > does the various LTO things (i.e. it changes the build logic). It > > > > We're unlikely to move to newer Linux kernel kbuild logic so this isn't > > going away, and there's not much in the way of logic that's changed for > > LTO that I see. > > > > > seems odd to me to enable the option and then disable it later in the > > > command line. It is therefore not quite equivalent. But it seems to > > > work well enough for me fom a small amount of testing. If you are > > > really set on not having a special option for it, I can live with it > > > for now. I'm also not convinced that my patch entirely removes the LTO > > > stuff in a consistent way. > > > > Yeah, I really don't want to go down the path of overriding CONFIG > > options via make/environment logic. I'm also open to turning off LTO on > > sandbox and on with qemu-* so it gets wider CI testing. > > Yes you did mention that, but the problem is that LTO is very handy > with sandbox, to test the strange things that happen. For example, I > found the bug where LTO was dropping a linker-list item, using > sandbox. We could perhaps make one of the sandbox builds not use LTO, > e.g. sandbox_flattree ? Well, the big issue with LTO+sandbox is that it slows down your workflow, so I would think you want the inverse, one platform does enable it? -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 02/13] Makefile: Allow LTO to be disabled for a build
Hi Tom, On Mon, 14 Mar 2022 at 06:49, Tom Rini wrote: > > On Sat, Mar 12, 2022 at 10:58:44AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Mon, 7 Mar 2022 at 07:33, Tom Rini wrote: > > > > > > On Fri, Mar 04, 2022 at 08:42:57AM -0700, 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 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 machine, but 6.7 > > > > seconds with LTO enabled. > > > > > > > > Add a LTO_BUILD=n 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 > > > > > > We don't need this since you can do: > > > make EXTRA_CFLAGS="-fno-lto" EXTRA_LDFLAGS="-fno-lto" > > > to pass -fno-lto to compile/linking and disable lto and per > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905 this has been working > > > for some time. > > > > Thanks for that, it is a big pain point for me, picking up this patch > > for every series I write. The incremental build time for sandbox goes > > from 3 seconds to 27 seconds on my laptop with LTO, which is > > intolerable. > > Yeah, I noticed it's visible on my laptop, but not at all on my desktop > (i7 vs Ryzen 7). > > > The EXTRA_CFLAGS says it is for 'Backward compatibility' and it still > > does the various LTO things (i.e. it changes the build logic). It > > We're unlikely to move to newer Linux kernel kbuild logic so this isn't > going away, and there's not much in the way of logic that's changed for > LTO that I see. > > > seems odd to me to enable the option and then disable it later in the > > command line. It is therefore not quite equivalent. But it seems to > > work well enough for me fom a small amount of testing. If you are > > really set on not having a special option for it, I can live with it > > for now. I'm also not convinced that my patch entirely removes the LTO > > stuff in a consistent way. > > Yeah, I really don't want to go down the path of overriding CONFIG > options via make/environment logic. I'm also open to turning off LTO on > sandbox and on with qemu-* so it gets wider CI testing. Yes you did mention that, but the problem is that LTO is very handy with sandbox, to test the strange things that happen. For example, I found the bug where LTO was dropping a linker-list item, using sandbox. We could perhaps make one of the sandbox builds not use LTO, e.g. sandbox_flattree ? Regards, Simon
Re: [PATCH v2 02/13] Makefile: Allow LTO to be disabled for a build
On Sat, Mar 12, 2022 at 10:58:44AM -0700, Simon Glass wrote: > Hi Tom, > > On Mon, 7 Mar 2022 at 07:33, Tom Rini wrote: > > > > On Fri, Mar 04, 2022 at 08:42:57AM -0700, 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 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 machine, but 6.7 > > > seconds with LTO enabled. > > > > > > Add a LTO_BUILD=n 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 > > > > We don't need this since you can do: > > make EXTRA_CFLAGS="-fno-lto" EXTRA_LDFLAGS="-fno-lto" > > to pass -fno-lto to compile/linking and disable lto and per > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905 this has been working > > for some time. > > Thanks for that, it is a big pain point for me, picking up this patch > for every series I write. The incremental build time for sandbox goes > from 3 seconds to 27 seconds on my laptop with LTO, which is > intolerable. Yeah, I noticed it's visible on my laptop, but not at all on my desktop (i7 vs Ryzen 7). > The EXTRA_CFLAGS says it is for 'Backward compatibility' and it still > does the various LTO things (i.e. it changes the build logic). It We're unlikely to move to newer Linux kernel kbuild logic so this isn't going away, and there's not much in the way of logic that's changed for LTO that I see. > seems odd to me to enable the option and then disable it later in the > command line. It is therefore not quite equivalent. But it seems to > work well enough for me fom a small amount of testing. If you are > really set on not having a special option for it, I can live with it > for now. I'm also not convinced that my patch entirely removes the LTO > stuff in a consistent way. Yeah, I really don't want to go down the path of overriding CONFIG options via make/environment logic. I'm also open to turning off LTO on sandbox and on with qemu-* so it gets wider CI testing. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 02/13] Makefile: Allow LTO to be disabled for a build
Hi Tom, On Mon, 7 Mar 2022 at 07:33, Tom Rini wrote: > > On Fri, Mar 04, 2022 at 08:42:57AM -0700, 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 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 machine, but 6.7 > > seconds with LTO enabled. > > > > Add a LTO_BUILD=n 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 > > We don't need this since you can do: > make EXTRA_CFLAGS="-fno-lto" EXTRA_LDFLAGS="-fno-lto" > to pass -fno-lto to compile/linking and disable lto and per > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905 this has been working > for some time. Thanks for that, it is a big pain point for me, picking up this patch for every series I write. The incremental build time for sandbox goes from 3 seconds to 27 seconds on my laptop with LTO, which is intolerable. The EXTRA_CFLAGS says it is for 'Backward compatibility' and it still does the various LTO things (i.e. it changes the build logic). It seems odd to me to enable the option and then disable it later in the command line. It is therefore not quite equivalent. But it seems to work well enough for me fom a small amount of testing. If you are really set on not having a special option for it, I can live with it for now. I'm also not convinced that my patch entirely removes the LTO stuff in a consistent way. > Not that you need to respin the series for this. Regards, Simon
Re: [PATCH v2 02/13] Makefile: Allow LTO to be disabled for a build
On Fri, Mar 04, 2022 at 08:42:57AM -0700, 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 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 machine, but 6.7 > seconds with LTO enabled. > > Add a LTO_BUILD=n 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 We don't need this since you can do: make EXTRA_CFLAGS="-fno-lto" EXTRA_LDFLAGS="-fno-lto" to pass -fno-lto to compile/linking and disable lto and per https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905 this has been working for some time. Not that you need to respin the series for this. -- Tom signature.asc Description: PGP signature
[PATCH v2 02/13] Makefile: Allow LTO to be disabled for a build
LTO (Link-Time Optimisation) is an very useful feature which can
significantly reduce the size of U-Boot binaries. So far it has 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 machine, but 6.7
seconds with LTO enabled.
Add a LTO_BUILD=n 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 9ef34ca4b7..716f5e1a08 100644
--- a/Makefile
+++ b/Makefile
@@ -434,6 +434,9 @@ KBUILD_CFLAGS += -fshort-wchar -fno-strict-aliasing
KBUILD_AFLAGS := -D__ASSEMBLY__
KBUILD_LDFLAGS :=
+# Set this to "n" use of LTO for this build, e.g. LTO_BUILD=n
+LTO_BUILD ?= y
+
ifeq ($(cc-name),clang)
ifneq ($(CROSS_COMPILE),)
CLANG_TARGET := --target=$(notdir $(CROSS_COMPILE:%-=%))
@@ -643,6 +646,11 @@ export CFLAGS_EFI # Compiler flags to add when building
EFI app
export CFLAGS_NON_EFI # Compiler flags to remove when building EFI app
export EFI_TARGET # binutils target if EFI is natively supported
+export LTO_ENABLE
+
+# This is y if LTO is enabled for this build
+LTO_ENABLE=$(if $(CONFIG_LTO),$(LTO_BUILD),)
+
# If board code explicitly specified LDSCRIPT or CONFIG_SYS_LDSCRIPT, use
# that (or fail if absent). Otherwise, search for a linker script in a
# standard location.
@@ -690,16 +698,16 @@ endif
LTO_CFLAGS :=
LTO_FINAL_LDFLAGS :=
export LTO_CFLAGS LTO_FINAL_LDFLAGS
-ifdef CONFIG_LTO
+ifeq ($(LTO_ENABLE),y)
ifeq ($(cc-name),clang)
- LTO_CFLAGS += -flto
+ LTO_CFLAGS += -DLTO_ENABLE -flto
LTO_FINAL_LDFLAGS += -flto
AR = $(shell $(CC)
-print-prog-name=llvm-ar)
NM = $(shell $(CC)
-print-prog-name=llvm-nm)
else
NPROC := $(shell nproc 2>/dev/null || echo 1)
- LTO_CFLAGS += -flto=$(NPROC)
+ LTO_CFLAGS += -DLTO_ENABLE -flto=$(NPROC)
LTO_FINAL_LDFLAGS += -fuse-linker-plugin -flto=$(NPROC)
# use plugin aware tools
@@ -1740,7 +1748,7 @@ ARCH_POSTLINK := $(wildcard
$(srctree)/arch/$(ARCH)/Makefile.postlink)
# Generate linker list symbols references to force compiler to not optimize
# them away when compiling with LTO
-ifdef CONFIG_LTO
+ifeq ($(LTO_ENABLE),y)
u-boot-keep-syms-lto := keep-syms-lto.o
u-boot-keep-syms-lto_c := $(patsubst %.o,%.c,$(u-boot-keep-syms-lto))
@@ -1762,7 +1770,7 @@ endif
# Rule to link u-boot
# May be overridden by arch/$(ARCH)/config.mk
-ifdef CONFIG_LTO
+ifeq ($(LTO_ENABLE),y)
quiet_cmd_u-boot__ ?= LTO $@
cmd_u-boot__ ?=
\
$(CC) -nostdlib -nostartfiles
\
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index b107b1af27..065dbec406 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -15,11 +15,11 @@ CFLAGS_NON_EFI := -fno-pic -ffixed-r9 -ffunction-sections
-fdata-sections \
-fstack-protector-strong
CFLAGS_EFI := -fpic -fshort-wchar
-ifneq ($(CONFIG_LTO)$(CONFIG_USE_PRIVATE_LIBGCC),yy)
+ifneq ($(LTO_ENABLE)$(CONFIG_USE_PRIVATE_LIBGCC),yy)
LDFLAGS_FINAL += --gc-sections
endif
-ifndef CONFIG_LTO
+ifneq ($(LTO_ENABLE),y)
PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections
endif
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index 085e12b5d4..b255b195aa 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -98,7 +98,7 @@ struct arch_global_data {
#include
-#if defined(__clang__) || defined(CONFIG_LTO)
+#if defined(__clang__) || defined(LTO_ENABLE)
#define DECLARE_GLOBAL_DATA_PTR
#define gd get_gd()
diff --git a/doc/build/gcc.rst b/doc/build/gcc.rst
index b883cf73ee..08c74c4d7b 100644
--- a/doc/build/gcc.rst
+++ b/doc/build/gcc.rst
@@ -151,6 +151,23 @@ of dtc is new enough. It also makes sure that pylibfdt is
present, if needed
Note that the :doc:`tools` are always built with the included version of libfdt
so it is not possible to build U-Boot tools with a system libfdt, at present.
+Link-time optimisation (LTO)
+
+
+U-Boot supports link-time optimisation which can reduce the size of the final
+U-Boot binaries, particularly with SPL.
+
+At present this can be enabled by ARM boards by adding `CONFIG_LTO=y`
