similar to: llvm (the middle-end) is getting slower, December edition

On Sat, Dec 17, 2016 at 8:39 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > >>> >> LVI is one of those analyses with quadratic runtime, but has a cutoff to >> its search depth so that it is technically not quadratic. So increased >> inlining could easily exacerbate it more than non-"quadratic" passes. >> (increased inlining would also cause

> 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. >

> > >> > LVI is one of those analyses with quadratic runtime, but has a cutoff to > its search depth so that it is technically not quadratic. So increased > inlining could easily exacerbate it more than non-"quadratic" passes. > (increased inlining would also cause a general slowdown too). > > LVI is only quadratic because of the way we've built it

On Dec 17, 2016 7:41 PM, "Sean Silva" <chisophugis at gmail.com> wrote: On Sat, Dec 17, 2016 at 6:32 PM, Davide Italiano via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Sat, Dec 17, 2016 at 1:35 PM, Davide Italiano <davide at freebsd.org> > wrote: > [...] > > > I don't have an infrastructure to measure the runtime performance > >

On 12/17/2016 01:35 PM, Davide Italiano via llvm-dev 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. > Rafael did something similar back in March, so

On Sat, Dec 17, 2016 at 1:35 PM, Davide Italiano <davide at freebsd.org> wrote: [...] > I don't have an infrastructure to measure the runtime performance > benefits/regression of clang, but I have for `game7`. > I wasn't able to notice any fundamental speedup (at least, not > something that justifies a 2x build-time). > Just to provide numbers (using Sean's

On Sat, 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. >

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

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

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 -

On Sun, Dec 18, 2016 at 11:10 AM, Philip Reames <listmail at philipreames.com> wrote: > On 12/17/2016 01:35 PM, Davide Italiano via llvm-dev wrote: >> [...] > > I'd really like to see a profile which broke down the time spent in Value > Propagation and LVI. As the person who has touched both most recently, I am > probably the responsible party. At the same time,

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

On 12/21/2016 04:40 PM, Mehdi Amini wrote: > >> On Dec 21, 2016, at 1:57 PM, Hal Finkel via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >> On 12/21/2016 03:36 PM, Sanjay Patel via llvm-dev wrote: >>> I would have replied to this thread sooner, but I was busy adding >>> more instcombines.

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! >

On 12/21/2016 03:36 PM, Sanjay Patel via llvm-dev wrote: > 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, >

> On Dec 21, 2016, at 1:57 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On 12/21/2016 03:36 PM, Sanjay Patel via llvm-dev wrote: >> 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

> 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. >

On Sat, Dec 17, 2016 at 6:39 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> 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

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. Rafael did something similar back in March, so this can be considered as an update. This tries to include a more accurate high-level

On 03/17/2017 04:30 PM, Mehdi Amini via llvm-dev wrote: > >> On Mar 17, 2017, at 11:50 AM, Mikhail Zolotukhin via llvm-dev >> <llvm-dev at lists.llvm.org <mailto: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