Messages in this thread | | | From | Ard Biesheuvel <> | Date | Mon, 14 Nov 2022 20:40:50 +0100 | Subject | Re: [PATCH 00/46] gcc-LTO support for the kernel |
| |
On Mon, 14 Nov 2022 at 12:44, Jiri Slaby (SUSE) <jirislaby@kernel.org> wrote: > > Hi, > > this is the first call for comments (and kbuild complaints) for this > support of gcc (full) LTO in the kernel. Most of the patches come from > Andi. Me and Martin rebased them to new kernels and fixed the to-use > known issues. Also I updated most of the commit logs and reordered the > patches to groups of patches with similar intent. > > The very first patch comes from Alexander and is pending on some x86 > queue already (I believe). I am attaching it only for completeness. > Without that, the kernel does not boot (LTO reorders a lot). > > In our measurements, the performance differences are negligible. > > The kernel is bigger with gcc LTO due to more inlining.
OK, so if I understand this correctly: - the performance is the same - the resulting image is bigger - we need a whole lot of ugly hacks to placate the linker.
Pardon my cynicism, but this cover letter does not mention any advantages of LTO, so what is the point of all of this?
(On Clang, LTO was needed for CFI, but this is not even the case anymore)
| |