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

[via llvm-dev]

> 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