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
Without this patch, the assertion triggers below on the test case,
because we are using different oracles for the verification.
Assertion failed: (Targets == NoChunksCounter.count() && "number of chunks changes when reducing"), function runDeltaPass, file Delta.cpp, line 272.
Also skip dead defs when looking for a previous vreg with the same
class. This helps avoid some mid-reduction verifier errors when
LiveIntervals computation starts introducing dead flags everywhere.
This should cut down on the visual noise when reducing. Still keep output when we run a pass or when we successfully reduce.
Notably, this also suppresses redirecting the test output to stdout/stderr.
Reviewed By: regehr
Differential Revision: https://reviews.llvm.org/D131922
There are two different senses in which a block can be "address-taken".
There can be a BlockAddress involved, which means we need to map the
IR-level value to some specific block of machine code. Or there can be
constructs inside a function which involve using the address of a basic
block to implement certain kinds of control flow.
Mixing these together causes a problem: if target-specific passes are
marking random blocks "address-taken", if we have a BlockAddress, we
can't actually tell which MachineBasicBlock corresponds to the
BlockAddress.
So split this into two separate bits: one for BlockAddress, and one for
the machine-specific bits.
Discovered while trying to sort out related stuff on D102817.
Differential Revision: https://reviews.llvm.org/D124697
so that we can reduce away incidental parts of the CFG in cases where
the full simplifyCFG pass makes the test case uninteresting
Differential Revision: https://reviews.llvm.org/D131920
out of chunk ones. the non-default second argument to
removePredecessor() is necessary to avoid creating invalid IR on
examples like the one in the provided test case
Differential Revision: https://reviews.llvm.org/D131843
This was done by adding --abort-on-invalid-reduction to remove-function-bodies-used-in-globals.ll and fixing the fallout.
Aliases must have a GlobalValue or ConstantExpr aliasee and the aliasee must be a definition if it's a GlobalValue.
Don't RAUW functions with null if there's an alias pointing to it, and similarly don't delete the body of a function.
Don't delete the entire body of a function when reducing blocks, preserve at least one block.
Also make debugging these sorts of things easier by dumping the module when --abort-on-invalid-reduction triggers.
Reviewed By: regehr
Differential Revision: https://reviews.llvm.org/D131505
Try to insert an implicit_def to replace the instruction's value,
replacing the original instruction's def with a dead register. If all
defs are delete the instruction entirely.
This is pretty similar to the instruction reduction, but leaves the
new defs in the same place as the original instruction. This could
possibly replace it. I'm not sure if we should directly delete the
instructions here, or leave dead ones behind.
This could also further work to replace physical register defs.
I have a register allocator failure that only reproduces with IPRA
enabled, and requires the specific regmask if I want to only run the
one relevant pass. The printed custom regmask is enormous and I would
like to reduce it.
This reduces each individual bit in the mask, but it would probably be
better to start at register units and clear all aliasing fields at a
time. This would require stricter verification that all aliasing bits
are set in regmasks (although I would prefer to switch regmasks to use
register units in the first place).
Integer vectors were previously ignored when reducing operands. When
6b8bd0f72 introduced support for reducing floating-point
scalars/vectors, the vector case was written to only handle
floating-point values. It would crash when creating an invalid
ConstantFP from the integer element type.
Instead of reinstating the old integer vector behaviour, we might as
well reduce integer vectors to all-one splats.
A couple of existing tests has also been renamed from "remove" to
"reduce" to better reflect the deltas they test.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D129629
Fixes this error:
/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/
llvm-project/llvm/tools/llvm-reduce/TestRunner.cpp:20:7:
error: field 'TM' will be initialized after field 'ToolName'
[-Werror,-Wreorder-ctor]
TM(std::move(TM)), ToolName(ToolName) {
^~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~
Program(std::move(Program)) TM(std::move(TM))
1 error generated.
https://lab.llvm.org/buildbot/\#/builders/77/builds/19154
Adds support for reading and writing LTO bitcode files.
- Emit a summary if the original bitcode file had a summary
- Use split LTO units if the original bitcode file used them.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D127168
The intention is that these should never have undef operands. It turns
out the restriction the verifier enforces is too lax. The verifier
enforces that registers without a register class cannot be undef, but
it's valid to use a register with a register class and type. The
verifier needs to change to be based on the opcode.
Arthur Eubanks