402 Commits

Author SHA1 Message Date
Benjamin Kramer
9eccc7357e [bazel] Fix the build after 2c3326608460 2022-05-03 23:04:10 +02:00
Eric Li
aaddfbf9d6 [bazel] Add test targets for dataflow framework
Differential Revision: https://reviews.llvm.org/D124819
2022-05-03 14:09:10 +00:00
Matthias Springer
3c2a74a3ae [mlir][linalg][transform] Add TileOp to transform dialect
This commit adds a tiling op to the transform dialect as an external op.

Differential Revision: https://reviews.llvm.org/D124661
2022-04-29 21:35:31 +09:00
Benjamin Kramer
b8d4fe0f0a [bazel] Port 92a836da0759 2022-04-28 22:51:27 +02:00
Benjamin Kramer
1fbdf3a02e [bazel] Port 84fe39a45b73 2022-04-28 18:29:43 +02:00
Stephan Herhut
c10bbc20bc [mlir][bazel] Add suport for PDLL tests.
Differential Revision: https://reviews.llvm.org/D124515
2022-04-27 12:35:12 +02:00
Adrian Kuegel
c2a8490193 [mlir][Bazel] Add missing dependencies.
When building with layering_check enabled, there needs to be a
dependency for each header include.
2022-04-25 09:24:07 +02:00
Fangrui Song
bbbc49f780 [Bazel] Add more mlir dependencies after D124298
The Bazel layering_check feature compiles libraries with `-fmodule-name=X
-fmodules-strict-decluse` which require #include to be in deps.
2022-04-23 13:06:54 -07:00
Fangrui Song
6c8612fe6f [Bazel] Make mlir:BufferizationDialect depend on mlir:ArithmeticDialect after D124298 2022-04-23 12:59:37 -07:00
Alex Zinenko
40a8bd635b [mlir] use side effects in the Transform dialect
Currently, the sequence of Transform dialect operations only supports a single
use of each operand (verified by the `transform.sequence` operation). This was
originally motivated by the need to guard against accessing a payload IR
operation associated with a transform IR value after this operation has likely
been rewritten by a transformation. However, not all Transform dialect
operations rewrite payload IR, in particular the "navigation" operation such as
`transform.pdl_match` do not.

Introduce memory effects to the Transform dialect operations to describe their
effect on the payload IR and the mapping between payload IR opreations and
transform IR values. Use these effects to replace the single-use rule, allowing
repeated reads and disallowing use-after-free, where operations with the "free"
effect are considered to "consume" the transform IR value and rewrite the
corresponding payload IR operations). As an additional improvement, this
enables code motion transformation on the transform IR itself.

Reviewed By: Mogball

Differential Revision: https://reviews.llvm.org/D124181
2022-04-22 23:29:11 +02:00
Fangrui Song
baebe12ad0 [Bazel] Make mlir/test:TestShapeDialect depend on mlir:FuncDialect 2022-04-22 13:55:27 -07:00
Jacques Pienaar
9bae20b528 [mlir] Add shape.func
Add shape func op for use (primarily) in shape function_library op. Allows
setting default dialect for some simpler authoring. This is a minimal version
of the ops needed.

Differential Revision: https://reviews.llvm.org/D124055
2022-04-22 11:35:35 -07:00
Matthias Springer
e07a7fd5c0 [mlir][bufferization] Move ModuleBufferization to bufferization dialect
* Move Module Bufferization to the bufferization dialect. The implementation is split into `OneShotModuleBufferize.cpp` and `FuncBufferizableOpInterfaceImpl.cpp`, so that the external model implementation can be easily moved to the func dialect in the future.
* Split and clean up test cases. A few test cases are still remaining in Linalg and will be updated separately.
* `linalg.inplaceable` is renamed to `bufferization.writable` to accurately reflect its current usage.
* Attributes and their verifiers are moved from the Linalg dialect to the Bufferization dialect.
* Expand documentation.
* Add a new flag to One-Shot Bufferize to allow for function boundary bufferization.

Differential Revision: https://reviews.llvm.org/D122229
2022-04-22 19:37:28 +09:00
Sam McCall
0d43614df1 [bazel] try to adapt a7691dee2d3c0ea3f9f4d1, again 2022-04-21 22:33:40 +02:00
Sam McCall
f595b51f50 [bazel] try to adapt a7691dee2d3c0ea3f9f4d1 2022-04-21 22:09:12 +02:00
Alex Zinenko
30f22429d3 [mlir] Connect Transform dialect to PDL
This introduces a pair of ops to the Transform dialect that connect it to PDL
patterns. Transform dialect relies on PDL for matching the Payload IR ops that
are about to be transformed. For this purpose, it provides a container op for
patterns, a "pdl_match" op and transform interface implementations that call
into the pattern matching infrastructure.

To enable the caching of compiled patterns, this also provides the extension
mechanism for TransformState. Extensions allow one to store additional
information in the TransformState and thus communicate it between different
Transform dialect operations when they are applied. They can be added and
removed when applying transform ops. An extension containing a symbol table in
which the pattern names are resolved and a pattern compilation cache is
introduced as the first client.

Depends On D123664

Reviewed By: Mogball

Differential Revision: https://reviews.llvm.org/D124007
2022-04-21 16:23:10 +02:00
Chuanqi Xu
483efc9ad0 [Pipelines] Remove Legacy Passes in Coroutines
The legacy passes are deprecated now and would be removed in near
future. This patch tries to remove legacy passes in coroutines.

Reviewed By: aeubanks

Differential Revision: https://reviews.llvm.org/D123918
2022-04-21 10:59:11 +08:00
Benjamin Kramer
ff087d705c [bazel] Port f26c41e8dd28 2022-04-20 16:15:16 +02:00
Alex Zinenko
0eb403ad1b [mlir][transform] Introduce transform.sequence op
Sequence is an important transform combination primitive that just indicates
transform ops being applied in a row. The simplest version requires fails
immediately if any transformation in the sequence fails. Introducing this
operation allows one to start placing transform IR within other IR.

Depends On D123135

Reviewed By: Mogball, rriddle

Differential Revision: https://reviews.llvm.org/D123664
2022-04-19 21:41:02 +02:00
Mogball
fa26c7ff4b [mlir] Refactor LICM into a utility
LICM is refactored into a utility that is application on any region. The implementation is moved to Transform/Utils.
2022-04-16 00:37:07 +00:00
Stella Stamenova
353f0a8e43 Revert "[mlir] Refactor LICM into a utility"
This reverts commit 3131f808243abe3746280e016ab9459c14d9e53b.

This commit broke the Windows mlir bot:
https://lab.llvm.org/buildbot/#/builders/13/builds/19745
2022-04-15 17:09:16 -07:00
Mogball
3131f80824 [mlir] Refactor LICM into a utility
LICM is refactored into a utility that is application on any region. The implementation is moved to Transform/Utils.
2022-04-15 22:07:01 +00:00
rdzhabarov
3ef4099a61 [mlir] Fix BUILD issues and dependencies.
Differential Revision: https://reviews.llvm.org/D123868
2022-04-15 19:05:02 +00:00
Dmitri Gribenko
61bd985f2a Adjust Bazel BUILD files for 6d45558c1 2022-04-15 15:45:18 +02:00
Thomas Raoux
fa2762a251 [mlir] Update bazel file after adding nvgpu to nvvm conversion 2022-04-15 04:29:32 +00:00
Thomas Raoux
59058c441a [mlir][vector] Add operations used for Vector distribution
Add vector op warp_execute_on_lane_0 that will be used to do incremental
vector distribution in order to target warp level vector programming for
architectures with GPU-like SIMT programming model.
The idea behing the op is discussed further on discourse:
https://discourse.llvm.org/t/vector-vector-distribution-large-vector-to-small-vector/1983/23

Differential Revision: https://reviews.llvm.org/D123703
2022-04-15 03:47:52 +00:00
Thomas Raoux
4c564940a1 [mlir][nvgpu] Add NVGPU dialect (architectural specific gpu dialect)
This introduce a new dialect for vendro specific ptx operations. This
also adds the first operation ldmatrix as an example. More operations
will be added in follow up patches.
This new dialect is meant to be a bridge between GPU and Vector
dialectis and NVVM dialect.

This is based on the RFC proposed here:
https://discourse.llvm.org/t/rfc-add-nv-gpu-dialect-hw-specific-extension-of-gpu-dialect-for-nvidia-gpus/61466/8

Differential Revision: https://reviews.llvm.org/D123266
2022-04-14 16:33:46 +00:00
Alex Zinenko
d064c4801c [mlir] Introduce Transform dialect
This dialect provides operations that can be used to control transformation of
the IR using a different portion of the IR. It refers to the IR being
transformed as payload IR, and to the IR guiding the transformation as
transform IR.

The main use case for this dialect is orchestrating fine-grain transformations
on individual operations or sets thereof. For example, it may involve finding
loop-like operations with specific properties (e.g., large size) in the payload
IR, applying loop tiling to those and only those operations, and then applying
loop unrolling to the inner loops produced by the previous transformations. As
such, it is not intended as a replacement for the pass infrastructure, nor for
the pattern rewriting infrastructure. In the most common case, the transform IR
will be processed and applied to payload IR by a pass. Transformations
expressed by the transform dialect may be implemented using the pattern
infrastructure or any other relevant MLIR component.

This dialect is designed to be extensible, that is, clients of this dialect are
allowed to inject additional operations into this dialect using the newly
introduced in this patch `TransformDialectExtension` mechanism. This allows the
dialect to avoid a dependency on the implementation of the transformation as
well as to avoid introducing dialect-specific transform dialects.

See https://discourse.llvm.org/t/rfc-interfaces-and-dialects-for-precise-ir-transformation-control/60927.

Reviewed By: nicolasvasilache, Mogball, rriddle

Differential Revision: https://reviews.llvm.org/D123135
2022-04-14 13:48:45 +02:00
Alex Zinenko
09141f1adf [mlir] Split intrinsics out of LLVMOps.td
Move the operations that correspond to LLVM IR intrinsics in a separate .td
file. This makes it easier to maintain the intrinsics and decreases the compile
time of LLVMDialect.cpp by ~25%.

Depends On D123310

Reviewed By: wsmoses, jacquesguan

Differential Revision: https://reviews.llvm.org/D123315
2022-04-14 13:23:31 +02:00
Stella Laurenzo
61352a580a [mlir] Introduce ml_program dialect.
Differential Revision: https://reviews.llvm.org/D120203
2022-04-13 21:38:14 -07:00
Arthur Eubanks
08bd7d557c [bazel] Set CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL to 1
Matches official cmake build.
2022-04-13 16:31:52 -07:00
Dmitri Gribenko
e67b90bdb3 Update the Bazel build files for "[mlir][Math] Replace some constant ..." 2022-04-12 13:47:51 +02:00
rdzhabarov
64d3e163d8 Fix BUILD dependency for ExecutionEngineUtils
Differential Revision: https://reviews.llvm.org/D123570
2022-04-12 04:49:16 +00:00
Eugene Zhulenev
b35b9e307f [mlir] Add msan memory unpoisoning macros to mlir ExecutionEngine
Adding annotations on as-needed bases, currently only for memrefCopy, but in general all C API functions that take pointers to memory allocated/initialized inside the jit-compiled code must be annotated, to be able to run with msan.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D123557
2022-04-11 18:58:28 -07:00
rdzhabarov
e4c4d0d298 Fixing BUILD dependency on the DialectBase.
Differential Revision: https://reviews.llvm.org/D123558
2022-04-12 01:22:15 +00:00
Fangrui Song
a8ef1647aa [CMake][gn][Bazel] Remove HAVE_PTHREAD_GETSPECIFIC
The only user was removed by d351f54a076edf24c2a2bfda7cc7e3313ee3eecf.
2022-04-11 14:44:45 -07:00
Fangrui Song
ca68038d12 Reland "[Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON""
(With C++ exceptions, `clang++ --target=mips64{,el}-linux-gnu -fpie -pie
-fuse-ld=lld` has link errors (lld does not implement some strange R_MIPS_64
.eh_frame handling in GNU ld). However, sanitizer-x86_64-linux-qemu used this to
build ScudoUnitTests. Pined ScudoUnitTests to -no-pie.)

Default the option introduced in D113372 to ON to match all(?) major Linux
distros. This matches GCC and improves consistency with Android and linux-musl
which always default to PIE.
Note: CLANG_DEFAULT_PIE_ON_LINUX may be removed in the future.

Differential Revision: https://reviews.llvm.org/D120305
2022-04-08 23:40:18 -07:00
Jorge Gorbe Moya
ac1235dda6 Fix bazel rule for __support_fputil_fma when using header modules.
Putting __support/FPUtil/x86_64/FMA.h in `hdrs` will trigger a
compilation action for that header, and it will always `#error` out for
non-FMA targets. Move these platform-specific headers that are
conditionally included to `textual_hdrs` instead.
2022-04-08 16:28:31 -07:00
Tue Ly
c5f8a0a1e9 [libc] Add support for x86-64 targets that do not have FMA instructions.
Make FMA flag checks more accurate for x86-64 targets, and refactor
polyeval to use multiply and add instead when FMA instructions are not
available.

Reviewed By: michaelrj, sivachandra

Differential Revision: https://reviews.llvm.org/D123335
2022-04-08 14:12:24 -04:00
Nico Weber
e22a60b1c8 Revert "Reland "[Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON"""
This reverts commit 2aca33baf15926afe2520a06b1427a9894226fd2.
Broke tests on several bots, see comments on https://reviews.llvm.org/D120305
2022-04-07 10:07:07 -04:00
Benjamin Kramer
6b15157610 [bazel] Port 3031fa88f0 2022-04-07 12:14:14 +02:00
Benjamin Kramer
b8acaaa0c7 [bazel] Port 5390606aa963 2022-04-07 10:40:55 +02:00
Fangrui Song
2aca33baf1 Reland "[Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON""
(The upgrade of the ppc64le bot and D121257 have fixed compiler-rt failures. Tested by nemanjai.)

Default the option introduced in D113372 to ON to match all(?) major Linux
distros. This matches GCC and improves consistency with Android and linux-musl
which always default to PIE.
Note: CLANG_DEFAULT_PIE_ON_LINUX may be removed in the future.

Differential Revision: https://reviews.llvm.org/D120305
2022-04-06 20:19:07 -07:00
Nikita Popov
ed4e6e0398 [cmake] Remove LLVM_ENABLE_NEW_PASS_MANAGER cmake option
Or rather, error out if it is set to something other than ON. This
removes the ability to enable the legacy pass manager by default,
but does not remove the ability to explicitly enable it through
various flags like -flegacy-pass-manager or -enable-new-pm=0.

I checked, and our test suite definitely doesn't pass with
LLVM_ENABLE_NEW_PASS_MANAGER=OFF anymore.

Differential Revision: https://reviews.llvm.org/D123126
2022-04-06 09:52:21 +02:00
Jorge Gorbe Moya
54cc7de4bc Fix bazel build.
- https://reviews.llvm.org/D122619 bumped zlib version but didn't change
  the hash

- Added new header from https://reviews.llvm.org/D108438
2022-04-05 15:45:53 -07:00
Benjamin Kramer
fe11344257 [bazel] Try to fix the build after 4661a65f4b 2022-04-05 14:40:52 +02:00
Alexander Belyaev
004d4f8980 [mlir] Update BUILD.bazel. 2022-04-05 11:25:40 +02:00
Alexander Belyaev
cc6788aece [mlir] Update mlir/BUILD.bazel. 2022-04-05 10:14:41 +02:00
Rob Suderman
126e7eaf0d [tosa] Add option to disable tosa.apply_scale lowering in TosaToStandard
Apply scale should be optionally disabled when lowering via TosaToStandard.
In most cases it should persist until the lowering to specific backend.

Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D122948
2022-04-04 12:22:12 -07:00
Mikhail Goncharov
567a979ea8 fix bazel build after 369337e3c2 2022-04-01 15:27:32 +02:00