[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