[U-Boot] [PATCH] initcall: Move to inline function

[Tom Rini]

On Sun, Feb 10, 2019 at 02:48:32PM +0100, Alexander Graf wrote:
> 
> 
> > Am 10.02.2019 um 14:16 schrieb Tom Rini <trini at 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 <sjg at chromium.org>:
> >>> 
> >>> Hi Alex,
> >>> 
> >>>> On Sat, 2 Feb 2019 at 09:07, Alexander Graf <agraf at suse.de> wrote:
> >>>> 
> >>>> 
> >>>> 
> >>>>> Am 02.02.2019 um 15:13 schrieb Simon Glass <sjg at chromium.org>:
> >>>>> 
> >>>>> Hi Alex,
> >>>>> 
> >>>>>> On Thu, 31 Jan 2019 at 08:06, Alexander Graf <agraf at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190210/ab535185/attachment.sig>