2019-05-17 14:41:04 +08:00
|
|
|
; REQUIRES: plugins
|
[bugpoint] Find 'opt', etc., in bugpoint directory
Summary:
When bugpoint attempts to find the other executables it needs to run,
such as `opt` or `clang`, it tries searching the user's PATH. However,
in many cases, the 'bugpoint' executable is part of an LLVM build, and
the 'opt' executable it's looking for is in that same directory.
Many LLVM tools handle this case by using the `Paths` parameter of
`llvm::sys::findProgramByName`, passing the parent path of the currently
running executable. Do this same thing for bugpoint. However, to
preserve the current behavior exactly, first search the user's PATH,
and then search for 'opt' in the directory containing 'bugpoint'.
Test Plan:
`check-llvm`. Many of the existing bugpoint tests no longer need to use the
`--opt-command` option as a result of these changes.
Reviewers: MatzeB, silvas, davide
Reviewed By: MatzeB, davide
Subscribers: davide, llvm-commits
Differential Revision: https://reviews.llvm.org/D54884
llvm-svn: 348734
2018-12-10 08:56:13 +08:00
|
|
|
; RUN: bugpoint -load %llvmshlibdir/BugpointPasses%shlibext %s -output-prefix %t -bugpoint-crashcalls -silence-passes -disable-namedmd-remove -disable-strip-debuginfo -disable-strip-debug-types > /dev/null
|
2016-10-26 02:44:13 +08:00
|
|
|
; RUN: llvm-dis %t-reduced-simplified.bc -o - | FileCheck %s
|
|
|
|
;
|
[bugpoint] Find 'opt', etc., in bugpoint directory
Summary:
When bugpoint attempts to find the other executables it needs to run,
such as `opt` or `clang`, it tries searching the user's PATH. However,
in many cases, the 'bugpoint' executable is part of an LLVM build, and
the 'opt' executable it's looking for is in that same directory.
Many LLVM tools handle this case by using the `Paths` parameter of
`llvm::sys::findProgramByName`, passing the parent path of the currently
running executable. Do this same thing for bugpoint. However, to
preserve the current behavior exactly, first search the user's PATH,
and then search for 'opt' in the directory containing 'bugpoint'.
Test Plan:
`check-llvm`. Many of the existing bugpoint tests no longer need to use the
`--opt-command` option as a result of these changes.
Reviewers: MatzeB, silvas, davide
Reviewed By: MatzeB, davide
Subscribers: davide, llvm-commits
Differential Revision: https://reviews.llvm.org/D54884
llvm-svn: 348734
2018-12-10 08:56:13 +08:00
|
|
|
; RUN: bugpoint -load %llvmshlibdir/BugpointPasses%shlibext %s -output-prefix %t-nodebug -bugpoint-crashcalls -silence-passes -disable-namedmd-remove > /dev/null
|
2016-10-26 02:44:13 +08:00
|
|
|
; RUN: llvm-dis %t-nodebug-reduced-simplified.bc -o - | FileCheck %s --check-prefix=NODEBUG
|
|
|
|
;
|
[bugpoint] Find 'opt', etc., in bugpoint directory
Summary:
When bugpoint attempts to find the other executables it needs to run,
such as `opt` or `clang`, it tries searching the user's PATH. However,
in many cases, the 'bugpoint' executable is part of an LLVM build, and
the 'opt' executable it's looking for is in that same directory.
Many LLVM tools handle this case by using the `Paths` parameter of
`llvm::sys::findProgramByName`, passing the parent path of the currently
running executable. Do this same thing for bugpoint. However, to
preserve the current behavior exactly, first search the user's PATH,
and then search for 'opt' in the directory containing 'bugpoint'.
Test Plan:
`check-llvm`. Many of the existing bugpoint tests no longer need to use the
`--opt-command` option as a result of these changes.
Reviewers: MatzeB, silvas, davide
Reviewed By: MatzeB, davide
Subscribers: davide, llvm-commits
Differential Revision: https://reviews.llvm.org/D54884
llvm-svn: 348734
2018-12-10 08:56:13 +08:00
|
|
|
; RUN: bugpoint -load %llvmshlibdir/BugpointPasses%shlibext %s -output-prefix %t-notype -bugpoint-crashcalls -silence-passes -disable-namedmd-remove -disable-strip-debuginfo > /dev/null
|
2016-10-26 02:44:13 +08:00
|
|
|
; RUN: llvm-dis %t-notype-reduced-simplified.bc -o - | FileCheck %s --check-prefix=NOTYPE
|
|
|
|
;
|
2019-10-30 22:30:42 +08:00
|
|
|
; Bugpoint can drop the metadata on the call, as it does not contrinute to the crash.
|
2010-08-25 04:23:51 +08:00
|
|
|
|
2019-10-30 22:30:42 +08:00
|
|
|
; CHECK: call void @foo()
|
|
|
|
; NODEBUG: call void @foo()
|
|
|
|
; NOTYPE: call void @foo()
|
|
|
|
; NODEBUG-NOT: call void @foo()
|
2016-10-26 02:44:13 +08:00
|
|
|
; NOTYPE-NOT: !DIBasicType
|
|
|
|
; NOTYPE: !DICompileUnit
|
|
|
|
; NOTYPE-NOT: !DIBasicType
|
2010-08-25 04:23:51 +08:00
|
|
|
|
|
|
|
%rust_task = type {}
|
2019-10-30 22:30:42 +08:00
|
|
|
define void @test(i32* %a, i8* %b) !dbg !9 {
|
2010-08-25 04:23:51 +08:00
|
|
|
%s = mul i8 22, 9, !attach !0, !dbg !10
|
|
|
|
store i8 %s, i8* %b, !attach !1, !dbg !11
|
|
|
|
call void @foo(), !attach !2, !dbg !12
|
|
|
|
store i32 7, i32* %a, !attach !3, !dbg !13
|
|
|
|
%t = add i32 0, 5, !attach !4, !dbg !14
|
|
|
|
ret void
|
|
|
|
}
|
|
|
|
|
|
|
|
declare void @foo()
|
|
|
|
|
2013-11-23 09:16:29 +08:00
|
|
|
!llvm.module.flags = !{!17}
|
2016-04-12 07:30:29 +08:00
|
|
|
!llvm.dbg.cu = !{!8}
|
2013-11-23 09:16:29 +08:00
|
|
|
|
IR: Make metadata typeless in assembly
Now that `Metadata` is typeless, reflect that in the assembly. These
are the matching assembly changes for the metadata/value split in
r223802.
- Only use the `metadata` type when referencing metadata from a call
intrinsic -- i.e., only when it's used as a `Value`.
- Stop pretending that `ValueAsMetadata` is wrapped in an `MDNode`
when referencing it from call intrinsics.
So, assembly like this:
define @foo(i32 %v) {
call void @llvm.foo(metadata !{i32 %v}, metadata !0)
call void @llvm.foo(metadata !{i32 7}, metadata !0)
call void @llvm.foo(metadata !1, metadata !0)
call void @llvm.foo(metadata !3, metadata !0)
call void @llvm.foo(metadata !{metadata !3}, metadata !0)
ret void, !bar !2
}
!0 = metadata !{metadata !2}
!1 = metadata !{i32* @global}
!2 = metadata !{metadata !3}
!3 = metadata !{}
turns into this:
define @foo(i32 %v) {
call void @llvm.foo(metadata i32 %v, metadata !0)
call void @llvm.foo(metadata i32 7, metadata !0)
call void @llvm.foo(metadata i32* @global, metadata !0)
call void @llvm.foo(metadata !3, metadata !0)
call void @llvm.foo(metadata !{!3}, metadata !0)
ret void, !bar !2
}
!0 = !{!2}
!1 = !{i32* @global}
!2 = !{!3}
!3 = !{}
I wrote an upgrade script that handled almost all of the tests in llvm
and many of the tests in cfe (even handling many `CHECK` lines). I've
attached it (or will attach it in a moment if you're speedy) to PR21532
to help everyone update their out-of-tree testcases.
This is part of PR21532.
llvm-svn: 224257
2014-12-16 03:07:53 +08:00
|
|
|
!0 = !{!"boring"}
|
|
|
|
!1 = !{!"uninteresting"}
|
|
|
|
!2 = !{!"the call to foo"}
|
|
|
|
!3 = !{!"noise"}
|
|
|
|
!4 = !{!"filler"}
|
2010-08-25 04:23:51 +08:00
|
|
|
|
2016-04-15 23:57:41 +08:00
|
|
|
!8 = distinct !DICompileUnit(language: DW_LANG_C99, file: !15)
|
2016-10-26 02:44:13 +08:00
|
|
|
!9 = distinct !DISubprogram(name: "test", file: !15, type: !18, unit: !8)
|
2015-04-30 00:38:44 +08:00
|
|
|
!10 = !DILocation(line: 100, column: 101, scope: !9)
|
|
|
|
!11 = !DILocation(line: 102, column: 103, scope: !9)
|
|
|
|
!12 = !DILocation(line: 104, column: 105, scope: !9)
|
|
|
|
!13 = !DILocation(line: 106, column: 107, scope: !9)
|
|
|
|
!14 = !DILocation(line: 108, column: 109, scope: !9)
|
|
|
|
!15 = !DIFile(filename: "source.c", directory: "/dir")
|
2015-03-26 13:03:10 +08:00
|
|
|
!16 = !{}
|
2015-03-04 01:24:31 +08:00
|
|
|
!17 = !{i32 1, !"Debug Info Version", i32 3}
|
2016-10-26 02:44:13 +08:00
|
|
|
!18 = !DISubroutineType(types: !19)
|
|
|
|
!19 = !{!20, !20}
|
|
|
|
!20 = !DIBasicType(name: "int", size: 32, align: 32, encoding: DW_ATE_signed)
|