[PATCH] D29870: [InlineCost] Increase the cost of Switch
Chandler Carruth via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Feb 13 09:39:10 PST 2017
chandlerc added inline comments.
================
Comment at: lib/Analysis/InlineCost.cpp:1031
- // Otherwise, we need to accumulate a cost proportional to the number of
- // distinct successor blocks. This fan-out in the CFG cannot be represented
- // for free even if we can represent the core switch as a jumptable that
- // takes a single instruction.
+ // Otherwise, we assume the most general case where the big swith is lowered
+ // into a balanced binary tree, the probability of entering each case is
----------------
junbuml wrote:
> I wonder if this assumption is reasonable enough. If I remember correctly, a switch could also end up with a jump table or mix of jump table and BTree depending on the number of case, comparison value, etc.
Yes, see my top level comment -- I think something more detailed than this will be necessary in order to model the usage of jump tables.
I wonder if we should just expose a TTI hook that can query the same logic that lowering actually uses to decide this....
Repository:
rL LLVM
https://reviews.llvm.org/D29870
More information about the llvm-commits
mailing list