On Sun, Feb 10, 2019 at 02:48:32PM +0100, Alexander Graf wrote: > > > > Am 10.02.2019 um 14:16 schrieb Tom Rini <tr...@konsulko.com>: > > > >> On Fri, Feb 08, 2019 at 08:58:18AM +0100, Alexander Graf wrote: > >> > >> > >>> Am 08.02.2019 um 05:11 schrieb Simon Glass <s...@chromium.org>: > >>> > >>> Hi Alex, > >>> > >>>> On Sat, 2 Feb 2019 at 09:07, Alexander Graf <ag...@suse.de> wrote: > >>>> > >>>> > >>>> > >>>>> Am 02.02.2019 um 15:13 schrieb Simon Glass <s...@chromium.org>: > >>>>> > >>>>> Hi Alex, > >>>>> > >>>>>> On Thu, 31 Jan 2019 at 08:06, Alexander Graf <ag...@suse.de> wrote: > >>>>>> > >>>>>> The board_r init function was complaining that we are looping through > >>>>>> an array, calling all our tiny init stubs sequentially via indirect > >>>>>> function calls (which can't be speculated, so they are slow). > >>>>> > >>>>> Is this a compiler warning? Could you let me know what this is? > >>>> > >>>> It's the code comment I'm removing with this patch :). > >>>> > >>>>> > >>>>>> > >>>>>> The solution to that is pretty easy though. All we need to do is inline > >>>>>> the function that loops through the functions and the compiler will > >>>>>> automatically convert almost all indirect calls into direct inlined > >>>>>> code. > >>>>> > >>>>> You mean it calls the functions one after the other without a > >>>>> function-table array? > >>>> > >>>> Exactly. Magical, eh? It even inlines them! > >>> > >>> Yes it is surprising. I am also surprised that it reduces code size, > >>> but I suppose that is why it does it. Presumably the inlining is what > >>> does that. > >> > >> Yes, of course. With separate object files, the compiler can not > >> inline anything at all, because it does not know how the function > >> pointers get used. > >> > >> The alternative to this *might* be LTO, which we could think about as > >> well. It should help reduce indirection and code size overall. But I > >> don't know how well gold works with the linker scripts we have. > > > > I don't object to LTO but there's a LOT of groundwork before it's an > > option. I think in addition to switching to gcc for ld, looking over an > > old git stash from when I tried this last, we need to globally switch to > > the "clang" method of keeping track of gd rather than how we do it > > today. > > Sounds like x86_64 could be an easy target for experimentation then? :)
Could be? I tried ARM for some reason first. -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
