
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></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 12, 2016, at 9:25 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" class="">peter@pcc.me.uk</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"><div class="gmail_quote">On Thu, May 12, 2016 at 8:29 PM, Mehdi Amini<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:mehdi.amini@apple.com" target="_blank" class="">mehdi.amini@apple.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 style="word-wrap: break-word;" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On May 12, 2016, at 6:29 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" target="_blank" class="">peter@pcc.me.uk</a>> wrote:</div><br class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class="">Thanks Rafael.<br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, May 12, 2016 at 4:32 PM, Rafael Espíndola<span class=""> </span><span dir="ltr" class=""><<a href="mailto:rafael.espindola@gmail.com" target="_blank" class="">rafael.espindola@gmail.com</a>></span><span class=""> </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;"><span class="">On 12 May 2016 at 16:13, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" target="_blank" class="">peter@pcc.me.uk</a>> wrote:<br class="">> pcc added a comment.<br class="">><br class="">> I have updated the patch. I just want to make sure that people are happy with the situation around the ThinLTO API. I've been working on an LTO/ThinLTO API that could be used by both the gold plugin and lld which should address Mehdi's concerns, but it will take some time until that's ready.<br class="">><br class=""><br class=""></span>Sorry I dropped out of this thread.<br class=""><br class="">I don't known a lot about ThinLTO, so most comments will be generic about LTO.<br class=""><br class="">The way the existing lib/LTO is implemented is fundamentally different<br class="">from what we do in the gold plugin or lld. We want to make sure we<br class="">don't even read and copy symbols if the linker decided to not keep it.<br class="">The lib/LTO interface is designed to talk about symbols in the merged<br class="">module.<br class=""></blockquote><div class=""><br class=""></div><div class="">Right, I certainly don't want to use any of the existing lib/LTO anywhere we're not using it now. The new API I'm working on deals with symbols in individual modules.</div><div class=""><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;">Having said that, I dislike duplicated code as much as anyone else.<br class="">That is why I really don't want lld calling into Linker::linkModules:<br class="">it duplicates symbol resolution. The same goes for the call to<br class="">addPassesToEmitFile. We really should figure out a single place to<br class="">populate the pipeline.<br class=""><br class="">If it is possible for lld/gold/LTO to share more code, excellent but:<br class=""><br class="">* I would probably not put that in lib/LTO. Lets keep that just for<br class="">the existing api.<br class=""></blockquote><div class=""><br class=""></div><div class="">Putting the new API in some other lib makes sense to me.</div></div></div></div></div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div></span><div class="">Can you elaborate on the rational for that? It does not seem obvious to me (i.e. that's where I'd go for any new API that is dedicated to LTO).</div></div></div></blockquote><div class=""><br class=""></div><div class="">I think the idea is that we'd have one API with a resolution-based interface, and a separate API with a resolution-free interface. We might want to call this new API "LTO" and rename the existing one to something else, to make it clear which one people should try to use. Pick your favourite bikeshed colour.</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 style="word-wrap: break-word;" class=""><div class=""><span class=""><div class=""><br class=""></div><div class=""><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-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div 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;">* It still seems a bit early for this. We still having more basic<br class="">things to finish in lld and the thinLTO api is still moving.<br class=""></blockquote><div class=""><br class=""></div><div class=""><div class="">Regarding the new API, I think there’s a secondary reason why we might want to introduce it sooner rather than later. That reason is that we plan to store symbol resolutions in a combined module index, which basically describes which module contains the prevailing definition of each function. Getting this right is basically a critical correctness issue, as we could otherwise for example import the definition of a weak symbol instead of the prevailing strong symbol. I also understand that Teresa plans to use this information in distributed backends.</div><div class=""><br class=""></div><div class="">One way we could implement this could be to expose gold's symbol resolutions to the ThinLTO importer in some form. The problem with this is that it adds more complexity in a gold-specific layer, when we know that we will eventually need to deal with that in every linker. Or we could implement symbol resolution ourselves in the importer via the linkage info in the summaries, but as I’m sure you are aware, this would be duplicating logic from the linker. That’s why I feel it’s best to have the importer deal with linker-agnostic symbol resolution info.</div><div class=""><br class=""></div><div class="">Getting this right in the gold plugin is basically orthogonal to whether we implement anything in lld. So, the course of action I was considering was</div><div class="">1) Get the new interface in place, and port the gold plugin to it;</div><div class="">2) (in parallel with 1) Polish regular LTO in lld as necessary;</div><div class="">3) Port lld to the new interface.</div></div><div class="">4) (low priority for me, but maybe Mehdi can help) Port libLTO to the new interface.</div></div></div></div></div></blockquote></span></div><br class=""><div class="">It absolutely makes no sense to me to develop a new API in LLVM that refactor gold and lld without taking into account the current ThinLTOCodeGenerator.</div></div></blockquote><div class=""><br class=""></div><div class="">Oh, I certainly agree, which is why the API will permit resolution-free APIs such as *LTOCodeGenerator to be implemented in terms of it. As I mentioned on IRC, this could work by teaching *LTOCodeGenerator to compute symbol resolutions by itself and passing those resolutions to the new interface.</div><div class=""><br class=""></div><div class="">This is an issue of priorities for me. As I mentioned, I haven't made any decisions yet. I understand that libLTO is important for you, but I have no direct interest in it, which by default makes porting that API a low priority for me, but I would agree that porting it would be in the best interests of the project. I can certainly bump the priority if you think you won't be able to help out.</div></div></div></div></div></blockquote><div><br class=""></div><div>I don't have much short-term interest in regular LTO, my main concern is getting ThinLTO (and its API) "right".</div><div>LTO is largely a subset of ThinLTO in term of what needs to be handled, and seems far less involved IMO.</div><div><br class=""></div><div>-- </div><div>Mehdi</div><div><br class=""></div></div></body></html>