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
This switches everything to use the memory attribute proposed in
https://discourse.llvm.org/t/rfc-unify-memory-effect-attributes/65579.
The old argmemonly, inaccessiblememonly and inaccessiblemem_or_argmemonly
attributes are dropped. The readnone, readonly and writeonly attributes
are restricted to parameters only.
The old attributes are auto-upgraded both in bitcode and IR.
The bitcode upgrade is a policy requirement that has to be retained
indefinitely. The IR upgrade is mainly there so it's not necessary
to update all tests using memory attributes in this patch, which
is already large enough. We could drop that part after migrating
tests, or retain it longer term, to make it easier to import IR
from older LLVM versions.
High-level Function/CallBase APIs like doesNotAccessMemory() or
setDoesNotAccessMemory() are mapped transparently to the memory
attribute. Code that directly manipulates attributes (e.g. via
AttributeList) on the other hand needs to switch to working with
the memory attribute instead.
Differential Revision: https://reviews.llvm.org/D135780
Some host targets are managing to get through MIR parsing
without constructing their MachineFunctionInfo.
Fixes at least SystemZ and SPARC (issue 58768)
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.
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).
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.
A future change will skip the reduction for functions with
unreachable blocks. Also stop using the hard to follow python based
interestingness check in favor of FileCheck.
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
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.
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.
This patch modifies the testcase to use error substitution so it will pass on all platforms.
Reviewed By: fanbo-meng, zibi
Differential Revision: https://reviews.llvm.org/D134034
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.
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
Matt Arsenault