<div dir="ltr">So, just a thought:<div>"<span style="font-size:12.8px">The purpose of many of InstCombine's xforms is to canonicalize the IR to make life easier for downstream passes and analyses.</span><span style="font-size:12.8px">"</span></div><div><span style="font-size:12.8px">That sounds sane.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">So, are the expensive things canonicalization?</span></div><div><span style="font-size:12.8px">If that is the case, why are we doing such expensive canonicalization?  That seems strange to me.</span></div><div><span style="font-size:12.8px"><br></span></div><div>If they are not canonicalization, should they really not be separated out (into some pass that possibly shares infrastructure)?</div><div><br></div><div>No compiler is going to get everything anyway, and instcombine needs to decide what "good enough" really means.</div><div><br></div><div>I would rather see us understand what we want out of instcombine, precisely, before we try to decide how to make it faster at doing whatever that thing is :)</div><div><br></div><div><br></div><div>--Dan</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 21, 2017 at 11:12 AM, Davide Italiano 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 class="HOEnZb"><div class="h5">On Fri, Mar 17, 2017 at 11:50 AM, Mikhail Zolotukhin via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> One of the most time-consuming passes in LLVM middle-end is InstCombine (see e.g. [1]). It is a very powerful pass capable of doing all the crazy stuff, and new patterns are being constantly introduced there. The problem is that we often use it just as a clean-up pass: it's scheduled 6 times in the current pass pipeline, and each time it's invoked it checks all known patterns. It sounds ok for O3, where we try to squeeze as much performance as possible, but it is too excessive for other opt-levels. InstCombine has an ExpensiveCombines parameter to address that - but I think it's underused at the moment.<br>
><br>
> Trying to find out, which patterns are important, and which are rare, I profiled clang using CTMark and got the following coverage report:<br>
><br>
</div></div><span class="">> (beware, the file is ~6MB).<br>
><br>
> Guided by this profile I moved some patterns under the "if (ExpensiveCombines)" check, which expectedly happened to be neutral for runtime performance, but improved compile-time. The testing results are below (measured for Os).<br>
><br>
<br>
</span>As somebody who brought up this problem at least once in the mailing<br>
lists, I'm in agreement with David Majnemer here.<br>
I think we should consider a caching strategy before going this route.<br>
FWIW, I'm not a big fan of `ExpensiveCombines` at all, I can see the<br>
reason why it was introduced, but in my experience the "expensive"<br>
bits of Instcombine comes from the implementation of bitwise domain,<br>
i.e. known bits & friends, so at least evaluating caching is something<br>
I would try earlier.<br>
<br>
Something else that can be tried (even if it doesn't improve compile<br>
time is still a nice cleanup) is that of moving combines not creating<br>
new instructions from instcombine to instsimplify. Many passes use<br>
instruction simplify so that might result in the amount of code that's<br>
processed by instcombine being smaller and/or could result in improved<br>
code quality. Just speculations, but a decent experiment if somebody<br>
has time to take a look at.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Davide<br>
<br>
"There are no solved problems; there are only problems that are more<br>
or less solved" -- Henri Poincare<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<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/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>