This patch makes sure that the following case is lowered correctly
("duplication"):
```
func.func @broadcast_scalable_duplication(%arg0: vector<[32]xf32>) -> vector<1x[32]xf32> {
%res = vector.broadcast %arg0 : vector<[32]xf32> to vector<1x[32]xf32>
return %res : vector<1x[32]xf32>
}
```
To avoid confusion with vectorization-masked.mlir, move
test/Dialect/Linalg/masked_vectorization.mlir
to:
test/Dialect/Linalg/transpose-compose-masked-vectorize-and-cleanups.mlir
The updated name better reflects what's being tested.
Differential Revision: https://reviews.llvm.org/D158427
The DXContainer pipeline state information encodes a bunch of mask
vectors that are used to track things about the inputs and outputs from
each shader.
This adds support for reading and writing them throught he YAML test
interfaces. The writing logic in MC is extremely primitive and we'll
want to revisit the API for that, but since I'm not sure how we'll want
to generate the mask bits from DXIL during code generation I didn't want
to spend too much time on the API.
Fixes#59479
* This avoid pinging folks on all issue when they got pinged on bugzilla
eons ago
* Avoid formatting bugs when there is html in the issue description
* Truncate the list of files and the diff independently of each other.
This avoids truncating cutting a file line in 2 and to cut in the middle
of html markup. This is a fringe case but it does happen when people
accidentally push weird branches conflicting on all the files.
Change `SingleBlock::{insert,push_back}` to avoid inserting the argument
operation after the block's terminator. This allows removing
`SingleBlockImplicitTerminator`'s functions with the same name.
Define `Block::hasTerminator` checking whether the block has a
terminator operation.
Signed-off-by: Victor Perez <victor.perez@codeplay.com>
If an assertion fails during the configuration of the test suite because
the compiler doesn't support a flag (or the compiler configuration is
borked entirely), we will now print additional context to help debug the
issue instead of just saying "The compiler doesn't support the flag" and
bailing.
We were running the test suite in C++20 mode, but we should really be
tracking the latest supported version. We can't do C++26 because the
latest stable AppleClang doesn't support it yet.
This removes a lot of code duplication, makes the code simpler and
prepares the terrain for https://reviews.llvm.org/D101206, which will
fix some UB in the node-based containers.
This also allows removing the dependency of list and forward_list on
unique_ptr by using __allocation_guard instead.
Notice that because Holder<Incomplete> is _possible_ to complete, but
_unsafe_ to complete, that means that Holder<Incomplete>* is basically
not an iterator and it's not even safe to ask if
input_iterator<Holder<Incomplete>*> because that _will_ necessarily
complete the type. So it's totally expected that we still cannot safely
ask e.g.
static_assert(std::indirect_unary_predicate<bool(&)(Holder<Incomplete>&),
Holder<Incomplete>*>);
or even
static_assert(!std::indirect_unary_predicate<int, Holder<Incomplete>*>);
This was originally uploaded as https://reviews.llvm.org/D119029 and I
picked it up here as part of the Github PR transition.
Co-authored-by: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Reapply after fixing the test by enabling the `debug.ExprInspection` checker.
-----
NonLoc symbolic SVal to Loc casts are not supported except for
nonloc::ConcreteInt.
This change simplifies the source SVals so that the more casts can
go through nonloc::ConcreteInt->loc::ConcreteInt path. For example:
void test_simplified_before_cast_add(long long t1) {
long long t2 = t1 + 3;
if (!t2) {
int *p = (int *) t2;
clang_analyzer_eval(p == 0); // expected-warning{{TRUE}}
}
}
If simplified, 't2' is 0, resulting 'p' is nullptr, otherwise 'p'
is unknown.
Fixes#62232
With both +sve and +dotprod, and a scalable vecreduce(sext) we could attempt to
access the number of elements of a scalable vector. Guard against this for now,
until scalable dotprod are properly supported.
Reapply after fixing a clang bug this exposed in D158972 and
adjusting a number of tests that failed for 32-bit targets.
-----
Add a check that the DILocalVariable fragment size in dbg.declare
does not exceed the size of the alloca.
This would have caught the invalid debuginfo regenerated by rustc
in https://github.com/llvm/llvm-project/issues/64149.
Differential Revision: https://reviews.llvm.org/D158743
The test demonstrates that the `this` pointer seen in the constructor
has the
same value as the address of the variable the object is constructed
into.
When (post-SSA) MIR has multiple defs of the same vreg,
update_mir_test_checks would use different variable names for each def
like this, where DEF and DEF1 both refer to %0:
```
%0:gr32 = IMPLICIT_DEF
%0:gr32 = IMPLICIT_DEF
-->
; CHECK: [[DEF:%[0-9]+]]:gr32 = IMPLICIT_DEF
; CHECK-NEXT: [[DEF1:%[0-9]+]]:gr32 = IMPLICIT_DEF
```
This should be harmless, but it messed up the way that mangle_vreg
counts the number of names in vreg_map to come up with a new numeric
suffix, such that you could get the same variable name for different
vregs, like this, where DEF2 refers to both %0 and %2:
```
%0:gr32 = IMPLICIT_DEF
%1:gr32 = IMPLICIT_DEF
%0:gr32 = IMPLICIT_DEF
%2:gr32 = IMPLICIT_DEF
-->
; CHECK: [[DEF:%[0-9]+]]:gr32 = IMPLICIT_DEF
; CHECK-NEXT: [[DEF1:%[0-9]+]]:gr32 = IMPLICIT_DEF
; CHECK-NEXT: [[DEF2:%[0-9]+]]:gr32 = IMPLICIT_DEF
; CHECK-NEXT: [[DEF2:%[0-9]+]]:gr32 = IMPLICIT_DEF
```
Fix this by always using the same variable name for the same vreg.
This reverts commit 3ebf3dd30da219f9f9aee12f42d45d18d55e7580.
I thought "Mergeing" will wait and confirm if the checks pass, and only
merge it if they succeed. Apparently, it's not the case here xD
The test is just broken in x86. See:
https://lab.llvm.org/buildbot/#/builders/109/builds/73686
This PR adds the paths the SPIR-V backend folks maintains. (Another
distince SPIR-V team exists, but only for the MLIR part (mlir-spirv).
---------
Signed-off-by: Nathan Gauër <brioche@google.com>
NonLoc symbolic SVal to Loc casts are not supported except for
nonloc::ConcreteInt.
This change simplifies the source SVals so that the more casts can go
through nonloc::ConcreteInt->loc::ConcreteInt path. For example:
```c
void test_simplified_before_cast_add(long long t1) {
long long t2 = t1 + 3;
if (!t2) {
int *p = (int *) t2;
clang_analyzer_eval(p == 0); // expected-warning{{TRUE}}
}
}
```
If simplified, `t2` is 0, resulting `p` is nullptr, otherwise `p` is
unknown.
Fixes#62232
On the very first iteration for the reductions, when trying to build
reduction for boolean logic operations, no need to compare LHS/RHS with
the Reduction(VectorizedTree), need to compare with actual parameters of
the reduction operations.
Otherwise CMake might throw and error:
CMake Error: try_run() invoked in cross-compiling mode, please set the
following cache variables appropriately:
Z3_RETURNCODE (advanced)
Z3_RETURNCODE__TRYRUN_OUTPUT (advanced)
Calls on RISC-V are typically compiled to `auipc`/`jalr` pairs to allow
a maximum target range (32-bit pc-relative). In order to optimize calls
to near targets, linker relaxation may replace those pairs with, for
example, single `jal` instructions.
To allow BOLT to freely reassign function addresses in relaxed binaries,
this patch proposes the following approach:
- Expand all relaxed calls back to `auipc`/`jalr`;
- Rely on JITLink to relax those back to shorter forms where possible.
This is implemented by detecting all possible call instructions and
replacing them with `PseudoCALL` (or `PseudoTAIL`) instructions. The
RISC-V backend then expands those and adds the necessary relocations for
relaxation.
Since BOLT generally ignores pseudo instruction, this patch makes
`MCPlusBuilder::isPseudo` virtual so that `RISCVMCPlusBuilder` can
override it to exclude `PseudoCALL` and `PseudoTAIL`.
To ensure JITLink knows about the correct section addresses while
relaxing, reassignment of addresses has been moved to a post-allocation
pass. Note that this is probably the time it had to be done in the
first place since in `notifyResolved` (where it was done before), all
symbols are supposed to be resolved already.
Depends on D159082
Reviewed By: maksfb
Differential Revision: https://reviews.llvm.org/D159089
