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/tbaa.ll

124 lines
4.6 KiB
LLVM
Raw Normal View History

[Verifier] Add verification for TBAA metadata Summary: This change adds some verification in the IR verifier around struct path TBAA metadata. Other than some basic sanity checks (e.g. we get constant integers where we expect constant integers), this checks: - That by the time an struct access tuple `(base-type, offset)` is "reduced" to a scalar base type, the offset is `0`. For instance, in C++ you can't start from, say `("struct-a", 16)`, and end up with `("int", 4)` -- by the time the base type is `"int"`, the offset better be zero. In particular, a variant of this invariant is needed for `llvm::getMostGenericTBAA` to be correct. - That there are no cycles in a struct path. - That struct type nodes have their offsets listed in an ascending order. - That when generating the struct access path, you eventually reach the access type listed in the tbaa tag node. Reviewers: dexonsmith, chandlerc, reames, mehdi_amini, manmanren Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D26438 llvm-svn: 289402
2016-12-12 04:07:15 +08:00
; RUN: not llvm-as < %s 2>&1 | FileCheck %s
Move the stripping of invalid debug info from the Verifier to AutoUpgrade. This came out of a recent discussion on llvm-dev (https://reviews.llvm.org/D38042). Currently the Verifier will strip the debug info metadata from a module if it finds the dbeug info to be malformed. This feature is very valuable since it allows us to improve the Verifier by making it stricter without breaking bcompatibility, but arguable the Verifier pass should not be modifying the IR. This patch moves the stripping of broken debug info into AutoUpgrade (UpgradeDebugInfo to be precise), which is a much better location for this since the stripping of malformed (i.e., produced by older, buggy versions of Clang) is a (harsh) form of AutoUpgrade. This change is mostly NFC in nature, the one big difference is the behavior when LLVM module passes are introducing malformed debug info. Prior to this patch, a NoAsserts build would have printed a warning and stripped the debug info, after this patch the Verifier will report a fatal error. I believe this behavior is actually more desirable anyway. Differential Revision: https://reviews.llvm.org/D38184 llvm-svn: 314699
2017-10-03 02:31:29 +08:00
; RUN: llvm-as -disable-verify < %s | opt -verify -S | FileCheck %s --check-prefix=STRIP
[Verifier] Add verification for TBAA metadata Summary: This change adds some verification in the IR verifier around struct path TBAA metadata. Other than some basic sanity checks (e.g. we get constant integers where we expect constant integers), this checks: - That by the time an struct access tuple `(base-type, offset)` is "reduced" to a scalar base type, the offset is `0`. For instance, in C++ you can't start from, say `("struct-a", 16)`, and end up with `("int", 4)` -- by the time the base type is `"int"`, the offset better be zero. In particular, a variant of this invariant is needed for `llvm::getMostGenericTBAA` to be correct. - That there are no cycles in a struct path. - That struct type nodes have their offsets listed in an ascending order. - That when generating the struct access path, you eventually reach the access type listed in the tbaa tag node. Reviewers: dexonsmith, chandlerc, reames, mehdi_amini, manmanren Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D26438 llvm-svn: 289402
2016-12-12 04:07:15 +08:00
Strip invalid TBAA when reading bitcode This ensures backward compatibility on bitcode loading. Differential Revision: https://reviews.llvm.org/D27839 llvm-svn: 289977
2016-12-17 03:16:29 +08:00
; STRIP-NOT: tbaa
; STRIP: @f_0
; STRIP: Do no strip this
[Verifier] Add verification for TBAA metadata Summary: This change adds some verification in the IR verifier around struct path TBAA metadata. Other than some basic sanity checks (e.g. we get constant integers where we expect constant integers), this checks: - That by the time an struct access tuple `(base-type, offset)` is "reduced" to a scalar base type, the offset is `0`. For instance, in C++ you can't start from, say `("struct-a", 16)`, and end up with `("int", 4)` -- by the time the base type is `"int"`, the offset better be zero. In particular, a variant of this invariant is needed for `llvm::getMostGenericTBAA` to be correct. - That there are no cycles in a struct path. - That struct type nodes have their offsets listed in an ascending order. - That when generating the struct access path, you eventually reach the access type listed in the tbaa tag node. Reviewers: dexonsmith, chandlerc, reames, mehdi_amini, manmanren Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D26438 llvm-svn: 289402
2016-12-12 04:07:15 +08:00
define void @f_0(i32* %ptr) {
; This part checks for the easy syntactic verifier rules.
; CHECK: Struct tag metadata must have either 3 or 4 operands
; CHECK-NEXT: store i32 0, i32* %ptr, !tbaa !{{[0-9]+}}
; CHECK: Immutability tag on struct tag metadata must be a constant
; CHECK-NEXT: store i32 1, i32* %ptr, !tbaa !{{[0-9]+}}
; CHECK: Immutability part of the struct tag metadata must be either 0 or 1
; CHECK-NEXT: store i32 2, i32* %ptr, !tbaa !{{[0-9]+}}
; CHECK: Offset must be constant integer
; CHECK-NEXT: store i32 3, i32* %ptr, !tbaa !{{[0-9]+}}
; CHECK: Malformed struct tag metadata: base and access-type should be non-null and point to Metadata nodes
; CHECK-NEXT: store i32 4, i32* %ptr, !tbaa !{{[0-9]+}}
[TBAAVerifier] Be stricter around verifying scalar nodes This fixes the issue exposed in PR31393, where we weren't trying sufficiently hard to diagnose bad TBAA metadata. This does reduce the variety in the error messages we print out, but I think the tradeoff of verifying more, simply and quickly overrules the need for more helpful error messags here. llvm-svn: 290713
2016-12-29 23:47:05 +08:00
; CHECK: Access type node must be a valid scalar type
[Verifier] Add verification for TBAA metadata Summary: This change adds some verification in the IR verifier around struct path TBAA metadata. Other than some basic sanity checks (e.g. we get constant integers where we expect constant integers), this checks: - That by the time an struct access tuple `(base-type, offset)` is "reduced" to a scalar base type, the offset is `0`. For instance, in C++ you can't start from, say `("struct-a", 16)`, and end up with `("int", 4)` -- by the time the base type is `"int"`, the offset better be zero. In particular, a variant of this invariant is needed for `llvm::getMostGenericTBAA` to be correct. - That there are no cycles in a struct path. - That struct type nodes have their offsets listed in an ascending order. - That when generating the struct access path, you eventually reach the access type listed in the tbaa tag node. Reviewers: dexonsmith, chandlerc, reames, mehdi_amini, manmanren Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D26438 llvm-svn: 289402
2016-12-12 04:07:15 +08:00
; CHECK-NEXT: store i32 5, i32* %ptr, !tbaa !{{[0-9]+}}
; CHECK: Access bit-width not the same as description bit-width
; CHECK-NEXT: store i32 6, i32* %ptr, !tbaa !{{[0-9]+}}
[TBAAVerifier] Be stricter around verifying scalar nodes This fixes the issue exposed in PR31393, where we weren't trying sufficiently hard to diagnose bad TBAA metadata. This does reduce the variety in the error messages we print out, but I think the tradeoff of verifying more, simply and quickly overrules the need for more helpful error messags here. llvm-svn: 290713
2016-12-29 23:47:05 +08:00
; CHECK: Access type node must be a valid scalar type
[Verifier] Add verification for TBAA metadata Summary: This change adds some verification in the IR verifier around struct path TBAA metadata. Other than some basic sanity checks (e.g. we get constant integers where we expect constant integers), this checks: - That by the time an struct access tuple `(base-type, offset)` is "reduced" to a scalar base type, the offset is `0`. For instance, in C++ you can't start from, say `("struct-a", 16)`, and end up with `("int", 4)` -- by the time the base type is `"int"`, the offset better be zero. In particular, a variant of this invariant is needed for `llvm::getMostGenericTBAA` to be correct. - That there are no cycles in a struct path. - That struct type nodes have their offsets listed in an ascending order. - That when generating the struct access path, you eventually reach the access type listed in the tbaa tag node. Reviewers: dexonsmith, chandlerc, reames, mehdi_amini, manmanren Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D26438 llvm-svn: 289402
2016-12-12 04:07:15 +08:00
; CHECK-NEXT: store i32 7, i32* %ptr, !tbaa !{{[0-9]+}}
[TBAAVerifier] Be stricter around verifying scalar nodes This fixes the issue exposed in PR31393, where we weren't trying sufficiently hard to diagnose bad TBAA metadata. This does reduce the variety in the error messages we print out, but I think the tradeoff of verifying more, simply and quickly overrules the need for more helpful error messags here. llvm-svn: 290713
2016-12-29 23:47:05 +08:00
; CHECK: Struct tag nodes have a string as their first operand
; CHECK-NEXT: !{{[0-9]+}} = !{!{{[0-9]+}}, !{{[0-9]+}}, i64 0}
; CHECK: Access type node must be a valid scalar type
; CHECK-NEXT: store i32 9, i32* %ptr, !tbaa !{{[0-9]+}}
[Verifier] Add verification for TBAA metadata Summary: This change adds some verification in the IR verifier around struct path TBAA metadata. Other than some basic sanity checks (e.g. we get constant integers where we expect constant integers), this checks: - That by the time an struct access tuple `(base-type, offset)` is "reduced" to a scalar base type, the offset is `0`. For instance, in C++ you can't start from, say `("struct-a", 16)`, and end up with `("int", 4)` -- by the time the base type is `"int"`, the offset better be zero. In particular, a variant of this invariant is needed for `llvm::getMostGenericTBAA` to be correct. - That there are no cycles in a struct path. - That struct type nodes have their offsets listed in an ascending order. - That when generating the struct access path, you eventually reach the access type listed in the tbaa tag node. Reviewers: dexonsmith, chandlerc, reames, mehdi_amini, manmanren Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D26438 llvm-svn: 289402
2016-12-12 04:07:15 +08:00
store i32 0, i32* %ptr, !tbaa !{!3, !2, i64 40, i64 0, i64 1, i64 2}
store i32 1, i32* %ptr, !tbaa !{!3, !2, i64 40, !"immutable"}
store i32 2, i32* %ptr, !tbaa !{!3, !2, i64 40, i64 4}
store i32 3, i32* %ptr, !tbaa !{!3, !2, !"40", i64 0}
store i32 4, i32* %ptr, !tbaa !{!3, null, !"40", i64 0}
store i32 5, i32* %ptr, !tbaa !{!3, !3, !"40", i64 0}
store i32 6, i32* %ptr, !tbaa !{!3, !2, i32 40, i64 0}
Strip invalid TBAA when reading bitcode This ensures backward compatibility on bitcode loading. Differential Revision: https://reviews.llvm.org/D27839 llvm-svn: 289977
2016-12-17 03:16:29 +08:00
store i32 7, i32* %ptr, !tbaa !{!3, !12, i32 40, i64 0}, !metadata !42
[TBAAVerifier] Be stricter around verifying scalar nodes This fixes the issue exposed in PR31393, where we weren't trying sufficiently hard to diagnose bad TBAA metadata. This does reduce the variety in the error messages we print out, but I think the tradeoff of verifying more, simply and quickly overrules the need for more helpful error messags here. llvm-svn: 290713
2016-12-29 23:47:05 +08:00
store i32 8, i32* %ptr, !tbaa !{!13, !1, i64 0}
store i32 9, i32* %ptr, !tbaa !{!14, !14, i64 0}
[Verifier] Add verification for TBAA metadata Summary: This change adds some verification in the IR verifier around struct path TBAA metadata. Other than some basic sanity checks (e.g. we get constant integers where we expect constant integers), this checks: - That by the time an struct access tuple `(base-type, offset)` is "reduced" to a scalar base type, the offset is `0`. For instance, in C++ you can't start from, say `("struct-a", 16)`, and end up with `("int", 4)` -- by the time the base type is `"int"`, the offset better be zero. In particular, a variant of this invariant is needed for `llvm::getMostGenericTBAA` to be correct. - That there are no cycles in a struct path. - That struct type nodes have their offsets listed in an ascending order. - That when generating the struct access path, you eventually reach the access type listed in the tbaa tag node. Reviewers: dexonsmith, chandlerc, reames, mehdi_amini, manmanren Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D26438 llvm-svn: 289402
2016-12-12 04:07:15 +08:00
ret void
}
Strip invalid TBAA when reading bitcode This ensures backward compatibility on bitcode loading. Differential Revision: https://reviews.llvm.org/D27839 llvm-svn: 289977
2016-12-17 03:16:29 +08:00
!42 = !{!"Do no strip this!"}
[Verifier] Add verification for TBAA metadata Summary: This change adds some verification in the IR verifier around struct path TBAA metadata. Other than some basic sanity checks (e.g. we get constant integers where we expect constant integers), this checks: - That by the time an struct access tuple `(base-type, offset)` is "reduced" to a scalar base type, the offset is `0`. For instance, in C++ you can't start from, say `("struct-a", 16)`, and end up with `("int", 4)` -- by the time the base type is `"int"`, the offset better be zero. In particular, a variant of this invariant is needed for `llvm::getMostGenericTBAA` to be correct. - That there are no cycles in a struct path. - That struct type nodes have their offsets listed in an ascending order. - That when generating the struct access path, you eventually reach the access type listed in the tbaa tag node. Reviewers: dexonsmith, chandlerc, reames, mehdi_amini, manmanren Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D26438 llvm-svn: 289402
2016-12-12 04:07:15 +08:00
define void @f_1(i32* %ptr) {
; This part checks for more semantic verifier rules.
; CHECK: Cycle detected in struct path
; CHECK-NEXT: store i32 0, i32* %ptr, !tbaa !{{[0-9]+}}
; CHECK: Offset not zero at the point of scalar access
; CHECK-NEXT: store i32 1, i32* %ptr, !tbaa !{{[0-9]+}}
; CHECK: Offset not zero at the point of scalar access
; CHECK-NEXT: store i32 2, i32* %ptr, !tbaa !{{[0-9]+}}
; CHECK: Could not find TBAA parent in struct type node
; CHECK-NEXT: store i32 3, i32* %ptr, !tbaa !{{[0-9]+}}
; CHECK: Did not see access type in access path!
; CHECK-NEXT: store i32 3, i32* %ptr, !tbaa !{{[0-9]+}}
[TBAAVerifier] Be stricter around verifying scalar nodes This fixes the issue exposed in PR31393, where we weren't trying sufficiently hard to diagnose bad TBAA metadata. This does reduce the variety in the error messages we print out, but I think the tradeoff of verifying more, simply and quickly overrules the need for more helpful error messags here. llvm-svn: 290713
2016-12-29 23:47:05 +08:00
; CHECK: Access type node must be a valid scalar type
[Verifier] Add verification for TBAA metadata Summary: This change adds some verification in the IR verifier around struct path TBAA metadata. Other than some basic sanity checks (e.g. we get constant integers where we expect constant integers), this checks: - That by the time an struct access tuple `(base-type, offset)` is "reduced" to a scalar base type, the offset is `0`. For instance, in C++ you can't start from, say `("struct-a", 16)`, and end up with `("int", 4)` -- by the time the base type is `"int"`, the offset better be zero. In particular, a variant of this invariant is needed for `llvm::getMostGenericTBAA` to be correct. - That there are no cycles in a struct path. - That struct type nodes have their offsets listed in an ascending order. - That when generating the struct access path, you eventually reach the access type listed in the tbaa tag node. Reviewers: dexonsmith, chandlerc, reames, mehdi_amini, manmanren Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D26438 llvm-svn: 289402
2016-12-12 04:07:15 +08:00
; CHECK-NEXT: store i32 4, i32* %ptr, !tbaa !{{[0-9]+}}
[TBAAVerifier] Be stricter around verifying scalar nodes This fixes the issue exposed in PR31393, where we weren't trying sufficiently hard to diagnose bad TBAA metadata. This does reduce the variety in the error messages we print out, but I think the tradeoff of verifying more, simply and quickly overrules the need for more helpful error messags here. llvm-svn: 290713
2016-12-29 23:47:05 +08:00
; CHECK: Access type node must be a valid scalar type
[Verifier] Add verification for TBAA metadata Summary: This change adds some verification in the IR verifier around struct path TBAA metadata. Other than some basic sanity checks (e.g. we get constant integers where we expect constant integers), this checks: - That by the time an struct access tuple `(base-type, offset)` is "reduced" to a scalar base type, the offset is `0`. For instance, in C++ you can't start from, say `("struct-a", 16)`, and end up with `("int", 4)` -- by the time the base type is `"int"`, the offset better be zero. In particular, a variant of this invariant is needed for `llvm::getMostGenericTBAA` to be correct. - That there are no cycles in a struct path. - That struct type nodes have their offsets listed in an ascending order. - That when generating the struct access path, you eventually reach the access type listed in the tbaa tag node. Reviewers: dexonsmith, chandlerc, reames, mehdi_amini, manmanren Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D26438 llvm-svn: 289402
2016-12-12 04:07:15 +08:00
; CHECK-NEXT: store i32 5, i32* %ptr, !tbaa !{{[0-9]+}}
[TBAAVerifier] Be stricter around verifying scalar nodes This fixes the issue exposed in PR31393, where we weren't trying sufficiently hard to diagnose bad TBAA metadata. This does reduce the variety in the error messages we print out, but I think the tradeoff of verifying more, simply and quickly overrules the need for more helpful error messags here. llvm-svn: 290713
2016-12-29 23:47:05 +08:00
; CHECK: Access type node must be a valid scalar type
[Verifier] Add verification for TBAA metadata Summary: This change adds some verification in the IR verifier around struct path TBAA metadata. Other than some basic sanity checks (e.g. we get constant integers where we expect constant integers), this checks: - That by the time an struct access tuple `(base-type, offset)` is "reduced" to a scalar base type, the offset is `0`. For instance, in C++ you can't start from, say `("struct-a", 16)`, and end up with `("int", 4)` -- by the time the base type is `"int"`, the offset better be zero. In particular, a variant of this invariant is needed for `llvm::getMostGenericTBAA` to be correct. - That there are no cycles in a struct path. - That struct type nodes have their offsets listed in an ascending order. - That when generating the struct access path, you eventually reach the access type listed in the tbaa tag node. Reviewers: dexonsmith, chandlerc, reames, mehdi_amini, manmanren Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D26438 llvm-svn: 289402
2016-12-12 04:07:15 +08:00
; CHECK-NEXT: store i32 6, i32* %ptr, !tbaa !{{[0-9]+}}
; CHECK: Struct tag nodes must have an odd number of operands!
; CHECK-NEXT:!{{[0-9]+}} = !{!"bad-struct-type-0", !{{[0-9]+}}, i64 40, !{{[0-9]+}}}
; CHECK: Incorrect field entry in struct type node!
; CHECK-NEXT: store i32 8, i32* %ptr, !tbaa !{{[0-9]+}}
; CHECK: Bitwidth between the offsets and struct type entries must match
; CHECK-NEXT: store i32 9, i32* %ptr, !tbaa !{{[0-9]+}}
; CHECK: Offsets must be increasing!
; CHECK-NEXT: store i32 10, i32* %ptr, !tbaa !{{[0-9]+}}
store i32 0, i32* %ptr, !tbaa !{!4, !2, i64 40}
store i32 1, i32* %ptr, !tbaa !{!3, !2, i64 45}
store i32 2, i32* %ptr, !tbaa !{!3, !2, i64 45}
store i32 3, i32* %ptr, !tbaa !{!3, !2, i64 10}
store i32 4, i32* %ptr, !tbaa !{!5, !5, i64 0}
store i32 5, i32* %ptr, !tbaa !{!6, !6, i64 0}
store i32 6, i32* %ptr, !tbaa !{!7, !7, i64 0}
store i32 7, i32* %ptr, !tbaa !{!8, !1, i64 40}
store i32 8, i32* %ptr, !tbaa !{!9, !1, i64 40}
store i32 9, i32* %ptr, !tbaa !{!10, !1, i64 40}
store i32 10, i32* %ptr, !tbaa !{!11, !1, i64 40}
ret void
}
!0 = !{!"root"}
!1 = !{!"scalar-a", !0}
!2 = !{!"scalar-b", !0}
!3 = !{!"struct-a", !2, i64 20, !1, i64 40}
!4 = distinct !{!"self-recursive-struct", !2, i64 20, !4, i64 40}
!5 = !{!"bad-scalar-0", i64 40}
!6 = !{i64 42, !0}
!7 = !{!"bad-scalar-1", null}
!8 = !{!"bad-struct-type-0", !1, i64 40, !1}
!9 = !{!"bad-struct-type-1", !1, i64 40, i64 56, !1}
!10 = !{!"bad-struct-type-2", !1, i64 40, !1, i32 56}
!11 = !{!"bad-struct-type-2", !1, i64 80, !1, i64 56}
!12 = !{!"bad-scalar-2", !3, i64 0}
[TBAAVerifier] Be stricter around verifying scalar nodes This fixes the issue exposed in PR31393, where we weren't trying sufficiently hard to diagnose bad TBAA metadata. This does reduce the variety in the error messages we print out, but I think the tradeoff of verifying more, simply and quickly overrules the need for more helpful error messags here. llvm-svn: 290713
2016-12-29 23:47:05 +08:00
!13 = !{!1, !1, i64 0}
!14 = !{!"bad-scalar-2", !13}