<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="">I just hit another issue: before of ODR type uniquing on bitcode loading, we can end-up with a metadata graph that include metadata from the destination module, including a DICompileUnit.<div class="">Unfortunately this compile-unit is not listed in llvm.dbg.cu and this does not pass the verifier.</div><div class=""><br class=""></div><div class="">CC a few folks more aware of debug info that I am: is there a plan to make llvm.dbg.cu disappear?</div><div class=""><br class=""></div><div class="">— </div><div class="">Mehdi</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 23, 2016, at 11:04 AM, Mehdi Amini via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 23, 2016, at 9:34 AM, Teresa Johnson <<a href="mailto:tejohnson@google.com" class="">tejohnson@google.com</a>> wrote:</div><br class="Apple-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 dir="ltr" class=""><<a href="mailto:mehdi.amini@apple.com" target="_blank" class="">mehdi.amini@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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><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=""> 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 class="">36</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="">
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><div class="">Not sure why? Since currently the destination module is valid, the post-process should be OK as well?</div><div class=""><br class=""></div><div class="">— </div><div class="">Mehdi</div></div></div>_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></div></body></html>