<div dir="ltr"><div class="gmail_extra">On Mon, Feb 27, 2017 at 9:17 AM, Rafael Avila de Espindola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> writes:<br>
<br>
> On Sun, Feb 26, 2017 at 5:14 PM, Rafael Avila de Espindola <<br>
> <a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br>
><br>
>> Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> writes:<br>
>><br>
>> > We can define this as -icf=everything or something (as opposed to the<br>
>> > current -icf=all), but do you want that now?<br>
>><br>
>> No, it doesn't have to be now.<br>
>><br>
>> Thinking a bit more about it it is not even clear if we should have<br>
>> it. The logic in ICF is not that different and once we have a way of<br>
>> representing unnamed_addr in ELF, --icf=all will just mean icf<br>
>> executable sections even if they are not know to be safe.<br>
>><br>
><br>
> Can you elaborate a bit on why you want to propagate unnamed_addr and how<br>
> you use that in the linker?<br>
<br>
</div></div>The idea is that by default symbol addresses are significant. By some<br>
way (flag, metadata section), a symbol can be marked as having non<br>
significant address.<br>
<br>
If a section has no address-significant symbol, it can be merged.<br>
<br>
That could be also used to hide linkonce_odr symbols like we do in lto,<br>
but in a regular link.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></div>