maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Transforms/RewriteStatepointsForGC/base-pointers.ll

155 lines
6.0 KiB
LLVM
Raw Normal View History

[RS4GC] Clamp UseDeoptBundles to true and update tests The full diff for the test directory may be hard to read because of the filename clash; so here's all that happened as far as the tests are concerned: ``` cd test/Transforms/RewriteStatepointsForGC git rm *ll git mv deopt-bundles/* ./ rmdir deopt-bundles find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g' ``` llvm-svn: 259129
2016-01-29 08:28:57 +08:00
; RUN: opt < %s -rewrite-statepoints-for-gc -S 2>&1 | FileCheck %s
[RewriteStatepointsForGC] Add tests for the base pointer identification algorithm These tests cover the 'base object' identification and rewritting portion of RewriteStatepointsForGC. These aren't completely exhaustive, but they've proven to be reasonable effective over time at finding regressions. In the process of porting these tests over, I found my first "cleanup per llvm code style standards" bug. We were relying on the order of iteration when testing the base pointers found for a derived pointer. When we switched from std::set to DenseSet, this stopped being a safe assumption. I'm suspecting I'm going to find more of those. In particular, I'm now really wondering about the main iteration loop for this algorithm. I need to go take a closer look at the assumptions there. I'm not really happy with the fact these are testing what is essentially debug output (i.e. enabled via command line flags). Suggestions for how to structure this better are very welcome. llvm-svn: 230818
2015-02-28 08:20:48 +08:00
; The rewriting needs to make %obj loop variant by inserting a phi
; of the original value and it's relocation.
[RS4GC] Clamp UseDeoptBundles to true and update tests The full diff for the test directory may be hard to read because of the filename clash; so here's all that happened as far as the tests are concerned: ``` cd test/Transforms/RewriteStatepointsForGC git rm *ll git mv deopt-bundles/* ./ rmdir deopt-bundles find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g' ``` llvm-svn: 259129
2016-01-29 08:28:57 +08:00
declare i64 addrspace(1)* @generate_obj() "gc-leaf-function"
declare void @use_obj(i64 addrspace(1)*) "gc-leaf-function"
[RewriteStatepointsForGC] Add tests for the base pointer identification algorithm These tests cover the 'base object' identification and rewritting portion of RewriteStatepointsForGC. These aren't completely exhaustive, but they've proven to be reasonable effective over time at finding regressions. In the process of porting these tests over, I found my first "cleanup per llvm code style standards" bug. We were relying on the order of iteration when testing the base pointers found for a derived pointer. When we switched from std::set to DenseSet, this stopped being a safe assumption. I'm suspecting I'm going to find more of those. In particular, I'm now really wondering about the main iteration loop for this algorithm. I need to go take a closer look at the assumptions there. I'm not really happy with the fact these are testing what is essentially debug output (i.e. enabled via command line flags). Suggestions for how to structure this better are very welcome. llvm-svn: 230818
2015-02-28 08:20:48 +08:00
define void @def_use_safepoint() gc "statepoint-example" {
; CHECK-LABEL: def_use_safepoint
[RS4GC] Clamp UseDeoptBundles to true and update tests The full diff for the test directory may be hard to read because of the filename clash; so here's all that happened as far as the tests are concerned: ``` cd test/Transforms/RewriteStatepointsForGC git rm *ll git mv deopt-bundles/* ./ rmdir deopt-bundles find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g' ``` llvm-svn: 259129
2016-01-29 08:28:57 +08:00
; CHECK: phi i64 addrspace(1)*
; CHECK-DAG: [ %obj.relocated.casted, %loop ]
; CHECK-DAG: [ %obj, %entry ]
[RewriteStatepointsForGC] Add tests for the base pointer identification algorithm These tests cover the 'base object' identification and rewritting portion of RewriteStatepointsForGC. These aren't completely exhaustive, but they've proven to be reasonable effective over time at finding regressions. In the process of porting these tests over, I found my first "cleanup per llvm code style standards" bug. We were relying on the order of iteration when testing the base pointers found for a derived pointer. When we switched from std::set to DenseSet, this stopped being a safe assumption. I'm suspecting I'm going to find more of those. In particular, I'm now really wondering about the main iteration loop for this algorithm. I need to go take a closer look at the assumptions there. I'm not really happy with the fact these are testing what is essentially debug output (i.e. enabled via command line flags). Suggestions for how to structure this better are very welcome. llvm-svn: 230818
2015-02-28 08:20:48 +08:00
entry:
%obj = call i64 addrspace(1)* @generate_obj()
br label %loop
[RS4GC] Clamp UseDeoptBundles to true and update tests The full diff for the test directory may be hard to read because of the filename clash; so here's all that happened as far as the tests are concerned: ``` cd test/Transforms/RewriteStatepointsForGC git rm *ll git mv deopt-bundles/* ./ rmdir deopt-bundles find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g' ``` llvm-svn: 259129
2016-01-29 08:28:57 +08:00
loop: ; preds = %loop, %entry
[RewriteStatepointsForGC] Add tests for the base pointer identification algorithm These tests cover the 'base object' identification and rewritting portion of RewriteStatepointsForGC. These aren't completely exhaustive, but they've proven to be reasonable effective over time at finding regressions. In the process of porting these tests over, I found my first "cleanup per llvm code style standards" bug. We were relying on the order of iteration when testing the base pointers found for a derived pointer. When we switched from std::set to DenseSet, this stopped being a safe assumption. I'm suspecting I'm going to find more of those. In particular, I'm now really wondering about the main iteration loop for this algorithm. I need to go take a closer look at the assumptions there. I'm not really happy with the fact these are testing what is essentially debug output (i.e. enabled via command line flags). Suggestions for how to structure this better are very welcome. llvm-svn: 230818
2015-02-28 08:20:48 +08:00
call void @use_obj(i64 addrspace(1)* %obj)
[RS4GC] Clamp UseDeoptBundles to true and update tests The full diff for the test directory may be hard to read because of the filename clash; so here's all that happened as far as the tests are concerned: ``` cd test/Transforms/RewriteStatepointsForGC git rm *ll git mv deopt-bundles/* ./ rmdir deopt-bundles find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g' ``` llvm-svn: 259129
2016-01-29 08:28:57 +08:00
call void @do_safepoint() [ "deopt"(i32 0, i32 -1, i32 0, i32 0, i32 0) ]
[RewriteStatepointsForGC] Add tests for the base pointer identification algorithm These tests cover the 'base object' identification and rewritting portion of RewriteStatepointsForGC. These aren't completely exhaustive, but they've proven to be reasonable effective over time at finding regressions. In the process of porting these tests over, I found my first "cleanup per llvm code style standards" bug. We were relying on the order of iteration when testing the base pointers found for a derived pointer. When we switched from std::set to DenseSet, this stopped being a safe assumption. I'm suspecting I'm going to find more of those. In particular, I'm now really wondering about the main iteration loop for this algorithm. I need to go take a closer look at the assumptions there. I'm not really happy with the fact these are testing what is essentially debug output (i.e. enabled via command line flags). Suggestions for how to structure this better are very welcome. llvm-svn: 230818
2015-02-28 08:20:48 +08:00
br label %loop
}
declare void @do_safepoint()
declare void @parse_point(i64 addrspace(1)*)
define i64 addrspace(1)* @test1(i32 %caller, i8 addrspace(1)* %a, i8 addrspace(1)* %b, i32 %unknown) gc "statepoint-example" {
; CHECK-LABEL: test1
[RS4GC] Clamp UseDeoptBundles to true and update tests The full diff for the test directory may be hard to read because of the filename clash; so here's all that happened as far as the tests are concerned: ``` cd test/Transforms/RewriteStatepointsForGC git rm *ll git mv deopt-bundles/* ./ rmdir deopt-bundles find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g' ``` llvm-svn: 259129
2016-01-29 08:28:57 +08:00
entry:
[RewriteStatepointsForGC] Add tests for the base pointer identification algorithm These tests cover the 'base object' identification and rewritting portion of RewriteStatepointsForGC. These aren't completely exhaustive, but they've proven to be reasonable effective over time at finding regressions. In the process of porting these tests over, I found my first "cleanup per llvm code style standards" bug. We were relying on the order of iteration when testing the base pointers found for a derived pointer. When we switched from std::set to DenseSet, this stopped being a safe assumption. I'm suspecting I'm going to find more of those. In particular, I'm now really wondering about the main iteration loop for this algorithm. I need to go take a closer look at the assumptions there. I'm not really happy with the fact these are testing what is essentially debug output (i.e. enabled via command line flags). Suggestions for how to structure this better are very welcome. llvm-svn: 230818
2015-02-28 08:20:48 +08:00
br i1 undef, label %left, label %right
[RS4GC] Clamp UseDeoptBundles to true and update tests The full diff for the test directory may be hard to read because of the filename clash; so here's all that happened as far as the tests are concerned: ``` cd test/Transforms/RewriteStatepointsForGC git rm *ll git mv deopt-bundles/* ./ rmdir deopt-bundles find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g' ``` llvm-svn: 259129
2016-01-29 08:28:57 +08:00
left: ; preds = %entry
[RewriteStatepointsForGC] Add tests for the base pointer identification algorithm These tests cover the 'base object' identification and rewritting portion of RewriteStatepointsForGC. These aren't completely exhaustive, but they've proven to be reasonable effective over time at finding regressions. In the process of porting these tests over, I found my first "cleanup per llvm code style standards" bug. We were relying on the order of iteration when testing the base pointers found for a derived pointer. When we switched from std::set to DenseSet, this stopped being a safe assumption. I'm suspecting I'm going to find more of those. In particular, I'm now really wondering about the main iteration loop for this algorithm. I need to go take a closer look at the assumptions there. I'm not really happy with the fact these are testing what is essentially debug output (i.e. enabled via command line flags). Suggestions for how to structure this better are very welcome. llvm-svn: 230818
2015-02-28 08:20:48 +08:00
; CHECK: left:
; CHECK-NEXT: %a.cast = bitcast i8 addrspace(1)* %a to i64 addrspace(1)*
; CHECK-NEXT: [[CAST_L:%.*]] = bitcast i8 addrspace(1)* %a to i64 addrspace(1)*
; Our safepoint placement pass calls removeUnreachableBlocks, which does a bunch
; of simplifications to branch instructions. This bug is visible only when
; there are multiple branches into the same block from the same predecessor, and
; the following ceremony is to make that artefact survive a call to
; removeUnreachableBlocks. As an example, "br i1 undef, label %merge, label %merge"
; will get simplified to "br label %merge" by removeUnreachableBlocks.
[RS4GC] Clamp UseDeoptBundles to true and update tests The full diff for the test directory may be hard to read because of the filename clash; so here's all that happened as far as the tests are concerned: ``` cd test/Transforms/RewriteStatepointsForGC git rm *ll git mv deopt-bundles/* ./ rmdir deopt-bundles find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g' ``` llvm-svn: 259129
2016-01-29 08:28:57 +08:00
%a.cast = bitcast i8 addrspace(1)* %a to i64 addrspace(1)*
switch i32 %unknown, label %right [
i32 0, label %merge
i32 1, label %merge
i32 5, label %merge
i32 3, label %right
]
right: ; preds = %left, %left, %entry
[RewriteStatepointsForGC] Add tests for the base pointer identification algorithm These tests cover the 'base object' identification and rewritting portion of RewriteStatepointsForGC. These aren't completely exhaustive, but they've proven to be reasonable effective over time at finding regressions. In the process of porting these tests over, I found my first "cleanup per llvm code style standards" bug. We were relying on the order of iteration when testing the base pointers found for a derived pointer. When we switched from std::set to DenseSet, this stopped being a safe assumption. I'm suspecting I'm going to find more of those. In particular, I'm now really wondering about the main iteration loop for this algorithm. I need to go take a closer look at the assumptions there. I'm not really happy with the fact these are testing what is essentially debug output (i.e. enabled via command line flags). Suggestions for how to structure this better are very welcome. llvm-svn: 230818
2015-02-28 08:20:48 +08:00
; CHECK: right:
; CHECK-NEXT: %b.cast = bitcast i8 addrspace(1)* %b to i64 addrspace(1)*
; CHECK-NEXT: [[CAST_R:%.*]] = bitcast i8 addrspace(1)* %b to i64 addrspace(1)*
[RS4GC] Clamp UseDeoptBundles to true and update tests The full diff for the test directory may be hard to read because of the filename clash; so here's all that happened as far as the tests are concerned: ``` cd test/Transforms/RewriteStatepointsForGC git rm *ll git mv deopt-bundles/* ./ rmdir deopt-bundles find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g' ``` llvm-svn: 259129
2016-01-29 08:28:57 +08:00
%b.cast = bitcast i8 addrspace(1)* %b to i64 addrspace(1)*
br label %merge
[RewriteStatepointsForGC] Add tests for the base pointer identification algorithm These tests cover the 'base object' identification and rewritting portion of RewriteStatepointsForGC. These aren't completely exhaustive, but they've proven to be reasonable effective over time at finding regressions. In the process of porting these tests over, I found my first "cleanup per llvm code style standards" bug. We were relying on the order of iteration when testing the base pointers found for a derived pointer. When we switched from std::set to DenseSet, this stopped being a safe assumption. I'm suspecting I'm going to find more of those. In particular, I'm now really wondering about the main iteration loop for this algorithm. I need to go take a closer look at the assumptions there. I'm not really happy with the fact these are testing what is essentially debug output (i.e. enabled via command line flags). Suggestions for how to structure this better are very welcome. llvm-svn: 230818
2015-02-28 08:20:48 +08:00
[RS4GC] Clamp UseDeoptBundles to true and update tests The full diff for the test directory may be hard to read because of the filename clash; so here's all that happened as far as the tests are concerned: ``` cd test/Transforms/RewriteStatepointsForGC git rm *ll git mv deopt-bundles/* ./ rmdir deopt-bundles find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g' ``` llvm-svn: 259129
2016-01-29 08:28:57 +08:00
merge: ; preds = %right, %left, %left, %left
[RewriteStatepointsForGC] Add tests for the base pointer identification algorithm These tests cover the 'base object' identification and rewritting portion of RewriteStatepointsForGC. These aren't completely exhaustive, but they've proven to be reasonable effective over time at finding regressions. In the process of porting these tests over, I found my first "cleanup per llvm code style standards" bug. We were relying on the order of iteration when testing the base pointers found for a derived pointer. When we switched from std::set to DenseSet, this stopped being a safe assumption. I'm suspecting I'm going to find more of those. In particular, I'm now really wondering about the main iteration loop for this algorithm. I need to go take a closer look at the assumptions there. I'm not really happy with the fact these are testing what is essentially debug output (i.e. enabled via command line flags). Suggestions for how to structure this better are very welcome. llvm-svn: 230818
2015-02-28 08:20:48 +08:00
; CHECK: merge:
[RewriteStatepointsForGC] Adjust naming scheme to be more stable The names for instructions inserted were previous dependent on iteration order. By deriving the names from the original instructions, we can avoid instability in tests without resorting to ordered traversals. It also makes the IR mildly easier to read at large scale. llvm-svn: 243140
2015-07-25 03:01:39 +08:00
; CHECK-NEXT: %value.base = phi i64 addrspace(1)* [ [[CAST_L]], %left ], [ [[CAST_L]], %left ], [ [[CAST_L]], %left ], [ [[CAST_R]], %right ], !is_base_value !0
[RS4GC] Clamp UseDeoptBundles to true and update tests The full diff for the test directory may be hard to read because of the filename clash; so here's all that happened as far as the tests are concerned: ``` cd test/Transforms/RewriteStatepointsForGC git rm *ll git mv deopt-bundles/* ./ rmdir deopt-bundles find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g' ``` llvm-svn: 259129
2016-01-29 08:28:57 +08:00
%value = phi i64 addrspace(1)* [ %a.cast, %left ], [ %a.cast, %left ], [ %a.cast, %left ], [ %b.cast, %right ]
call void @parse_point(i64 addrspace(1)* %value) [ "deopt"(i32 0, i32 0, i32 0, i32 0, i32 0) ]
[RewriteStatepointsForGC] Add tests for the base pointer identification algorithm These tests cover the 'base object' identification and rewritting portion of RewriteStatepointsForGC. These aren't completely exhaustive, but they've proven to be reasonable effective over time at finding regressions. In the process of porting these tests over, I found my first "cleanup per llvm code style standards" bug. We were relying on the order of iteration when testing the base pointers found for a derived pointer. When we switched from std::set to DenseSet, this stopped being a safe assumption. I'm suspecting I'm going to find more of those. In particular, I'm now really wondering about the main iteration loop for this algorithm. I need to go take a closer look at the assumptions there. I'm not really happy with the fact these are testing what is essentially debug output (i.e. enabled via command line flags). Suggestions for how to structure this better are very welcome. llvm-svn: 230818
2015-02-28 08:20:48 +08:00
ret i64 addrspace(1)* %value
}
;; The purpose of this test is to ensure that when two live values share a
;; base defining value with inherent conflicts, we end up with a *single*
;; base phi/select per such node. This is testing an optimization, not a
;; fundemental correctness criteria
[RS4GC] Clamp UseDeoptBundles to true and update tests The full diff for the test directory may be hard to read because of the filename clash; so here's all that happened as far as the tests are concerned: ``` cd test/Transforms/RewriteStatepointsForGC git rm *ll git mv deopt-bundles/* ./ rmdir deopt-bundles find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g' ``` llvm-svn: 259129
2016-01-29 08:28:57 +08:00
define void @test2(i1 %cnd, i64 addrspace(1)* %base_obj, i64 addrspace(1)* %base_arg2) gc "statepoint-example" {
[RewriteStatepointsForGC] Add tests for the base pointer identification algorithm These tests cover the 'base object' identification and rewritting portion of RewriteStatepointsForGC. These aren't completely exhaustive, but they've proven to be reasonable effective over time at finding regressions. In the process of porting these tests over, I found my first "cleanup per llvm code style standards" bug. We were relying on the order of iteration when testing the base pointers found for a derived pointer. When we switched from std::set to DenseSet, this stopped being a safe assumption. I'm suspecting I'm going to find more of those. In particular, I'm now really wondering about the main iteration loop for this algorithm. I need to go take a closer look at the assumptions there. I'm not really happy with the fact these are testing what is essentially debug output (i.e. enabled via command line flags). Suggestions for how to structure this better are very welcome. llvm-svn: 230818
2015-02-28 08:20:48 +08:00
; CHECK-LABEL: @test2
entry:
%obj = getelementptr i64, i64 addrspace(1)* %base_obj, i32 1
br label %loop
; CHECK-LABEL: loop
[RewriteStatepointsForGC] Adjust naming scheme to be more stable The names for instructions inserted were previous dependent on iteration order. By deriving the names from the original instructions, we can avoid instability in tests without resorting to ordered traversals. It also makes the IR mildly easier to read at large scale. llvm-svn: 243140
2015-07-25 03:01:39 +08:00
; CHECK: %current.base = phi i64 addrspace(1)*
[RewriteStatepointsForGC] Add tests for the base pointer identification algorithm These tests cover the 'base object' identification and rewritting portion of RewriteStatepointsForGC. These aren't completely exhaustive, but they've proven to be reasonable effective over time at finding regressions. In the process of porting these tests over, I found my first "cleanup per llvm code style standards" bug. We were relying on the order of iteration when testing the base pointers found for a derived pointer. When we switched from std::set to DenseSet, this stopped being a safe assumption. I'm suspecting I'm going to find more of those. In particular, I'm now really wondering about the main iteration loop for this algorithm. I need to go take a closer look at the assumptions there. I'm not really happy with the fact these are testing what is essentially debug output (i.e. enabled via command line flags). Suggestions for how to structure this better are very welcome. llvm-svn: 230818
2015-02-28 08:20:48 +08:00
; CHECK-DAG: [ %base_obj, %entry ]
[RS4GC] Clamp UseDeoptBundles to true and update tests The full diff for the test directory may be hard to read because of the filename clash; so here's all that happened as far as the tests are concerned: ``` cd test/Transforms/RewriteStatepointsForGC git rm *ll git mv deopt-bundles/* ./ rmdir deopt-bundles find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g' ``` llvm-svn: 259129
2016-01-29 08:28:57 +08:00
[RewriteStatepointsForGC] Use an actual liveness algorithm When rewriting statepoints to make relocations explicit, we need to have a conservative but consistent notion of where a particular pointer is live at a particular site. The old code just used dominance, which is correct, but decidedly more conservative then it needed to be. This patch implements a simple dataflow algorithm that's run one per function (well, twice counting fixup after base pointer insertion). There's still lots of room to make this faster, but it's fast enough for all practical purposes today. Differential Revision: http://reviews.llvm.org/D8674 llvm-svn: 234657
2015-04-11 06:53:14 +08:00
; Given the two selects are equivelent, so are their base phis - ideally,
; we'd have commoned these, but that's a missed optimization, not correctness.
[RewriteStatepointsForGC] Adjust naming scheme to be more stable The names for instructions inserted were previous dependent on iteration order. By deriving the names from the original instructions, we can avoid instability in tests without resorting to ordered traversals. It also makes the IR mildly easier to read at large scale. llvm-svn: 243140
2015-07-25 03:01:39 +08:00
; CHECK-DAG: [ [[DISCARD:%.*.base.relocated.casted]], %loop ]
; CHECK-NOT: extra.base
[RS4GC] Revert optimization attempt due to memory corruption This change reverts "246133 [RewriteStatepointsForGC] Reduce the number of new instructions for base pointers" and a follow on bugfix 12575. As pointed out in pr25846, this code suffers from a memory corruption bug. Since I'm (empirically) not going to get back to this any time soon, simply reverting the problematic change is the right answer. llvm-svn: 261565
2016-02-23 04:45:56 +08:00
; CHECK: next.base = select
[RewriteStatepointsForGC] Add tests for the base pointer identification algorithm These tests cover the 'base object' identification and rewritting portion of RewriteStatepointsForGC. These aren't completely exhaustive, but they've proven to be reasonable effective over time at finding regressions. In the process of porting these tests over, I found my first "cleanup per llvm code style standards" bug. We were relying on the order of iteration when testing the base pointers found for a derived pointer. When we switched from std::set to DenseSet, this stopped being a safe assumption. I'm suspecting I'm going to find more of those. In particular, I'm now really wondering about the main iteration loop for this algorithm. I need to go take a closer look at the assumptions there. I'm not really happy with the fact these are testing what is essentially debug output (i.e. enabled via command line flags). Suggestions for how to structure this better are very welcome. llvm-svn: 230818
2015-02-28 08:20:48 +08:00
; CHECK: next = select
[RewriteStatepointsForGC] Adjust naming scheme to be more stable The names for instructions inserted were previous dependent on iteration order. By deriving the names from the original instructions, we can avoid instability in tests without resorting to ordered traversals. It also makes the IR mildly easier to read at large scale. llvm-svn: 243140
2015-07-25 03:01:39 +08:00
; CHECK: extra2.base = select
[RewriteStatepointsForGC] Add tests for the base pointer identification algorithm These tests cover the 'base object' identification and rewritting portion of RewriteStatepointsForGC. These aren't completely exhaustive, but they've proven to be reasonable effective over time at finding regressions. In the process of porting these tests over, I found my first "cleanup per llvm code style standards" bug. We were relying on the order of iteration when testing the base pointers found for a derived pointer. When we switched from std::set to DenseSet, this stopped being a safe assumption. I'm suspecting I'm going to find more of those. In particular, I'm now really wondering about the main iteration loop for this algorithm. I need to go take a closer look at the assumptions there. I'm not really happy with the fact these are testing what is essentially debug output (i.e. enabled via command line flags). Suggestions for how to structure this better are very welcome. llvm-svn: 230818
2015-02-28 08:20:48 +08:00
; CHECK: extra2 = select
; CHECK: statepoint
;; Both 'next' and 'extra2' are live across the backedge safepoint...
[RS4GC] Clamp UseDeoptBundles to true and update tests The full diff for the test directory may be hard to read because of the filename clash; so here's all that happened as far as the tests are concerned: ``` cd test/Transforms/RewriteStatepointsForGC git rm *ll git mv deopt-bundles/* ./ rmdir deopt-bundles find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g' ``` llvm-svn: 259129
2016-01-29 08:28:57 +08:00
loop: ; preds = %loop, %entry
[RewriteStatepointsForGC] Add tests for the base pointer identification algorithm These tests cover the 'base object' identification and rewritting portion of RewriteStatepointsForGC. These aren't completely exhaustive, but they've proven to be reasonable effective over time at finding regressions. In the process of porting these tests over, I found my first "cleanup per llvm code style standards" bug. We were relying on the order of iteration when testing the base pointers found for a derived pointer. When we switched from std::set to DenseSet, this stopped being a safe assumption. I'm suspecting I'm going to find more of those. In particular, I'm now really wondering about the main iteration loop for this algorithm. I need to go take a closer look at the assumptions there. I'm not really happy with the fact these are testing what is essentially debug output (i.e. enabled via command line flags). Suggestions for how to structure this better are very welcome. llvm-svn: 230818
2015-02-28 08:20:48 +08:00
%current = phi i64 addrspace(1)* [ %obj, %entry ], [ %next, %loop ]
%extra = phi i64 addrspace(1)* [ %obj, %entry ], [ %extra2, %loop ]
%nexta = getelementptr i64, i64 addrspace(1)* %current, i32 1
%next = select i1 %cnd, i64 addrspace(1)* %nexta, i64 addrspace(1)* %base_arg2
%extra2 = select i1 %cnd, i64 addrspace(1)* %nexta, i64 addrspace(1)* %base_arg2
[RS4GC] Clamp UseDeoptBundles to true and update tests The full diff for the test directory may be hard to read because of the filename clash; so here's all that happened as far as the tests are concerned: ``` cd test/Transforms/RewriteStatepointsForGC git rm *ll git mv deopt-bundles/* ./ rmdir deopt-bundles find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g' ``` llvm-svn: 259129
2016-01-29 08:28:57 +08:00
call void @foo() [ "deopt"(i32 0, i32 -1, i32 0, i32 0, i32 0) ]
[RewriteStatepointsForGC] Add tests for the base pointer identification algorithm These tests cover the 'base object' identification and rewritting portion of RewriteStatepointsForGC. These aren't completely exhaustive, but they've proven to be reasonable effective over time at finding regressions. In the process of porting these tests over, I found my first "cleanup per llvm code style standards" bug. We were relying on the order of iteration when testing the base pointers found for a derived pointer. When we switched from std::set to DenseSet, this stopped being a safe assumption. I'm suspecting I'm going to find more of those. In particular, I'm now really wondering about the main iteration loop for this algorithm. I need to go take a closer look at the assumptions there. I'm not really happy with the fact these are testing what is essentially debug output (i.e. enabled via command line flags). Suggestions for how to structure this better are very welcome. llvm-svn: 230818
2015-02-28 08:20:48 +08:00
br label %loop
}
[RS4GC] Clamp UseDeoptBundles to true and update tests The full diff for the test directory may be hard to read because of the filename clash; so here's all that happened as far as the tests are concerned: ``` cd test/Transforms/RewriteStatepointsForGC git rm *ll git mv deopt-bundles/* ./ rmdir deopt-bundles find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g' ``` llvm-svn: 259129
2016-01-29 08:28:57 +08:00
define i64 addrspace(1)* @test3(i1 %cnd, i64 addrspace(1)* %obj, i64 addrspace(1)* %obj2) gc "statepoint-example" {
[RewriteStatepointsForGC] Reduce the number of new instructions for base pointers When computing base pointers, we introduce new instructions to propagate the base of existing instructions which might not be bases. However, the algorithm doesn't make any effort to recognize when the new instruction to be inserted is the same as an existing one already in the IR. Since this is happening immediately before rewriting, we don't really have a chance to fix it after the pass runs without teaching loop passes about statepoints. I'm really not thrilled with this patch. I've rewritten it 4 different ways now, but this is the best I've come up with. The case where the new instruction is just the original base defining value could be merged into the existing algorithm with some complexity. The problem is that we might have something like an extractelement from a phi of two vectors. It may be trivially obvious that the base of the 0th element is an existing instruction, but I can't see how to make the algorithm itself figure that out. Thus, I resort to the call to SimplifyInstruction instead. Note that we can only adjust the instructions we've inserted ourselves. The live sets are still being tracked in side structures at this point in the code. We can't easily muck with instructions which might be in them. Long term, I'm really thinking we need to materialize the live pointer sets explicitly in the IR somehow rather than using side structures to track them. Differential Revision: http://reviews.llvm.org/D12004 llvm-svn: 246133
2015-08-27 09:02:28 +08:00
; CHECK-LABEL: @test3
entry:
br i1 %cnd, label %merge, label %taken
[RS4GC] Clamp UseDeoptBundles to true and update tests The full diff for the test directory may be hard to read because of the filename clash; so here's all that happened as far as the tests are concerned: ``` cd test/Transforms/RewriteStatepointsForGC git rm *ll git mv deopt-bundles/* ./ rmdir deopt-bundles find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g' ``` llvm-svn: 259129
2016-01-29 08:28:57 +08:00
taken: ; preds = %entry
[RewriteStatepointsForGC] Reduce the number of new instructions for base pointers When computing base pointers, we introduce new instructions to propagate the base of existing instructions which might not be bases. However, the algorithm doesn't make any effort to recognize when the new instruction to be inserted is the same as an existing one already in the IR. Since this is happening immediately before rewriting, we don't really have a chance to fix it after the pass runs without teaching loop passes about statepoints. I'm really not thrilled with this patch. I've rewritten it 4 different ways now, but this is the best I've come up with. The case where the new instruction is just the original base defining value could be merged into the existing algorithm with some complexity. The problem is that we might have something like an extractelement from a phi of two vectors. It may be trivially obvious that the base of the 0th element is an existing instruction, but I can't see how to make the algorithm itself figure that out. Thus, I resort to the call to SimplifyInstruction instead. Note that we can only adjust the instructions we've inserted ourselves. The live sets are still being tracked in side structures at this point in the code. We can't easily muck with instructions which might be in them. Long term, I'm really thinking we need to materialize the live pointer sets explicitly in the IR somehow rather than using side structures to track them. Differential Revision: http://reviews.llvm.org/D12004 llvm-svn: 246133
2015-08-27 09:02:28 +08:00
br label %merge
[RS4GC] Clamp UseDeoptBundles to true and update tests The full diff for the test directory may be hard to read because of the filename clash; so here's all that happened as far as the tests are concerned: ``` cd test/Transforms/RewriteStatepointsForGC git rm *ll git mv deopt-bundles/* ./ rmdir deopt-bundles find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g' ``` llvm-svn: 259129
2016-01-29 08:28:57 +08:00
merge: ; preds = %taken, %entry
[RewriteStatepointsForGC] Reduce the number of new instructions for base pointers When computing base pointers, we introduce new instructions to propagate the base of existing instructions which might not be bases. However, the algorithm doesn't make any effort to recognize when the new instruction to be inserted is the same as an existing one already in the IR. Since this is happening immediately before rewriting, we don't really have a chance to fix it after the pass runs without teaching loop passes about statepoints. I'm really not thrilled with this patch. I've rewritten it 4 different ways now, but this is the best I've come up with. The case where the new instruction is just the original base defining value could be merged into the existing algorithm with some complexity. The problem is that we might have something like an extractelement from a phi of two vectors. It may be trivially obvious that the base of the 0th element is an existing instruction, but I can't see how to make the algorithm itself figure that out. Thus, I resort to the call to SimplifyInstruction instead. Note that we can only adjust the instructions we've inserted ourselves. The live sets are still being tracked in side structures at this point in the code. We can't easily muck with instructions which might be in them. Long term, I'm really thinking we need to materialize the live pointer sets explicitly in the IR somehow rather than using side structures to track them. Differential Revision: http://reviews.llvm.org/D12004 llvm-svn: 246133
2015-08-27 09:02:28 +08:00
; CHECK-LABEL: merge:
[RS4GC] Revert optimization attempt due to memory corruption This change reverts "246133 [RewriteStatepointsForGC] Reduce the number of new instructions for base pointers" and a follow on bugfix 12575. As pointed out in pr25846, this code suffers from a memory corruption bug. Since I'm (empirically) not going to get back to this any time soon, simply reverting the problematic change is the right answer. llvm-svn: 261565
2016-02-23 04:45:56 +08:00
; CHECK-NEXT: phi
; CHECK-NEXT: phi
[RewriteStatepointsForGC] Reduce the number of new instructions for base pointers When computing base pointers, we introduce new instructions to propagate the base of existing instructions which might not be bases. However, the algorithm doesn't make any effort to recognize when the new instruction to be inserted is the same as an existing one already in the IR. Since this is happening immediately before rewriting, we don't really have a chance to fix it after the pass runs without teaching loop passes about statepoints. I'm really not thrilled with this patch. I've rewritten it 4 different ways now, but this is the best I've come up with. The case where the new instruction is just the original base defining value could be merged into the existing algorithm with some complexity. The problem is that we might have something like an extractelement from a phi of two vectors. It may be trivially obvious that the base of the 0th element is an existing instruction, but I can't see how to make the algorithm itself figure that out. Thus, I resort to the call to SimplifyInstruction instead. Note that we can only adjust the instructions we've inserted ourselves. The live sets are still being tracked in side structures at this point in the code. We can't easily muck with instructions which might be in them. Long term, I'm really thinking we need to materialize the live pointer sets explicitly in the IR somehow rather than using side structures to track them. Differential Revision: http://reviews.llvm.org/D12004 llvm-svn: 246133
2015-08-27 09:02:28 +08:00
; CHECK-NEXT: gc.statepoint
%bdv = phi i64 addrspace(1)* [ %obj, %entry ], [ %obj2, %taken ]
[RS4GC] Clamp UseDeoptBundles to true and update tests The full diff for the test directory may be hard to read because of the filename clash; so here's all that happened as far as the tests are concerned: ``` cd test/Transforms/RewriteStatepointsForGC git rm *ll git mv deopt-bundles/* ./ rmdir deopt-bundles find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g' ``` llvm-svn: 259129
2016-01-29 08:28:57 +08:00
call void @foo() [ "deopt"(i32 0, i32 -1, i32 0, i32 0, i32 0) ]
[RewriteStatepointsForGC] Reduce the number of new instructions for base pointers When computing base pointers, we introduce new instructions to propagate the base of existing instructions which might not be bases. However, the algorithm doesn't make any effort to recognize when the new instruction to be inserted is the same as an existing one already in the IR. Since this is happening immediately before rewriting, we don't really have a chance to fix it after the pass runs without teaching loop passes about statepoints. I'm really not thrilled with this patch. I've rewritten it 4 different ways now, but this is the best I've come up with. The case where the new instruction is just the original base defining value could be merged into the existing algorithm with some complexity. The problem is that we might have something like an extractelement from a phi of two vectors. It may be trivially obvious that the base of the 0th element is an existing instruction, but I can't see how to make the algorithm itself figure that out. Thus, I resort to the call to SimplifyInstruction instead. Note that we can only adjust the instructions we've inserted ourselves. The live sets are still being tracked in side structures at this point in the code. We can't easily muck with instructions which might be in them. Long term, I'm really thinking we need to materialize the live pointer sets explicitly in the IR somehow rather than using side structures to track them. Differential Revision: http://reviews.llvm.org/D12004 llvm-svn: 246133
2015-08-27 09:02:28 +08:00
ret i64 addrspace(1)* %bdv
}
[RS4GC] Clamp UseDeoptBundles to true and update tests The full diff for the test directory may be hard to read because of the filename clash; so here's all that happened as far as the tests are concerned: ``` cd test/Transforms/RewriteStatepointsForGC git rm *ll git mv deopt-bundles/* ./ rmdir deopt-bundles find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g' ``` llvm-svn: 259129
2016-01-29 08:28:57 +08:00
define i64 addrspace(1)* @test4(i1 %cnd, i64 addrspace(1)* %obj, i64 addrspace(1)* %obj2) gc "statepoint-example" {
[RewriteStatepointsForGC] Improve debug output [NFC] llvm-svn: 246713
2015-09-03 05:11:44 +08:00
; CHECK-LABEL: @test4
entry:
br i1 %cnd, label %merge, label %taken
[RS4GC] Clamp UseDeoptBundles to true and update tests The full diff for the test directory may be hard to read because of the filename clash; so here's all that happened as far as the tests are concerned: ``` cd test/Transforms/RewriteStatepointsForGC git rm *ll git mv deopt-bundles/* ./ rmdir deopt-bundles find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g' ``` llvm-svn: 259129
2016-01-29 08:28:57 +08:00
taken: ; preds = %entry
[RewriteStatepointsForGC] Improve debug output [NFC] llvm-svn: 246713
2015-09-03 05:11:44 +08:00
br label %merge
[RS4GC] Clamp UseDeoptBundles to true and update tests The full diff for the test directory may be hard to read because of the filename clash; so here's all that happened as far as the tests are concerned: ``` cd test/Transforms/RewriteStatepointsForGC git rm *ll git mv deopt-bundles/* ./ rmdir deopt-bundles find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g' ``` llvm-svn: 259129
2016-01-29 08:28:57 +08:00
merge: ; preds = %taken, %entry
[RewriteStatepointsForGC] Improve debug output [NFC] llvm-svn: 246713
2015-09-03 05:11:44 +08:00
; CHECK-LABEL: merge:
[RS4GC] Revert optimization attempt due to memory corruption This change reverts "246133 [RewriteStatepointsForGC] Reduce the number of new instructions for base pointers" and a follow on bugfix 12575. As pointed out in pr25846, this code suffers from a memory corruption bug. Since I'm (empirically) not going to get back to this any time soon, simply reverting the problematic change is the right answer. llvm-svn: 261565
2016-02-23 04:45:56 +08:00
; CHECK-NEXT: phi
[RewriteStatepointsForGC] Improve debug output [NFC] llvm-svn: 246713
2015-09-03 05:11:44 +08:00
; CHECK-NEXT: gc.statepoint
%bdv = phi i64 addrspace(1)* [ %obj, %entry ], [ %obj, %taken ]
[RS4GC] Clamp UseDeoptBundles to true and update tests The full diff for the test directory may be hard to read because of the filename clash; so here's all that happened as far as the tests are concerned: ``` cd test/Transforms/RewriteStatepointsForGC git rm *ll git mv deopt-bundles/* ./ rmdir deopt-bundles find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g' ``` llvm-svn: 259129
2016-01-29 08:28:57 +08:00
call void @foo() [ "deopt"(i32 0, i32 -1, i32 0, i32 0, i32 0) ]
[RewriteStatepointsForGC] Improve debug output [NFC] llvm-svn: 246713
2015-09-03 05:11:44 +08:00
ret i64 addrspace(1)* %bdv
}
[RS4GC] Clamp UseDeoptBundles to true and update tests The full diff for the test directory may be hard to read because of the filename clash; so here's all that happened as far as the tests are concerned: ``` cd test/Transforms/RewriteStatepointsForGC git rm *ll git mv deopt-bundles/* ./ rmdir deopt-bundles find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g' ``` llvm-svn: 259129
2016-01-29 08:28:57 +08:00
define i64 addrspace(1)* @test5(i1 %cnd, i64 addrspace(1)* %obj, i64 addrspace(1)* %obj2) gc "statepoint-example" {
[RewriteStatepointsForGC] Improve debug output [NFC] llvm-svn: 246713
2015-09-03 05:11:44 +08:00
; CHECK-LABEL: @test5
entry:
br label %merge
[RS4GC] Clamp UseDeoptBundles to true and update tests The full diff for the test directory may be hard to read because of the filename clash; so here's all that happened as far as the tests are concerned: ``` cd test/Transforms/RewriteStatepointsForGC git rm *ll git mv deopt-bundles/* ./ rmdir deopt-bundles find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g' ``` llvm-svn: 259129
2016-01-29 08:28:57 +08:00
merge: ; preds = %merge, %entry
[RewriteStatepointsForGC] Improve debug output [NFC] llvm-svn: 246713
2015-09-03 05:11:44 +08:00
; CHECK-LABEL: merge:
[RS4GC] Revert optimization attempt due to memory corruption This change reverts "246133 [RewriteStatepointsForGC] Reduce the number of new instructions for base pointers" and a follow on bugfix 12575. As pointed out in pr25846, this code suffers from a memory corruption bug. Since I'm (empirically) not going to get back to this any time soon, simply reverting the problematic change is the right answer. llvm-svn: 261565
2016-02-23 04:45:56 +08:00
; CHECK-NEXT: phi
; CHECK-NEXT: phi
[RewriteStatepointsForGC] Improve debug output [NFC] llvm-svn: 246713
2015-09-03 05:11:44 +08:00
; CHECK-NEXT: br i1
%bdv = phi i64 addrspace(1)* [ %obj, %entry ], [ %obj2, %merge ]
br i1 %cnd, label %merge, label %next
[RS4GC] Clamp UseDeoptBundles to true and update tests The full diff for the test directory may be hard to read because of the filename clash; so here's all that happened as far as the tests are concerned: ``` cd test/Transforms/RewriteStatepointsForGC git rm *ll git mv deopt-bundles/* ./ rmdir deopt-bundles find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g' ``` llvm-svn: 259129
2016-01-29 08:28:57 +08:00
next: ; preds = %merge
call void @foo() [ "deopt"(i32 0, i32 -1, i32 0, i32 0, i32 0) ]
[RewriteStatepointsForGC] Improve debug output [NFC] llvm-svn: 246713
2015-09-03 05:11:44 +08:00
ret i64 addrspace(1)* %bdv
}
[RewriteStatepointsForGC] Add tests for the base pointer identification algorithm These tests cover the 'base object' identification and rewritting portion of RewriteStatepointsForGC. These aren't completely exhaustive, but they've proven to be reasonable effective over time at finding regressions. In the process of porting these tests over, I found my first "cleanup per llvm code style standards" bug. We were relying on the order of iteration when testing the base pointers found for a derived pointer. When we switched from std::set to DenseSet, this stopped being a safe assumption. I'm suspecting I'm going to find more of those. In particular, I'm now really wondering about the main iteration loop for this algorithm. I need to go take a closer look at the assumptions there. I'm not really happy with the fact these are testing what is essentially debug output (i.e. enabled via command line flags). Suggestions for how to structure this better are very welcome. llvm-svn: 230818
2015-02-28 08:20:48 +08:00
declare void @foo()