[U-Boot] [PATCH] initcall: Move to inline function
Alexander Graf
agraf at suse.de
Sun Feb 10 13:48:32 UTC 2019
> 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? :)
Alex
>
> --
> Tom
More information about the U-Boot
mailing list