There's no need to construct a map of attributes to modify throughout
the whole function before applying them all at once. The attribute
classes already have the necessary set behavior.
Use the existing mechanism to change the data layout using callbacks.
Before this patch, we had a callback type DataLayoutCallbackTy that receives
a single StringRef specifying the target triple, and optionally returns
the data layout string to be used. Module loaders (both IR and BC) then
apply the callback to potentially override the module's data layout,
after first having imported and parsed the data layout from the file.
We can't do the same to fix invalid data layouts, because the import will already
fail, before the callback has a chance to fix it.
Instead, module loaders now tentatively parse the data layout into a string,
wait until the target triple has been parsed, apply the override callback
to the imported string and only then parse the tentative string as a data layout.
Moreover, add the old data layout string S as second argument to the callback,
in addition to the already existing target triple argument.
S is either the default data layout string in case none is specified, or the data
layout string specified in the module, possibly after auto-upgrades (for the BitcodeReader).
This allows callbacks to inspect the old data layout string,
and fix it instead of setting a fixed data layout.
Also allow to pass data layout override callbacks to lazy bitcode module
loader functions.
Differential Revision: https://reviews.llvm.org/D140985
This reverts commit 4f575620d51032cf98424c9defafe4dfc8d66f45.
I realized the test wasn't very good and when fixed, shows the
reduction doesn't work correctly. Revert the change and keep the fixed
version of the test.
The current reduction logic tries to reproduce what a serial reduction
would produce, and just takes the first one that is still
interesting. We still have to wait for all others to complete though,
which at that point is just a waste.
This helps speed things up with long running reducers, which I
frequently have. e.g. for the added sleep test on my system, it took
about 8 seconds before this change and about 4 after.
https://reviews.llvm.org/D138953
Just avoid crashing for now, we should be able to replace the blockaddresses
themselves.
BlockAddress::handleOperandChangeImpl assumes it can cast to Function.
The verifier seems nonexistent and the langref isn't particularly explicit
on what's allowed as a blockaddress operand. As far as I can tell bugpoint
isn't doing anything to handle this.
Something low level is broken with BlockAddress handling,
demonstrated by reduce-functions-blockaddress-wrong-function.ll.
The BasicBlock destructor of the deleted function is triggering replacement
of blockaddresses for the kept function in some cases. I've only half debugged
this but it seems like blockaddress is handled too-specially compared to other
Constants. I have tentative patches to allow any constant to be a blockaddress
input, but having the verifier check if it's really a function/block.
https://reviews.llvm.org/D140909
For some reason the global variable reduction was trying to delete
use instructions. This broke the verifier if the user was a terminator,
since the block now no longer has one. It doesn't make sense for this
reduction to delete the users, so just stop doing that.
Main thing I was unsure about was to whether try to delete the now
dead landing blocks, or leave that for the unreachable block reduction.
Personality function is not reduced, but that should be a separate
reduction on the function.
Fixes#58815
We required the test and input arguments for --print-delta-passes
which is unhelpful. Also, start printing the help output if no
arguments were supplied.
It looks like there's more sophisticated ways to accomplish this with
the opt library, but it was less work to manually emit these errors.
The verifier should fail if constrained intrinsics are used in
functions with strictfp, but that patch hasn't been pushed yet.
Ideally we would be able to analyze the function body to see if any
constrained intrinsics were used, but we seem to be missing a utility
function to check for any constrained ops.
The current reduction tries all or nothing elimination of named
metadata. I noticed in one case where one of the module flags was
necessary, but it left the rest. Reduce the individual operands of
named metadata nodes that are known to behave like lists. Be
conservative since some named metadata may have more specific verifier
requirements for the operands.
Fixes missing test coverage for the failed to execute case. However,
this test fails to verify the newline is printed. I can't figure out
how to get FileCheck to match the trailing newline.
These are going to waste a lot of time and produce clutter when we're
bulk introducing crashes. Add a flag to disable this behavior in case
this matters to a reproducer.
This is a fairly large changeset, but it can be broken into a few
pieces:
- `llvm/Support/*TargetParser*` are all moved from the LLVM Support
component into a new LLVM Component called "TargetParser". This
potentially enables using tablegen to maintain this information, as
is shown in https://reviews.llvm.org/D137517. This cannot currently
be done, as llvm-tblgen relies on LLVM's Support component.
- This also moves two files from Support which use and depend on
information in the TargetParser:
- `llvm/Support/Host.{h,cpp}` which contains functions for inspecting
the current Host machine for info about it, primarily to support
getting the host triple, but also for `-mcpu=native` support in e.g.
Clang. This is fairly tightly intertwined with the information in
`X86TargetParser.h`, so keeping them in the same component makes
sense.
- `llvm/ADT/Triple.h` and `llvm/Support/Triple.cpp`, which contains
the target triple parser and representation. This is very intertwined
with the Arm target parser, because the arm architecture version
appears in canonical triples on arm platforms.
- I moved the relevant unittests to their own directory.
And so, we end up with a single component that has all the information
about the following, which to me seems like a unified component:
- Triples that LLVM Knows about
- Architecture names and CPUs that LLVM knows about
- CPU detection logic for LLVM
Given this, I have also moved `RISCVISAInfo.h` into this component, as
it seems to me to be part of that same set of functionality.
If you get link errors in your components after this patch, you likely
need to add TargetParser into LLVM_LINK_COMPONENTS in CMake.
Differential Revision: https://reviews.llvm.org/D137838
llvm::Any had several bugs in the past, due to being sensitive to symbol
visibility. (See D101972 and D108943)
Even with these fixes applied, I still encounter the same issue on
Windows.
Similar to llvm::Optional going away in favor of std::optional, we can
use std::any from C++17.
Using std::any fixes the problem and puts the burden to do it correctly
on the standard library.
Differential Revision: https://reviews.llvm.org/D139532
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.
