<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 18, 2016, at 11:16 AM, Peter Collingbourne via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" class="">llvm-commits@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><br class="Apple-interchange-newline"><br class=""><div class="gmail_quote">On Tue, May 17, 2016 at 6:46 PM, Chandler Carruth<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:chandlerc@gmail.com" target="_blank" class="">chandlerc@gmail.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr" class=""><div class="gmail_quote"><div class=""><div class=""><div dir="ltr" class="">On Tue, May 17, 2016 at 6:40 PM Peter Collingbourne via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank" class="">llvm-commits@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Tue, May 17, 2016 at 6:07 PM, Chandler Carruth<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:chandlerc@gmail.com" target="_blank" class="">chandlerc@gmail.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr" class=""><div class="gmail_quote"><div class="">Thanks for the detailed write-up, and sorry to Rafael and Mehdi that it's on a new thread. =/</div><div class=""><div class=""><div class=""><br class=""></div><div dir="ltr" class="">On Tue, May 17, 2016 at 5:59 PM Peter Collingbourne via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank" class="">llvm-commits@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">pcc created this revision.<br class="">pcc added reviewers: rafael, joker.eph, chandlerc, majnemer.<br class="">pcc added a subscriber: llvm-commits.<br class="">Herald added a reviewer: tstellarAMD.<br class="">Herald added subscribers: jfb, mzolotukhin, joker.eph, arsenm.<br class=""><br class="">If a local_unnamed_addr attribute is attached to a global, the address<br class="">is known to be insignificant within the module. It is distinct from the<br class="">existing unnamed_addr attribute in that it only describes a local property<br class="">of the module rather than a global property of the symbol.<br class=""><br class="">This attribute is intended to be used by the code generator and LTO to allow<br class="">the linker to decide whether the global needs to be in the symbol table. It is<br class="">possible to exclude a global from the symbol table if three things are true:<br class="">- This attribute is present on every instance of the global (which means that<br class=""> <span class="Apple-converted-space"> </span>the normal rule that the global must have a unique address can be broken without<br class=""> <span class="Apple-converted-space"> </span>being observable by the program by performing comparisons against the global's<br class=""> <span class="Apple-converted-space"> </span>address)<br class="">- The global has linkonce_odr linkage (which means that each linkage unit must have<br class=""> <span class="Apple-converted-space"> </span>its own copy of the global if it requires one, and the copy in each linkage unit<br class=""> <span class="Apple-converted-space"> </span>must be the same)<br class="">- It is a constant or a function (which means that the program cannot observe that<br class=""> <span class="Apple-converted-space"> </span>the unique-address rule has been broken by writing to the global)<br class=""><br class="">Although this attribute could in principle be computed from the module<br class="">contents, LTO clients (i.e. linkers) will normally need to be able to compute<br class="">this property as part of symbol resolution, and it would be inefficient to<br class="">materialize every module just to compute it.<br class=""></blockquote><div class=""><br class=""></div></div></div><div class="">Cool, this last part is really key.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">My real problem with adding this as a normal attribute is that I'm not sure what it really means. Is it just a "cache" of some local analysis? Do we expect things to invalidate it if they make the address significant within a module? Is this something that would be "blessed" by some frontends?</div><div class=""><br class=""></div><div class="">I feel like, from your description, this really is just intended to solve the problem of materializing all of the module. It would seem that for that purpose something more akin to the "summary" information used by ThinLTO would be a better tool than an attribute which has to have a semantic contract for the IR.</div><div class=""><br class=""></div><div class="">What do you think?</div></div></div></blockquote><div class=""><br class=""></div></div></div></div><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">To a certain extent this is a summary of the module contents, and in most cases I'd expect the property to simply summarize the module.</div><div class=""><br class=""></div><div class="">However, it is also a property that should be preserved if a pass introduces an address comparison. Modulo bugs, the new comparison should be "benign" -- if the original program could not observe the address, the optimized program shouldn't be able to observe it either.</div><div class=""><br class=""></div><div class="">One example of this would be a comparison of a vptr against a vtable or function address for speculative devirtualization, or in general any form of PGO that relies on global addresses. The introduction of such a comparison doesn't invalidate the unnamed_addr property (which we do currently apply to vtables), as the program would still have the same semantics if we, say, merged two identical vtables. The same applies to the local_unnamed_addr property.</div><div class=""><br class=""></div><div class=""> Regarding frontends, yes, I'd expect that if a frontend knows that all address comparisons within a module are benign, it could apply this property.<br class=""></div></div></div></div></blockquote><div class=""><br class=""></div></div></div><div class="">OK, all of this argues that we *can* define this as a semantic attribute, but doesn't really speak to why we *should*.</div></div></div></blockquote></div></div></div></div></blockquote><div><br class=""></div><div><br class=""></div><div>As Peter mentioned above, some transformations can introduce constructs that would prevent from inferring the attribute, which means that when writing out bitcode we won't be able to generate it. Because of that, having it only in the bitcode (like the summary) makes it more "fragile" (round-tripping may be broken).</div><div><br class=""></div><div>It seems to me that if we don't make it first class in the IR, we will still want to have an analysis (or metadata) populated from the summary data that can be used to preverse this "property".</div><div><br class=""></div><div>-- </div><div>Mehdi</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">Adding yet another semantic attribute is a really invasive change, and it feels like there should be a smaller / simpler mechanism to achieve the goals you have here. The whole point of having summary information available it bitcode was to allow LTO-like applications to read a small header to answer specific questions like the one motivating this patch.</div><div class=""><br class=""></div><div class="">I'd like to understand why a summary approach isn't the correct approach here before we extend the IR to represent a new concept, especially one with extremely close overlap and subtle distinctions from an existing concept.</div></div></div></blockquote><div class=""><br class=""></div><div class="">We could make this a summary or an analysis, but that wouldn't really change anything as I see it. Whatever representation we use would need to be:</div><div class="">- stored in the bitcode</div><div class="">- available at LTO and (as Pete pointed out) codegen time</div><div class="">Whether we call this an attribute or a summary, it's basically still the same thing. And in my view at least, I think it would be a little more tricky to store the global property in a separate place to the local property, as they could more easily get out of sync.</div><div class=""><br class=""></div><div class="">Note that we do have plans to store a "summary" for LTO purposes in the bitcode file. That's essentially what Rafael has proposed with<span class="Apple-converted-space"> </span><a href="http://llvm.org/pr27551" class="">llvm.org/pr27551</a><span class="Apple-converted-space"> </span>-- we'd add a symbol table to the bitcode format that stores just the information needed to do symbol resolution against bitcode files. That symbol table would most likely include this property. But that work will take some time, and it doesn't solve the need for the information to be available at codegen time.<br class=""></div><div class=""><br class=""></div><div class="">Thanks,</div></div>--<span class="Apple-converted-space"> </span><br class=""><div class=""><div dir="ltr" class="">-- <div class="">Peter</div></div></div></div></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">llvm-commits mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="mailto:llvm-commits@lists.llvm.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">llvm-commits@lists.llvm.org</a><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a></div></blockquote></div><br class=""></body></html>