<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 Dec 27, 2016, at 7:29 AM, Teresa Johnson <<a href="mailto:tejohnson@google.com" class="">tejohnson@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><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=""><div class="gmail_quote" 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;">On Fri, Dec 23, 2016 at 11:04 AM, 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="gmail-m_-8101089548609833497gmail-"><blockquote type="cite" class=""><div class="">On Dec 23, 2016, at 9:34 AM, Teresa Johnson <<a href="mailto:tejohnson@google.com" target="_blank" class="">tejohnson@google.com</a>> wrote:</div><br class="gmail-m_-8101089548609833497gmail-m_-8411146068639043466Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Dec 22, 2016 at 8:55 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;">Hey,<br class=""><br class="">As I’m playing with Metadata lazy-loading, I added a verifier right before running the IRLinker in FunctionImport.cpp, and it does not pass (on current trunk) in a few cases. One that I looked at ended up with aliases pointing to available_externally functions for instance.<br class=""></blockquote><div class=""><br class=""></div><div class="">How do these look after IRLinking (in the dest module)? I looked at the logic in renameModuleForThinLTO and all the conversions to available_externally are predicated on it being in the provided GlobalsToImport set. But in FunctionImport.cpp selectCallee() we specifically prevent importing of aliases that would result in the aliasee becoming available_externally. Presumably the resulting IRLinked dest module looks legit, otherwise we would have later verifier failures.</div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">So the source module is:</div><div class=""><br class=""></div><div class="">@weakalias = weak alias void (...), bitcast (void ()* @globalfunc1 to void (...)*)<br class="">define void @globalfunc1() #0 {<br class="">entry:<br class=""> <span class="Apple-converted-space"> </span>ret void<br class="">}<br class=""><br class=""></div><div class="">But we turn globalfunc1 into available_externally in renameModuleForThinLTO(), which make the alias invalid.</div><div class=""><br class=""></div><div class="">We don’t import the IR so the destination module is OK.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Presumably we have decided to import globalfunc1 (otherwise renameModuleForThinLTO would not convert its linkage type), but not weakalias (since selectcallee should block it because aliases can't be imported unless the aliasee is linkonceodr). And the dest module is ok because we only import globalfunc1 and not weakalias. In that case, yes, I guess the source module can't be verified after doing renameModuleForThinLTO. Why not just verify before we do renameModuleForThinLTO, and then the dest module again after IR linking? Not sure it is worth verifying between those two points. </div><div class=""><br class=""></div><div class="">Except that as noted in the follow-on emails, type ODRing which kicks in when the source module is loaded, will cause other issues.</div><div class=""><br class=""></div><div class="">Ah, see that you added the verification before renameModuleForThinLTO, then removed it again due to the typeODR issue.</div></div></div></blockquote><div><br class=""></div><div>Right, this was extremely annoying was bringing up the on-demand loading of metadata. Being able to validate the IR after loading is really important in this case.</div><div><br class=""></div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="gmail_quote" 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;"><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="gmail-m_-8101089548609833497gmail-"><blockquote type="cite" class=""><div class=""><div dir="ltr" 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;">I’m hesitant about breaking the IR verifier like that before calling the IRLinker. The alternative I can see now would be:<br class="">- to perform any handling that requires breaking the verifier as part of the IRLinker process,<br class="">- or to perform the verifier-breaking changes that we do as a pre-process step to the IRLinker as a post-process step on the linked module.<br class=""></blockquote><div class=""><br class=""></div><div class="">Wouldn't this second option result in verification errors on the resulting dest module?</div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Not sure why? Since currently the destination module is valid, the post-process should be OK as well?</div></div></div></blockquote><div class=""><br class=""></div><div class="">I misunderstood what you were saying - you mentioned applying "verifier-breaking changes" as a post-process, but the key difference is that they are not verifier-breaking at that point.</div><div class=""><br class=""></div><div class="">I'm not sure it is worth making these changes, especially since there are other reasons (type ODR) that prevent verification until that point. </div></div></div></blockquote><br class=""></div><div>I don’t have an immediate need / issue, but since it is not usual to manipulate “incorrect IR” in a pass or a transformation utility “by design", I figured I’ll bring up this issue.</div><div><br class=""></div>— <div class="">Mehdi</div></body></html>