This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
There's a data race on the UninterestingChunks set. The code seems to
be operating on the assumption that all the tasks completed, so ensure
the unused results do complete. This started showing up about 50% of
the time when running operands-skip-parallel.ll after the recent
switch to use DenseSet; previously it failed much less frequently with
std::set.
We should introduce a mechanism to early terminate unused
results. Alternatively, I've been thinking about ways to to make the
reduction order smarter. I frequently have tests that take multiple
minutes to compile and hit the failure. It may be helpful to see which
chunks took the least time and prefer those over just taking the first
result.
Unconditionally removing landing pads results in invalid IR,
if there is a different `invoke` that uses it. Update the code
to only remove the landing pad if the current invoke is the only
user. Also carefully avoid creating plain branches to bbs with
landing pads we couldn't remove.
Reviewed By: arsenm, aeubanks
Differential Revision: https://reviews.llvm.org/D138072
Most tools accept .ll or .bc inputs interchangably, but some don't.
Default to writing temporary files that match the input. This
will also aid reducing deserialization bugs.
Previously, this unconditionally emitted text IR. I ran
into a bug that manifested in broken disassembly, so the
desired output was the bitcode format. If the input format
was binary bitcode, the requested output file ends in .bc,
or an explicit -output-bitcode option was used, emit bitcode.
This was also trying to write the bitcode to the failed file
on failure, which asserts. Also, consistently use
ToolOutputFile, instead of one path manually removing
the temp file.
It's not valid to simply branch to a landingpad block, so it
needs to be removed.
Also stop trying to scan forward to find a block that can be merged.
The predecessor merge rules are more complex than this. This also
would need to have considered landingpads. Just do the minimum
to delete the block, and let the simplify-cfg reduction handle
the branch chain cleanups.
Previously this would produce many invalid reductions with
"Instruction does not dominate uses" verifier errors.
This fixes issues in cases where the incoming IR
has unreachable blocks, and the resulting reduction
introduced new reachable blocks.
Have basic-blocks skip functions that have unreachable
blocks, Introduce a separate reduction which only
deletes unreachable blocks. Cleanup any newly unreachable
blocks after trimming out the requested deletions.
Includes a variety of meta-reduced tests for llvm-reduce
itself with -abort-on-invalid-reduction that were failing
on different iterations of this patch.
Bugpoint's implementation is much simpler (but currently I don't
understand how it avoids disconnecting interesting blocks from the CFG).
Each delta pass run should have guaranteed the output is still
interesting, so it should be pointless to recheck this each
iteration. I have many issues that take multiple minutes
to reproduce, so this ends up being a huge waste of time.
Also, remove broken line counting. This never worked, since
getLines was failing to open the temporary file which was just
deleted.
Copy this technique from bugpoint. Before trying to blindly
delete blocks, try to fold branch conditions. This intuitively
makes more sense for a faster reduction, since you can find
dead paths in the function to prune out before trying to bisect
blocks in source order.
Seems to provide some speedup on my multi-hour reduction samples.
This does have the potential to produce testcases with unreachable
blocks. This is already a problem with the existing block
reduction pass. I'm struggling dealing with invalid reductions
in these cases, so in the future this should probably start
deleting those. However, I do sometimes try to reduce failures
in code that becomes unreachable, so I'm not totally sure
what to do here.
ce3c3cb291 broke this by
speculatively making transforms before checking shouldKeep.
Originally I tried to roll back changes to the IR, but it's probably
best to not touch it before querying.
This was making decisions based on BBsToDelete, while being
used to determine BBsToDelete which doesn't really work.
Additionally, this is a lot of logic just to avoid deleting
the entry block when we can just skip it.
Make load and store non-atomic. Make the others monotonic.
We could probably try to incrementally relax the orderings; not sure
how useful that would be.
I often run llvm-reduce on IR that contains debug info, this prevents an
extra step of `opt -passes=strip` I do every time and will result in a
lot less invalid reductions around debug metadata.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D136208
So we don't over count the number of chunks and do unnecessary work reducing more chunks than exist.
This lowers some random reduction I tested with locally from 250s to 232s.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D136127
We randomly use outs() or errs(), which makes test logs confusing.
We also randomly add/don't add a line afterward.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D136130
When reducing llvm-reduce with llvm-reduce, it can be confusing
to figure out what lines are printed by the child or parent. Not
sure this is the most reliable way to set and restore this.
Try some dumb strength reductions to "simpler" opcodes.
Make some opcode substitutions I typically try to get smaller
MIR out of codegen. This is a bit target specific and I have a
lot of increasingly target specific modifications I try
during manual reduction.
In a testcase I'm working on, the old write out and count IR lines
was taking about 200-300ms per iteration. This drops it out of the
profile.
This doesn't account for everything, but it doesn't seem to matter.
We should probably try to account for metadata and constantexpr tree
depths.
Verify all the requested passes exist before trying to run any.
For long reductions, it was really annoying for it to get halfway through
and then I come back later to an incomplete reduction.
Also add a new skip-delta-passes flag. Most of the time I want to opt out
of specific reductions, rather than run a select few.
Without this patch, we hit the following a lot:
"llvm.dbg.declare intrinsic requires a !dbg attachment"
"DICompileUnit not listed in llvm.dbg.cu"
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D135492
Phis have a quirk where the same predecessor block may appear multiple times
if the same block branches to it multiple ways. All the values need to match,
but this was replacing each operand independently. If an operand can be simplified,
make sure to replace every instance of the incoming block's value.
This new pass for llvm-reduce attempts to reduce DebugInfo metadata.
The process used is:
1. Scan every MD node, keeping track of nodes already visited.
2. Look for DebugInfo nodes, then record any operands that are lists.
3. Bisect though all the elements of the collected lists.
Differential Revision: https://reviews.llvm.org/D132077
This reverts commit 69549de865.
The change in D135237 can lead to verification failures like `scope must have two or three operands`.
The ongoing work in D132077 does something similar without these failures, so lets wait for that to land and revert this patch.
Reviewed By: aeubanks
Differential Revision: https://reviews.llvm.org/D135395
There can be lots of `MDTuple` debug metadata nodes. For example, `globals: !{!1, !2}` in `!DICompileUnit()`. Search through all debug info to find `MDTuple`'s and remove some of their elements.
For D135114 I was able to get a reproducer with 364 lines without manually deleting elements. After this patch I got it down to 67 lines.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D135237
Avoid crash in `reduceOperandsOneDeltaPass` function for operands with
vector of pointer type.
While on it add a `reduce-operands-ptr.ll` test in the spirit of the
existing `reduce-operands-int.ll`/`reduce-operands-fp.ll` tests.
Differential Revision: https://reviews.llvm.org/D135307
Fangrui Song