mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-24 19:52:54 +01:00
eae3e5a494
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.
18 lines
943 B
LLVM
18 lines
943 B
LLVM
; Test that llvm-reduce can remove uninteresting function arguments from function definitions as well as their calls.
|
|
;
|
|
; 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
|
|
|
|
; CHECK-ALL: declare void @use(i32, i32, i32)
|
|
declare void @use(i32, i32, i32)
|
|
|
|
; CHECK-ALL: @interesting(i32 %uninteresting1, i32 %uninteresting2, i32 %uninteresting3
|
|
define void @interesting(i32 %uninteresting1, i32 %uninteresting2, i32 %uninteresting3) {
|
|
entry:
|
|
; CHECK-ALL: 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)
|
|
call void @use(i32 %uninteresting1, i32 %uninteresting2, i32 %uninteresting3)
|
|
ret void
|
|
}
|