[PATCH] Expand SimplifyCFG to convert certain simple switches to selects
Marcello Maggioni
hayarms at gmail.com
Fri Jun 20 20:36:35 PDT 2014
================
Comment at: lib/Transforms/Utils/SimplifyCFG.cpp:3766
@@ +3765,3 @@
+// select.
+static Value *
+ConvertTwoCaseSwitch(const SmallVectorImpl<ConstantInt *> &FirstGroupCases,
----------------
Philip Reames wrote:
> It looks like this code is actually handling two cases + default. Update the comment?
>
> Also, is it always profitable to replace one switch with two selects? I would guess not, but will defer to actual measurement.
On X86 from the measurements I did with a very simple micro benchmark it seems profitable.
This is the code of the benchmark:
int foo1_with_def(int a) {
switch(a) {
case 10:
return 10;
case 20:
return 2;
}
return 4;
}
int main() {
int a = 0;
int ret = 0;
for (; a < 2000000000; ++a) {
ret |= foo1_with_def(a);
}
return ret;
}
And the generated code for the functions containing the switch is (+ performance results):
LLVM without patch:
_foo1_with_def:
movl $10, %eax
cmpl $10, %edi
je LBB0_4
cmpl $20, %edi
jne LBB0_3
movl $2, %eax
retq
LBB0_3:
movl $4, %eax
LBB0_4:
retq
real 0m5.522s
user 0m5.519s
sys 0m0.002s
LLVM with patch:
_foo1_with_def:
cmpl $10, %edi
movl $4, %ecx
cmovel %edi, %ecx
cmpl $20, %edi
movl $2, %eax
cmovnel %ecx, %eax
retq
real 0m3.233s
user 0m3.230s
sys 0m0.002s
I don't have any real world application though to back this up (it looks like a good result though).
In addition to that X86 is quite a control flow "friendly" architecture with respect to many others and if the results are positive on X86 I would expect that on some more custom architectures where control flow is more expensive this optimization might actually be even more effective.
================
Comment at: lib/Transforms/Utils/SimplifyCFG.cpp:3955
@@ +3954,3 @@
+ (FirstPossibleHits + SecondPossibleHits)) != 0);
+ DefaultCanTrigger &= DefaultResult != nullptr;
+
----------------
Philip Reames wrote:
> It seems like proving the switch default is dead is a useful optimization even if we can make no other changes. Should this be separated and generalized?
Do you mean making it a generic independent static function in SimplifyCFG.cpp ?
http://reviews.llvm.org/D4219
More information about the llvm-commits
mailing list