[llvm-dev] Saving Compile Time in InstCombine

[Daniel Berlin via llvm-dev]

So, just a thought:
"The purpose of many of InstCombine's xforms is to canonicalize the IR to
make life easier for downstream passes and analyses."
That sounds sane.

So, are the expensive things canonicalization?
If that is the case, why are we doing such expensive canonicalization?
That seems strange to me.

If they are not canonicalization, should they really not be separated out
(into some pass that possibly shares infrastructure)?

No compiler is going to get everything anyway, and instcombine needs to
decide what "good enough" really means.

I would rather see us understand what we want out of instcombine,
precisely, before we try to decide how to make it faster at doing whatever
that thing is :)


--Dan



On Tue, Mar 21, 2017 at 11:12 AM, Davide Italiano via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Fri, Mar 17, 2017 at 11:50 AM, Mikhail Zolotukhin via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > Hi,
> >
> > One of the most time-consuming passes in LLVM middle-end is InstCombine
> (see e.g. [1]). It is a very powerful pass capable of doing all the crazy
> stuff, and new patterns are being constantly introduced there. The problem
> is that we often use it just as a clean-up pass: it's scheduled 6 times in
> the current pass pipeline, and each time it's invoked it checks all known
> patterns. It sounds ok for O3, where we try to squeeze as much performance
> as possible, but it is too excessive for other opt-levels. InstCombine has
> an ExpensiveCombines parameter to address that - but I think it's underused
> at the moment.
> >
> > Trying to find out, which patterns are important, and which are rare, I
> profiled clang using CTMark and got the following coverage report:
> >
> > (beware, the file is ~6MB).
> >
> > Guided by this profile I moved some patterns under the "if
> (ExpensiveCombines)" check, which expectedly happened to be neutral for
> runtime performance, but improved compile-time. The testing results are
> below (measured for Os).
> >
>
> As somebody who brought up this problem at least once in the mailing
> lists, I'm in agreement with David Majnemer here.
> I think we should consider a caching strategy before going this route.
> FWIW, I'm not a big fan of `ExpensiveCombines` at all, I can see the
> reason why it was introduced, but in my experience the "expensive"
> bits of Instcombine comes from the implementation of bitwise domain,
> i.e. known bits & friends, so at least evaluating caching is something
> I would try earlier.
>
> Something else that can be tried (even if it doesn't improve compile
> time is still a nice cleanup) is that of moving combines not creating
> new instructions from instcombine to instsimplify. Many passes use
> instruction simplify so that might result in the amount of code that's
> processed by instcombine being smaller and/or could result in improved
> code quality. Just speculations, but a decent experiment if somebody
> has time to take a look at.
>
> --
> Davide
>
> "There are no solved problems; there are only problems that are more
> or less solved" -- Henri Poincare
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170321/c6a52f32/attachment.html>