maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Verifier/invalid-statepoint.ll

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

20 lines
817 B
LLVM
Raw Normal View History

Fix an issue in the verifier where we could try to read information out of a malformed statepoint intrinsic. In this situation we would always have already flagged an error on the statepoint intrinsic, but then we carry on to parse other, related GC intrinsics, and could end up crashing during that verification when they try to access data from the malformed statepoint. llvm-svn: 231759
2015-03-10 13:58:21 +08:00
; RUN: not opt -verify 2>&1 < %s | FileCheck %s
; CHECK: gc.statepoint: mismatch in number of call arguments
declare zeroext i1 @return0i1()
; Function Attrs: nounwind
[gc.statepoint] Change gc.statepoint intrinsic's return type to token type instead of i32 type Summary: This patch changes gc.statepoint intrinsic's return type to token type instead of i32 type. Using token types could prevent LLVM to merge different gc.statepoint nodes into PHI nodes and cause further problems with gc relocations. The patch also changes the way on how gc.relocate and gc.result look for their corresponding gc.statepoint on unwind path. The current implementation uses the selector value extracted from a { i8*, i32 } landingpad as a hook to find the gc.statepoint, while the patch directly uses a token type landingpad (http://reviews.llvm.org/D15405) to find the gc.statepoint. Reviewers: sanjoy, JosephTremoulet, pgavlin, igor-laevsky, mjacob Subscribers: reames, mjacob, sanjoy, llvm-commits Differential Revision: http://reviews.llvm.org/D15662 llvm-svn: 256443
2015-12-26 15:54:32 +08:00
declare token @llvm.experimental.gc.statepoint.p0f0i1f(i64, i32, i1 ()*, i32, i32, ...) #0
Fix an issue in the verifier where we could try to read information out of a malformed statepoint intrinsic. In this situation we would always have already flagged an error on the statepoint intrinsic, but then we carry on to parse other, related GC intrinsics, and could end up crashing during that verification when they try to access data from the malformed statepoint. llvm-svn: 231759
2015-03-10 13:58:21 +08:00
; Function Attrs: nounwind
[gc.statepoint] Change gc.statepoint intrinsic's return type to token type instead of i32 type Summary: This patch changes gc.statepoint intrinsic's return type to token type instead of i32 type. Using token types could prevent LLVM to merge different gc.statepoint nodes into PHI nodes and cause further problems with gc relocations. The patch also changes the way on how gc.relocate and gc.result look for their corresponding gc.statepoint on unwind path. The current implementation uses the selector value extracted from a { i8*, i32 } landingpad as a hook to find the gc.statepoint, while the patch directly uses a token type landingpad (http://reviews.llvm.org/D15405) to find the gc.statepoint. Reviewers: sanjoy, JosephTremoulet, pgavlin, igor-laevsky, mjacob Subscribers: reames, mjacob, sanjoy, llvm-commits Differential Revision: http://reviews.llvm.org/D15662 llvm-svn: 256443
2015-12-26 15:54:32 +08:00
declare i32 addrspace(1)* @llvm.experimental.gc.relocate.p1i32(token, i32, i32) #0
Fix an issue in the verifier where we could try to read information out of a malformed statepoint intrinsic. In this situation we would always have already flagged an error on the statepoint intrinsic, but then we carry on to parse other, related GC intrinsics, and could end up crashing during that verification when they try to access data from the malformed statepoint. llvm-svn: 231759
2015-03-10 13:58:21 +08:00
define i32 addrspace(1)* @0(i32 addrspace(1)* %dparam) {
%a00 = load i32, i32 addrspace(1)* %dparam
[gc.statepoint] Change gc.statepoint intrinsic's return type to token type instead of i32 type Summary: This patch changes gc.statepoint intrinsic's return type to token type instead of i32 type. Using token types could prevent LLVM to merge different gc.statepoint nodes into PHI nodes and cause further problems with gc relocations. The patch also changes the way on how gc.relocate and gc.result look for their corresponding gc.statepoint on unwind path. The current implementation uses the selector value extracted from a { i8*, i32 } landingpad as a hook to find the gc.statepoint, while the patch directly uses a token type landingpad (http://reviews.llvm.org/D15405) to find the gc.statepoint. Reviewers: sanjoy, JosephTremoulet, pgavlin, igor-laevsky, mjacob Subscribers: reames, mjacob, sanjoy, llvm-commits Differential Revision: http://reviews.llvm.org/D15662 llvm-svn: 256443
2015-12-26 15:54:32 +08:00
%to0 = call token (i64, i32, i1 ()*, i32, i32, ...) @llvm.experimental.gc.statepoint.p0f0i1f(i64 0, i32 0, i1 ()* @return0i1, i32 9, i32 0, i2 0, i32 addrspace(1)* %dparam)
%relocate = call i32 addrspace(1)* @llvm.experimental.gc.relocate.p1i32(token %to0, i32 2, i32 6)
Fix an issue in the verifier where we could try to read information out of a malformed statepoint intrinsic. In this situation we would always have already flagged an error on the statepoint intrinsic, but then we carry on to parse other, related GC intrinsics, and could end up crashing during that verification when they try to access data from the malformed statepoint. llvm-svn: 231759
2015-03-10 13:58:21 +08:00
ret i32 addrspace(1)* %relocate
}
[Statepoints] Support for "patchable" statepoints. Summary: This change adds two new parameters to the statepoint intrinsic, `i64 id` and `i32 num_patch_bytes`. `id` gets propagated to the ID field in the generated StackMap section. If the `num_patch_bytes` is non-zero then the statepoint is lowered to `num_patch_bytes` bytes of nops instead of a call (the spill and reload code remains unchanged). A non-zero `num_patch_bytes` is useful in situations where a language runtime requires complete control over how a call is lowered. This change brings statepoints one step closer to patchpoints. With some additional work (that is not part of this patch) it should be possible to get rid of `TargetOpcode::STATEPOINT` altogether. PlaceSafepoints generates `statepoint` wrappers with `id` set to `0xABCDEF00` (the old default value for the ID reported in the stackmap) and `num_patch_bytes` set to `0`. This can be made more sophisticated later. Reviewers: reames, pgavlin, swaroop.sridhar, AndyAyers Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9546 llvm-svn: 237214
2015-05-13 07:52:24 +08:00
attributes #0 = { nounwind }