CrashDebugger.cpp has the following include chain:
llvm/Analysis/TargetTransformInfo.h
llvm/IR/IntrinsicInst.h
llvm/IR/Function.h
llvm/IR/Argument.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen
This means bugpoint needs to depend on intrinsics_gen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287402 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Split ReaderWriter.h which contains the APIs into both the BitReader and
BitWriter libraries into BitcodeReader.h and BitcodeWriter.h.
This is to address Chandler's concern about sharing the same API header
between multiple libraries (BitReader and BitWriter). That concern is
why we create a single bitcode library in our downstream build of clang,
which led to r286297 being reverted as it added a dependency that
created a cycle only when there is a single bitcode library (not two as
in upstream).
Reviewers: mehdi_amini
Subscribers: dlj, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D26502
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286566 91177308-0d34-0410-b5e6-96231b3b80d8
This adds a new function to DebugInfo.cpp that takes an llvm::Module
as input and removes all debug info metadata that is not directly
needed for line tables, thus effectively stripping all type and
variable information from the module.
The primary motivation for this feature was the bitcode work flow
(cf. http://lists.llvm.org/pipermail/llvm-dev/2016-June/100643.html
for more background). This is not wired up yet, but will be in
subsequent patches. For testing, the new functionality is exposed to
opt with a -strip-nonlinetable-debuginfo option.
The secondary use-case (and one that works right now!) is as a
reduction pass in bugpoint. I added two new bugpoint options
(-disable-strip-debuginfo and -disable-strip-debug-types) to control
the new features. By default it will first attempt to remove all debug
information, then only the type info, and then proceed to hack at any
remaining MDNodes.
Thanks to Adrian Prantl for stewarding this patch!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285094 91177308-0d34-0410-b5e6-96231b3b80d8
debugger.
When bugpoint hacks at a testcase it may at one point create illegal
debug info metadata that won't even pass the Verifier. A bugpoint
*driver* built with assertions should not assert on it, but reject the
malformed intermediate step and continue to do its job.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284490 91177308-0d34-0410-b5e6-96231b3b80d8
The core of the change is supposed to be NFC, however it also fixes
what I believe was an undefined behavior when calling:
va_start(ValueArgs, Desc);
with Desc being a StringRef.
Differential Revision: https://reviews.llvm.org/D25342
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283671 91177308-0d34-0410-b5e6-96231b3b80d8
This adds a new function to DebugInfo.cpp that takes an llvm::Module
as input and removes all debug info metadata that is not directly
needed for line tables, thus effectively stripping all type and
variable information from the module.
The primary motivation for this feature was the bitcode work flow
(cf. http://lists.llvm.org/pipermail/llvm-dev/2016-June/100643.html
for more background). This is not wired up yet, but will be in
subsequent patches. For testing, the new functionality is exposed to
opt with a -strip-nonlinetable-debuginfo option.
The secondary use-case (and one that works right now!) is as a
reduction pass in bugpoint. I added two new bugpoint options
(-disable-strip-debuginfo and -disable-strip-debug-types) to control
the new features. By default it will first attempt to remove all debug
information, then only the type info, and then proceed to hack at any
remaining MDNodes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283473 91177308-0d34-0410-b5e6-96231b3b80d8
It got disconnected during the cmake conversion. For Miscompilation.cpp,
it was purely advisory for the user and the ToolRunner.cpp version was
trying to compensate for libs and bins in the same directory, which
hasn't been the case for a very long time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283022 91177308-0d34-0410-b5e6-96231b3b80d8
The ValueSymbolTable is used to detect name conflict and rename
instructions automatically. This is not needed when the value
names are automatically discarded by the LLVMContext.
No functional change intended, just saving a little bit of memory.
This is a recommit of r281806 after fixing the accessor to return
a pointer instead of a reference and updating all the call-sites.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281813 91177308-0d34-0410-b5e6-96231b3b80d8
This change ensures all necessary symbols are resolved correctly. Before this
change on some systems, the linker may have eliminated some symbols not directly
used in bugpoint, but used in Polly.
Suggested-by: Michael Kruse <lvm@meinersbur.de>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281438 91177308-0d34-0410-b5e6-96231b3b80d8
This replaces the threading of `std::string &Error` through all of
these APIs with checked Error returns instead. There are very few
places here that actually emit any errors right now, but threading the
APIs through will allow us to replace a bunch of exit(1)'s that are
scattered through this code with proper error handling.
This is more or less NFC, but does move around where a couple of error
messages are printed out.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280720 91177308-0d34-0410-b5e6-96231b3b80d8
This isn't the right thing to do - it turns out a number of the APIs
that "never fail" just exit(1) if something bad happens. We can and
should thread Error through this instead.
That diff will make more sense with this reverted. Sorry for the
noise.
This reverts r280690
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280691 91177308-0d34-0410-b5e6-96231b3b80d8
This simplifies ListReducer and most of its subclasses by removing the
std::string &Error that was threaded through all of them but almost
never used. If we end up needing error handling in more places here we
can reinstate it using llvm::Error instead of these unwieldy strings.
The 2 cases (out of 12) that actually can hit the error cases are a
little bit awkward now, but those will clean up as I refactor this API
further.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280690 91177308-0d34-0410-b5e6-96231b3b80d8
minimal and boring form than the old pass manager's version.
This pass does the very minimal amount of work necessary to inline
functions declared as always-inline. It doesn't support a wide array of
things that the legacy pass manager did support, but is alse ... about
20 lines of code. So it has that going for it. Notably things this
doesn't support:
- Array alloca merging
- To support the above, bottom-up inlining with careful history
tracking and call graph updates
- DCE of the functions that become dead after this inlining.
- Inlining through call instructions with the always_inline attribute.
Instead, it focuses on inlining functions with that attribute.
The first I've omitted because I'm hoping to just turn it off for the
primary pass manager. If that doesn't pan out, I can add it here but it
will be reasonably expensive to do so.
The second should really be handled by running global-dce after the
inliner. I don't want to re-implement the non-trivial logic necessary to
do comdat-correct DCE of functions. This means the -O0 pipeline will
have to be at least 'always-inline,global-dce', but that seems
reasonable to me. If others are seriously worried about this I'd like to
hear about it and understand why. Again, this is all solveable by
factoring that logic into a utility and calling it here, but I'd like to
wait to do that until there is a clear reason why the existing
pass-based factoring won't work.
The final point is a serious one. I can fairly easily add support for
this, but it seems both costly and a confusing construct for the use
case of the always inliner running at -O0. This attribute can of course
still impact the normal inliner easily (although I find that
a questionable re-use of the same attribute). I've started a discussion
to sort out what semantics we want here and based on that can figure out
if it makes sense ta have this complexity at O0 or not.
One other advantage of this design is that it should be quite a bit
faster due to checking for whether the function is a viable candidate
for inlining exactly once per function instead of doing it for each call
site.
Anyways, hopefully a reasonable starting point for this pass.
Differential Revision: https://reviews.llvm.org/D23299
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278896 91177308-0d34-0410-b5e6-96231b3b80d8
If the result of the find is only used to compare against end(), just
use is_contained instead.
No functionality change is intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278433 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Depends on D22841
We now use a much simpler CFG simplification routine for bugpoint,
because SimplifyCFG is no longer a good match for what bugpoint wants
to do.
At the same time, to make sure we don't lose anything valuable it was doing,
SimplifyCFG is now run as a per-BB reduction pass.
With this and D22841 combined, bugpoint operates both much faster on
the large testcases i have, and reduces them to pretty much minimal
testcases (in one case, bugpoint used to leave about 6000 useless blocks, and
now it leaves 3 ...)
Reviewers: chandlerc, majnemer
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D22845
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277063 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Add a pass to bugpoint to make it transform conditional jumps into unconditional jumps.
Often, bugpoint generates output that has large numbers of br undef jumps, where
one side is dead.
What is happening is two fold:
1. It never tries to just pick a direction for the jump, and just see what happens
<<<< this patch
2. SimplifyCFG no longer is a good match for bugpoint's usecase. It
does too much.
Even things in SimplifyCFG, like removeUnreachableBlocks, go to great
lengths to transform undefined behavior into blocks and kill large
parts of the CFG. This is great for regular code, not so much for
bugpoint, which often generates UB on purpose (store undef is a great
example).
<<<< a followup patch that is coming, to move simplifycfg into a
separate reduction pass, and move the existing reduceCrashingBlocks
pass to use simpleSimplifyCFG.
Both of these patches significantly reduce the size and complexity of bugpoint
generated testcases.
Reviewers: chandlerc, majnemer
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D22841
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276884 91177308-0d34-0410-b5e6-96231b3b80d8
The default behavior of bugpoint is to print "<crash>" when it finds a reduced
test that crashes compilation. With this flag we now can see the output of the
crashing program. This is useful to make sure it is the same error being
tracked down and not a different error that happens to crash the compiler as
well.
Differential Revision: https://reviews.llvm.org/D22411
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275646 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is necessary to keep the verifier happy after bugpoint removes an
initializer from a global variable with a comdat annotation, because
globals without initializers may not have comdats.
Reviewers: majnemer, rnk
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D21274
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272854 91177308-0d34-0410-b5e6-96231b3b80d8
looking for it along $PATH. This allows installs of LLVM tools outside of
$PATH to find the symbolizer and produce pretty backtraces if they crash.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272232 91177308-0d34-0410-b5e6-96231b3b80d8
We forgot to consider the target of ifuncs when considering if a
function was alive or dead.
N.B. Also update a few auxiliary tools like bugpoint and
verify-uselistorder.
This fixes PR27593.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268468 91177308-0d34-0410-b5e6-96231b3b80d8
At the same time, fixes InstructionsTest::CastInst unittest: yes
you can leave the IR in an invalid state and exit when you don't
destroy the context (like the global one), no longer now.
This is the first part of http://reviews.llvm.org/D19094
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266379 91177308-0d34-0410-b5e6-96231b3b80d8
Support seeding a ValueMap with nullptr for Metadata entries, a
situation I didn't consider in the Metadata/Value split.
I added a ValueMapper::getMappedMD accessor that returns an
Optional<Metadata*> with the mapped (possibly null) metadata. IRMover
needs to use this to avoid modifying the map when it's checking for
unneeded subprograms. I updated a call from bugpoint since I find the
new code clearer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265228 91177308-0d34-0410-b5e6-96231b3b80d8
A DICompileUnit that is not listed in llvm.dbg.cu will cause assertion
failures and/or crashes in the backend. The Verifier should reject this.
rdar://problem/25369499
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264657 91177308-0d34-0410-b5e6-96231b3b80d8
These sets perform linear searching in small mode so it is never a good
idea to use SmallSize/N bigger than 32.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259283 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html
"I felt a great disturbance in the [build system], as if millions of [makefiles] suddenly cried out in terror and were suddenly silenced. I fear something [amazing] has happened."
- Obi Wan Kenobi
Reviewers: chandlerc, grosbach, bob.wilson, tstellarAMD, echristo, whitequark
Subscribers: chfast, simoncook, emaste, jholewinski, tberghammer, jfb, danalbert, srhines, arsenm, dschuff, jyknight, dsanders, joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D16471
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258861 91177308-0d34-0410-b5e6-96231b3b80d8
Passing in a std::unique_ptr should help find errors when the module
is used after being linked into another module.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255842 91177308-0d34-0410-b5e6-96231b3b80d8
This patch converts code that has access to a LLVMContext to not take a
diagnostic handler.
This has a few advantages
* It is easier to use a consistent diagnostic handler in a single program.
* Less clutter since we are not passing a handler around.
It does make it a bit awkward to implement some C APIs that return a
diagnostic string. I will propose new versions of these APIs and
deprecate the current ones.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255571 91177308-0d34-0410-b5e6-96231b3b80d8
Before this patch the diagnostic handler was optional. If it was not
passed, the one in the LLVMContext was used.
That is probably not a pattern we want to follow. If each area has an
optional callback, there is a sea of callbacks and it is hard to follow
which one is called.
Doing this also found cases where the callback is a nice addition, like
testing that no errors or warnings are reported.
The other option is to always use the diagnostic handler in the
LLVMContext. That has a few problems
* To implement the C API we would have to set the diag handler and then
set it back to the original value.
* Code that creates the context might be far away from code that wants
the diagnostics.
I do have a patch that implements the second option and will send that as
an RFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254777 91177308-0d34-0410-b5e6-96231b3b80d8
