diff options
| author | Manish Goregaokar <manishsmail@gmail.com> | 2016-05-14 11:57:47 +0200 |
|---|---|---|
| committer | Manish Goregaokar <manishsmail@gmail.com> | 2016-05-14 11:57:47 +0200 |
| commit | 36c4c6d433aadb3645ac790b5f2fcb830881c9c9 (patch) | |
| tree | 83bbac84f5300cdded068bb6aaf9894dba900867 /src/libsyntax/errors | |
| parent | d3ec9d43cf948813fa5aab3dfacf97035ee90d16 (diff) | |
| parent | 00f6513259c12af733d22398b1ea77cff67b7beb (diff) | |
| download | rust-36c4c6d433aadb3645ac790b5f2fcb830881c9c9.tar.gz rust-36c4c6d433aadb3645ac790b5f2fcb830881c9c9.zip | |
Rollup merge of #33544 - dotdash:baby_dont_break_me_no_more, r=Aatch
Only break critical edges where actually needed Currently, to prepare for MIR trans, we break _all_ critical edges, although we only actually need to do this for edges originating from a call that gets translated to an invoke instruction in LLVM. This has the unfortunate effect of undoing a bunch of the things that SimplifyCfg has done. A particularly bad case arises when you have a C-like enum with N variants and a derived PartialEq implementation. In that case, the match on the (&lhs, &rhs) tuple gets translated into nested matches with N arms each and a basic block each, resulting in N² basic blocks. SimplifyCfg reduces that to roughly 2*N basic blocks, but breaking the critical edges means that we go back to N². In nickel.rs, there is such an enum with roughly N=800. So we get about 640K basic blocks or 2.5M lines of LLVM IR. LLVM takes a while to reduce that to the final "disr_a == disr_b". So before this patch, we had 2.5M lines of IR with 640K basic blocks, which took about about 3.6s in LLVM to get optimized and translated. After this patch, we get about 650K lines with about 1.6K basic blocks and spent a little less than 0.2s in LLVM. cc #33111 r? @Aatch
Diffstat (limited to 'src/libsyntax/errors')
0 files changed, 0 insertions, 0 deletions
