After removing the range type, Linalg does not define any type. The revision thus consolidates the LinalgOps.h and LinalgTypes.h into a single Linalg.h header. Additionally, LinalgTypes.cpp is renamed to LinalgDialect.cpp to follow the convention adopted by other dialects such as the tensor dialect.
Depends On D115727
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D115728
Instead of modifying the existing linalg.tiled_loop op, create a new op with memref input/outputs and delete the old op.
Differential Revision: https://reviews.llvm.org/D115493
Instead of modifying the existing scf.for op, create a new op with memref OpOperands/OpResults and delete the old op.
New allocations / other memrefs can now be yielded from the loop. This functionality is deactivated by default and guarded against by AssertDestinationPassingStyle.
This change also introduces `replaceOp`, which will be utilized by all other `bufferize` implementations in future commits. Bufferization will then no longer rely on old (pre-bufferize) ops to DCE away. Instead old ops are deleted on the spot. This improves debuggability because there won't be any duplicate ops anymore (bufferized + not-yet-bufferized) when dumping IR during bufferization. It is also less fragile because unbufferized IR can no longer silently "hang around" due to an implementation bug.
Differential Revision: https://reviews.llvm.org/D114926
In 2015-05, GCC added the configure option `--enable-default-pie`. When enabled,
* in the absence of -fno-pic/-fpie/-fpic (and their upper-case variants), -fPIE is the default.
* in the absence of -no-pie/-pie/-shared/-static/-static-pie, -pie is the default.
This has been adopted by all(?) major distros.
I think default PIE is the majority in the Linux world, but
--disable-default-pie users is not that uncommon because GCC upstream hasn't
switched the default yet (https://gcc.gnu.org/PR103398).
This patch add CLANG_DEFAULT_PIE_ON_LINUX which allows distros to use default PIE.
The option is justified as its adoption can be very high among Linux distros
to make Clang default match GCC, and is likely a future-new-default, at which
point we will remove CLANG_DEFAULT_PIE_ON_LINUX.
The lit feature `default-pie-on-linux` can be handy to exclude default PIE sensitive tests.
Reviewed By: foutrelis, sylvestre.ledru, thesamesam
Differential Revision: https://reviews.llvm.org/D113372
This patch provides a draft overlay to support compilation of llvm libc with Bazel.
Tested on linux x86-64 with
```
cd git/llvm-project/utils/bazel
bazelisk-linux-amd64 build --sandbox_base=/dev/shm --config=generic_clang @llvm-project//libc:all
```
Differential Revision: https://reviews.llvm.org/D114712
This change provides `BufferizableOpInterface` implementations for ops from the Bufferization dialects. These ops are needed at the bufferization boundaries for partial bufferization.
Differential Revision: https://reviews.llvm.org/D114618
This cmake configure option was added in
df0ba47c36, and was ported to
Bazel in 7d323dc773.
However, the setting chosen in Bazel seems accidental, not necessarily
intentional.
LLVM_WINDOWS_PREFER_FORWARD_SLASH has no effect on Unix, and on
Windows, setting it to 0 is the default, which gets the same behaviour
as before. Setting it to 1 enables new experimental behaviours
(which is enabled by default on MinGW targets only).
As I don't see any explicit intent to opt in to the new experimental
behaviour, I believe the current configuration in bazel was a
mistake.
Differential Revision: https://reviews.llvm.org/D114065
They aren't needed anymore, we handle conditional compilation in those
files.
Reviewed By: GMNGeoffrey
Differential Revision: https://reviews.llvm.org/D114970
Bufferization of function boundaries is extracted from ComprehensiveBufferize into a separate file. This will become its own build target in the future.
Differential Revision: https://reviews.llvm.org/D114226
This reverts commit 3028bca6a9.
For some reason using FallbackModel works with CMake and does not work
with bazel. Using `ExternalModel` works. I will check what's going on
and resubmit tomorrow.
Remove the interface from op defs in MemRefOps.td and make it an external model.
This is the first PR of many that will move bufferization-related ops, interfaces, passes to Dialect/Bufferize.
RFC: https://llvm.discourse.group/t/rfc-dialect-for-bufferization-related-ops/4712
It is still debated if the comprehensive bufferization has to be moved there as well, so for now I am just moving the "gradual" bufferization.
Differential Revision: https://reviews.llvm.org/D114147
This reverts commit a9e236bed8.
This broke the Windows build:
mlir\include\mlir/Dialect/X86Vector/Transforms.h(28): error C2061: syntax error: identifier 'uint'
Step towards removing the hard coded behavior for this trait and to instead use common interface.
Differential Revision: https://reviews.llvm.org/D114208
This feature checks that headers included by a file are provided by a
header exported by one of the direct dependencies of the build rule in
which it is contained. It ensures that appropriate layering (a goal of
the LLVM project) is preserved. So far, I'm only adding this to MLIR
because we've had it turned on internally since the beginning, so MLIR
is already layering clean. It would be nice to also enable it for LLVM,
but that requires some additional cleanup.
Reviewed By: jpienaar
Differential Revision: https://reviews.llvm.org/D113952
We noticed that the library structure causes link ordering problems in Google's internal build. However, we don't think the problem is specific to Google's build, it probably can be reproduced anywhere with the right library structure.
In general splitting the Python bindings from their dependencies (the C API targets) creates the possibility that the two libraries might end up in the wrong order on the linker command line. We can avoid this problem happening by reverting the structure of the MLIRBindingsPythonCore to represent its dependencies in the usual way, rather than composing an incomplete `MLIRBindingsPythonCoreNoCAPI` target and their CAPI dependencies. It was probably a mistake to rewrite this particular `cc_library()` rule in terms of the two, since nothing guarantees that the two will be correctly ordered by the linker when both are being linked into the same binary, and it was only an incidental "cleanup" done in passing.
Otherwise the previous PR (D113565) is fine, since that was about the case where both are being built into two separate shared libraries. It just shouldn't have made this (unrelated) change.
Reviewed By: GMNGeoffrey
Differential Revision: https://reviews.llvm.org/D113773
This allows clients to build, e.g., the Python bindings against the C API headers, without including the C API implementations. This is useful when distributing software as multiple shared libraries.
Reviewed By: GMNGeoffrey
Differential Revision: https://reviews.llvm.org/D113565
* Move "linalg.inplaceable" attr name literals to BufferizableOpInterface.
* Use `memref.copy` by default. Override to `linalg.copy` in ComprehensiveBufferizePass.
These are the last remaining code dependencies on Linalg in Comprehensive Bufferize. The next commit will make ComprehensiveBufferize independent of the Linalg dialect.
Differential Revision: https://reviews.llvm.org/D113457
This revision adds an implementation of 2-D vector.transpose for 4x8 and 8x8 for
AVX2 and surfaces it to the Linalg level of control.
Reviewed By: dcaballe
Differential Revision: https://reviews.llvm.org/D113347
Guillaume Chatelet