From: Rafaël Carré <funman_at_videolan.org>
Date: Sun, 4 Dec 2011 23:48:34 -0500

Le Sun, 04 Dec 2011 23:01:34 -0500,
Boris Gjenero <boris.gjenero_at_gmail.com> a écrit :

> On 04/12/11 06:23 PM, Rafaël Carré wrote:
> > flto at least failed to work when mixing thumb and arm code (i think
> > the last version i tried was gcc 4.6.1)
>
> I didn't spend much time on arm -flto, because I was mainly interested
> in getting smaller Archos binaries. I didn't even get a working 5G iPod
> binary with binutils 2.21.1 and the normal compiler. It seems like the
> majority of binutils-2.20.1-ld-thumb-interwork-long-call.diff is in
> 2.21.1, but it's not an exact match. I wonder if that is the problem.

When I backported that patch I understood that all what was required was in their trunk

Anyway only the Sansa AMSv1 with 2MB of RAM (clipv1, c200v2, m200v4) use thumb (by default)

> I wanted to use the new binutils because the link time optimizer needs
> linker plugin support to access files in archives (like libfirmware.a).
> A compile can succeed without that, but it's not fully link time optimized.
>
> > In the long run it would be nice to use it though, if properly tested
> > (especially wrt codecs speed).
>
> If the best possible codec speed is desired, it might make sense to use
> per-codec optimization options. For example -flto could be used for some
> but not for others. I'm not sure if this could get too messy and
> difficult if different targets need different settings.

Hum that would be nice of course (when we use a more recent gcc), and there is
already a system to finely tune codec flags

> >>> I can see some linker scripts have something like that already:
> >>> KEEP(*(.vectors));// otherwise there are no references to it and the linker strip it
> >>
> >> Yes. For example, the firmware/target/sh/archos/app.lds has it, and so
> >> -Wl,--gc-sections can be used without problems on Archos hwcodec targets.
> >
> > Should we mark all sections as KEEP in all scripts ?
>
> No, just the ones that are necessary but not referenced by other
> sections. That should just be the vectors. They're for use by the CPU,
> and not accessed by anything in Rockbox. I expect putting KEEP
> everywhere would defeat --gc-sections.
>
> BTW. -flto has its own similar problem. When compiling for the Recorder
> V2, gcc 4.6.2 failed to figure out that C code referenced from assembly
> code needed to be kept. In most cases, that's an undefined reference,
> but the interrupt vector table uses .weak to make vectors default to
> their UIE location. All the interrupt handlers got discarded, and every
> interrupt led to UIE(). __attribute__((used)) fixed that.
>
> The other -flto problems had to do with how code gets shuffled. It's not
> possible to assume that C code stays within range of a relative branch,
> and assembler code labels need to have .global because C functions in
> the same file can end up in a different assembler file.

I think C code accessed from asm() can be problematic, if we do that we should
consider the worst case (and make a long call)

> Regards,
>
> Boris

Nice to see you had a long look at this feature, perhaps a wiki page on FLTO
would be helpful to track what's missing and what are the benefits of FLTO

-- 
Rafaël Carré

Received on 2011-12-05