search for: r289855

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

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

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, > then it suggests we have a bigger problem?...that's a simple matcher > (no value tr...

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

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

...rg <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. :) >>> >>> 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 >>...

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

...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 You probably can try reverting them locally to check if my hypothesis is correct. I also looked at earlier data, and on top of the before-mentioned issues I found the following causes of compile-time degradation...

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