RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-23 19:23:23 +01:00
Code Issues Projects Releases Wiki Activity
5fafff6179
llvm-mirror/test/LTO/X86/strip-debug-info.ll

47 lines
1.8 KiB
LLVM
Raw Normal View History

Revert "Revert "ThinLTO: Verify bitcode before lauching the ThinLTOCodeGenerator."" This reapplies commit r303438 modified to not verify cross-imported bitcode in FunctionImporter. rdar://problem/31233625 Differential Revision: https://reviews.llvm.org/D33370 llvm-svn: 303470
2017-05-20 02:00:08 +02:00
; RUN: llvm-as -disable-verify %s -o %t.bc
; ---- Full LTO ---------------------------------------------
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-02 20:31:29 +02:00
; RUN: llvm-lto \
Allow the LTO code generator to strip invalid debug info from the input. This patch introduces a new option -lto-strip-invalid-debug-info, which drops malformed debug info from the input. The problem I'm trying to solve with this sequence of patches is that historically we've done a really bad job at verifying debug info. We want to be able to make the verifier stricter without having to worry about breaking bitcode compatibility with existing producers. For example, we don't necessarily want IR produced by an older version of clang to be rejected by an LTO link just because of malformed debug info, and rather provide an option to strip it. Note that merely outdated (but well-formed) debug info would continue to be auto-upgraded in this scenario. rdar://problem/25818489 http://reviews.llvm.org/D19987 This reapplies 268936 with a test case fix for Linux (-exported-symbol foo) llvm-svn: 268965
2016-05-09 21:57:15 +02:00
; RUN: -exported-symbol foo -exported-symbol _foo \
Revert "Revert "ThinLTO: Verify bitcode before lauching the ThinLTOCodeGenerator."" This reapplies commit r303438 modified to not verify cross-imported bitcode in FunctionImporter. rdar://problem/31233625 Differential Revision: https://reviews.llvm.org/D33370 llvm-svn: 303470
2017-05-20 02:00:08 +02:00
; RUN: -o %t.o %t.bc 2>&1 | \
Allow the LTO code generator to strip invalid debug info from the input. This patch introduces a new option -lto-strip-invalid-debug-info, which drops malformed debug info from the input. The problem I'm trying to solve with this sequence of patches is that historically we've done a really bad job at verifying debug info. We want to be able to make the verifier stricter without having to worry about breaking bitcode compatibility with existing producers. For example, we don't necessarily want IR produced by an older version of clang to be rejected by an LTO link just because of malformed debug info, and rather provide an option to strip it. Note that merely outdated (but well-formed) debug info would continue to be auto-upgraded in this scenario. rdar://problem/25818489 http://reviews.llvm.org/D19987 This reapplies 268936 with a test case fix for Linux (-exported-symbol foo) llvm-svn: 268965
2016-05-09 21:57:15 +02:00
; RUN: FileCheck %s -allow-empty -check-prefix=CHECK-WARN
; RUN: llvm-nm %t.o | FileCheck %s
Revert "Revert "ThinLTO: Verify bitcode before lauching the ThinLTOCodeGenerator."" This reapplies commit r303438 modified to not verify cross-imported bitcode in FunctionImporter. rdar://problem/31233625 Differential Revision: https://reviews.llvm.org/D33370 llvm-svn: 303470
2017-05-20 02:00:08 +02:00
; ---- Thin LTO (codegen only) ------------------------------
; RUN: llvm-lto -thinlto -thinlto-action=codegen \
; RUN: %t.bc -disable-verify 2>&1 | \
; RUN: FileCheck %s -allow-empty -check-prefix=CHECK-WARN
; ---- Thin LTO (optimize, strip main file) -----------------
; RUN: opt -disable-verify -module-summary %s -o %t.bc
; RUN: opt -disable-verify -module-summary %S/Inputs/strip-debug-info-bar.ll \
; RUN: -o %t2.bc
; RUN: llvm-lto -thinlto -thinlto-action=run \
; RUN: %t.bc -disable-verify 2>&1 | \
; RUN: FileCheck %s -allow-empty -check-prefix=CHECK-WARN
; ---- Thin LTO (optimize, strip imported file) -------------
; RUN: opt -disable-verify -strip-debug -module-summary %t.bc -o %t-stripped.bc
; RUN: llvm-lto -thinlto-action=thinlink -o %t.index.bc %t-stripped.bc %t2.bc
; RUN: llvm-lto -thinlto -thinlto-action=import \
; RUN: -thinlto-index=%t.index.bc \
; RUN: -exported-symbol foo -exported-symbol _foo \
; RUN: %t-stripped.bc -disable-verify 2>&1 | \
; RUN: FileCheck %s -allow-empty -check-prefix=CHECK-WARN
Allow the LTO code generator to strip invalid debug info from the input. This patch introduces a new option -lto-strip-invalid-debug-info, which drops malformed debug info from the input. The problem I'm trying to solve with this sequence of patches is that historically we've done a really bad job at verifying debug info. We want to be able to make the verifier stricter without having to worry about breaking bitcode compatibility with existing producers. For example, we don't necessarily want IR produced by an older version of clang to be rejected by an LTO link just because of malformed debug info, and rather provide an option to strip it. Note that merely outdated (but well-formed) debug info would continue to be auto-upgraded in this scenario. rdar://problem/25818489 http://reviews.llvm.org/D19987 This reapplies 268936 with a test case fix for Linux (-exported-symbol foo) llvm-svn: 268965
2016-05-09 21:57:15 +02:00
; CHECK-ERR: Broken module found, compilation aborted
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-02 20:31:29 +02:00
; CHECK-WARN: warning{{.*}} ignoring invalid debug info
Revert "Revert "ThinLTO: Verify bitcode before lauching the ThinLTOCodeGenerator."" This reapplies commit r303438 modified to not verify cross-imported bitcode in FunctionImporter. rdar://problem/31233625 Differential Revision: https://reviews.llvm.org/D33370 llvm-svn: 303470
2017-05-20 02:00:08 +02:00
; CHECK-WARN-NOT: Broken module found
Allow the LTO code generator to strip invalid debug info from the input. This patch introduces a new option -lto-strip-invalid-debug-info, which drops malformed debug info from the input. The problem I'm trying to solve with this sequence of patches is that historically we've done a really bad job at verifying debug info. We want to be able to make the verifier stricter without having to worry about breaking bitcode compatibility with existing producers. For example, we don't necessarily want IR produced by an older version of clang to be rejected by an LTO link just because of malformed debug info, and rather provide an option to strip it. Note that merely outdated (but well-formed) debug info would continue to be auto-upgraded in this scenario. rdar://problem/25818489 http://reviews.llvm.org/D19987 This reapplies 268936 with a test case fix for Linux (-exported-symbol foo) llvm-svn: 268965
2016-05-09 21:57:15 +02:00
; CHECK: foo
Revert "Change the X86 datalayout to add three address spaces for 32 bit signed," This reverts commit r370083 because it caused check-lld failures on sanitizer-x86_64-linux-fast. llvm-svn: 370142
2019-08-28 03:08:54 +02:00
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
Revert "Revert "ThinLTO: Verify bitcode before lauching the ThinLTOCodeGenerator."" This reapplies commit r303438 modified to not verify cross-imported bitcode in FunctionImporter. rdar://problem/31233625 Differential Revision: https://reviews.llvm.org/D33370 llvm-svn: 303470
2017-05-20 02:00:08 +02:00
target triple = "x86_64-apple-macosx10.12"
declare void @bar()
Allow the LTO code generator to strip invalid debug info from the input. This patch introduces a new option -lto-strip-invalid-debug-info, which drops malformed debug info from the input. The problem I'm trying to solve with this sequence of patches is that historically we've done a really bad job at verifying debug info. We want to be able to make the verifier stricter without having to worry about breaking bitcode compatibility with existing producers. For example, we don't necessarily want IR produced by an older version of clang to be rejected by an LTO link just because of malformed debug info, and rather provide an option to strip it. Note that merely outdated (but well-formed) debug info would continue to be auto-upgraded in this scenario. rdar://problem/25818489 http://reviews.llvm.org/D19987 This reapplies 268936 with a test case fix for Linux (-exported-symbol foo) llvm-svn: 268965
2016-05-09 21:57:15 +02:00
define void @foo() {
Revert "Revert "ThinLTO: Verify bitcode before lauching the ThinLTOCodeGenerator."" This reapplies commit r303438 modified to not verify cross-imported bitcode in FunctionImporter. rdar://problem/31233625 Differential Revision: https://reviews.llvm.org/D33370 llvm-svn: 303470
2017-05-20 02:00:08 +02:00
call void @bar()
Allow the LTO code generator to strip invalid debug info from the input. This patch introduces a new option -lto-strip-invalid-debug-info, which drops malformed debug info from the input. The problem I'm trying to solve with this sequence of patches is that historically we've done a really bad job at verifying debug info. We want to be able to make the verifier stricter without having to worry about breaking bitcode compatibility with existing producers. For example, we don't necessarily want IR produced by an older version of clang to be rejected by an LTO link just because of malformed debug info, and rather provide an option to strip it. Note that merely outdated (but well-formed) debug info would continue to be auto-upgraded in this scenario. rdar://problem/25818489 http://reviews.llvm.org/D19987 This reapplies 268936 with a test case fix for Linux (-exported-symbol foo) llvm-svn: 268965
2016-05-09 21:57:15 +02:00
ret void
}
!llvm.module.flags = !{!0}
!llvm.dbg.cu = !{!1}
!0 = !{i32 2, !"Debug Info Version", i32 3}
!1 = !DIFile(filename: "broken", directory: "")
Reference in New Issue Copy Permalink