search for: d28368

Currently, loop fully unroller shares the same default threshold as loop dynamic unroller and partial unroller. This seems conservative because unlike dynamic/partial unrolling, fully unrolling will not affect LSD/ICache performance. In https://reviews.llvm.org/D28368, I proposed to double the threshold for loop fully unroller. This will change the codegen of several SPECCPU benchmarks: Code size: 447.dealII 0.50% 453.povray 0.42% 433.milc 0.20% 445.gobmk 0.32% 403.gcc 0.05% 464.h264ref 3.62% Compile Time: 447.dealII 0.22% 453.povray -0.16% 433.milc 0.09% 445....

...lists.llvm.org> wrote: > > Currently, loop fully unroller shares the same default threshold as loop dynamic unroller and partial unroller. This seems conservative because unlike dynamic/partial unrolling, fully unrolling will not affect LSD/ICache performance. In https://reviews.llvm.org/D28368 <https://reviews.llvm.org/D28368>, I proposed to double the threshold for loop fully unroller. This will change the codegen of several SPECCPU benchmarks: > > Code size: > 447.dealII 0.50% > 453.povray 0.42% > 433.milc 0.20% > 445.gobmk 0.32% > 403.gcc 0.05% > 464.h26...

...g> wrote: > > Currently, loop fully unroller shares the same default threshold as loop > dynamic unroller and partial unroller. This seems conservative because > unlike dynamic/partial unrolling, fully unrolling will not affect > LSD/ICache performance. In https://reviews.llvm.org/D28368, I proposed to > double the threshold for loop fully unroller. This will change the codegen > of several SPECCPU benchmarks: > > Code size: > 447.dealII 0.50% > 453.povray 0.42% > 433.milc 0.20% > 445.gobmk 0.32% > 403.gcc 0.05% > 464.h264ref 3.62% > > Compile Ti...

...; >> Currently, loop fully unroller shares the same default threshold as loop >> dynamic unroller and partial unroller. This seems conservative because >> unlike dynamic/partial unrolling, fully unrolling will not affect >> LSD/ICache performance. In https://reviews.llvm.org/D28368, I proposed >> to double the threshold for loop fully unroller. This will change the >> codegen of several SPECCPU benchmarks: >> >> Code size: >> 447.dealII 0.50% >> 453.povray 0.42% >> 433.milc 0.20% >> 445.gobmk 0.32% >> 403.gcc 0.05% >&gt...

...That > could be useful to anyone that comes along later and wants to reproduce > and/or compare to the original, motivating data. > > > On Fri, Feb 10, 2017 at 4:53 PM, Dehao Chen <dehao at google.com> wrote: > > Thanks Hal, could you help approve https://reviews.llvm.org/D28368? > > I'll hold off until early Tuesday in case other people have more concerns. > > Thanks, > Dehao > > On Fri, Feb 10, 2017 at 3:23 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > On 02/10/2017 05:21 PM, Dehao Chen wrote: > > Thanks every for the comm...

...oping you find this useful, > Very. Once again, this kind of data and analysis is awesome. =D > > Kristof > > > On Tue, Feb 14, 2017 at 1:06 PM Kristof Beyls via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > I've run the patch on https://reviews.llvm.org/D28368 on the test-suite > and other benchmarks, for AArch64 -O3 -fomit-frame-pointer, both for > Cortex-A53 and Cortex-A57. > > The geomean over the few hundred programs in there is roughly the same for > Cortex-A53 and Cortex-A57: a bit over 1% improvement in execution speed for > a bi...

...org>> wrote: >> >> Currently, loop fully unroller shares the same default threshold as loop dynamic unroller and partial unroller. This seems conservative because unlike dynamic/partial unrolling, fully unrolling will not affect LSD/ICache performance. In https://reviews.llvm.org/D28368 <https://reviews.llvm.org/D28368>, I proposed to double the threshold for loop fully unroller. This will change the codegen of several SPECCPU benchmarks: >> >> Code size: >> 447.dealII 0.50% >> 453.povray 0.42% >> 433.milc 0.20% >> 445.gobmk 0.32% >&gt...

...uot;1, 2, 3, ..." or whatever, much like we did for Google-internal benchmarks. It's still useful to know the shape of the change. On Tue, Feb 14, 2017 at 1:06 PM Kristof Beyls via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I've run the patch on https://reviews.llvm.org/D28368 on the test-suite > and other benchmarks, for AArch64 -O3 -fomit-frame-pointer, both for > Cortex-A53 and Cortex-A57. > > The geomean over the few hundred programs in there is roughly the same for > Cortex-A53 and Cortex-A57: a bit over 1% improvement in execution speed for > a bi...

...gain, this kind of data and analysis is awesome. =D > > Kristof > >> >> On Tue, Feb 14, 2017 at 1:06 PM Kristof Beyls via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> I've run the patch on https://reviews.llvm.org/D28368 <https://reviews.llvm.org/D28368> on the test-suite and other benchmarks, for AArch64 -O3 -fomit-frame-pointer, both for Cortex-A53 and Cortex-A57. >> >> The geomean over the few hundred programs in there is roughly the same for Cortex-A53 and Cortex-A57: a bit over 1% improvemen...

On 02/10/2017 05:21 PM, Dehao Chen wrote: > Thanks every for the comments. > > Do we have a decision here? You're good to go as far as I'm concerned. -Hal > > Dehao > > On Tue, Feb 7, 2017 at 10:24 PM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: > > > On 02/07/2017 05:29 PM, Sanjay Patel via llvm-dev wrote: