[llvm-dev] llvm (the middle-end) is getting slower, December edition

[Andrew Trick via llvm-dev]

> On Dec 17, 2016, at 5:19 PM, Michael Gottesman <mgottesman at apple.com> wrote:
> 
>> 2) For clang, we spend 35% more time inside instcombine, and for game7
>> instcombine seems to largely dominate the amount of time we spend
>> optimizing IR. I tried to bisect (which is not easy considering the
>> test takes a long time to run), but I wasn't able to identify a single
>> point in time responsible for the regression. It seems to be an
>> additive effect. My wild (or not so wild) guess is that every day
>> somebody adds a matcher of two because that improves their testcase,
>> and at some point all this things add up. I'll try to do some
>> additional profiling but I guess large part of our time is spent
>> solving bitwise-domain dataflow problems (ComputeKnownBits et
>> similia). Once GVN will be in a more stable state, I plan to
>> experiment with caching results.
> 
> We have seen a similar thing when compiling the swift standard library. We have talked about making a small simple instcombine pass that doesn't iterate to a fixed point (IIRC). IIRC Andy/Mark looked at this (so my memory might be wrong).


In that case we wanted a lighter-weight instcombine cleanup pass to run right after LLVM IR generation. But, in general it makes sense to separate cleanup and canonicalization vs. optimization. I’ve always been strongly in favor of splitting InstCombine into a set of cheap, canonical transforms that run frequently, vs. optimizations that can run once later in the pipeline. It’s particularly annoying when somewhat target-specific codegen optimization get thrown into InstCombine—I’m not how prevalent that still is. It would be a lot of work to go through all the patterns and figure out what they’re needed for. But it might make sense to try reducing the number of times InstCombine is run, replace the earlier runs with an EarlyInstCombine and gradually move the most important canonical transforms into EarlyInstCombine as they’re needed.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161218/b187011e/attachment.html>