llvm dev - Dec 2016 - llvm (the middle-end) is getting slower, December edition

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.

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare

FWIW, r289813 also seems to be causing/exposing a miscompile of
spec2006/perlbench on AArch64 (PR31449).

-- Matt

On Wed, Dec 21, 2016 at 11: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.
>
> --
> 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/5c6487e5/attachment.html>

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>

On 12/21/2016 01:11 PM, Sean Silva via llvm-dev wrote:
>
>
> On Wed, Dec 21, 2016 at 8:07 AM, Davide Italiano via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>
>     On Mon, Dec 19, 2016 at 4:24 PM, Mikhail Zolotukhin
>     <mzolotukhin at apple.com <mailto: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)
https://llvm.org/bugs/show_bug.cgi?id=31449 - it seems that r289813 also 
is causing a miscompile.

  -Hal
>
> -- 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 <mailto:llvm-dev at lists.llvm.org>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161221/2faba829/attachment.html>

I have reverted r289813 in r290266.

On Wed, Dec 21, 2016 at 11:10 AM, Matthew Simpson via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> FWIW, r289813 also seems to be causing/exposing a miscompile of
> spec2006/perlbench on AArch64 (PR31449).
>
> -- Matt
>
> On Wed, Dec 21, 2016 at 11: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.
>>
>> --
>> 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
>>
>
>
> _______________________________________________
> 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/e5a2ab93/attachment.html>

I would have replied to this thread sooner, but I was busy adding more
instcombines. :)

The motivation for r289855 is in the commit msg (I'm out of the office and
can't look things up conveniently). Feel free to revert that and the follow
ups, however, if that patch caused a noticeable slowdown, then it suggests
we have a bigger problem?...that's a simple matcher (no value tracking
required).

On Wed, Dec 21, 2016 at 12:12 PM Sean Silva <chisophugis at gmail.com>
wrote:
> 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/821ab7f0/attachment.html>