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

via llvm-dev
2016-12-18T20:55:44Z

> On Dec 17, 2016, at 1:35 PM, Davide Italiano via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>
> First of all, sorry for the long mail.
> Inspired by the excellent analysis Rui did for lld, I decided to do
> the same for llvm.
> I'm personally very interested in build-time for LTO configuration,
> with particular attention to the time spent in the optimizer.

From our own offline regression testing, one of the biggest culprits in our
experience is Instcombine’s known bits calculation. A number of new known bits
checks have been added in the past few years (e.g. to infer nuw, nsw, etc on
various instructions) and the cost adds up quite a lot, because *the cost is
paid even if Instcombine does nothing*, since it’s a significant cost on
visiting every relevant instruction.

This IME is one of the greatest ways performance gets lost: a tiny bit at a
time, whenever a new combine/transformation is added that is *expensive to test
for*. The test has to be done every time no matter what (and instcombine gets
called a lot!), so the cost adds up.

—escha