[IR] Don't include GenericDomTreeConstruction.h in header (NFC)

The whole point of the GenericDomTree.h vs
GenericDomTreeConstruction.h distinction is that the latter only
needs to be included in th

[IR] Don't include GenericDomTreeConstruction.h in header (NFC)

The whole point of the GenericDomTree.h vs
GenericDomTreeConstruction.h distinction is that the latter only
needs to be included in the source file and not the header.

show more ...

[llvm] Fix duplicate word typos. NFC

Those fixes were taken from https://reviews.llvm.org/D137338

[Support] Change SetVector's default template parameter to SmallVector<*, 0>

Similar to D156016 for MapVector.

This brings back commit fae7b98c221b5b28797f7b56b656b6b819d99f27 with a
fix to llvm/un

[Support] Change SetVector's default template parameter to SmallVector<*, 0>

Similar to D156016 for MapVector.

This brings back commit fae7b98c221b5b28797f7b56b656b6b819d99f27 with a
fix to llvm/unittests/Support/ThreadPool.cpp's `_WIN32` code path.

show more ...

Revert rGfae7b98c221b5b28797f7b56b656b6b819d99f27 "[Support] Change SetVector's default template parameter to SmallVector<*, 0>"

This is failing on Windows MSVC builds:
llvm\unittests\Support\Thread

Revert rGfae7b98c221b5b28797f7b56b656b6b819d99f27 "[Support] Change SetVector's default template parameter to SmallVector<*, 0>"

This is failing on Windows MSVC builds:
llvm\unittests\Support\ThreadPool.cpp(380): error C2440: 'return': cannot convert from 'Vector' to 'std::vector<llvm::BitVector,std::allocator<llvm::BitVector>>'
with
[
Vector=llvm::SmallVector<llvm::BitVector,0>
]

show more ...

[Support] Change SetVector's default template parameter to SmallVector<*, 0>

Similar to D156016 for MapVector.

llvm-reduce: Fix introducing invalid uses of intrinsics

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 ...

llvm-reduce: Fix another invalid reduction with repeated input phis

ReduceOperandsSkip had the same issue as ReduceOperands when handling
phis with repeated predecessors.

stop llvm-reduce from introducing undefs

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

[llvm-reduce] Fix build after D113537

Forgot to amend D113537 with these changes before committing.

[llvm-reduce] Introduce operands-skip pass.

Add a new "operands-skip" pass whose goal is to remove instructions in the middle of dependency chains. For instance:
```
%baseptr = alloca i32
%array

[llvm-reduce] Introduce operands-skip pass.

Add a new "operands-skip" pass whose goal is to remove instructions in the middle of dependency chains. For instance:
```
%baseptr = alloca i32
%arrayidx = getelementptr i32, i32* %baseptr, i32 %idxprom
store i32 42, i32* %arrayidx
```
might be reducible to
```
%baseptr = alloca i32
%arrayidx = getelementptr ... ; now dead, together with the computation of %idxprom
store i32 42, i32* %baseptr
```
Other passes would either replace `%baseptr` with undef (operands, instructions) or move it to become a function argument (operands-to-args), both of which might fail the interestingness check.

In principle the implementation allows operand replacement with any value or instruction in the function that passes the filter constraints (same type, dominance, "more reduced"), but is limited in this patch to values that are directly or indirectly used to compute the current operand value, motivated by the example above. Additionally, function arguments are added to the candidate set which helps reducing the number of relevant arguments mitigating a concern of too many arguments mentioned in https://reviews.llvm.org/D110274#3025013.

Possible future extensions:
* Instead of requiring the same type, bitcast/trunc/zext could be automatically inserted for some more flexibility.
* If undef is added to the candidate set, "operands-skip"is able to produce any reduction that "operands" can do. Additional candidates might be zero and one, where the "reductive power" classification can prefer one over the other. If undefined behaviour should not be introduced, undef can be removed from the candidate set.

Recommit after resolving conflict with D112651 and reusing
shouldReduceOperand from D113532.

Reviewed By: aeubanks

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

show more ...

[llvm-reduce] Introduce operands-skip pass.

Add a new "operands-skip" pass whose goal is to remove instructions in the middle of dependency chains. For instance:
```
%baseptr = alloca i32
%array

[llvm-reduce] Introduce operands-skip pass.

Add a new "operands-skip" pass whose goal is to remove instructions in the middle of dependency chains. For instance:
```
%baseptr = alloca i32
%arrayidx = getelementptr i32, i32* %baseptr, i32 %idxprom
store i32 42, i32* %arrayidx
```
might be reducible to
```
%baseptr = alloca i32
%arrayidx = getelementptr ... ; now dead, together with the computation of %idxprom
store i32 42, i32* %baseptr
```
Other passes would either replace `%baseptr` with undef (operands, instructions) or move it to become a function argument (operands-to-args), both of which might fail the interestingness check.

In principle the implementation allows operand replacement with any value or instruction in the function that passes the filter constraints (same type, dominance, "more reduced"), but is limited in this patch to values that are directly or indirectly used to compute the current operand value, motivated by the example above. Additionally, function arguments are added to the candidate set which helps reducing the number of relevant arguments mitigating a concern of too many arguments mentioned in https://reviews.llvm.org/D110274#3025013.

Possible future extensions:
* Instead of requiring the same type, bitcast/trunc/zext could be automatically inserted for some more flexibility.
* If undef is added to the candidate set, "operands-skip"is able to produce any reduction that "operands" can do. Additional candidates might be zero and one, where the "reductive power" classification can prefer one over the other. If undefined behaviour should not be introduced, undef can be removed from the candidate set.

Reviewed By: aeubanks

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

show more ...