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

Sean Silva via llvm-dev llvm-dev at lists.llvm.org
Wed Dec 21 11:11:54 PST 2016


On Wed, Dec 21, 2016 at 8:07 AM, Davide Italiano via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Mon, Dec 19, 2016 at 4:24 PM, Mikhail Zolotukhin
> <mzolotukhin at apple.com> wrote:
> > Hi Davide,
> >
> > Thanks for the analysis, it's really interesting! And I'm really glad
> that we now put more and more attention at the compile time!
> >
> > Just recently I've been looking into historical compile time data as
> well, and have had similar conclusions. The regressions you've found are
> probably caused by:
> > 1) r289813 and r289855 - new matchers in InstCombine
> > 2) r286814 and r288024 - changes in Inlining cost model
> >
>
> Haven't looked at 2) yet, but I can confirm for 1). Sanjay/Ehsan, can
> you please explain what's the motivation behind the new
> transformations you introduced? I'm tempted to ask a revert, but I'd
> like to understand the motivations first.
>


Both r289813 and r289855 add a very small amount of matching (it seems?)
compared to the rest of the size of instcombine. How is it that these
checks are causing such a disproportionate slowdown compared to the rest of
instcombine? (by "I can confirm for 1)" I assume you mean these two patches
have a pretty significant impact on compile time; not "0.1%" each)

-- Sean Silva


>
> --
> 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/20161221/4d38a5f0/attachment.html>


More information about the llvm-dev mailing list