[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