[PATCH] D30365: ELF ICF: Merge only functions.

Rui Ueyama via llvm-commits llvm-commits at lists.llvm.org
Mon Feb 27 10:50:09 PST 2017


On Mon, Feb 27, 2017 at 9:17 AM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:

> Rui Ueyama <ruiu at google.com> writes:
>
> > On Sun, Feb 26, 2017 at 5:14 PM, Rafael Avila de Espindola <
> > rafael.espindola at gmail.com> wrote:
> >
> >> Rui Ueyama <ruiu at google.com> writes:
> >>
> >> > We can define this as -icf=everything or something (as opposed to the
> >> > current -icf=all), but do you want that now?
> >>
> >> No, it doesn't have to be now.
> >>
> >> Thinking a bit more about it it is not even clear if we should have
> >> it. The logic in ICF is not that different and once we have a way of
> >> representing unnamed_addr in ELF, --icf=all will just mean icf
> >> executable sections even if they are not know to be safe.
> >>
> >
> > Can you elaborate a bit on why you want to propagate unnamed_addr and how
> > you use that in the linker?
>
> The idea is that by default symbol addresses are significant. By some
> way (flag, metadata section), a symbol can be marked as having non
> significant address.
>
> If a section has no address-significant symbol, it can be merged.
>
> That could be also used to hide linkonce_odr symbols like we do in lto,
> but in a regular link.
>

In that way, you can mark a symbol as having a significant address only
when the symbol is local to a TU, no? If a symbol is global, other TU may
use its address, so you need to assume conservatively that all globals
addresses are significant.

I'd think that address taken/not-taken is more like an attribute of each
reocation, rather than symbol or section. Currently, relocations to take
addresses are all the same, so linkers cannot know their intentions
(whether it is used as a pointer or not). If we introduce a new set of
relocations to convey that information, we can fix this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170227/97be9961/attachment.html>


More information about the llvm-commits mailing list