[llvm-dev] RFC: Switching to the new pass manager by default
Chandler Carruth via llvm-dev
llvm-dev at lists.llvm.org
Thu Oct 26 13:03:23 PDT 2017
I just want to send a quick thanks to the *numerous* folks sending
benchmark numbers my way, this is tremendously useful. I'm going to go
through and triage these, but if any of you are feeling motivated and want
to file a bug to track specific ones and assign it to me, that also works.
Big thing that would help is just to confirm the exact architecture used. I
*think* I know based on who posted them, but can be useful. =D
Largely, I agree with Hal regarding strategy: the kinds of regressions
we're seeing here really just need to be either fixed or deeply understood
and explained as not something we care about. And I think that is true for
all of execution time, code size, and compile time. So far, looking at the
numbers, I'm not really nervous about any of this. Once that's done, I
don't think we need to do any kind of elaborate incremental switch.
I'm on holiday for a week so there will be some delay in me at least
starting to work on fixing these, but of course, if others want to jump on
any of them, that's always welcome.
On Thu, Oct 26, 2017 at 12:09 PM Mikhail Zolotukhin <mzolotukhin at apple.com>
wrote:
> Hi,
>
> I ran testing for compile time on CTMark, the numbers are below:
>
> ==== O0-g ====
> 7zip/7zip-benchmark -1.5%
> Bullet/bullet -1.4%
> ClamAV/clamscan -1.5%
> SPASS/SPASS -1.9%
> consumer-typeset/consumer-typeset -2.8%
> kimwitu++/kc 0.0%
> lencod/lencod -1.9%
> mafft/pairlocalalign -2.1%
> sqlite3/sqlite3 -3.6%
> tramp3d-v4/tramp3d-v4 -1.7%
> Geomean -1.9%
>
> ==== Os ====
> 7zip/7zip-benchmark -8.2%
> Bullet/bullet -5.7%
> ClamAV/clamscan -2.2%
> SPASS/SPASS -3.8%
> consumer-typeset/consumer-typeset -5.7%
> kimwitu++/kc -7.0%
> lencod/lencod -2.3%
> mafft/pairlocalalign -3.7%
> *sqlite3/sqlite3 16.1%*
> tramp3d-v4/tramp3d-v4 -8.9%
> Geomean -3.4%
>
> ==== O3 ====
> 7zip/7zip-benchmark -13.7%
> Bullet/bullet -8.3%
> ClamAV/clamscan -6.8%
> SPASS/SPASS -7.2%
> consumer-typeset/consumer-typeset -9.6%
> *kimwitu++/kc 31.3%*
> lencod/lencod -7.3%
> mafft/pairlocalalign -11.2%
> sqlite3/sqlite3 5.1%
> tramp3d-v4/tramp3d-v4 1.9%
> Geomean -3.3%
>
>
> So, in general, it's a win, but there are a couple of big outliers:
> sqlite3 on Os and kimwitu++/kc on O3. It would be good to understand if we
> can avoid these slowdowns.
>
> Michael
>
> On Oct 26, 2017, at 10:13 AM, Evgeny Astigeevich via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hi,
>
> I’ve got results of our private benchmarks. Clang options were the same.
> There are a few regressions. The biggest regression is 8.24%. We’ve got a
> lot of improvements in scores and code size. The biggest score improvement
> is 22.07%. The biggest code size improvement is 16.10%. Benchmark binaries
> are quite big: improved ones are greater than 1 Mbytes.
>
> I’ll check impact on AArch32 and investigate 1000% regression.
>
> Thanks,
> Evgeny Astigeevich
>
>
> *From: *Hal Finkel <hfinkel at anl.gov>
> *Organization: *Argonne National Laboratory
> *Date: *Wednesday, 25 October 2017 at 18:38
> *To: *Evgeny Astigeevich <Evgeny.Astigeevich at arm.com>, Chandler Carruth <
> chandlerc at gmail.com>
> *Cc: *llvm-dev <llvm-dev at lists.llvm.org>, nd <nd at arm.com>
> *Subject: *Re: [llvm-dev] RFC: Switching to the new pass manager by
> default
>
>
>
> On 10/25/2017 12:32 PM, Evgeny Astigeevich wrote:
>
> Hi Hal,
>
> I quickly checked the execution profile. It is real. The code changed
> significantly. A number of the hottest regions changed. I’ll compare IRs.
>
>
> Thanks. Obviously a 1000% execution performance regression seems
> problematic.
>
> -Hal
>
>
> JFYI FreeBench/fourinarow time graph:
> http://lnt.llvm.org/db_default/v4/nts/graph?highlight_run=76922&plot.1604615=1349.1604615.3
> Its graph in our LNT is more stable.
>
> Thanks,
> Evgeny
>
> *From: *Hal Finkel <hfinkel at anl.gov> <hfinkel at anl.gov>
> *Organization: *Argonne National Laboratory
> *Date: *Wednesday, 25 October 2017 at 18:14
> *To: *Evgeny Astigeevich <Evgeny.Astigeevich at arm.com>
> <Evgeny.Astigeevich at arm.com>, Chandler Carruth <chandlerc at gmail.com>
> <chandlerc at gmail.com>
> *Cc: *llvm-dev <llvm-dev at lists.llvm.org> <llvm-dev at lists.llvm.org>, nd
> <nd at arm.com> <nd at arm.com>
> *Subject: *Re: [llvm-dev] RFC: Switching to the new pass manager by
> default
>
>
>
> On 10/25/2017 12:10 PM, Evgeny Astigeevich via llvm-dev wrote:
>
> Hi Chandler,
>
> I ran the LNT benchmarks and SPEC2k6.train on AArch64 Cortex-A57. I used
> revisions: Clang 316561, LLVM 316563.
> Options: -O3 -mcpu=cortex-a57 -fomit-frame-pointer
> -fexperimental-new-pass-manager
>
> Regressions: execution time increase
>
> LNT
> MultiSource/Benchmarks/FreeBench/fourinarow/fourinarow
> 1018.58%
>
>
> How real is this?
>
> -Hal
>
>
>
> MultiSource/Benchmarks/Fhourstones/fhourstones
> 9.06%
> MultiSource/Benchmarks/Ptrdist/yacr2/yacr2
> 7.23%
> MultiSource/Benchmarks/Olden/perimeter/perimeter
> 6.87%
> MultiSource/Benchmarks/MiBench/consumer-typeset/consumer-typeset
> 6.02%
> MultiSource/Benchmarks/Trimaran/enc-pc1/enc-pc1
> 5.59%
> MultiSource/Benchmarks/ASC_Sequoia/AMGmk/AMGmk
> 5.03%
>
> SPEC2k6
> 453.povray 17.11%
> 482.sphinx3 3.44%
> 444.namd 2.89%
>
> Improvements: execution time decrease
>
> LNT
> MultiSource/Benchmarks/BitBench/uudecode/uudecode
> -50.90%
> SingleSource/Benchmarks/Adobe-C++/loop_unroll
> -27.75%
> SingleSource/Benchmarks/Misc/perlin
> -21.35%
> MultiSource/Benchmarks/Olden/em3d/em3d
> -19.12%
> MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4
> -8.58%
> SingleSource/Benchmarks/McGill/chomp
> -6.33%
> MultiSource/Benchmarks/sim/sim
> -5.41%
> MultiSource/Applications/ClamAV/clamscan
> -3.11%
> MultiSource/Benchmarks/TSVC/Symbolics-dbl/Symbolics-dbl
> -2.81%
>
> SPEC2k6
> 429.mcf -5.18%
> 473.astar -2.65%
> 400.perlbench -1.90%
>
> There are also code sizes increases/decreases. The maximum increase is
> 18.98%. The maximum decrease is 25.65%.
>
> Thanks,
> Evgeny Astigeevich
>
> *From: *llvm-dev <llvm-dev-bounces at lists.llvm.org>
> <llvm-dev-bounces at lists.llvm.org> on behalf of Chandler Carruth via
> llvm-dev<llvm-dev at lists.llvm.org> <llvm-dev at lists.llvm.org>
> *Reply-To: *Chandler Carruth <chandlerc at gmail.com> <chandlerc at gmail.com>
> *Date: *Wednesday, 18 October 2017 at 07:51
> *To: *llvm-dev <llvm-dev at lists.llvm.org> <llvm-dev at lists.llvm.org>
> *Subject: *[llvm-dev] RFC: Switching to the new pass manager by default
>
> Greetings everyone!
>
> The new pass manager is getting extremely close to the point where I'm not
> aware of any significant outstanding work needed, and I'd like to see what
> else would be needed to enable it by default. Here are the current
> functionality I'm aware of outstanding:
>
> 1) Does not do non-trivial loop unswitching. Majority of this is in
> https://reviews.llvm.org/D34200 but will need one or two small follow-ups.
>
> 2) Currently, sanitizers don't work correctly with it. Thanks to the work
> of others, the missing infrastructure has been added and I'll send a patch
> to wire this up this week.
>
> 3) Missing support for 'optnone'. I've been working on this, but the
> existing testing wasn't as thorough as I wanted, so it is going slowly.
> I've got about 1/4 of this implemented and should have patches this week or
> next.
>
> 4) Missing opt-bisect (or similar) facility. This looks pretty trivial to
> add, but I've not even started. If anyone is interested in it, go for it.
> We might even be able to do something simpler using the generic debug
> counters and get equivalent functionality.
>
> ... that's it?
>
> Optimization quality / run-time performance:
> - We've been using it at Google extensively and are very happy with the
> optimization quality. Benchmarks look *very* good here.
> - More data from other users would be important.
> - You can try it out with `-fexperimental-new-pass-manager` to Clang
>
> Compile-time performance:
> - Sometimes *much* better due to cached analyses.
> - Sometimes worse, typically due to more / different inlining in turn
> running main pipeline (GVN + InstCombine) more times or over more code.
> - Overall somewhat a wash, but the increased compile times typically due
> to the optimizer "trying" harder, so not too concerning on our end.
> - Again, more feedback from other users good:
> `-fexperimental-new-pass-manager` to Clang
>
> Once the four missing things land, I'll also happily work on collecting
> some of the basics on the test-suite and CTMark. But I suspect more "in the
> wild" data would really be useful here given the significance of the change.
>
> Thoughts? What else (beyond the four items above and feedback on run-time
> and compile-time) would folks like to see?
>
> Once this happens, I'll also be preparing some batch, mechanical updates
> to the test suite to primarily use the new pass manager. Also there is lots
> of documentation updates that will be needed here.
>
> -Chandler
>
> PS: I'll be sending a note to cfe-dev as a "heads up" about this
> discussion as in some ways, the default flip is mostly a Clang default
> flip. But hopefully our doc updates will trigger this being "perceived" as
> the default for other frontends, and I'll try to reach out to other major
> frontends as well (Swift and Rust are on my radar, and I've already started
> talking with Philip Reames about their Falcon JIT).
>
>
>
>
> _______________________________________________
>
> 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
>
>
>
> --
>
> Hal Finkel
>
> Lead, Compiler Technology and Programming Languages
>
> Leadership Computing Facility
>
> Argonne National Laboratory
>
> _______________________________________________
> 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/20171026/9fbe1fba/attachment-0001.html>
More information about the llvm-dev
mailing list