<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 21, 2017 at 9:55 AM, Sanjay Patel <span dir="ltr"><<a href="mailto:spatel@rotateright.com" target="_blank">spatel@rotateright.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><div><div class="m_-7137125155125550656gmail-h5">On Fri, May 19, 2017 at 5:27 PM, Davide Italiano <span dir="ltr"><<a href="mailto:davide@freebsd.org" target="_blank">davide@freebsd.org</a>></span> wrote:<span class="m_-7137125155125550656gmail-m_3523555752031586120m_6591352667863351406gmail-m_-436234310287858029gmail-"></span><br><span class="m_-7137125155125550656gmail-m_3523555752031586120m_6591352667863351406gmail-m_-436234310287858029gmail-"></span></div></div><span class="m_-7137125155125550656gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-7137125155125550656gmail-m_3523555752031586120m_6591352667863351406gmail-m_-436234310287858029gmail-">
</span>The real problem of instcombine IMHO is that it suffer from an<br>
additive effect. i.e. matchers over matchers are added over time which<br>
per-se don't slow down the compiler in any measurable manner. But all<br>
of them sum up result in a significant compiler slowdown, and we<br>
notice only when it's too late (i.e. when the code has been released).<br>
We've all under the assumption that the time in InstCombine was spent<br>
inside auxiliary analysis computing the bitwise domain<br>
(ComputeKnownBits et similia). Turns out we're not able to find a case<br>
where caching speeds up things.<br>
<span class="m_-7137125155125550656gmail-m_3523555752031586120m_6591352667863351406gmail-m_-436234310287858029gmail-"><br></span></blockquote><div><br></div></span><div>This conclusion doesn't line up with the experimental results I showed here:<br><a href="http://lists.llvm.org/pipermail/llvm-dev/2017-March/111416.html" target="_blank">http://lists.llvm.org/pipermai<wbr>l/llvm-dev/2017-March/111416.h<wbr>tml</a><br><br></div><div>Is there a bug report with a test case for the stated case of "matchers over matchers"? I'd like to try some experiments with that test. From the earlier thread, it sounded like improving that case was something that was being investigated or would be investigated soon.<br></div></div></div></div></blockquote><div><br></div><div>Ping on this question. I'm offering to do some work on this, but I can't guess what the important benchmarks and compile machines are for other people, and clearly my experiment didn't match your reality. Test file(s) to use as a gold standard and a hardware description for the compile machine are a minimum.<br><br></div><div>FWIW, I sloppily timed the same test as shown above using 'opt' built release today, and we're significantly faster than 2 months ago:<br> <br></div><div>r298514 (no knownbits caching):<br><pre>user    0m0.302s
user    0m0.300s
user    0m0.296s
user    0m0.299s
user    0m0.296s
<br></pre><pre><span style="font-family:arial,helvetica,sans-serif">r304034 (no knownbits caching):</span><br>user        0m0.266s<br>user  0m0.268s<br>user  0m0.268s<br>user  0m0.267s<br>user  0m0.265s<br><br></pre><pre><span style="font-family:arial,helvetica,sans-serif">This is actually the same speed as I measured 2 months ago *with* knownbits caching. I couldn't apply the patch from:<br><a href="https://reviews.llvm.org/D31239" target="_blank">https://reviews.llvm.org/<wbr>D31239</a></span><br></pre></div><div>...cleanly, so I'm not sure if there would still be an improvement from caching or not. I'd be very interested to see one of those perf vs. commit charts to see if there are commits we can pinpoint for this improvement. :)<br></div></div></div></div>