[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <289e03d2-be50-4249-343a-75dae302b0e5@linux.intel.com>
Date: Thu, 17 Nov 2022 14:07:23 -0800
From: Andi Kleen <ak@...ux.intel.com>
To: Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>
Cc: "Jiri Slaby (SUSE)" <jirislaby@...nel.org>,
linux-kernel@...r.kernel.org, Andy Lutomirski <luto@...nel.org>,
Martin Liska <mliska@...e.cz>, Jiri Slaby <jslaby@...e.cz>
Subject: Re: [PATCH 18/46] entry, lto: Mark raw_irqentry_exit_cond_resched()
as __visible
> 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
Powered by blists - more mailing lists