[llvm-dev] [llvm] r303387 - [InstCombine] add more tests for xor-of-icmps; NFC

Sanjay Patel via llvm-dev llvm-dev at lists.llvm.org
Fri May 26 15:49:10 PDT 2017


On Sun, May 21, 2017 at 9:55 AM, Sanjay Patel <spatel at rotateright.com>
wrote:

>
> On Fri, May 19, 2017 at 5:27 PM, Davide Italiano <davide at freebsd.org>
> wrote:
>
>> The real problem of instcombine IMHO is that it suffer from an
>> additive effect. i.e. matchers over matchers are added over time which
>> per-se don't slow down the compiler in any measurable manner. But all
>> of them sum up result in a significant compiler slowdown, and we
>> notice only when it's too late (i.e. when the code has been released).
>> We've all under the assumption that the time in InstCombine was spent
>> inside auxiliary analysis computing the bitwise domain
>> (ComputeKnownBits et similia). Turns out we're not able to find a case
>> where caching speeds up things.
>>
>>
> This conclusion doesn't line up with the experimental results I showed
> here:
> http://lists.llvm.org/pipermail/llvm-dev/2017-March/111416.html
>
> 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.
>

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.

FWIW, I sloppily timed the same test as shown above using 'opt' built
release today, and we're significantly faster than 2 months ago:

r298514 (no knownbits caching):

user    0m0.302s
user    0m0.300s
user    0m0.296s
user    0m0.299s
user    0m0.296s

r304034 (no knownbits caching):
user	0m0.266s
user	0m0.268s
user	0m0.268s
user	0m0.267s
user	0m0.265s

This is actually the same speed as I measured 2 months ago *with*
knownbits caching. I couldn't apply the patch from:
https://reviews.llvm.org/D31239

...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. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170526/cf0af5e9/attachment.html>


More information about the llvm-dev mailing list