search for: r286814

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

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

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

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

...ly enabled unrolling heuristic. +22% 24. r276942: Don't invoke getName() from Function::isIntrinsic(). -1% r277087: Revert "Don't invoke getName() from Function::isIntrinsic().", rL276942. +1% 25. r279585: [LoopUnroll] By default disable unrolling when optimizing for size. 26. r286814: [InlineCost] Remove skew when calculating call costs. +3% 27. r289755: Make processing @llvm.assume more efficient by using operand bundles. +6% 28. r290086: Revert @llvm.assume with operator bundles (r289755-r289757). -6% -------------- next part -------------- A non-text attachment was scrubbed....

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

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

...>> 24. r276942: Don't invoke getName() from Function::isIntrinsic(). -1% >> r277087: Revert "Don't invoke getName() from Function::isIntrinsic().", rL276942. +1% >> 25. r279585: [LoopUnroll] By default disable unrolling when optimizing for size. >> 26. r286814: [InlineCost] Remove skew when calculating call costs. +3% >> 27. r289755: Make processing @llvm.assume more efficient by using operand bundles. +6% >> 28. r290086: Revert @llvm.assume with operator bundles (r289755-r289757). -6% >> >> >> Disclaimer: >> The data...

.... r276942: Don't invoke getName() from Function::isIntrinsic(). -1% > > r277087: Revert "Don't invoke getName() from > Function::isIntrinsic().", rL276942. +1% > > 25. r279585: [LoopUnroll] By default disable unrolling when optimizing > for size. > > 26. r286814: [InlineCost] Remove skew when calculating call costs. +3% > > 27. r289755: Make processing @llvm.assume more efficient by using > operand bundles. +6% > > 28. r290086: Revert @llvm.assume with operator bundles > (r289755-r289757). -6% > > <CompileTime.pdf> > > D...

...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 degradations (and sometimes improvements): 1) Change...

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

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