Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7 |
|
#
ae6a5c1d |
| 03-Jan-2023 |
Matt Arsenault <Matthew.Arsenault@amd.com> |
llvm-reduce: Fix assertion on blockaddress during function reduction
Just avoid crashing for now, we should be able to replace the blockaddresses themselves.
BlockAddress::handleOperandChangeImpl a
llvm-reduce: Fix assertion on blockaddress during function reduction
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
show more ...
|
Revision tags: llvmorg-15.0.6 |
|
#
8e3e218a |
| 22-Nov-2022 |
Matt Arsenault <Matthew.Arsenault@amd.com> |
llvm-reduce: Fix producing invalid reductions on ifunc
|
Revision tags: llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3 |
|
#
309d4538 |
| 15-Aug-2022 |
Arthur Eubanks <aeubanks@google.com> |
[llvm-reduce] Move most debugging output behind --verbose
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
[llvm-reduce] Move most debugging output behind --verbose
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
show more ...
|
#
195087d8 |
| 09-Aug-2022 |
Arthur Eubanks <aeubanks@google.com> |
[llvm-reduce] Try harder to not create invalid aliases
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
[llvm-reduce] Try harder to not create invalid aliases
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
show more ...
|
Revision tags: llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6 |
|
#
2962f9df |
| 21-Jun-2022 |
John Regehr <regehr@cs.utah.edu> |
stop llvm-reduce from introducing undefs
Differential Revision: https://reviews.llvm.org/D128317
|