[PATCH] D65148: [SimplifyCFG] Bump phi-node-folding-threshold from 2 to 3

Roman Lebedev via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Sep 4 15:45:50 PDT 2019


lebedev.ri added a comment.

In D65148#1658514 <https://reviews.llvm.org/D65148#1658514>, @efriedma wrote:

> Aggressively flattening the CFG has tradeoffs.  If the branch is very unpredictable,
>  or it unblocks some important optimization, it can have a huge benefit.
>  If you don't fall into one of those cases, you're mildly degrading the performance
>  of a bunch of code, by forcing the execution of instructions where the result isn't used.


Yep, and that matches my benchmarks in D59035 <https://reviews.llvm.org/D59035>.

I have added tests for several cases that will be affected by this, and stated
some perf numbers i'm seeing on x86 on some my code (results are mildly great);
separately, @dmgreen has performed some ARM benchmarks
(https://reviews.llvm.org/D65148#1650984, also seemingly-ok)

> I'd like some idea of how often we actually end up with a "select" in the generated code,
>  vs. getting transformed back to a branch by some later pass.
>  We do some select->branch conversion before isel, and on x86,
>  we also do cmov->branch conversion after isel.

Also note that if it was specified that the branch is predictable (via PGO/`__builtin_assume()`),
the `select` **will** be converted back to branch.

So, what metric specifically do you want to see, a count of CMOV instructions at the end of codegen, how it is changed by this patch?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65148/new/

https://reviews.llvm.org/D65148





More information about the llvm-commits mailing list