On Thu, Mar 4, 2021 at 7:50 AM Marek Behun <marek.be...@nic.cz> wrote: > > On Thu, 4 Mar 2021 07:46:18 -0600 > Adam Ford <aford...@gmail.com> wrote: > > > On Thu, Mar 4, 2021 at 4:43 AM Marek Behun <marek.be...@nic.cz> wrote: > > > > > > On Wed, 3 Mar 2021 16:36:05 -0500 > > > Tom Rini <tr...@konsulko.com> wrote: > > > > > > > So, as I start testing things locally with two additional changes (1. > > > > LTO by default 2. No ffunction/data-sections with LTO) we see: > > > > https://gist.github.com/trini/350ab850c42293563228b8d68a1bb89a > > > > as the detailed size reduction. This also shows that with LTO we want > > > > to turn off -ffunction-sections/etc as it's not useful now. > > > > > > Tom, I have pushed another version to github PR to trigger CI, and am > > > still working on clang. You can look at the github PR if you want to > > > try yourself. I have also added patch that disables > > > -ffunction-section/fdata-section on arm. > > > > > > After I manage to make it all work in CI I will send v2 to mailing list. > > > > I tested this with the imx6q_logic board. I only tested the U-Boot > > portion, but it appeared to work and it booted the kernel. The U-Boot > > size reduced -7182 bytes (about 3% smaller). > > > > I haven't been able to successfully boot the OMAP3 boards I have yet. > > I'm still looking into this. > > > > I don't think we should enable LTO by default for all boards yet. > > Adam, did you try the current version from github.com/elkablo/u-boot > branch lto ?
Not yet. The SPL issue that I am fighting appears to be a regression in master somewhere between 2020.04-rc1 and the current head. I want to resolve that issue before I get back to re-testing the LTO stuff. I don't really have time to git bisect now, but I'll try to work on it this weekend. This is very exciting to me because of the very limited SPL space in several of my 32-bit ARM boards. From my build-only tests, my SPL sizes are shrinking 10-20% with LTO enabled depending on the board. Thank you for the work you've done. adam
