[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