[PATCH] D37163: [LICM] sink through non-trivially replicable PHI

[Daniel Berlin via Phabricator via llvm-commits]

dberlin added a comment.

In https://reviews.llvm.org/D37163#863648, @junbuml wrote:

> > Okay.
> > One reason we don't split critical edges by default in most passes in LLVM is that edges coming out of switches that lead to the same block are pretty much always critical.
> >  Doing so by default for large switches leads to *huge* code blowup.
> >  IE it goes from 1 block to N blocks, where N is the number of switch cases.
> > If there are multiple layers of switches, it's obviously even worse.
> > Have you tested on this on any switch heavy code to ensure it does not blow up code size and compile time?
>
> I tried to build spec2000/spec2006/spec2017 with/without this change for aarch64. This change was applied widely and as far as I know perlbench use lots of big switches, but I didn't see any significant changes in code size and compile time across all benchmarks.  
>  However, as you point out, it could possibly increase code size even in some case where splitting is required for sinking. Just to be safe what about checking if the number of predecessors is larger than some threshold from cl::opt before splitting?


If you haven't seen any real code size regressions, i think you should just be prepared to address it in the future, and let's leave it at that for now :)
Thanks for working through all this.


https://reviews.llvm.org/D37163