The MLIR SVE integration tests are now enabled in the
clang-aarch64-full-2stage buildbot under emulation (QEMU) and two of the
sparse integration tests are failing [1]:
* mlir/test/Integration/Dialect/SparseTensor/CPU/sparse_sorted_coo.mlir
* mlir/test/Integration/Dialect/SparseTensor/CPU/sparse_spmm.mlir
The reason for this is the SVE RUN lines use plain 'lli' rather than the
'%lli_host_or_aarch64_cmd' substitution that's necessary to run under
emulation. The CI doesn't support SVE so the tests will SIGILL unless
run under emulation.
I should note the logs don't show a SIGILL, only the non-descript:
FileCheck error: '<stdin>' is empty.
but I expect this is what's actually happening.
https://lab.llvm.org/buildbot/#/builders/179/builds/6051/steps/12/logs/stdio
This patch addresses some of the flags and features that are currently
missing from the hermetic test support. This mostly just fixes the
`add_libc_test` option failing to find a few dependencies or missing
arguments from the previous unit test support.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D149629
For empty sections, RuntimeDyld always allocates 1 byte but leaves it
uninitialized. This causes the contents of some output sections to be
non-deterministic.
Note that this issue is also solved by D147544.
Fixes#59008
Reviewed By: maksfb
Differential Revision: https://reviews.llvm.org/D149243
This patch fixes a bug introduced by D142586, which landed as
434992c96e. The fix was to only look for alignments that are powers
of 2. See the new test case for details.
Reviewed By: jdoerfert, jhuber6
Differential Revision: https://reviews.llvm.org/D149490
This patch makes interface of AddressManager from DWARFLinker
to be compatible with AddressesMap from DWARFLinkerParallel.
This makes both linkers to be interchangeable.
Differential Revision: https://reviews.llvm.org/D147455
Since we don't always need the vendor extension to be in riscv_vector.td,
so it's better to make it be in separated header.
Depends on D148223 and D148680
Differential Revision: https://reviews.llvm.org/D148308
Assuming that the stack grows downwards, it is fine if the stack
pointer is exactly at the stacklet boundary. We should use
less-or-equal condition when deciding whether to skip new memory
allocation.
Differential Revision: https://reviews.llvm.org/D149315
For finding the last iteration of a loop, or the last section an
if condition is generated. Using scf::if can cause some lowering
issues since the code contained inside it can have branches. Using
fir::if instead ensures that the fir::if is lowered into branches
along with any code contained inside that can generate branches.
Fixes#62458.
Reviewed By: NimishMishra
Differential Revision: https://reviews.llvm.org/D149547
We just want to test whether the language switch works.
This is easier to control for libc++, since for bots building
the tests against libstdc++ we might not have the necessary
`<compare>` header available currently.
This patch resolves an issue where a value
is incorrectly displayed if it is represented
by DW_OP_div.
This issue is caused by lldb evaluating
operands of DW_OP_div as unsigned
and performed unintended unsigned
division.
This issue is resolved by creating two
temporary signed scalar and performing
signed division.
(Addresses GH#61727)
Differential Revision: https://reviews.llvm.org/D147370
This will eliminate the need for more pass-through APIs. Also replace pass-through usages with this exposure.
Reviewed By: ymandel, gribozavr2, xazax.hun
Differential Revision: https://reviews.llvm.org/D149464
There is no need to combine metadata if we're performing store to
load forwarding. In that case we would end up combining metadata
on an unrelated load instruction.
This adds ComputeNumSignBits for the NEON vector comparison nodes, which all
either return 0 or -1. Also adds sign_extend_inreg from VASHR+VSHL to show it
performing transforms.
Differential Revision: https://reviews.llvm.org/D148624
This commit removes potential UB in the PGO instrumentation passes that
was caused by casting away constness and then potentially modifying the
object.
Reviewed By: gysit
Differential Revision: https://reviews.llvm.org/D148903
Define llvm.trap, llvm.debugtrap, and llvm.ubsantrap intrinsics in the
llvm dialect.
Signed-off-by: Victor Perez <victor.perez@codeplay.com>
Differential Revision: https://reviews.llvm.org/D149574
LCSSA currently invalidates SCEV for all instructions for which
LCSSA phi nodes are created. This used to be necessary, because
SCEV has historically tried to maintain LCSSA form as well. As
such, some SCEV uses of the value would have to become uses of
the phi node instead.
However, nowadays SCEV itself no longer maintains LCSSA form.
The SCEV of on LCSSA phi node will be the same as the SCEV of its
argument. LCSSA is instead maintained in the SCEVExpander.
As such, I believe it is no longer necessary to perform any SCEV
invalidation during LCSSA construction.
After this patch the ScalarEvolution argument to the LCSSA utilities
is no longer necessary -- I'll remove it in a followup NFC patch to
keep this patch more concise.
Differential Revision: https://reviews.llvm.org/D149435
Currently, most Mach-O tests fail when executed on a big-endian host. This is
because the Mach-O back-end does not perform the necessary byte swaps when
accessing the (little-endian) binary file format.
For now, simply consider all Mach-O tests unsupported on big-endian hosts,
to enable running the test suite at all on such hosts.
Reviewed by: oontvoo
Differential Revision: https://reviews.llvm.org/D149270
Various OptionValue related classes are passing around will_modify but
the value is never used. This patch simplifies the interfaces by
removing the redundant argument.
This new features enabled to dedicate custom storage inline within operations.
This storage can be used as an alternative to attributes to store data that is
specific to an operation. Attribute can also be stored inside the properties
storage if desired, but any kind of data can be present as well. This offers
a way to store and mutate data without uniquing in the Context like Attribute.
See the OpPropertiesTest.cpp for an example where a struct with a
std::vector<> is attached to an operation and mutated in-place:
struct TestProperties {
int a = -1;
float b = -1.;
std::vector<int64_t> array = {-33};
};
More complex scheme (including reference-counting) are also possible.
The only constraint to enable storing a C++ object as "properties" on an
operation is to implement three functions:
- convert from the candidate object to an Attribute
- convert from the Attribute to the candidate object
- hash the object
Optional the parsing and printing can also be customized with 2 extra
functions.
A new options is introduced to ODS to allow dialects to specify:
let usePropertiesForAttributes = 1;
When set to true, the inherent attributes for all the ops in this dialect
will be using properties instead of being stored alongside discardable
attributes.
The TestDialect showcases this feature.
Another change is that we introduce new APIs on the Operation class
to access separately the inherent attributes from the discardable ones.
We envision deprecating and removing the `getAttr()`, `getAttrsDictionary()`,
and other similar method which don't make the distinction explicit, leading
to an entirely separate namespace for discardable attributes.
Recommit d572cd1b06 after fixing python bindings build.
Differential Revision: https://reviews.llvm.org/D141742
https://llvm.org/docs/LangRef.html#llvm-powi-intrinsic
The max length of the integer power of `llvm.powi` intrinsic is 32, and
the value can be negative. If we use `int32_t` to store this value, `-Val`
will underflow when it is `INT32_MIN`
The issue was reported in D149033.
The `ReversePredicate` should have made sure the reverse predicate is
supported by target, but the check comes from early function and might
be invalid by any mistake. So it's better to double confirm it here.
Differential Revision: https://reviews.llvm.org/D149586
