[PATCH] D21291: [SimplifyCFG] Range reduce switches

Hans Wennborg via llvm-commits llvm-commits at lists.llvm.org
Wed Jul 27 11:42:20 PDT 2016


hans added a comment.

The code seems fine to me. I'm OK with this landing.

I still wonder if we shouldn't just do this in SimplifyCFG though. How big is the pay-off here? I've seen switches with e.g. a common factor of 10 in the cases, but are powers of 2 common enough to justify the complexity, especially if we start looking at densifying only parts of a switch?

I just imagine that doing this in SimplifyCFG instead would be so much simpler: we'd look for a common power-of-two factor and slap a rotate-right operation in front of the switch. This could potentially allow more lookup tables, jump tables, bit-test lowerings, new adjacent cases, who knows -- one could argue that densifying the switch is just general goodness, and if it doesn't pay off it's just an extra rotate which is cheap.


================
Comment at: lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:8389
@@ -8323,3 +8388,3 @@
 
   // The algorithm below is not suitable for -O0.
   if (TM.getOptLevel() == CodeGenOpt::None)
----------------
This comment refers to the algorithm that finds dense partitions in Clusters, which is O(n^2). Now that there's more stuff happening below, maybe update it to "don't try any harder at -O0", or you could jsut move your code before it, since I don't think it would be a problem running it a -O0.


Repository:
  rL LLVM

https://reviews.llvm.org/D21291





More information about the llvm-commits mailing list