<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="">Hi Anna,<div class=""><br class=""></div><div class="">Can you clarify if you observed this post-linking?</div><div class=""><br class=""></div><div class="">— </div><div class="">Mehdi</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 23, 2016, at 12:42 PM, Anna Thomas <<a href="mailto:anna@azul.com" class="">anna@azul.com</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="">
We had the same problem with verification when merging/linking 2 modules: a compile unit is not listed in named metadata (llvm.dbg.cu),
<div class=""><br class="">
</div>
<div class="">We worked around this problem by using the DebugInfoFinder processModule function, which identifies all the compile units in the new module, by visiting all the subprogram scopes and the already available compile units. However, this succeeds
verification only if the unnamed/missing compile units have children sub programs. This is not a strong guarantee. </div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">Anna</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Dec 23, 2016, at 2:33 PM, 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="">
<div 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 class="">
<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="">
<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="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</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="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div></blockquote></div><br class=""></div></body></html>