[llvm] Remove no-op ptr-to-ptr bitcasts (NFC)

Opaque ptr cleanup effort (NFC).

[ADT][NFCI] Do not use non-const lvalue-refs with enumerate in llvm/

Replace references to `enumerate` results with either const lvalue
rerences or structured bindings. I did not use structured bind

[ADT][NFCI] Do not use non-const lvalue-refs with enumerate in llvm/

Replace references to `enumerate` results with either const lvalue
rerences or structured bindings. I did not use structured bindings
everywhere as it wasn't clear to me it would improve readability.

This is in preparation to the switch to `zip` semantics which won't
support non-const lvalue reference to elements:
https://reviews.llvm.org/D144503.

Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D145987

show more ...

llvm-reduce: Use consistent ReductionFunc types

Some of these were relying on ReducerWorkItem's operator Module&.

[llvm-reduce] Unify pass logging

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: http

[llvm-reduce] Unify pass logging

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

show more ...

stop llvm-reduce from introducing undefs

Differential Revision: https://reviews.llvm.org/D128317

Cleanup includes: TransformsUtils

Estimation on the impact on preprocessor output:
before: 1065307662
after: 1064800684

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-

Cleanup includes: TransformsUtils

Estimation on the impact on preprocessor output:
before: 1065307662
after: 1064800684

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D120741

show more ...

[NFC] Remove unnecessary "#include"s from header files

[llvm-reduce] Count chunks by running a preliminary reduction

Having a separate counting method runs the risk of a mismatch between
the actual reduction method and the counting method.

Instead, cre

[llvm-reduce] Count chunks by running a preliminary reduction

Having a separate counting method runs the risk of a mismatch between
the actual reduction method and the counting method.

Instead, create an Oracle that always returns true for shouldKeep(), run
the reduction, and count how many times shouldKeep() was called. The
module should not be modified if shouldKeep() always returns true.

Reviewed By: Meinersbur

Differential Revision: https://reviews.llvm.org/D113537

show more ...

[llvm-reduce] optimize extractFromModule functions

The extractBasicBlocksFromModule, extractInstrFromModule, and other
similar functions previously performed very poorly when the number of
such elem

[llvm-reduce] optimize extractFromModule functions

The extractBasicBlocksFromModule, extractInstrFromModule, and other
similar functions previously performed very poorly when the number of
such elements in the program to reduce was very high. Previously, we
were creating the set which caches elements to keep by looping through
all elements in the module and adding them to the set. However, since
std::set is an ordered set, this introduces a massive amount of
rebalancing if the order of elements in the program and the order of
their pointers in memory are not the same.

The solution is straightforward: first put all the elements to be kept
in a vector, then use the constructor for std::set which takes a pair of
iterators over a collection. This constructor is optimized to avoid
doing unnecessary work when initializing large sets.

Also in this change, we pass BBsToKeep set to functions
replaceBranchTerminator and removeUninterestingBBsFromSwitch as a const
reference rather than passing it by value. This ought to prevent the
need to copy the collection each time these functions are called, which
is expensive if the collection is large.

Reviewed By: aeubanks

Differential Revision: https://reviews.llvm.org/D112757

show more ...

[NFC][llvm-reduce] Cleanup types

Use Module& wherever possible.
Since every reduction immediately turns Chunks into an Oracle, directly pass Oracle instead.

Reviewed By: hans

Differential Revision

[NFC][llvm-reduce] Cleanup types

Use Module& wherever possible.
Since every reduction immediately turns Chunks into an Oracle, directly pass Oracle instead.

Reviewed By: hans

Differential Revision: https://reviews.llvm.org/D111122

show more ...

[llvm-reduce] Skip updating calls where OldF isn't the called fn.

When replacing function calls, skip call instructions where the old
function is not the called function, but e.g. the old function i

[llvm-reduce] Skip updating calls where OldF isn't the called fn.

When replacing function calls, skip call instructions where the old
function is not the called function, but e.g. the old function is passed
as an argument.

This fixes a crash due to trying to construct invalid IR for the test
case.

Reviewed By: aeubanks

Differential Revision: https://reviews.llvm.org/D109759

show more ...

[llvm-reduce] Don't delete arguments of intrinsics

The argument reduction pass shouldn't remove arguments of
intrinsics, because the resulting module is ill-formed, and so
inherently uninteresting.

[llvm-reduce] Don't delete arguments of intrinsics

The argument reduction pass shouldn't remove arguments of
intrinsics, because the resulting module is ill-formed, and so
inherently uninteresting.

Reviewed By: aeubanks

Differential Revision: https://reviews.llvm.org/D103129

show more ...

[Reduce] Argument reduction: shoe-horn new function into remaining uses of old function

Much like with function reduction, there may be remaining unhandled uses
of function, in particular in blockad

[Reduce] Argument reduction: shoe-horn new function into remaining uses of old function

Much like with function reduction, there may be remaining unhandled uses
of function, in particular in blockaddress. And in constants we can't
RAUW it with undef, because undef is not a function.
Instead, let's try to pretent that in the remaining cases, the new
signature didn't change, by bitcasting it.

A new (previously crashing) test case added.

show more ...

[Reduce] Argument reduction: do deal with function declarations

We can happily turn function definitions into declarations,
thus obscuring their argument from being elided by this pass.

I don't bel

[Reduce] Argument reduction: do deal with function declarations

We can happily turn function definitions into declarations,
thus obscuring their argument from being elided by this pass.

I don't believe there is a good reason to just ignore declarations.
likely even proper llvm intrinsics ones,
at worst the input becomes uninteresting.

The other question here is that all these transforms are all-or-nothing.
In some cases, should we be treating each use separately?

The main blocker here seemed to be that llvm::CloneFunctionInto()
does `&OldFunc->front()`, which inserts a nullptr into a densemap,
which is not happy about it and asserts.

show more ...

[Reduce] Argument reduction: do properly handle invoke insts (PR46819)

replaceFunctionCalls() is very non-exhaustive, it only handles
CallInst's. Which means, by the time we drop old function,
there

[Reduce] Argument reduction: do properly handle invoke insts (PR46819)

replaceFunctionCalls() is very non-exhaustive, it only handles
CallInst's. Which means, by the time we drop old function,
there may still be uses of it lurking around.
Let's instead whack-a-mole them by all by replacing with undef.

I'm not sure this is the best handling, especially for calls, but IMO
poorly reduced input is much better than crashing reduction tool.
A (previously-crashing!) test added.

Fixes https://bugs.llvm.org/show_bug.cgi?id=46819

show more ...

[Reduce] Argument reduction: don't try to drop terminator instructions

Newly-added test previously crashed.

While it is up for debate whether or not instruction reduction
should be indiscriminate i

[Reduce] Argument reduction: don't try to drop terminator instructions

Newly-added test previously crashed.

While it is up for debate whether or not instruction reduction
should be indiscriminate in instruction dropping (there you can
just ensure that the test case is still -verify'ies), here
if we drop terminator, CloneFunctionInto() will immediately crash.

So let's not do that :)

show more ...

[llvm-reduce] Fix incorrect indices in argument reduction pass

The function extractArgumentsFromModule() was passing a one-based index to,
but replaceFunctionCalls() was expecting a zero-based argum

[llvm-reduce] Fix incorrect indices in argument reduction pass

The function extractArgumentsFromModule() was passing a one-based index to,
but replaceFunctionCalls() was expecting a zero-based argument index. This
resulted in assertion errors when reducing function call arguments with
different types. Additionally, the

Reviewed By: lebedev.ri

Differential Revision: https://reviews.llvm.org/D84099

show more ...

[NFCI][llvm-reduce] Cleanup Delta passes to use Oracle abstraction

Summary:
I think, this results in much more understandable/readable flow.
At least the original logic was perhaps the most hard thi

[NFCI][llvm-reduce] Cleanup Delta passes to use Oracle abstraction

Summary:
I think, this results in much more understandable/readable flow.
At least the original logic was perhaps the most hard thing for me to grasp when taking an initial look on the delta passes.

Reviewers: nickdesaulniers, dblaikie, diegotf, george.burgess.iv

Reviewed By: nickdesaulniers

Subscribers: llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D83287

show more ...

[llvm-reduce] extractArgumentsFromModule(): don't crash when deleting instr twice

As it can be seen in newly-added (previously-crashing) test-case,
there can be a situation where multiple arguments

[llvm-reduce] extractArgumentsFromModule(): don't crash when deleting instr twice

As it can be seen in newly-added (previously-crashing) test-case,
there can be a situation where multiple arguments are used in instr,
and we would schedule the same instruction to be deleted several times,
crashing when trying to delete it the second time.

We could either store WeakVH (done here), or use something set-like.
I think using WeakVH is prevalent in these cases elsewhere.

show more ...

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly m

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.

show more ...

llvm-reduce: Fix inconsistencies between int/unsigned usage (standardize on int)

llvm-svn: 372270

Fix -Wdocumentation "@returns in a void function" warning. NFCI.

llvm-svn: 372212

Reapply llvm-reduce: Add pass to reduce parameters""

Fixing a couple of asan-identified bugs
* use of an invalid "Use" iterator after the element was removed
* use of StringRef to Function name afte

Reapply llvm-reduce: Add pass to reduce parameters""

Fixing a couple of asan-identified bugs
* use of an invalid "Use" iterator after the element was removed
* use of StringRef to Function name after the Function was erased

This reapplies r371567, which was reverted in r371580.

llvm-svn: 371700

show more ...

llvm-reduce: Add pass to reduce parameters

Patch by Diego Treviño!

Differential Revision: https://reviews.llvm.org/D65479

llvm-svn: 371567