[PATCH] [RFC] arm64: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION
Nicolas Pitre
nico at fluxnic.net
Wed Mar 10 21:19:15 GMT 2021
On Mon, 1 Mar 2021, Nicholas Piggin wrote:
> Excerpts from Arnd Bergmann's message of February 27, 2021 7:49 pm:
> > Unlike what Nick expected in his submission, I now think the annotations
> > will be needed for LTO just like they are for --gc-sections.
>
> Yeah I wasn't sure exactly what LTO looks like or how it would work.
> I thought perhaps LTO might be able to find dead code with circular /
> back references, we could put references from the code back to these
> tables or something so they would be kept without KEEP. I don't know, I
> was handwaving!
>
> I managed to get powerpc (and IIRC x86?) working with gc sections with
> those KEEP annotations, but effectiveness of course is far worse than
> what Nicolas was able to achieve with all his techniques and tricks.
>
> But yes unless there is some other mechanism to handle these tables,
> then KEEP probably has to stay. I suggest this wants a very explicit and
> systematic way to handle it (maybe with some toolchain support) rather
> than trying to just remove things case by case and see what breaks.
>
> I don't know if Nicolas is still been working on his shrinking patches
> recenty but he probably knows more than anyone about this stuff.
Looks like not much has changed since last time I played with this stuff.
There is a way to omit the KEEP() on tables, but something must create a
dependency from the code being pointed to by those tables to the table
entries themselves. I did write my findings in the following article
(just skip over the introductory blurb):
https://lwn.net/Articles/741494/
Once that dependency is there, then the KEEP() may go and
garbage-collecting a function will also garbage-collect the table entry
automatically.
OTOH this trickery is not needed with LTO as garbage collection happens
at the source code optimization level. The KEEP() may remain in that
case as unneeded table entries will simply not be created in the first
place.
Nicolas
More information about the linux-arm-kernel
mailing list