<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 30, 2015 at 1:03 PM, Sean Silva via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Sat, Aug 29, 2015 at 3:03 PM, Duncan P. N. Exon Smith via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The verifier takes ~5% of link time when using LTO.  I think we<br>
should add a `-disable-llvm-verifier` option to the LTO plugins, and<br>
change the clang driver to pass the option through in release builds.<br>
In asserts builds, the clang driver would not pass the option.<br>
<br>
This would match the way the driver passes -disable-llvm-verifier to<br>
-cc1.<br>
<br>
Everyone on board?<br></blockquote><div><br></div></span><div>I would prefer to keep it on by default; in the cc1 case we know that the input was immediately produced by clang (so we have a pretty high confidence that it is correct), which is not the case in LTO.</div><div><br></div><div>The verifier should be pretty much the cheapest of all passes. If it is taking 5%, then that means that we can be running a max of 20 passes, </div></div></div></div></blockquote><div><br>Not quite sure I understand this conclusion - not all passes take similar execution time (& especially not on larger inputs where they scale differently, etc), right?<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>which seems off (especially considering that some passes should be *enormously* more expensive, like codegen). Is 5% a number you measured in a profiler or an empirical difference when running with/without -disable-llvm-verifier? Do you have a breakdown of where that 5% is coming from? Is the number consistent across different programs (e.g. of different sizes)?</div><div><br></div><div>-- Sean Silva</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></span></div><br></div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>