maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/X86/implicit-null-check.ll

344 lines
9.6 KiB
LLVM
Raw Normal View History

[ImplicitNullChecks] Account for implicit-defs as well when updating the liveness. The replaced load may have implicit-defs and those defs may be used in the block of the original load. Make sure to update the liveness accordingly. This is a generalization of r267817. llvm-svn: 268412
2016-05-04 02:09:06 +08:00
; RUN: llc -verify-machineinstrs -O3 -mtriple=x86_64-apple-macosx -enable-implicit-null-checks < %s | FileCheck %s
[CodeGen] Add a pass to fold null checks into nearby memory operations. Summary: This change adds an "ImplicitNullChecks" target dependent pass. This pass folds null checks into memory operation using the FAULTING_LOAD pseudo-op introduced in previous patches. Depends on D10197 Depends on D10199 Depends on D10200 Reviewers: reames, rnk, pgavlin, JosephTremoulet, atrick Reviewed By: atrick Subscribers: ab, JosephTremoulet, llvm-commits Differential Revision: http://reviews.llvm.org/D10201 llvm-svn: 239743
2015-06-16 02:44:27 +08:00
[FaultMaps] Add a parser for the __llvm__faultmaps section. Summary: The parser is exercised by llvm-objdump using -print-fault-maps. As is probably obvious, the code itself was "heavily inspired" by http://reviews.llvm.org/D10434. Reviewers: reames, atrick, JosephTremoulet Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10491 llvm-svn: 240304
2015-06-23 02:03:02 +08:00
; RUN: llc < %s -mtriple=x86_64-apple-macosx -enable-implicit-null-checks \
; RUN: | llvm-mc -triple x86_64-apple-macosx -filetype=obj -o - \
; RUN: | llvm-objdump -triple x86_64-apple-macosx -fault-map-section - \
; RUN: | FileCheck %s -check-prefix OBJDUMP
; RUN: llc < %s -mtriple=x86_64-unknown-linux-gnu -enable-implicit-null-checks \
; RUN: | llvm-mc -triple x86_64-unknown-linux-gnu -filetype=obj -o - \
; RUN: | llvm-objdump -triple x86_64-unknown-linux-gnu -fault-map-section - \
; RUN: | FileCheck %s -check-prefix OBJDUMP
[CodeGen] Add a pass to fold null checks into nearby memory operations. Summary: This change adds an "ImplicitNullChecks" target dependent pass. This pass folds null checks into memory operation using the FAULTING_LOAD pseudo-op introduced in previous patches. Depends on D10197 Depends on D10199 Depends on D10200 Reviewers: reames, rnk, pgavlin, JosephTremoulet, atrick Reviewed By: atrick Subscribers: ab, JosephTremoulet, llvm-commits Differential Revision: http://reviews.llvm.org/D10201 llvm-svn: 239743
2015-06-16 02:44:27 +08:00
define i32 @imp_null_check_load(i32* %x) {
; CHECK-LABEL: _imp_null_check_load:
[X86] Model FAULTING_LOAD_OP as a terminator and branch. This operation may branch to the handler block and we do not want it to happen anywhere within the basic block. Moreover, by marking it "terminator and branch" the machine verifier does not wrongly assume (because of AnalyzeBranch not knowing better) the branch is analyzable. Indeed, the target was seeing only the unconditional branch and not the faulting load op and thought it was a simple unconditional block. The machine verifier was complaining because of that and moreover, other optimizations could have done wrong transformation! In the process, simplify the representation of the handler block in the faulting load op. Now, we directly reference the handler block instead of using a label. This has the benefits of: 1. MC knows how to issue a label for a BB, so leave that to it. 2. Accessing the target BB from its label is painful, whereas it is direct from a MBB operand. Note: The 2 bytes offset in implicit-null-check.ll comes from the fact the unconditional jumps are not removed anymore, as the whole terminator sequence is not analyzable anymore. Will fix it in a subsequence commit. llvm-svn: 268327
2016-05-03 06:58:54 +08:00
; CHECK: [[BB0_imp_null_check_load:L[^:]+]]:
[CodeGen] Add a pass to fold null checks into nearby memory operations. Summary: This change adds an "ImplicitNullChecks" target dependent pass. This pass folds null checks into memory operation using the FAULTING_LOAD pseudo-op introduced in previous patches. Depends on D10197 Depends on D10199 Depends on D10200 Reviewers: reames, rnk, pgavlin, JosephTremoulet, atrick Reviewed By: atrick Subscribers: ab, JosephTremoulet, llvm-commits Differential Revision: http://reviews.llvm.org/D10201 llvm-svn: 239743
2015-06-16 02:44:27 +08:00
; CHECK: movl (%rdi), %eax
; CHECK: retq
[X86] Model FAULTING_LOAD_OP as a terminator and branch. This operation may branch to the handler block and we do not want it to happen anywhere within the basic block. Moreover, by marking it "terminator and branch" the machine verifier does not wrongly assume (because of AnalyzeBranch not knowing better) the branch is analyzable. Indeed, the target was seeing only the unconditional branch and not the faulting load op and thought it was a simple unconditional block. The machine verifier was complaining because of that and moreover, other optimizations could have done wrong transformation! In the process, simplify the representation of the handler block in the faulting load op. Now, we directly reference the handler block instead of using a label. This has the benefits of: 1. MC knows how to issue a label for a BB, so leave that to it. 2. Accessing the target BB from its label is painful, whereas it is direct from a MBB operand. Note: The 2 bytes offset in implicit-null-check.ll comes from the fact the unconditional jumps are not removed anymore, as the whole terminator sequence is not analyzable anymore. Will fix it in a subsequence commit. llvm-svn: 268327
2016-05-03 06:58:54 +08:00
; CHECK: [[BB1_imp_null_check_load:LBB0_[0-9]+]]:
[CodeGen] Add a pass to fold null checks into nearby memory operations. Summary: This change adds an "ImplicitNullChecks" target dependent pass. This pass folds null checks into memory operation using the FAULTING_LOAD pseudo-op introduced in previous patches. Depends on D10197 Depends on D10199 Depends on D10200 Reviewers: reames, rnk, pgavlin, JosephTremoulet, atrick Reviewed By: atrick Subscribers: ab, JosephTremoulet, llvm-commits Differential Revision: http://reviews.llvm.org/D10201 llvm-svn: 239743
2015-06-16 02:44:27 +08:00
; CHECK: movl $42, %eax
; CHECK: retq
entry:
%c = icmp eq i32* %x, null
[FaultMaps] Let the frontend pre-select implicit null check candidates. Summary: This change introduces a !make.implicit metadata that allows the frontend to pre-select the set of explicit null checks that will be considered for transformation into implicit null checks. The reason for not using profiling data instead of !make.implicit is explained in the change to `FaultMaps.rst`. Reviewers: atrick, reames, pgavlin, JosephTremoulet Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10824 llvm-svn: 241116
2015-07-01 05:22:32 +08:00
br i1 %c, label %is_null, label %not_null, !make.implicit !0
[CodeGen] Add a pass to fold null checks into nearby memory operations. Summary: This change adds an "ImplicitNullChecks" target dependent pass. This pass folds null checks into memory operation using the FAULTING_LOAD pseudo-op introduced in previous patches. Depends on D10197 Depends on D10199 Depends on D10200 Reviewers: reames, rnk, pgavlin, JosephTremoulet, atrick Reviewed By: atrick Subscribers: ab, JosephTremoulet, llvm-commits Differential Revision: http://reviews.llvm.org/D10201 llvm-svn: 239743
2015-06-16 02:44:27 +08:00
is_null:
ret i32 42
not_null:
%t = load i32, i32* %x
ret i32 %t
}
define i32 @imp_null_check_gep_load(i32* %x) {
; CHECK-LABEL: _imp_null_check_gep_load:
[X86] Model FAULTING_LOAD_OP as a terminator and branch. This operation may branch to the handler block and we do not want it to happen anywhere within the basic block. Moreover, by marking it "terminator and branch" the machine verifier does not wrongly assume (because of AnalyzeBranch not knowing better) the branch is analyzable. Indeed, the target was seeing only the unconditional branch and not the faulting load op and thought it was a simple unconditional block. The machine verifier was complaining because of that and moreover, other optimizations could have done wrong transformation! In the process, simplify the representation of the handler block in the faulting load op. Now, we directly reference the handler block instead of using a label. This has the benefits of: 1. MC knows how to issue a label for a BB, so leave that to it. 2. Accessing the target BB from its label is painful, whereas it is direct from a MBB operand. Note: The 2 bytes offset in implicit-null-check.ll comes from the fact the unconditional jumps are not removed anymore, as the whole terminator sequence is not analyzable anymore. Will fix it in a subsequence commit. llvm-svn: 268327
2016-05-03 06:58:54 +08:00
; CHECK: [[BB0_imp_null_check_gep_load:L[^:]+]]:
[CodeGen] Add a pass to fold null checks into nearby memory operations. Summary: This change adds an "ImplicitNullChecks" target dependent pass. This pass folds null checks into memory operation using the FAULTING_LOAD pseudo-op introduced in previous patches. Depends on D10197 Depends on D10199 Depends on D10200 Reviewers: reames, rnk, pgavlin, JosephTremoulet, atrick Reviewed By: atrick Subscribers: ab, JosephTremoulet, llvm-commits Differential Revision: http://reviews.llvm.org/D10201 llvm-svn: 239743
2015-06-16 02:44:27 +08:00
; CHECK: movl 128(%rdi), %eax
; CHECK: retq
[X86] Model FAULTING_LOAD_OP as a terminator and branch. This operation may branch to the handler block and we do not want it to happen anywhere within the basic block. Moreover, by marking it "terminator and branch" the machine verifier does not wrongly assume (because of AnalyzeBranch not knowing better) the branch is analyzable. Indeed, the target was seeing only the unconditional branch and not the faulting load op and thought it was a simple unconditional block. The machine verifier was complaining because of that and moreover, other optimizations could have done wrong transformation! In the process, simplify the representation of the handler block in the faulting load op. Now, we directly reference the handler block instead of using a label. This has the benefits of: 1. MC knows how to issue a label for a BB, so leave that to it. 2. Accessing the target BB from its label is painful, whereas it is direct from a MBB operand. Note: The 2 bytes offset in implicit-null-check.ll comes from the fact the unconditional jumps are not removed anymore, as the whole terminator sequence is not analyzable anymore. Will fix it in a subsequence commit. llvm-svn: 268327
2016-05-03 06:58:54 +08:00
; CHECK: [[BB1_imp_null_check_gep_load:LBB1_[0-9]+]]:
[CodeGen] Add a pass to fold null checks into nearby memory operations. Summary: This change adds an "ImplicitNullChecks" target dependent pass. This pass folds null checks into memory operation using the FAULTING_LOAD pseudo-op introduced in previous patches. Depends on D10197 Depends on D10199 Depends on D10200 Reviewers: reames, rnk, pgavlin, JosephTremoulet, atrick Reviewed By: atrick Subscribers: ab, JosephTremoulet, llvm-commits Differential Revision: http://reviews.llvm.org/D10201 llvm-svn: 239743
2015-06-16 02:44:27 +08:00
; CHECK: movl $42, %eax
; CHECK: retq
entry:
%c = icmp eq i32* %x, null
[FaultMaps] Let the frontend pre-select implicit null check candidates. Summary: This change introduces a !make.implicit metadata that allows the frontend to pre-select the set of explicit null checks that will be considered for transformation into implicit null checks. The reason for not using profiling data instead of !make.implicit is explained in the change to `FaultMaps.rst`. Reviewers: atrick, reames, pgavlin, JosephTremoulet Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10824 llvm-svn: 241116
2015-07-01 05:22:32 +08:00
br i1 %c, label %is_null, label %not_null, !make.implicit !0
[CodeGen] Add a pass to fold null checks into nearby memory operations. Summary: This change adds an "ImplicitNullChecks" target dependent pass. This pass folds null checks into memory operation using the FAULTING_LOAD pseudo-op introduced in previous patches. Depends on D10197 Depends on D10199 Depends on D10200 Reviewers: reames, rnk, pgavlin, JosephTremoulet, atrick Reviewed By: atrick Subscribers: ab, JosephTremoulet, llvm-commits Differential Revision: http://reviews.llvm.org/D10201 llvm-svn: 239743
2015-06-16 02:44:27 +08:00
is_null:
ret i32 42
not_null:
%x.gep = getelementptr i32, i32* %x, i32 32
%t = load i32, i32* %x.gep
ret i32 %t
}
define i32 @imp_null_check_add_result(i32* %x, i32 %p) {
; CHECK-LABEL: _imp_null_check_add_result:
[X86] Model FAULTING_LOAD_OP as a terminator and branch. This operation may branch to the handler block and we do not want it to happen anywhere within the basic block. Moreover, by marking it "terminator and branch" the machine verifier does not wrongly assume (because of AnalyzeBranch not knowing better) the branch is analyzable. Indeed, the target was seeing only the unconditional branch and not the faulting load op and thought it was a simple unconditional block. The machine verifier was complaining because of that and moreover, other optimizations could have done wrong transformation! In the process, simplify the representation of the handler block in the faulting load op. Now, we directly reference the handler block instead of using a label. This has the benefits of: 1. MC knows how to issue a label for a BB, so leave that to it. 2. Accessing the target BB from its label is painful, whereas it is direct from a MBB operand. Note: The 2 bytes offset in implicit-null-check.ll comes from the fact the unconditional jumps are not removed anymore, as the whole terminator sequence is not analyzable anymore. Will fix it in a subsequence commit. llvm-svn: 268327
2016-05-03 06:58:54 +08:00
; CHECK: [[BB0_imp_null_check_add_result:L[^:]+]]:
[CodeGen] Add a pass to fold null checks into nearby memory operations. Summary: This change adds an "ImplicitNullChecks" target dependent pass. This pass folds null checks into memory operation using the FAULTING_LOAD pseudo-op introduced in previous patches. Depends on D10197 Depends on D10199 Depends on D10200 Reviewers: reames, rnk, pgavlin, JosephTremoulet, atrick Reviewed By: atrick Subscribers: ab, JosephTremoulet, llvm-commits Differential Revision: http://reviews.llvm.org/D10201 llvm-svn: 239743
2015-06-16 02:44:27 +08:00
; CHECK: addl (%rdi), %esi
; CHECK: movl %esi, %eax
; CHECK: retq
[X86] Model FAULTING_LOAD_OP as a terminator and branch. This operation may branch to the handler block and we do not want it to happen anywhere within the basic block. Moreover, by marking it "terminator and branch" the machine verifier does not wrongly assume (because of AnalyzeBranch not knowing better) the branch is analyzable. Indeed, the target was seeing only the unconditional branch and not the faulting load op and thought it was a simple unconditional block. The machine verifier was complaining because of that and moreover, other optimizations could have done wrong transformation! In the process, simplify the representation of the handler block in the faulting load op. Now, we directly reference the handler block instead of using a label. This has the benefits of: 1. MC knows how to issue a label for a BB, so leave that to it. 2. Accessing the target BB from its label is painful, whereas it is direct from a MBB operand. Note: The 2 bytes offset in implicit-null-check.ll comes from the fact the unconditional jumps are not removed anymore, as the whole terminator sequence is not analyzable anymore. Will fix it in a subsequence commit. llvm-svn: 268327
2016-05-03 06:58:54 +08:00
; CHECK: [[BB1_imp_null_check_add_result:LBB2_[0-9]+]]:
[CodeGen] Add a pass to fold null checks into nearby memory operations. Summary: This change adds an "ImplicitNullChecks" target dependent pass. This pass folds null checks into memory operation using the FAULTING_LOAD pseudo-op introduced in previous patches. Depends on D10197 Depends on D10199 Depends on D10200 Reviewers: reames, rnk, pgavlin, JosephTremoulet, atrick Reviewed By: atrick Subscribers: ab, JosephTremoulet, llvm-commits Differential Revision: http://reviews.llvm.org/D10201 llvm-svn: 239743
2015-06-16 02:44:27 +08:00
; CHECK: movl $42, %eax
; CHECK: retq
entry:
%c = icmp eq i32* %x, null
[FaultMaps] Let the frontend pre-select implicit null check candidates. Summary: This change introduces a !make.implicit metadata that allows the frontend to pre-select the set of explicit null checks that will be considered for transformation into implicit null checks. The reason for not using profiling data instead of !make.implicit is explained in the change to `FaultMaps.rst`. Reviewers: atrick, reames, pgavlin, JosephTremoulet Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10824 llvm-svn: 241116
2015-07-01 05:22:32 +08:00
br i1 %c, label %is_null, label %not_null, !make.implicit !0
[CodeGen] Add a pass to fold null checks into nearby memory operations. Summary: This change adds an "ImplicitNullChecks" target dependent pass. This pass folds null checks into memory operation using the FAULTING_LOAD pseudo-op introduced in previous patches. Depends on D10197 Depends on D10199 Depends on D10200 Reviewers: reames, rnk, pgavlin, JosephTremoulet, atrick Reviewed By: atrick Subscribers: ab, JosephTremoulet, llvm-commits Differential Revision: http://reviews.llvm.org/D10201 llvm-svn: 239743
2015-06-16 02:44:27 +08:00
is_null:
ret i32 42
not_null:
%t = load i32, i32* %x
%p1 = add i32 %t, %p
ret i32 %p1
}
[ImplicitNullChecks] Be smarter in picking the memory op. Summary: Before this change ImplicitNullChecks would only pick loads of the form: ``` test Reg, Reg jz elsewhere fallthrough: movl 32(Reg), Reg2 ``` but not (say) ``` test Reg, Reg jz elsewhere fallthrough: inc Reg3 movl 32(Reg), Reg2 ``` This change teaches ImplicitNullChecks to look through "unrelated" instructions like `inc Reg3` when searching for a load instruction to convert to a trapping load. Reviewers: atrick, JosephTremoulet, reames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11044 llvm-svn: 241850
2015-07-10 04:13:25 +08:00
define i32 @imp_null_check_hoist_over_unrelated_load(i32* %x, i32* %y, i32* %z) {
; CHECK-LABEL: _imp_null_check_hoist_over_unrelated_load:
[X86] Model FAULTING_LOAD_OP as a terminator and branch. This operation may branch to the handler block and we do not want it to happen anywhere within the basic block. Moreover, by marking it "terminator and branch" the machine verifier does not wrongly assume (because of AnalyzeBranch not knowing better) the branch is analyzable. Indeed, the target was seeing only the unconditional branch and not the faulting load op and thought it was a simple unconditional block. The machine verifier was complaining because of that and moreover, other optimizations could have done wrong transformation! In the process, simplify the representation of the handler block in the faulting load op. Now, we directly reference the handler block instead of using a label. This has the benefits of: 1. MC knows how to issue a label for a BB, so leave that to it. 2. Accessing the target BB from its label is painful, whereas it is direct from a MBB operand. Note: The 2 bytes offset in implicit-null-check.ll comes from the fact the unconditional jumps are not removed anymore, as the whole terminator sequence is not analyzable anymore. Will fix it in a subsequence commit. llvm-svn: 268327
2016-05-03 06:58:54 +08:00
; CHECK: [[BB0_imp_null_check_hoist_over_unrelated_load:L[^:]+]]:
[ImplicitNullChecks] Be smarter in picking the memory op. Summary: Before this change ImplicitNullChecks would only pick loads of the form: ``` test Reg, Reg jz elsewhere fallthrough: movl 32(Reg), Reg2 ``` but not (say) ``` test Reg, Reg jz elsewhere fallthrough: inc Reg3 movl 32(Reg), Reg2 ``` This change teaches ImplicitNullChecks to look through "unrelated" instructions like `inc Reg3` when searching for a load instruction to convert to a trapping load. Reviewers: atrick, JosephTremoulet, reames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11044 llvm-svn: 241850
2015-07-10 04:13:25 +08:00
; CHECK: movl (%rdi), %eax
; CHECK: movl (%rsi), %ecx
; CHECK: movl %ecx, (%rdx)
; CHECK: retq
[X86] Model FAULTING_LOAD_OP as a terminator and branch. This operation may branch to the handler block and we do not want it to happen anywhere within the basic block. Moreover, by marking it "terminator and branch" the machine verifier does not wrongly assume (because of AnalyzeBranch not knowing better) the branch is analyzable. Indeed, the target was seeing only the unconditional branch and not the faulting load op and thought it was a simple unconditional block. The machine verifier was complaining because of that and moreover, other optimizations could have done wrong transformation! In the process, simplify the representation of the handler block in the faulting load op. Now, we directly reference the handler block instead of using a label. This has the benefits of: 1. MC knows how to issue a label for a BB, so leave that to it. 2. Accessing the target BB from its label is painful, whereas it is direct from a MBB operand. Note: The 2 bytes offset in implicit-null-check.ll comes from the fact the unconditional jumps are not removed anymore, as the whole terminator sequence is not analyzable anymore. Will fix it in a subsequence commit. llvm-svn: 268327
2016-05-03 06:58:54 +08:00
; CHECK: [[BB1_imp_null_check_hoist_over_unrelated_load:LBB3_[0-9]+]]:
[ImplicitNullChecks] Be smarter in picking the memory op. Summary: Before this change ImplicitNullChecks would only pick loads of the form: ``` test Reg, Reg jz elsewhere fallthrough: movl 32(Reg), Reg2 ``` but not (say) ``` test Reg, Reg jz elsewhere fallthrough: inc Reg3 movl 32(Reg), Reg2 ``` This change teaches ImplicitNullChecks to look through "unrelated" instructions like `inc Reg3` when searching for a load instruction to convert to a trapping load. Reviewers: atrick, JosephTremoulet, reames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11044 llvm-svn: 241850
2015-07-10 04:13:25 +08:00
; CHECK: movl $42, %eax
; CHECK: retq
entry:
%c = icmp eq i32* %x, null
br i1 %c, label %is_null, label %not_null, !make.implicit !0
is_null:
ret i32 42
not_null:
%t0 = load i32, i32* %y
%t1 = load i32, i32* %x
store i32 %t0, i32* %z
ret i32 %t1
}
[ImplicitNullChecks] Work with implicit defs. Summary: This change generalizes the implicit null checks pass to work with instructions that don't have any explicit register defs. This lets us use X86's `cmp` against memory as faulting load instructions. Reviewers: reames, JosephTremoulet Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11286 llvm-svn: 242703
2015-07-21 04:31:39 +08:00
define i32 @imp_null_check_via_mem_comparision(i32* %x, i32 %val) {
; CHECK-LABEL: _imp_null_check_via_mem_comparision
[X86] Model FAULTING_LOAD_OP as a terminator and branch. This operation may branch to the handler block and we do not want it to happen anywhere within the basic block. Moreover, by marking it "terminator and branch" the machine verifier does not wrongly assume (because of AnalyzeBranch not knowing better) the branch is analyzable. Indeed, the target was seeing only the unconditional branch and not the faulting load op and thought it was a simple unconditional block. The machine verifier was complaining because of that and moreover, other optimizations could have done wrong transformation! In the process, simplify the representation of the handler block in the faulting load op. Now, we directly reference the handler block instead of using a label. This has the benefits of: 1. MC knows how to issue a label for a BB, so leave that to it. 2. Accessing the target BB from its label is painful, whereas it is direct from a MBB operand. Note: The 2 bytes offset in implicit-null-check.ll comes from the fact the unconditional jumps are not removed anymore, as the whole terminator sequence is not analyzable anymore. Will fix it in a subsequence commit. llvm-svn: 268327
2016-05-03 06:58:54 +08:00
; CHECK: [[BB0_imp_null_check_via_mem_comparision:L[^:]+]]:
[ImplicitNullChecks] Work with implicit defs. Summary: This change generalizes the implicit null checks pass to work with instructions that don't have any explicit register defs. This lets us use X86's `cmp` against memory as faulting load instructions. Reviewers: reames, JosephTremoulet Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11286 llvm-svn: 242703
2015-07-21 04:31:39 +08:00
; CHECK: cmpl %esi, 4(%rdi)
; CHECK: jge LBB4_2
; CHECK: movl $100, %eax
; CHECK: retq
[X86] Model FAULTING_LOAD_OP as a terminator and branch. This operation may branch to the handler block and we do not want it to happen anywhere within the basic block. Moreover, by marking it "terminator and branch" the machine verifier does not wrongly assume (because of AnalyzeBranch not knowing better) the branch is analyzable. Indeed, the target was seeing only the unconditional branch and not the faulting load op and thought it was a simple unconditional block. The machine verifier was complaining because of that and moreover, other optimizations could have done wrong transformation! In the process, simplify the representation of the handler block in the faulting load op. Now, we directly reference the handler block instead of using a label. This has the benefits of: 1. MC knows how to issue a label for a BB, so leave that to it. 2. Accessing the target BB from its label is painful, whereas it is direct from a MBB operand. Note: The 2 bytes offset in implicit-null-check.ll comes from the fact the unconditional jumps are not removed anymore, as the whole terminator sequence is not analyzable anymore. Will fix it in a subsequence commit. llvm-svn: 268327
2016-05-03 06:58:54 +08:00
; CHECK: [[BB1_imp_null_check_via_mem_comparision:LBB4_[0-9]+]]:
[ImplicitNullChecks] Work with implicit defs. Summary: This change generalizes the implicit null checks pass to work with instructions that don't have any explicit register defs. This lets us use X86's `cmp` against memory as faulting load instructions. Reviewers: reames, JosephTremoulet Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11286 llvm-svn: 242703
2015-07-21 04:31:39 +08:00
; CHECK: movl $42, %eax
; CHECK: retq
; CHECK: LBB4_2:
; CHECK: movl $200, %eax
; CHECK: retq
entry:
%c = icmp eq i32* %x, null
br i1 %c, label %is_null, label %not_null, !make.implicit !0
is_null:
ret i32 42
not_null:
%x.loc = getelementptr i32, i32* %x, i32 1
%t = load i32, i32* %x.loc
%m = icmp slt i32 %t, %val
br i1 %m, label %ret_100, label %ret_200
ret_100:
ret i32 100
ret_200:
ret i32 200
}
[ImplicitNullCheck] Extend canReorder scope Summary: This change allows a re-order of two intructions if their uses are overlapped. Patch by Serguei Katkov! Reviewers: reames, sanjoy Reviewed By: sanjoy Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29120 llvm-svn: 293775
2017-02-02 00:04:21 +08:00
define i32 @imp_null_check_gep_load_with_use_dep(i32* %x, i32 %a) {
; CHECK-LABEL: imp_null_check_gep_load_with_use_dep:
; CHECK: [[BB0_imp_null_check_gep_load_with_use_dep:L[^:]+]]:
; CHECK: movl (%rdi), %eax
; CHECK: addl %edi, %esi
; CHECK: leal 4(%rax,%rsi), %eax
; CHECK: retq
; CHECK: [[BB1_imp_null_check_gep_load_with_use_dep:LBB5_[0-9]+]]:
; CHECK: movl $42, %eax
; CHECK: retq
entry:
%c = icmp eq i32* %x, null
br i1 %c, label %is_null, label %not_null, !make.implicit !0
is_null:
ret i32 42
not_null:
%x.loc = getelementptr i32, i32* %x, i32 1
%y = ptrtoint i32* %x.loc to i32
%b = add i32 %a, %y
%t = load i32, i32* %x
%z = add i32 %t, %b
ret i32 %z
}
[ImplicitNullCheck] Extend Implicit Null Check scope by using stores Summary: This change allows usage of store instruction for implicit null check. Memory Aliasing Analisys is not used and change conservatively supposes that any store and load may access the same memory. As a result re-ordering of store-store, store-load and load-store is prohibited. Patch by Serguei Katkov! Reviewers: reames, sanjoy Reviewed By: sanjoy Subscribers: atrick, llvm-commits Differential Revision: https://reviews.llvm.org/D29400 llvm-svn: 294338
2017-02-08 03:19:49 +08:00
define void @imp_null_check_store(i32* %x) {
; CHECK-LABEL: _imp_null_check_store:
; CHECK: [[BB0_imp_null_check_store:L[^:]+]]:
; CHECK: movl $1, (%rdi)
; CHECK: retq
; CHECK: [[BB1_imp_null_check_store:LBB6_[0-9]+]]:
; CHECK: retq
entry:
%c = icmp eq i32* %x, null
br i1 %c, label %is_null, label %not_null, !make.implicit !0
is_null:
ret void
not_null:
store i32 1, i32* %x
ret void
}
Fix implicit null check with negative offset Summary: It seems that negative offset was accidentally allowed in D17967. AFAICT small negative offset should be valid (always raise segfault) on all archs that I'm aware of (especially x86, which is the only one with this optimization enabled) and such case can be useful when loading hiden metadata from an object. However, like the positive side, it should only be done within a certain limit. For now, use the same limit on the positive side for the negative side. A separate option can be added if needs appear. Reviewers: mcrosier, skatkov Reviewed By: skatkov Subscribers: sanjoy, llvm-commits Differential Revision: https://reviews.llvm.org/D38925 llvm-svn: 315991
2017-10-17 19:47:36 +08:00
define i32 @imp_null_check_neg_gep_load(i32* %x) {
; CHECK-LABEL: _imp_null_check_neg_gep_load:
; CHECK: [[BB0_imp_null_check_neg_gep_load:L[^:]+]]:
; CHECK: movl -128(%rdi), %eax
; CHECK: retq
; CHECK: [[BB1_imp_null_check_neg_gep_load:LBB7_[0-9]+]]:
; CHECK: movl $42, %eax
; CHECK: retq
entry:
%c = icmp eq i32* %x, null
br i1 %c, label %is_null, label %not_null, !make.implicit !0
is_null:
ret i32 42
not_null:
%x.gep = getelementptr i32, i32* %x, i32 -32
%t = load i32, i32* %x.gep
ret i32 %t
}
[FaultMaps] Let the frontend pre-select implicit null check candidates. Summary: This change introduces a !make.implicit metadata that allows the frontend to pre-select the set of explicit null checks that will be considered for transformation into implicit null checks. The reason for not using profiling data instead of !make.implicit is explained in the change to `FaultMaps.rst`. Reviewers: atrick, reames, pgavlin, JosephTremoulet Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10824 llvm-svn: 241116
2015-07-01 05:22:32 +08:00
!0 = !{}
[CodeGen] Add a pass to fold null checks into nearby memory operations. Summary: This change adds an "ImplicitNullChecks" target dependent pass. This pass folds null checks into memory operation using the FAULTING_LOAD pseudo-op introduced in previous patches. Depends on D10197 Depends on D10199 Depends on D10200 Reviewers: reames, rnk, pgavlin, JosephTremoulet, atrick Reviewed By: atrick Subscribers: ab, JosephTremoulet, llvm-commits Differential Revision: http://reviews.llvm.org/D10201 llvm-svn: 239743
2015-06-16 02:44:27 +08:00
; CHECK-LABEL: __LLVM_FaultMaps:
; Version:
; CHECK-NEXT: .byte 1
; Reserved x2
; CHECK-NEXT: .byte 0
; CHECK-NEXT: .short 0
; # functions:
Fix implicit null check with negative offset Summary: It seems that negative offset was accidentally allowed in D17967. AFAICT small negative offset should be valid (always raise segfault) on all archs that I'm aware of (especially x86, which is the only one with this optimization enabled) and such case can be useful when loading hiden metadata from an object. However, like the positive side, it should only be done within a certain limit. For now, use the same limit on the positive side for the negative side. A separate option can be added if needs appear. Reviewers: mcrosier, skatkov Reviewed By: skatkov Subscribers: sanjoy, llvm-commits Differential Revision: https://reviews.llvm.org/D38925 llvm-svn: 315991
2017-10-17 19:47:36 +08:00
; CHECK-NEXT: .long 8
[CodeGen] Add a pass to fold null checks into nearby memory operations. Summary: This change adds an "ImplicitNullChecks" target dependent pass. This pass folds null checks into memory operation using the FAULTING_LOAD pseudo-op introduced in previous patches. Depends on D10197 Depends on D10199 Depends on D10200 Reviewers: reames, rnk, pgavlin, JosephTremoulet, atrick Reviewed By: atrick Subscribers: ab, JosephTremoulet, llvm-commits Differential Revision: http://reviews.llvm.org/D10201 llvm-svn: 239743
2015-06-16 02:44:27 +08:00
; FunctionAddr:
; CHECK-NEXT: .quad _imp_null_check_add_result
; NumFaultingPCs
; CHECK-NEXT: .long 1
; Reserved:
; CHECK-NEXT: .long 0
; Fault[0].Type:
; CHECK-NEXT: .long 1
; Fault[0].FaultOffset:
[X86] Model FAULTING_LOAD_OP as a terminator and branch. This operation may branch to the handler block and we do not want it to happen anywhere within the basic block. Moreover, by marking it "terminator and branch" the machine verifier does not wrongly assume (because of AnalyzeBranch not knowing better) the branch is analyzable. Indeed, the target was seeing only the unconditional branch and not the faulting load op and thought it was a simple unconditional block. The machine verifier was complaining because of that and moreover, other optimizations could have done wrong transformation! In the process, simplify the representation of the handler block in the faulting load op. Now, we directly reference the handler block instead of using a label. This has the benefits of: 1. MC knows how to issue a label for a BB, so leave that to it. 2. Accessing the target BB from its label is painful, whereas it is direct from a MBB operand. Note: The 2 bytes offset in implicit-null-check.ll comes from the fact the unconditional jumps are not removed anymore, as the whole terminator sequence is not analyzable anymore. Will fix it in a subsequence commit. llvm-svn: 268327
2016-05-03 06:58:54 +08:00
; CHECK-NEXT: .long [[BB0_imp_null_check_add_result]]-_imp_null_check_add_result
[CodeGen] Add a pass to fold null checks into nearby memory operations. Summary: This change adds an "ImplicitNullChecks" target dependent pass. This pass folds null checks into memory operation using the FAULTING_LOAD pseudo-op introduced in previous patches. Depends on D10197 Depends on D10199 Depends on D10200 Reviewers: reames, rnk, pgavlin, JosephTremoulet, atrick Reviewed By: atrick Subscribers: ab, JosephTremoulet, llvm-commits Differential Revision: http://reviews.llvm.org/D10201 llvm-svn: 239743
2015-06-16 02:44:27 +08:00
; Fault[0].HandlerOffset:
[X86] Model FAULTING_LOAD_OP as a terminator and branch. This operation may branch to the handler block and we do not want it to happen anywhere within the basic block. Moreover, by marking it "terminator and branch" the machine verifier does not wrongly assume (because of AnalyzeBranch not knowing better) the branch is analyzable. Indeed, the target was seeing only the unconditional branch and not the faulting load op and thought it was a simple unconditional block. The machine verifier was complaining because of that and moreover, other optimizations could have done wrong transformation! In the process, simplify the representation of the handler block in the faulting load op. Now, we directly reference the handler block instead of using a label. This has the benefits of: 1. MC knows how to issue a label for a BB, so leave that to it. 2. Accessing the target BB from its label is painful, whereas it is direct from a MBB operand. Note: The 2 bytes offset in implicit-null-check.ll comes from the fact the unconditional jumps are not removed anymore, as the whole terminator sequence is not analyzable anymore. Will fix it in a subsequence commit. llvm-svn: 268327
2016-05-03 06:58:54 +08:00
; CHECK-NEXT: .long [[BB1_imp_null_check_add_result]]-_imp_null_check_add_result
[CodeGen] Add a pass to fold null checks into nearby memory operations. Summary: This change adds an "ImplicitNullChecks" target dependent pass. This pass folds null checks into memory operation using the FAULTING_LOAD pseudo-op introduced in previous patches. Depends on D10197 Depends on D10199 Depends on D10200 Reviewers: reames, rnk, pgavlin, JosephTremoulet, atrick Reviewed By: atrick Subscribers: ab, JosephTremoulet, llvm-commits Differential Revision: http://reviews.llvm.org/D10201 llvm-svn: 239743
2015-06-16 02:44:27 +08:00
; FunctionAddr:
; CHECK-NEXT: .quad _imp_null_check_gep_load
; NumFaultingPCs
; CHECK-NEXT: .long 1
; Reserved:
; CHECK-NEXT: .long 0
; Fault[0].Type:
; CHECK-NEXT: .long 1
; Fault[0].FaultOffset:
[X86] Model FAULTING_LOAD_OP as a terminator and branch. This operation may branch to the handler block and we do not want it to happen anywhere within the basic block. Moreover, by marking it "terminator and branch" the machine verifier does not wrongly assume (because of AnalyzeBranch not knowing better) the branch is analyzable. Indeed, the target was seeing only the unconditional branch and not the faulting load op and thought it was a simple unconditional block. The machine verifier was complaining because of that and moreover, other optimizations could have done wrong transformation! In the process, simplify the representation of the handler block in the faulting load op. Now, we directly reference the handler block instead of using a label. This has the benefits of: 1. MC knows how to issue a label for a BB, so leave that to it. 2. Accessing the target BB from its label is painful, whereas it is direct from a MBB operand. Note: The 2 bytes offset in implicit-null-check.ll comes from the fact the unconditional jumps are not removed anymore, as the whole terminator sequence is not analyzable anymore. Will fix it in a subsequence commit. llvm-svn: 268327
2016-05-03 06:58:54 +08:00
; CHECK-NEXT: .long [[BB0_imp_null_check_gep_load]]-_imp_null_check_gep_load
[CodeGen] Add a pass to fold null checks into nearby memory operations. Summary: This change adds an "ImplicitNullChecks" target dependent pass. This pass folds null checks into memory operation using the FAULTING_LOAD pseudo-op introduced in previous patches. Depends on D10197 Depends on D10199 Depends on D10200 Reviewers: reames, rnk, pgavlin, JosephTremoulet, atrick Reviewed By: atrick Subscribers: ab, JosephTremoulet, llvm-commits Differential Revision: http://reviews.llvm.org/D10201 llvm-svn: 239743
2015-06-16 02:44:27 +08:00
; Fault[0].HandlerOffset:
[X86] Model FAULTING_LOAD_OP as a terminator and branch. This operation may branch to the handler block and we do not want it to happen anywhere within the basic block. Moreover, by marking it "terminator and branch" the machine verifier does not wrongly assume (because of AnalyzeBranch not knowing better) the branch is analyzable. Indeed, the target was seeing only the unconditional branch and not the faulting load op and thought it was a simple unconditional block. The machine verifier was complaining because of that and moreover, other optimizations could have done wrong transformation! In the process, simplify the representation of the handler block in the faulting load op. Now, we directly reference the handler block instead of using a label. This has the benefits of: 1. MC knows how to issue a label for a BB, so leave that to it. 2. Accessing the target BB from its label is painful, whereas it is direct from a MBB operand. Note: The 2 bytes offset in implicit-null-check.ll comes from the fact the unconditional jumps are not removed anymore, as the whole terminator sequence is not analyzable anymore. Will fix it in a subsequence commit. llvm-svn: 268327
2016-05-03 06:58:54 +08:00
; CHECK-NEXT: .long [[BB1_imp_null_check_gep_load]]-_imp_null_check_gep_load
[CodeGen] Add a pass to fold null checks into nearby memory operations. Summary: This change adds an "ImplicitNullChecks" target dependent pass. This pass folds null checks into memory operation using the FAULTING_LOAD pseudo-op introduced in previous patches. Depends on D10197 Depends on D10199 Depends on D10200 Reviewers: reames, rnk, pgavlin, JosephTremoulet, atrick Reviewed By: atrick Subscribers: ab, JosephTremoulet, llvm-commits Differential Revision: http://reviews.llvm.org/D10201 llvm-svn: 239743
2015-06-16 02:44:27 +08:00
[ImplicitNullCheck] Extend canReorder scope Summary: This change allows a re-order of two intructions if their uses are overlapped. Patch by Serguei Katkov! Reviewers: reames, sanjoy Reviewed By: sanjoy Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29120 llvm-svn: 293775
2017-02-02 00:04:21 +08:00
; FunctionAddr:
; CHECK-NEXT: .quad _imp_null_check_gep_load_with_use_dep
; NumFaultingPCs
; CHECK-NEXT: .long 1
; Reserved:
; CHECK-NEXT: .long 0
; Fault[0].Type:
; CHECK-NEXT: .long 1
; Fault[0].FaultOffset:
; CHECK-NEXT: .long [[BB0_imp_null_check_gep_load_with_use_dep]]-_imp_null_check_gep_load_with_use_dep
; Fault[0].HandlerOffset:
; CHECK-NEXT: .long [[BB1_imp_null_check_gep_load_with_use_dep]]-_imp_null_check_gep_load_with_use_dep
[ImplicitNullChecks] Be smarter in picking the memory op. Summary: Before this change ImplicitNullChecks would only pick loads of the form: ``` test Reg, Reg jz elsewhere fallthrough: movl 32(Reg), Reg2 ``` but not (say) ``` test Reg, Reg jz elsewhere fallthrough: inc Reg3 movl 32(Reg), Reg2 ``` This change teaches ImplicitNullChecks to look through "unrelated" instructions like `inc Reg3` when searching for a load instruction to convert to a trapping load. Reviewers: atrick, JosephTremoulet, reames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11044 llvm-svn: 241850
2015-07-10 04:13:25 +08:00
; FunctionAddr:
; CHECK-NEXT: .quad _imp_null_check_hoist_over_unrelated_load
; NumFaultingPCs
; CHECK-NEXT: .long 1
; Reserved:
; CHECK-NEXT: .long 0
; Fault[0].Type:
; CHECK-NEXT: .long 1
; Fault[0].FaultOffset:
[X86] Model FAULTING_LOAD_OP as a terminator and branch. This operation may branch to the handler block and we do not want it to happen anywhere within the basic block. Moreover, by marking it "terminator and branch" the machine verifier does not wrongly assume (because of AnalyzeBranch not knowing better) the branch is analyzable. Indeed, the target was seeing only the unconditional branch and not the faulting load op and thought it was a simple unconditional block. The machine verifier was complaining because of that and moreover, other optimizations could have done wrong transformation! In the process, simplify the representation of the handler block in the faulting load op. Now, we directly reference the handler block instead of using a label. This has the benefits of: 1. MC knows how to issue a label for a BB, so leave that to it. 2. Accessing the target BB from its label is painful, whereas it is direct from a MBB operand. Note: The 2 bytes offset in implicit-null-check.ll comes from the fact the unconditional jumps are not removed anymore, as the whole terminator sequence is not analyzable anymore. Will fix it in a subsequence commit. llvm-svn: 268327
2016-05-03 06:58:54 +08:00
; CHECK-NEXT: .long [[BB0_imp_null_check_hoist_over_unrelated_load]]-_imp_null_check_hoist_over_unrelated_load
[ImplicitNullChecks] Be smarter in picking the memory op. Summary: Before this change ImplicitNullChecks would only pick loads of the form: ``` test Reg, Reg jz elsewhere fallthrough: movl 32(Reg), Reg2 ``` but not (say) ``` test Reg, Reg jz elsewhere fallthrough: inc Reg3 movl 32(Reg), Reg2 ``` This change teaches ImplicitNullChecks to look through "unrelated" instructions like `inc Reg3` when searching for a load instruction to convert to a trapping load. Reviewers: atrick, JosephTremoulet, reames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11044 llvm-svn: 241850
2015-07-10 04:13:25 +08:00
; Fault[0].HandlerOffset:
[X86] Model FAULTING_LOAD_OP as a terminator and branch. This operation may branch to the handler block and we do not want it to happen anywhere within the basic block. Moreover, by marking it "terminator and branch" the machine verifier does not wrongly assume (because of AnalyzeBranch not knowing better) the branch is analyzable. Indeed, the target was seeing only the unconditional branch and not the faulting load op and thought it was a simple unconditional block. The machine verifier was complaining because of that and moreover, other optimizations could have done wrong transformation! In the process, simplify the representation of the handler block in the faulting load op. Now, we directly reference the handler block instead of using a label. This has the benefits of: 1. MC knows how to issue a label for a BB, so leave that to it. 2. Accessing the target BB from its label is painful, whereas it is direct from a MBB operand. Note: The 2 bytes offset in implicit-null-check.ll comes from the fact the unconditional jumps are not removed anymore, as the whole terminator sequence is not analyzable anymore. Will fix it in a subsequence commit. llvm-svn: 268327
2016-05-03 06:58:54 +08:00
; CHECK-NEXT: .long [[BB1_imp_null_check_hoist_over_unrelated_load]]-_imp_null_check_hoist_over_unrelated_load
[ImplicitNullChecks] Be smarter in picking the memory op. Summary: Before this change ImplicitNullChecks would only pick loads of the form: ``` test Reg, Reg jz elsewhere fallthrough: movl 32(Reg), Reg2 ``` but not (say) ``` test Reg, Reg jz elsewhere fallthrough: inc Reg3 movl 32(Reg), Reg2 ``` This change teaches ImplicitNullChecks to look through "unrelated" instructions like `inc Reg3` when searching for a load instruction to convert to a trapping load. Reviewers: atrick, JosephTremoulet, reames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11044 llvm-svn: 241850
2015-07-10 04:13:25 +08:00
[CodeGen] Add a pass to fold null checks into nearby memory operations. Summary: This change adds an "ImplicitNullChecks" target dependent pass. This pass folds null checks into memory operation using the FAULTING_LOAD pseudo-op introduced in previous patches. Depends on D10197 Depends on D10199 Depends on D10200 Reviewers: reames, rnk, pgavlin, JosephTremoulet, atrick Reviewed By: atrick Subscribers: ab, JosephTremoulet, llvm-commits Differential Revision: http://reviews.llvm.org/D10201 llvm-svn: 239743
2015-06-16 02:44:27 +08:00
; FunctionAddr:
; CHECK-NEXT: .quad _imp_null_check_load
; NumFaultingPCs
; CHECK-NEXT: .long 1
; Reserved:
; CHECK-NEXT: .long 0
; Fault[0].Type:
; CHECK-NEXT: .long 1
; Fault[0].FaultOffset:
[X86] Model FAULTING_LOAD_OP as a terminator and branch. This operation may branch to the handler block and we do not want it to happen anywhere within the basic block. Moreover, by marking it "terminator and branch" the machine verifier does not wrongly assume (because of AnalyzeBranch not knowing better) the branch is analyzable. Indeed, the target was seeing only the unconditional branch and not the faulting load op and thought it was a simple unconditional block. The machine verifier was complaining because of that and moreover, other optimizations could have done wrong transformation! In the process, simplify the representation of the handler block in the faulting load op. Now, we directly reference the handler block instead of using a label. This has the benefits of: 1. MC knows how to issue a label for a BB, so leave that to it. 2. Accessing the target BB from its label is painful, whereas it is direct from a MBB operand. Note: The 2 bytes offset in implicit-null-check.ll comes from the fact the unconditional jumps are not removed anymore, as the whole terminator sequence is not analyzable anymore. Will fix it in a subsequence commit. llvm-svn: 268327
2016-05-03 06:58:54 +08:00
; CHECK-NEXT: .long [[BB0_imp_null_check_load]]-_imp_null_check_load
[CodeGen] Add a pass to fold null checks into nearby memory operations. Summary: This change adds an "ImplicitNullChecks" target dependent pass. This pass folds null checks into memory operation using the FAULTING_LOAD pseudo-op introduced in previous patches. Depends on D10197 Depends on D10199 Depends on D10200 Reviewers: reames, rnk, pgavlin, JosephTremoulet, atrick Reviewed By: atrick Subscribers: ab, JosephTremoulet, llvm-commits Differential Revision: http://reviews.llvm.org/D10201 llvm-svn: 239743
2015-06-16 02:44:27 +08:00
; Fault[0].HandlerOffset:
[X86] Model FAULTING_LOAD_OP as a terminator and branch. This operation may branch to the handler block and we do not want it to happen anywhere within the basic block. Moreover, by marking it "terminator and branch" the machine verifier does not wrongly assume (because of AnalyzeBranch not knowing better) the branch is analyzable. Indeed, the target was seeing only the unconditional branch and not the faulting load op and thought it was a simple unconditional block. The machine verifier was complaining because of that and moreover, other optimizations could have done wrong transformation! In the process, simplify the representation of the handler block in the faulting load op. Now, we directly reference the handler block instead of using a label. This has the benefits of: 1. MC knows how to issue a label for a BB, so leave that to it. 2. Accessing the target BB from its label is painful, whereas it is direct from a MBB operand. Note: The 2 bytes offset in implicit-null-check.ll comes from the fact the unconditional jumps are not removed anymore, as the whole terminator sequence is not analyzable anymore. Will fix it in a subsequence commit. llvm-svn: 268327
2016-05-03 06:58:54 +08:00
; CHECK-NEXT: .long [[BB1_imp_null_check_load]]-_imp_null_check_load
[FaultMaps] Add a parser for the __llvm__faultmaps section. Summary: The parser is exercised by llvm-objdump using -print-fault-maps. As is probably obvious, the code itself was "heavily inspired" by http://reviews.llvm.org/D10434. Reviewers: reames, atrick, JosephTremoulet Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10491 llvm-svn: 240304
2015-06-23 02:03:02 +08:00
Fix implicit null check with negative offset Summary: It seems that negative offset was accidentally allowed in D17967. AFAICT small negative offset should be valid (always raise segfault) on all archs that I'm aware of (especially x86, which is the only one with this optimization enabled) and such case can be useful when loading hiden metadata from an object. However, like the positive side, it should only be done within a certain limit. For now, use the same limit on the positive side for the negative side. A separate option can be added if needs appear. Reviewers: mcrosier, skatkov Reviewed By: skatkov Subscribers: sanjoy, llvm-commits Differential Revision: https://reviews.llvm.org/D38925 llvm-svn: 315991
2017-10-17 19:47:36 +08:00
; FunctionAddr:
; CHECK-NEXT: .quad _imp_null_check_neg_gep_load
; NumFaultingPCs
; CHECK-NEXT: .long 1
; Reserved:
; CHECK-NEXT: .long 0
; Fault[0].Type:
; CHECK-NEXT: .long 1
; Fault[0].FaultOffset:
; CHECK-NEXT: .long [[BB0_imp_null_check_neg_gep_load]]-_imp_null_check_neg_gep_load
; Fault[0].HandlerOffset:
; CHECK-NEXT: .long [[BB1_imp_null_check_neg_gep_load]]-_imp_null_check_neg_gep_load
[ImplicitNullCheck] Extend Implicit Null Check scope by using stores Summary: This change allows usage of store instruction for implicit null check. Memory Aliasing Analisys is not used and change conservatively supposes that any store and load may access the same memory. As a result re-ordering of store-store, store-load and load-store is prohibited. Patch by Serguei Katkov! Reviewers: reames, sanjoy Reviewed By: sanjoy Subscribers: atrick, llvm-commits Differential Revision: https://reviews.llvm.org/D29400 llvm-svn: 294338
2017-02-08 03:19:49 +08:00
; FunctionAddr:
; CHECK-NEXT: .quad _imp_null_check_store
; NumFaultingPCs
; CHECK-NEXT: .long 1
; Reserved:
; CHECK-NEXT: .long 0
; Fault[0].Type:
; CHECK-NEXT: .long 3
; Fault[0].FaultOffset:
; CHECK-NEXT: .long [[BB0_imp_null_check_store]]-_imp_null_check_store
; Fault[0].HandlerOffset:
; CHECK-NEXT: .long [[BB1_imp_null_check_store]]-_imp_null_check_store
[ImplicitNullChecks] Work with implicit defs. Summary: This change generalizes the implicit null checks pass to work with instructions that don't have any explicit register defs. This lets us use X86's `cmp` against memory as faulting load instructions. Reviewers: reames, JosephTremoulet Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11286 llvm-svn: 242703
2015-07-21 04:31:39 +08:00
; FunctionAddr:
; CHECK-NEXT: .quad _imp_null_check_via_mem_comparision
; NumFaultingPCs
; CHECK-NEXT: .long 1
; Reserved:
; CHECK-NEXT: .long 0
; Fault[0].Type:
; CHECK-NEXT: .long 1
; Fault[0].FaultOffset:
[X86] Model FAULTING_LOAD_OP as a terminator and branch. This operation may branch to the handler block and we do not want it to happen anywhere within the basic block. Moreover, by marking it "terminator and branch" the machine verifier does not wrongly assume (because of AnalyzeBranch not knowing better) the branch is analyzable. Indeed, the target was seeing only the unconditional branch and not the faulting load op and thought it was a simple unconditional block. The machine verifier was complaining because of that and moreover, other optimizations could have done wrong transformation! In the process, simplify the representation of the handler block in the faulting load op. Now, we directly reference the handler block instead of using a label. This has the benefits of: 1. MC knows how to issue a label for a BB, so leave that to it. 2. Accessing the target BB from its label is painful, whereas it is direct from a MBB operand. Note: The 2 bytes offset in implicit-null-check.ll comes from the fact the unconditional jumps are not removed anymore, as the whole terminator sequence is not analyzable anymore. Will fix it in a subsequence commit. llvm-svn: 268327
2016-05-03 06:58:54 +08:00
; CHECK-NEXT: .long [[BB0_imp_null_check_via_mem_comparision]]-_imp_null_check_via_mem_comparision
[ImplicitNullChecks] Work with implicit defs. Summary: This change generalizes the implicit null checks pass to work with instructions that don't have any explicit register defs. This lets us use X86's `cmp` against memory as faulting load instructions. Reviewers: reames, JosephTremoulet Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11286 llvm-svn: 242703
2015-07-21 04:31:39 +08:00
; Fault[0].HandlerOffset:
[X86] Model FAULTING_LOAD_OP as a terminator and branch. This operation may branch to the handler block and we do not want it to happen anywhere within the basic block. Moreover, by marking it "terminator and branch" the machine verifier does not wrongly assume (because of AnalyzeBranch not knowing better) the branch is analyzable. Indeed, the target was seeing only the unconditional branch and not the faulting load op and thought it was a simple unconditional block. The machine verifier was complaining because of that and moreover, other optimizations could have done wrong transformation! In the process, simplify the representation of the handler block in the faulting load op. Now, we directly reference the handler block instead of using a label. This has the benefits of: 1. MC knows how to issue a label for a BB, so leave that to it. 2. Accessing the target BB from its label is painful, whereas it is direct from a MBB operand. Note: The 2 bytes offset in implicit-null-check.ll comes from the fact the unconditional jumps are not removed anymore, as the whole terminator sequence is not analyzable anymore. Will fix it in a subsequence commit. llvm-svn: 268327
2016-05-03 06:58:54 +08:00
; CHECK-NEXT: .long [[BB1_imp_null_check_via_mem_comparision]]-_imp_null_check_via_mem_comparision
[ImplicitNullChecks] Work with implicit defs. Summary: This change generalizes the implicit null checks pass to work with instructions that don't have any explicit register defs. This lets us use X86's `cmp` against memory as faulting load instructions. Reviewers: reames, JosephTremoulet Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11286 llvm-svn: 242703
2015-07-21 04:31:39 +08:00
[FaultMaps] Add a parser for the __llvm__faultmaps section. Summary: The parser is exercised by llvm-objdump using -print-fault-maps. As is probably obvious, the code itself was "heavily inspired" by http://reviews.llvm.org/D10434. Reviewers: reames, atrick, JosephTremoulet Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10491 llvm-svn: 240304
2015-06-23 02:03:02 +08:00
; OBJDUMP: FaultMap table:
; OBJDUMP-NEXT: Version: 0x1
Fix implicit null check with negative offset Summary: It seems that negative offset was accidentally allowed in D17967. AFAICT small negative offset should be valid (always raise segfault) on all archs that I'm aware of (especially x86, which is the only one with this optimization enabled) and such case can be useful when loading hiden metadata from an object. However, like the positive side, it should only be done within a certain limit. For now, use the same limit on the positive side for the negative side. A separate option can be added if needs appear. Reviewers: mcrosier, skatkov Reviewed By: skatkov Subscribers: sanjoy, llvm-commits Differential Revision: https://reviews.llvm.org/D38925 llvm-svn: 315991
2017-10-17 19:47:36 +08:00
; OBJDUMP-NEXT: NumFunctions: 8
[FaultMaps] Add a parser for the __llvm__faultmaps section. Summary: The parser is exercised by llvm-objdump using -print-fault-maps. As is probably obvious, the code itself was "heavily inspired" by http://reviews.llvm.org/D10434. Reviewers: reames, atrick, JosephTremoulet Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10491 llvm-svn: 240304
2015-06-23 02:03:02 +08:00
; OBJDUMP-NEXT: FunctionAddress: 0x000000, NumFaultingPCs: 1
[MachineBlockPlacement] Let the target optimize the branches at the end. After the layout of the basic blocks is set, the target may be able to get rid of unconditional branches to fallthrough blocks that the generic code does not catch. This happens any time TargetInstrInfo::AnalyzeBranch is not able to analyze all the branches involved in the terminators sequence, while still understanding a few of them. In such situation, AnalyzeBranch can directly modify the branches if it has been instructed to do so. This patch takes advantage of that. llvm-svn: 268328
2016-05-03 06:58:59 +08:00
; OBJDUMP-NEXT: Fault kind: FaultingLoad, faulting PC offset: 0, handling PC offset: 5
[FaultMaps] Add a parser for the __llvm__faultmaps section. Summary: The parser is exercised by llvm-objdump using -print-fault-maps. As is probably obvious, the code itself was "heavily inspired" by http://reviews.llvm.org/D10434. Reviewers: reames, atrick, JosephTremoulet Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10491 llvm-svn: 240304
2015-06-23 02:03:02 +08:00
; OBJDUMP-NEXT: FunctionAddress: 0x000000, NumFaultingPCs: 1
[MachineBlockPlacement] Let the target optimize the branches at the end. After the layout of the basic blocks is set, the target may be able to get rid of unconditional branches to fallthrough blocks that the generic code does not catch. This happens any time TargetInstrInfo::AnalyzeBranch is not able to analyze all the branches involved in the terminators sequence, while still understanding a few of them. In such situation, AnalyzeBranch can directly modify the branches if it has been instructed to do so. This patch takes advantage of that. llvm-svn: 268328
2016-05-03 06:58:59 +08:00
; OBJDUMP-NEXT: Fault kind: FaultingLoad, faulting PC offset: 0, handling PC offset: 7
[ImplicitNullChecks] Be smarter in picking the memory op. Summary: Before this change ImplicitNullChecks would only pick loads of the form: ``` test Reg, Reg jz elsewhere fallthrough: movl 32(Reg), Reg2 ``` but not (say) ``` test Reg, Reg jz elsewhere fallthrough: inc Reg3 movl 32(Reg), Reg2 ``` This change teaches ImplicitNullChecks to look through "unrelated" instructions like `inc Reg3` when searching for a load instruction to convert to a trapping load. Reviewers: atrick, JosephTremoulet, reames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11044 llvm-svn: 241850
2015-07-10 04:13:25 +08:00
; OBJDUMP-NEXT: FunctionAddress: 0x000000, NumFaultingPCs: 1
[ImplicitNullCheck] Extend canReorder scope Summary: This change allows a re-order of two intructions if their uses are overlapped. Patch by Serguei Katkov! Reviewers: reames, sanjoy Reviewed By: sanjoy Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29120 llvm-svn: 293775
2017-02-02 00:04:21 +08:00
; OBJDUMP-NEXT: Fault kind: FaultingLoad, faulting PC offset: 0, handling PC offset: 9
; OBJDUMP-NEXT: FunctionAddress: 0x000000, NumFaultingPCs: 1
[MachineBlockPlacement] Let the target optimize the branches at the end. After the layout of the basic blocks is set, the target may be able to get rid of unconditional branches to fallthrough blocks that the generic code does not catch. This happens any time TargetInstrInfo::AnalyzeBranch is not able to analyze all the branches involved in the terminators sequence, while still understanding a few of them. In such situation, AnalyzeBranch can directly modify the branches if it has been instructed to do so. This patch takes advantage of that. llvm-svn: 268328
2016-05-03 06:58:59 +08:00
; OBJDUMP-NEXT: Fault kind: FaultingLoad, faulting PC offset: 0, handling PC offset: 7
[X86] Model FAULTING_LOAD_OP as a terminator and branch. This operation may branch to the handler block and we do not want it to happen anywhere within the basic block. Moreover, by marking it "terminator and branch" the machine verifier does not wrongly assume (because of AnalyzeBranch not knowing better) the branch is analyzable. Indeed, the target was seeing only the unconditional branch and not the faulting load op and thought it was a simple unconditional block. The machine verifier was complaining because of that and moreover, other optimizations could have done wrong transformation! In the process, simplify the representation of the handler block in the faulting load op. Now, we directly reference the handler block instead of using a label. This has the benefits of: 1. MC knows how to issue a label for a BB, so leave that to it. 2. Accessing the target BB from its label is painful, whereas it is direct from a MBB operand. Note: The 2 bytes offset in implicit-null-check.ll comes from the fact the unconditional jumps are not removed anymore, as the whole terminator sequence is not analyzable anymore. Will fix it in a subsequence commit. llvm-svn: 268327
2016-05-03 06:58:54 +08:00
; OBJDUMP-NEXT: FunctionAddress: 0x000000, NumFaultingPCs: 1
[MachineBlockPlacement] Let the target optimize the branches at the end. After the layout of the basic blocks is set, the target may be able to get rid of unconditional branches to fallthrough blocks that the generic code does not catch. This happens any time TargetInstrInfo::AnalyzeBranch is not able to analyze all the branches involved in the terminators sequence, while still understanding a few of them. In such situation, AnalyzeBranch can directly modify the branches if it has been instructed to do so. This patch takes advantage of that. llvm-svn: 268328
2016-05-03 06:58:59 +08:00
; OBJDUMP-NEXT: Fault kind: FaultingLoad, faulting PC offset: 0, handling PC offset: 3
[ImplicitNullCheck] Extend Implicit Null Check scope by using stores Summary: This change allows usage of store instruction for implicit null check. Memory Aliasing Analisys is not used and change conservatively supposes that any store and load may access the same memory. As a result re-ordering of store-store, store-load and load-store is prohibited. Patch by Serguei Katkov! Reviewers: reames, sanjoy Reviewed By: sanjoy Subscribers: atrick, llvm-commits Differential Revision: https://reviews.llvm.org/D29400 llvm-svn: 294338
2017-02-08 03:19:49 +08:00
; OBJDUMP-NEXT: FunctionAddress: 0x000000, NumFaultingPCs: 1
Fix implicit null check with negative offset Summary: It seems that negative offset was accidentally allowed in D17967. AFAICT small negative offset should be valid (always raise segfault) on all archs that I'm aware of (especially x86, which is the only one with this optimization enabled) and such case can be useful when loading hiden metadata from an object. However, like the positive side, it should only be done within a certain limit. For now, use the same limit on the positive side for the negative side. A separate option can be added if needs appear. Reviewers: mcrosier, skatkov Reviewed By: skatkov Subscribers: sanjoy, llvm-commits Differential Revision: https://reviews.llvm.org/D38925 llvm-svn: 315991
2017-10-17 19:47:36 +08:00
; OBJDUMP-NEXT: Fault kind: FaultingLoad, faulting PC offset: 0, handling PC offset: 4
; OBJDUMP-NEXT: FunctionAddress: 0x000000, NumFaultingPCs: 1
[ImplicitNullCheck] Extend Implicit Null Check scope by using stores Summary: This change allows usage of store instruction for implicit null check. Memory Aliasing Analisys is not used and change conservatively supposes that any store and load may access the same memory. As a result re-ordering of store-store, store-load and load-store is prohibited. Patch by Serguei Katkov! Reviewers: reames, sanjoy Reviewed By: sanjoy Subscribers: atrick, llvm-commits Differential Revision: https://reviews.llvm.org/D29400 llvm-svn: 294338
2017-02-08 03:19:49 +08:00
; OBJDUMP-NEXT: Fault kind: FaultingStore, faulting PC offset: 0, handling PC offset: 7
; OBJDUMP-NEXT: FunctionAddress: 0x000000, NumFaultingPCs: 1
; OBJDUMP-NEXT: Fault kind: FaultingLoad, faulting PC offset: 0, handling PC offset: 11