[PATCH] D17529: ELF: Implement ICF.

Sean Silva via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 23 15:12:50 PST 2016

On Tue, Feb 23, 2016 at 2:32 PM, Rafael EspĂ­ndola <
llvm-commits at lists.llvm.org> wrote:

> > I think the "take the address" part is the crucial hint. Can't you tell
> > from the combination of visibility and relocations what functions are
> > safe to merge? The only tricky part I can imagine is identifying
> > vtables, as they do not classify as pointer leak.
> Somewhat. Gold has that on its list of heuristics, but it is pretty
> nasty. In particular, using files compiled with -fPIC to produce
> regular executables breaks the heuristic.
> Lets focus on the non-safe version for now. When time comes I think
> the correct thing to do is to implement the nop padding as it is
> always safe and then propose adding a flag to ELF to say that a
> particular section/symbol doesn't need an unique address.

Yeah. The compiler already knows the this information. No need for the
linker to bend over backward to try to recover it.

-- Sean Silva

> Cheers,
> Rafael
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160223/e77a26a8/attachment.html>

More information about the llvm-commits mailing list