6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-12-14 11:32:34 +00:00
Code Issues Projects Releases Wiki Activity
435654b181
llvm-6502/test/Transforms/LoopUnswitch/2011-11-18-TwoSwitches.ll

139 lines
5.5 KiB
LLVM
Raw Normal View History

Reinstate r146578; it doesn't appear to be the cause of some recent execution- time regressions. In general, it is beneficial to compile-time. Original commit message: Fix for bug #11429: Wrong behaviour for switches. Small improvement for code size heuristics. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147175 91177308-0d34-0410-b5e6-96231b3b80d8
2011-12-22 21:06:36 +00:00
; RUN: opt -loop-unswitch -loop-unswitch-threshold 1000 -disable-output -stats -info-output-file - < %s | FileCheck --check-prefix=STATS %s
; RUN: opt -S -loop-unswitch -loop-unswitch-threshold 1000 -verify-loop-info -verify-dom-info %s | FileCheck %s
; STATS: 1 loop-simplify - Number of pre-header or exit blocks inserted
; STATS: 3 loop-unswitch - Number of switches unswitched
; CHECK: %1 = icmp eq i32 %c, 1
; CHECK-NEXT: br i1 %1, label %.split.us, label %..split_crit_edge
; CHECK: ..split_crit_edge: ; preds = %0
; CHECK-NEXT: br label %.split
; CHECK: .split.us: ; preds = %0
; CHECK-NEXT: %2 = icmp eq i32 %d, 1
; CHECK-NEXT: br i1 %2, label %.split.us.split.us, label %.split.us..split.us.split_crit_edge
; CHECK: .split.us..split.us.split_crit_edge: ; preds = %.split.us
; CHECK-NEXT: br label %.split.us.split
; CHECK: .split.us.split.us: ; preds = %.split.us
; CHECK-NEXT: br label %loop_begin.us.us
; CHECK: loop_begin.us.us: ; preds = %loop_begin.backedge.us.us, %.split.us.split.us
; CHECK-NEXT: %var_val.us.us = load i32* %var
; CHECK-NEXT: switch i32 1, label %second_switch.us.us [
; CHECK-NEXT: i32 1, label %inc.us.us
; CHECK: second_switch.us.us: ; preds = %loop_begin.us.us
; CHECK-NEXT: switch i32 1, label %default.us.us [
; CHECK-NEXT: i32 1, label %inc.us.us
Enable the new LoopInfo algorithm by default. The primary advantage is that loop optimizations will be applied in a stable order. This helps debugging and unit test creation. It is also a better overall implementation without pathologically bad performance on deep functions. On large functions (llvm-stress --size=200000 | opt -loops) Before: 0.1263s After: 0.0225s On deep functions (after tweaking llvm-stress, thanks Nadav): Before: 0.2281s After: 0.0227s See r158790 for more comments. The loop tree is now consistently generated in forward order, but loop passes are applied in reverse order over the program. If we have a loop optimization that prefers forward order, that can easily be achieved by adding a different type of LoopPassManager. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159183 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-26 04:11:38 +00:00
; CHECK: inc.us.us: ; preds = %second_switch.us.us, %loop_begin.us.us
; CHECK-NEXT: call void @incf() noreturn nounwind
; CHECK-NEXT: br label %loop_begin.backedge.us.us
Reinstate r146578; it doesn't appear to be the cause of some recent execution- time regressions. In general, it is beneficial to compile-time. Original commit message: Fix for bug #11429: Wrong behaviour for switches. Small improvement for code size heuristics. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147175 91177308-0d34-0410-b5e6-96231b3b80d8
2011-12-22 21:06:36 +00:00
; CHECK: .split.us.split: ; preds = %.split.us..split.us.split_crit_edge
; CHECK-NEXT: br label %loop_begin.us
; CHECK: loop_begin.us: ; preds = %loop_begin.backedge.us, %.split.us.split
; CHECK-NEXT: %var_val.us = load i32* %var
; CHECK-NEXT: switch i32 1, label %second_switch.us [
; CHECK-NEXT: i32 1, label %inc.us
; CHECK: second_switch.us: ; preds = %loop_begin.us
; CHECK-NEXT: switch i32 %d, label %default.us [
; CHECK-NEXT: i32 1, label %second_switch.us.inc.us_crit_edge
; CHECK-NEXT: ]
; CHECK: second_switch.us.inc.us_crit_edge: ; preds = %second_switch.us
; CHECK-NEXT: br i1 true, label %us-unreachable8, label %inc.us
Enable the new LoopInfo algorithm by default. The primary advantage is that loop optimizations will be applied in a stable order. This helps debugging and unit test creation. It is also a better overall implementation without pathologically bad performance on deep functions. On large functions (llvm-stress --size=200000 | opt -loops) Before: 0.1263s After: 0.0225s On deep functions (after tweaking llvm-stress, thanks Nadav): Before: 0.2281s After: 0.0227s See r158790 for more comments. The loop tree is now consistently generated in forward order, but loop passes are applied in reverse order over the program. If we have a loop optimization that prefers forward order, that can easily be achieved by adding a different type of LoopPassManager. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159183 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-26 04:11:38 +00:00
; CHECK: inc.us: ; preds = %second_switch.us.inc.us_crit_edge, %loop_begin.us
; CHECK-NEXT: call void @incf() noreturn nounwind
; CHECK-NEXT: br label %loop_begin.backedge.us
Reinstate r146578; it doesn't appear to be the cause of some recent execution- time regressions. In general, it is beneficial to compile-time. Original commit message: Fix for bug #11429: Wrong behaviour for switches. Small improvement for code size heuristics. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147175 91177308-0d34-0410-b5e6-96231b3b80d8
2011-12-22 21:06:36 +00:00
; CHECK: .split: ; preds = %..split_crit_edge
; CHECK-NEXT: %3 = icmp eq i32 %d, 1
; CHECK-NEXT: br i1 %3, label %.split.split.us, label %.split..split.split_crit_edge
; CHECK: .split..split.split_crit_edge: ; preds = %.split
; CHECK-NEXT: br label %.split.split
; CHECK: .split.split.us: ; preds = %.split
; CHECK-NEXT: br label %loop_begin.us1
; CHECK: loop_begin.us1: ; preds = %loop_begin.backedge.us6, %.split.split.us
; CHECK-NEXT: %var_val.us2 = load i32* %var
Enable the new LoopInfo algorithm by default. The primary advantage is that loop optimizations will be applied in a stable order. This helps debugging and unit test creation. It is also a better overall implementation without pathologically bad performance on deep functions. On large functions (llvm-stress --size=200000 | opt -loops) Before: 0.1263s After: 0.0225s On deep functions (after tweaking llvm-stress, thanks Nadav): Before: 0.2281s After: 0.0227s See r158790 for more comments. The loop tree is now consistently generated in forward order, but loop passes are applied in reverse order over the program. If we have a loop optimization that prefers forward order, that can easily be achieved by adding a different type of LoopPassManager. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159183 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-26 04:11:38 +00:00
; CHECK-NEXT: switch i32 %c, label %second_switch.us3 [
Reinstate r146578; it doesn't appear to be the cause of some recent execution- time regressions. In general, it is beneficial to compile-time. Original commit message: Fix for bug #11429: Wrong behaviour for switches. Small improvement for code size heuristics. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147175 91177308-0d34-0410-b5e6-96231b3b80d8
2011-12-22 21:06:36 +00:00
; CHECK-NEXT: i32 1, label %loop_begin.inc_crit_edge.us
; CHECK-NEXT: ]
Enable the new LoopInfo algorithm by default. The primary advantage is that loop optimizations will be applied in a stable order. This helps debugging and unit test creation. It is also a better overall implementation without pathologically bad performance on deep functions. On large functions (llvm-stress --size=200000 | opt -loops) Before: 0.1263s After: 0.0225s On deep functions (after tweaking llvm-stress, thanks Nadav): Before: 0.2281s After: 0.0227s See r158790 for more comments. The loop tree is now consistently generated in forward order, but loop passes are applied in reverse order over the program. If we have a loop optimization that prefers forward order, that can easily be achieved by adding a different type of LoopPassManager. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159183 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-26 04:11:38 +00:00
; CHECK: second_switch.us3: ; preds = %loop_begin.us1
Reinstate r146578; it doesn't appear to be the cause of some recent execution- time regressions. In general, it is beneficial to compile-time. Original commit message: Fix for bug #11429: Wrong behaviour for switches. Small improvement for code size heuristics. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147175 91177308-0d34-0410-b5e6-96231b3b80d8
2011-12-22 21:06:36 +00:00
; CHECK-NEXT: switch i32 1, label %default.us5 [
Enable the new LoopInfo algorithm by default. The primary advantage is that loop optimizations will be applied in a stable order. This helps debugging and unit test creation. It is also a better overall implementation without pathologically bad performance on deep functions. On large functions (llvm-stress --size=200000 | opt -loops) Before: 0.1263s After: 0.0225s On deep functions (after tweaking llvm-stress, thanks Nadav): Before: 0.2281s After: 0.0227s See r158790 for more comments. The loop tree is now consistently generated in forward order, but loop passes are applied in reverse order over the program. If we have a loop optimization that prefers forward order, that can easily be achieved by adding a different type of LoopPassManager. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159183 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-26 04:11:38 +00:00
; CHECK-NEXT: i32 1, label %inc.us4
Reinstate r146578; it doesn't appear to be the cause of some recent execution- time regressions. In general, it is beneficial to compile-time. Original commit message: Fix for bug #11429: Wrong behaviour for switches. Small improvement for code size heuristics. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147175 91177308-0d34-0410-b5e6-96231b3b80d8
2011-12-22 21:06:36 +00:00
; CHECK-NEXT: ]
Enable the new LoopInfo algorithm by default. The primary advantage is that loop optimizations will be applied in a stable order. This helps debugging and unit test creation. It is also a better overall implementation without pathologically bad performance on deep functions. On large functions (llvm-stress --size=200000 | opt -loops) Before: 0.1263s After: 0.0225s On deep functions (after tweaking llvm-stress, thanks Nadav): Before: 0.2281s After: 0.0227s See r158790 for more comments. The loop tree is now consistently generated in forward order, but loop passes are applied in reverse order over the program. If we have a loop optimization that prefers forward order, that can easily be achieved by adding a different type of LoopPassManager. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159183 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-26 04:11:38 +00:00
; CHECK: inc.us4: ; preds = %loop_begin.inc_crit_edge.us, %second_switch.us3
; CHECK-NEXT: call void @incf() noreturn nounwind
; CHECK-NEXT: br label %loop_begin.backedge.us6
Reinstate r146578; it doesn't appear to be the cause of some recent execution- time regressions. In general, it is beneficial to compile-time. Original commit message: Fix for bug #11429: Wrong behaviour for switches. Small improvement for code size heuristics. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147175 91177308-0d34-0410-b5e6-96231b3b80d8
2011-12-22 21:06:36 +00:00
; CHECK: loop_begin.inc_crit_edge.us: ; preds = %loop_begin.us1
Enable the new LoopInfo algorithm by default. The primary advantage is that loop optimizations will be applied in a stable order. This helps debugging and unit test creation. It is also a better overall implementation without pathologically bad performance on deep functions. On large functions (llvm-stress --size=200000 | opt -loops) Before: 0.1263s After: 0.0225s On deep functions (after tweaking llvm-stress, thanks Nadav): Before: 0.2281s After: 0.0227s See r158790 for more comments. The loop tree is now consistently generated in forward order, but loop passes are applied in reverse order over the program. If we have a loop optimization that prefers forward order, that can easily be achieved by adding a different type of LoopPassManager. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159183 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-26 04:11:38 +00:00
; CHECK-NEXT: br i1 true, label %us-unreachable.us-lcssa.us, label %inc.us4
Reinstate r146578; it doesn't appear to be the cause of some recent execution- time regressions. In general, it is beneficial to compile-time. Original commit message: Fix for bug #11429: Wrong behaviour for switches. Small improvement for code size heuristics. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147175 91177308-0d34-0410-b5e6-96231b3b80d8
2011-12-22 21:06:36 +00:00
; CHECK: .split.split: ; preds = %.split..split.split_crit_edge
; CHECK-NEXT: br label %loop_begin
; CHECK: loop_begin: ; preds = %loop_begin.backedge, %.split.split
; CHECK-NEXT: %var_val = load i32* %var
; CHECK-NEXT: switch i32 %c, label %second_switch [
; CHECK-NEXT: i32 1, label %loop_begin.inc_crit_edge
; CHECK-NEXT: ]
; CHECK: loop_begin.inc_crit_edge: ; preds = %loop_begin
; CHECK-NEXT: br i1 true, label %us-unreachable.us-lcssa, label %inc
; CHECK: second_switch: ; preds = %loop_begin
; CHECK-NEXT: switch i32 %d, label %default [
; CHECK-NEXT: i32 1, label %second_switch.inc_crit_edge
; CHECK-NEXT: ]
; CHECK: second_switch.inc_crit_edge: ; preds = %second_switch
; CHECK-NEXT: br i1 true, label %us-unreachable7, label %inc
define i32 @test(i32* %var) {
%mem = alloca i32
store i32 2, i32* %mem
%c = load i32* %mem
%d = load i32* %mem
br label %loop_begin
loop_begin:
%var_val = load i32* %var
switch i32 %c, label %second_switch [
i32 1, label %inc
]
second_switch:
switch i32 %d, label %default [
i32 1, label %inc
]
inc:
call void @incf() noreturn nounwind
br label %loop_begin
Enable the new LoopInfo algorithm by default. The primary advantage is that loop optimizations will be applied in a stable order. This helps debugging and unit test creation. It is also a better overall implementation without pathologically bad performance on deep functions. On large functions (llvm-stress --size=200000 | opt -loops) Before: 0.1263s After: 0.0225s On deep functions (after tweaking llvm-stress, thanks Nadav): Before: 0.2281s After: 0.0227s See r158790 for more comments. The loop tree is now consistently generated in forward order, but loop passes are applied in reverse order over the program. If we have a loop optimization that prefers forward order, that can easily be achieved by adding a different type of LoopPassManager. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159183 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-26 04:11:38 +00:00
default:
Reinstate r146578; it doesn't appear to be the cause of some recent execution- time regressions. In general, it is beneficial to compile-time. Original commit message: Fix for bug #11429: Wrong behaviour for switches. Small improvement for code size heuristics. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147175 91177308-0d34-0410-b5e6-96231b3b80d8
2011-12-22 21:06:36 +00:00
br label %loop_begin
loop_exit:
ret i32 0
}
declare void @incf() noreturn
declare void @decf() noreturn
Reference in New Issue Copy Permalink