[U-Boot] powerpc/nand spl: link libgcc

Recent GCC (4.4+) performs out-of-line epilogues in some cases, when
optimizing for size.  It causes a link error for _restgpr_30_x (and similar)
if libgcc is not linked.

It actually increases size with very small binaries, due to the fixed size
of the out-of-line code, and not having any functions that actually need to
restore more than 2 or 3 registers.  But I don't see a way to turn it off,
other than asking GCC to optimize for speed -- which may also increase
size for some boards.

Signed-off-by: Scott Wood <scottwood@freescale.com>
---
 nand_spl/board/amcc/acadia/Makefile           |    2 +-
 nand_spl/board/amcc/bamboo/Makefile           |    2 +-
 nand_spl/board/amcc/canyonlands/Makefile      |    2 +-
 nand_spl/board/amcc/kilauea/Makefile          |    2 +-
 nand_spl/board/amcc/sequoia/Makefile          |    2 +-
 nand_spl/board/freescale/mpc8313erdb/Makefile |    2 +-
 nand_spl/board/freescale/mpc8315erdb/Makefile |    2 +-
 nand_spl/board/sheldon/simpc8313/Makefile     |    2 +-
 8 files changed, 8 insertions(+), 8 deletions(-)

On Fri, 10 Dec 2010 17:00:51 -0600
Scott Wood <scottwood@freescale.com> wrote:

> Recent GCC (4.4+) performs out-of-line epilogues in some cases, when
> optimizing for size.  It causes a link error for _restgpr_30_x (and similar)
> if libgcc is not linked.
> 
> It actually increases size with very small binaries, due to the fixed size
> of the out-of-line code, and not having any functions that actually need to
> restore more than 2 or 3 registers.  But I don't see a way to turn it off,
> other than asking GCC to optimize for speed -- which may also increase
> size for some boards.
> 
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---

Stefan, can you please pick this up with my:

Acked-by: Kim Phillips <kim.phillips@freescale.com>

Thanks,

Kim

Dear Scott Wood,

In message <20101210230051.GA30739@udp111988uds.am.freescale.net> you wrote:
> Recent GCC (4.4+) performs out-of-line epilogues in some cases, when
> optimizing for size.  It causes a link error for _restgpr_30_x (and similar)
> if libgcc is not linked.
> 
> It actually increases size with very small binaries, due to the fixed size
> of the out-of-line code, and not having any functions that actually need to
> restore more than 2 or 3 registers.  But I don't see a way to turn it off,
> other than asking GCC to optimize for speed -- which may also increase
> size for some boards.
> 
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
>  nand_spl/board/amcc/acadia/Makefile           |    2 +-
>  nand_spl/board/amcc/bamboo/Makefile           |    2 +-
>  nand_spl/board/amcc/canyonlands/Makefile      |    2 +-
>  nand_spl/board/amcc/kilauea/Makefile          |    2 +-
>  nand_spl/board/amcc/sequoia/Makefile          |    2 +-
>  nand_spl/board/freescale/mpc8313erdb/Makefile |    2 +-
>  nand_spl/board/freescale/mpc8315erdb/Makefile |    2 +-
>  nand_spl/board/sheldon/simpc8313/Makefile     |    2 +-
>  8 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/nand_spl/board/amcc/acadia/Makefile b/nand_spl/board/amcc/acadia/Makefile
> index bee24bc..f8ca654 100644
> --- a/nand_spl/board/amcc/acadia/Makefile
> +++ b/nand_spl/board/amcc/acadia/Makefile
> @@ -51,7 +51,7 @@ $(nandobj)u-boot-spl.bin:	$(nandobj)u-boot-spl
>  	$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
>  
>  $(nandobj)u-boot-spl:	$(OBJS) $(nandobj)u-boot.lds
> -	cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) \
> +	cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) $(PLATFORM_LIBS) \
>  		-Map $(nandobj)u-boot-spl.map \
>  		-o $(nandobj)u-boot-spl

Just two questions:

Q1: Are we sure that the observed behaviour is intentional, and not
    eventually unintended behaviour (well, a bug) in the new versions
    of GCC?  In general newer releases are supposed to provide better
    optimization, but with GCC regressions seem to be more common?

Q2: What happens with older compilers, that don't need this?  Is this
    change a No-Op for these?


Best regards,

Wolfgang Denk

On Tue, 14 Dec 2010 00:16:28 +0100
Wolfgang Denk <wd@denx.de> wrote:

> Just two questions:
> 
> Q1: Are we sure that the observed behaviour is intentional, and not
>     eventually unintended behaviour (well, a bug) in the new versions
>     of GCC?  In general newer releases are supposed to provide better
>     optimization, but with GCC regressions seem to be more common?

I'm pretty sure it's intentional (though lacking an option to turn it
off seems ill-advised).  It should reduce code size normally -- it's
just that NAND SPL is too small for the savings to overcome the fixed
cost of the mechanism.  The main U-Boot images do seem to have gotten a
bit smaller with 4.5.

Going from 4.3 (doesn't do this) to 4.5 (does do this), I see SPL size
increases of between 16 and 112 bytes.  None of the boards in this
patch went over 4096 bytes.  Using -O2 instead of -Os, which disables
this "optimization", with 4.5 results in even larger SPLs (with or
without this patch).

> Q2: What happens with older compilers, that don't need this?  Is this
>     change a No-Op for these?

With compilers that don't do this, the symbol references won't be
generated, and no part of libgcc.a will be pulled in.

-Scott

On Tuesday 14 December 2010 00:49:20 Scott Wood wrote:
> > Q2: What happens with older compilers, that don't need this?  Is this
> >     change a No-Op for these?
> 
> With compilers that don't do this, the symbol references won't be
> generated, and no part of libgcc.a will be pulled in.

I tested with ELDK 4.2 (gcc 4.2.2) and see no code size change with this patch 
applied.

Cheers,
Stefan

--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de

On Tuesday 14 December 2010 00:06:11 Kim Phillips wrote:
> On Fri, 10 Dec 2010 17:00:51 -0600
> 
> Scott Wood <scottwood@freescale.com> wrote:
> > Recent GCC (4.4+) performs out-of-line epilogues in some cases, when
> > optimizing for size.  It causes a link error for _restgpr_30_x (and
> > similar) if libgcc is not linked.
> > 
> > It actually increases size with very small binaries, due to the fixed
> > size of the out-of-line code, and not having any functions that actually
> > need to restore more than 2 or 3 registers.  But I don't see a way to
> > turn it off, other than asking GCC to optimize for speed -- which may
> > also increase size for some boards.
> > 
> > Signed-off-by: Scott Wood <scottwood@freescale.com>
> > ---
> 
> Stefan, can you please pick this up with my:
> 
> Acked-by: Kim Phillips <kim.phillips@freescale.com>

I can do this if Wolfgang has no objections. So I'll wait a short while and 
pull it onto next then upstream pushing.

Cheers,
Stefan

--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de

Dear Stefan Roese,

In message <201012140909.27701.sr@denx.de> you wrote:
>
> I can do this if Wolfgang has no objections. So I'll wait a short while and 
> pull it onto next then upstream pushing.

I have no objections:

Acked-by: Wolfgang Denk <wd@denx.de>

Best regards,

Wolfgang Denk