maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Reduce/remove-multiple-use-of-args...

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

18 lines
943 B
LLVM
Raw Normal View History

[llvm-reduce] extractArgumentsFromModule(): 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 arguments 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 05:48:05 +08: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-26 05:56:36 +08: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] extractArgumentsFromModule(): 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 arguments 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 05:48:05 +08: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-26 05:56:36 +08:00
; CHECK-ALL: declare void @use(i32, i32, i32)
[llvm-reduce] extractArgumentsFromModule(): 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 arguments 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 05:48:05 +08:00
declare void @use(i32, i32, i32)
[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-26 05:56:36 +08:00
; CHECK-ALL: @interesting(i32 %uninteresting1, i32 %uninteresting2, i32 %uninteresting3
[llvm-reduce] extractArgumentsFromModule(): 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 arguments 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 05:48:05 +08:00
define void @interesting(i32 %uninteresting1, i32 %uninteresting2, i32 %uninteresting3) {
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-26 05:56:36 +08:00
; CHECK-ALL: call void @use(i32 %uninteresting1, i32 %uninteresting2, i32 %uninteresting3)
[llvm-reduce] extractArgumentsFromModule(): 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 arguments 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 05:48:05 +08: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
}