lkml.org 
[lkml]   [2022]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 18/46] entry, lto: Mark raw_irqentry_exit_cond_resched() as __visible
From

> I still don't understand any of it -- this symbol is not static (and
> thus lives in the global namespace and it's name must not be mangled
> lest it breaks ABI), this symbol has it's address taken, so it must not
> be eliminated.

It's not eliminated, but is still manged because gcc turns it into
static due to

-fwhole-program. Maybe this could avoided in gcc, but at least that's
what it does currently.

I believe disabling -fwhole-program would likely avoid it, but it would
also prevent some code

transformations because gcc would need to assume that every function can
be called by

someone it doesn't see.

> WTF does this crazy LTO thing require __visible on it?
>
> The original Changelog babbles something about multiple object files,
> which doesn't make sense either, there is only a single object file with
> LTO -- that's sort of the whole point. The translation unit output
> becomes some intermediate gunk -- to be used as input for the LTO pass,
> but it is not an ELF object file.
>
> The linker takes all these intermediate files, does the global
> optimization thing and then generates a real ELF object file.

That would be a single threaded very very slow global compilation.
Instead gcc WHOPR uses

partitioning to generate smaller units that can be compiled in parallel
based on their call dependencies,

and these use different object files from the individual assembler
invocations.

>
> Anyway; I think we can drop all this crazy on the floor again, since per
> the 0/n (which I didn't get) there isn't any actual benefit from using
> GCC-LTO, so why should we bother with all this ugly.

At least in the past it generated smaller kernels for small configurations.

One benefit that wasn't mentioned is doing type and other checks (e.g.
constant propagation

through inlining) across files.

In general LTO gives the compiler a lot more freedom to optimize code,
so even if it's not quite there

yet I think it's beneficial to let users play around with it and see if
they can get benefits.



-Andi

\
 
 \ /
  Last update: 2022-11-17 23:09    [W:0.084 / U:0.680 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site