RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-23 11:13:28 +01:00
Code Issues Projects Releases Wiki Activity
76f3fb45dc
llvm-mirror/test/Reduce/remove-multiple-use-of-global-vars-in-same-instruction.ll

24 lines
1.0 KiB
LLVM
Raw Normal View History

[llvm-reduce] extractGVsFromModule(): don't crash when deleting instr twice As it can be seen in newly-added (previously-crashing) test-case, there can be a situation where multiple GV's are used in instr, and we would schedule the same instruction to be deleted several times, crashing when trying to delete it the second time. We could either store WeakVH (done here), or use something set-like. I think using WeakVH is prevalent in these cases elsewhere.
2020-07-05 00:01:46 +02:00
; Test that llvm-reduce can remove uninteresting function arguments from function definitions as well as their calls.
;
[Reduce] Argument reduction: do deal with function declarations We can happily turn function definitions into declarations, thus obscuring their argument from being elided by this pass. I don't believe there is a good reason to just ignore declarations. likely even proper llvm intrinsics ones, at worst the input becomes uninteresting. The other question here is that all these transforms are all-or-nothing. In some cases, should we be treating each use separately? The main blocker here seemed to be that llvm::CloneFunctionInto() does `&OldFunc->front()`, which inserts a nullptr into a densemap, which is not happy about it and asserts.
2020-07-25 23:56:36 +02:00
; RUN: llvm-reduce --test FileCheck --test-arg --check-prefixes=CHECK-ALL,CHECK-INTERESTINGNESS --test-arg %s --test-arg --input-file %s -o %t
; RUN: cat %t | FileCheck --check-prefixes=CHECK-ALL,CHECK-FINAL %s
[llvm-reduce] extractGVsFromModule(): don't crash when deleting instr twice As it can be seen in newly-added (previously-crashing) test-case, there can be a situation where multiple GV's are used in instr, and we would schedule the same instruction to be deleted several times, crashing when trying to delete it the second time. We could either store WeakVH (done here), or use something set-like. I think using WeakVH is prevalent in these cases elsewhere.
2020-07-05 00:01:46 +02:00
[Reduce] Argument reduction: do deal with function declarations We can happily turn function definitions into declarations, thus obscuring their argument from being elided by this pass. I don't believe there is a good reason to just ignore declarations. likely even proper llvm intrinsics ones, at worst the input becomes uninteresting. The other question here is that all these transforms are all-or-nothing. In some cases, should we be treating each use separately? The main blocker here seemed to be that llvm::CloneFunctionInto() does `&OldFunc->front()`, which inserts a nullptr into a densemap, which is not happy about it and asserts.
2020-07-25 23:56:36 +02:00
; CHECK-ALL: @uninteresting1 = global
; CHECK-ALL: @uninteresting2 = global
; CHECK-ALL: @uninteresting3 = global
[llvm-reduce] extractGVsFromModule(): don't crash when deleting instr twice As it can be seen in newly-added (previously-crashing) test-case, there can be a situation where multiple GV's are used in instr, and we would schedule the same instruction to be deleted several times, crashing when trying to delete it the second time. We could either store WeakVH (done here), or use something set-like. I think using WeakVH is prevalent in these cases elsewhere.
2020-07-05 00:01:46 +02:00
@uninteresting1 = global i32 0, align 4
@uninteresting2 = global i32 0, align 4
@uninteresting3 = global i32 0, align 4
declare void @use(i32*, i32*, i32*)
; CHECK-LABEL: @interesting()
define void @interesting() {
entry:
[Reduce] Argument reduction: do deal with function declarations We can happily turn function definitions into declarations, thus obscuring their argument from being elided by this pass. I don't believe there is a good reason to just ignore declarations. likely even proper llvm intrinsics ones, at worst the input becomes uninteresting. The other question here is that all these transforms are all-or-nothing. In some cases, should we be treating each use separately? The main blocker here seemed to be that llvm::CloneFunctionInto() does `&OldFunc->front()`, which inserts a nullptr into a densemap, which is not happy about it and asserts.
2020-07-25 23:56:36 +02:00
; CHECK-ALL: call void @use(i32* @uninteresting1, i32* @uninteresting2, i32* @uninteresting3)
[llvm-reduce] extractGVsFromModule(): don't crash when deleting instr twice As it can be seen in newly-added (previously-crashing) test-case, there can be a situation where multiple GV's are used in instr, and we would schedule the same instruction to be deleted several times, crashing when trying to delete it the second time. We could either store WeakVH (done here), or use something set-like. I think using WeakVH is prevalent in these cases elsewhere.
2020-07-05 00:01:46 +02:00
call void @use(i32* @uninteresting1, i32* @uninteresting2, i32* @uninteresting3)
call void @use(i32* @uninteresting1, i32* @uninteresting2, i32* @uninteresting3)
call void @use(i32* @uninteresting1, i32* @uninteresting2, i32* @uninteresting3)
ret void
}
Reference in New Issue Copy Permalink