[RFC PATCH u-boot 00/12] U-Boot LTO (Sandbox + ARM Nokia RX-51)

[Tom Rini]

On Sat, Mar 06, 2021 at 06:37:49PM +0100, Marek Behun wrote:
> On Sat, 6 Mar 2021 05:12:12 -0600
> Adam Ford <aford173 at gmail.com> wrote:
> 
> > On Fri, Mar 5, 2021 at 9:03 PM Adam Ford <aford173 at gmail.com> wrote:
> > >
> > > On Fri, Mar 5, 2021 at 11:10 AM Adam Ford <aford173 at gmail.com> wrote:  
> > > >
> > > > On Fri, Mar 5, 2021 at 6:31 AM Stefan Roese <sr at denx.de> wrote:  
> > > > >
> > > > > On 05.03.21 12:25, Adam Ford wrote:  
> > > > > > On Thu, Mar 4, 2021 at 4:33 PM Marek Behun <marek.behun at nic.cz> wrote:  
> > > > > >>
> > > > > >> On Thu, 4 Mar 2021 16:18:03 -0600
> > > > > >> Adam Ford <aford173 at gmail.com> wrote:
> > > > > >>  
> > > > > >>> diff --git a/arch/arm/mach-omap2/omap3/Makefile
> > > > > >>> b/arch/arm/mach-omap2/omap3/Makefile
> > > > > >>> index 91ed8ebc9f..a2cc21c6d2 100644
> > > > > >>> --- a/arch/arm/mach-omap2/omap3/Makefile
> > > > > >>> +++ b/arch/arm/mach-omap2/omap3/Makefile
> > > > > >>> @@ -6,6 +6,8 @@
> > > > > >>>   # If clock.c is compiled for Thumb2, then it fails on OMAP3530
> > > > > >>>   CFLAGS_clock.o += -marm
> > > > > >>>
> > > > > >>> +CFLAGS_REMOVE_file.o := $(LTO_CFLAGS)  
> > > > > >>
> > > > > >> Eh? There is no file.c in arch/arm/mach-omap2/omap3/ directory.  
> > > > > >
> > > > > > It must be from something else that had changed when I did a git pull
> > > > > > pull on your repo. I guess that's better news.  
> > > > >
> > > > > It might be a misunderstanding. Marek means that you need to replace
> > > > > "file" with your real filename, like:
> > > > >
> > > > > driver_spi.c ->
> > > > >
> > > > > +CFLAGS_REMOVE_driver_spi.o := $(LTO_CFLAGS)  
> > > >
> > > > I first did a git pull from his git repo, and then blindly copy-pasted
> > > > the suggested link to that above directly.  I don't play with
> > > > Makefiles often, so I didn't really notice that I needed to match the
> > > > line to an actual file.  When I rebuilt, my initial issue with showing
> > > > too much DDR and hanging went away, so I wrongly assumed that this
> > > > fixed it.  In reality, I think it was a patch that had been applied to
> > > > his git repo that got pulled in at the same time.
> > > >
> > > > On the testing front,
> > > > I started testing the da850evm (ARM9) this morning.  I ran into an
> > > > issue that I apparently caused some time ago, and I'm trying to
> > > > resolve that now.  I have it working, but I need to clean it up.  I'll
> > > > push the clean-up to the ML then try the LTO on that board to see if
> > > > U-Boot and/or SPL work with LTO enabled.
> > > >
> > > > As of now, I have one board that seems to fully boot (imx6q_logic) and
> > > > a family of boards that work in U-Boot but not SPL (omap3_logic).
> > > >
> > > > After the da850em, I'll test a 64-bit Renesas board without SPL and a
> > > > 64-bit NXP board with SPL to test.
> > > >
> > > > On the build-testing I have done, I am seeing an average of a 10-20%
> > > > reduction in size for SPL, and a ~ 3% reduction in size in U-Boot.
> > > >  
> > >
> > > With a patch that I've already sent to the mailing list for the
> > > da850evm, it's booting both SPL and U-Boot
> > >
> > > With the compiler I have, the code went from:
> > > SPL        24305
> > > U-Boot  381930
> > >
> > > To:
> > > SPL        20937
> > > U-Boot  358780
> > >
> > > For a Reduction of:
> > > SPL    -3368 (-13.86%)
> > > U-Boot -23150 (-6.06%)
> > >
> > > I didn't test the NOR or NAND booting versions of the da850evm, but I
> > > will try to do that when the time comes.
> > >  
> > 
> > I ran the same tests on the imx8mn_beacon board, and this board boots.
> > 
> > Without LTO
> > SPL         82487
> > U-Boot  704477
> > 
> > With LTO:
> > SPL         74526
> > U-Boot   670859
> > 
> > For a reduction of:
> > SPL         -7961 (-9.65%)
> > U-Boot  -33618 (-4.77%)
> 
> Thank you Adam for these tests.
> I think you are right in that we should not enable LTO for all ARM
> boards, but only those that are tested, at least until for example
> about 80% of them are tested.

Perhaps we'll default to yes on some SoCs.  The omap3 thing is a bit
odd, but we'll see what happens on real N900 hardware.  I'm gonna be
pretty confident that the LTO-related issues are in the SoC-specific
areas and probably related to some assumptions or another about where
code gets located within the resulting binary.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210306/34a59ea3/attachment.sig>