Commit Graph

95 Commits

Author SHA1 Message Date
Hanhan Wang 855a119604 [mlir][linalg] Allow TC ops taking an unused shaped operand.
If one operand is not used in the formula, it will be considered a
shaped operand. And the result of indexing map of the operand will be the first
reduction dims.

Depends On D97383

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D97384
2021-02-26 06:45:56 -08:00
Stella Laurenzo 6c9541d4dd Implement simple type polymorphism for linalg named ops.
* It was decided that this was the end of the line for the existing custom tc parser/generator, and this is the first step to replacing it with a declarative format that maps well to mathy source languages.
* One such source language is implemented here: https://github.com/stellaraccident/mlir-linalgpy/blob/main/samples/mm.py
  * In fact, this is the exact source of the declarative `polymorphic_matmul` in this change.
  * I am working separately to clean this python implementation up and add it to MLIR (probably as `mlir.tools.linalg_opgen` or equiv). The scope of the python side is greater than just generating named ops: the ops are callable and directly emit `linalg.generic` ops fully dynamically, and this is intended to be a feature for frontends like npcomp to define custom linear algebra ops at runtime.
* There is more work required to handle full type polymorphism, especially with respect to integer formulations, since they require more specificity wrt types.
* Followups to this change will bring the new generator to feature parity with the current one and delete the current. Roughly, this involves adding support for interface declarations and attribute symbol bindings.

Differential Revision: https://reviews.llvm.org/D97135
2021-02-21 14:30:31 -08:00
Alexander Belyaev a89035d750 Revert "[MLIR] Create memref dialect and move several dialect-specific ops from std."
This commit introduced a cyclic dependency:
Memref dialect depends on Standard because it used ConstantIndexOp.
Std depends on the MemRef dialect in its EDSC/Intrinsics.h

Working on a fix.

This reverts commit 8aa6c3765b.
2021-02-18 12:49:52 +01:00
Julian Gross 8aa6c3765b [MLIR] Create memref dialect and move several dialect-specific ops from std.
Create the memref dialect and move several dialect-specific ops without
dependencies to other ops from std dialect to this dialect.

Moved ops:
AllocOp -> MemRef_AllocOp
AllocaOp -> MemRef_AllocaOp
DeallocOp -> MemRef_DeallocOp
MemRefCastOp -> MemRef_CastOp
GetGlobalMemRefOp -> MemRef_GetGlobalOp
GlobalMemRefOp -> MemRef_GlobalOp
PrefetchOp -> MemRef_PrefetchOp
ReshapeOp -> MemRef_ReshapeOp
StoreOp -> MemRef_StoreOp
TransposeOp -> MemRef_TransposeOp
ViewOp -> MemRef_ViewOp

The roadmap to split the memref dialect from std is discussed here:
https://llvm.discourse.group/t/rfc-split-the-memref-dialect-from-std/2667

Differential Revision: https://reviews.llvm.org/D96425
2021-02-18 11:29:39 +01:00
Weiwei Li 2ef24139fc [mlir][spirv] Add support for sampled image type
co-authored-by: Alan Liu <alanliu.yf@gmail.com>

Reviewed By: antiagainst

Differential Revision: https://reviews.llvm.org/D96169
2021-02-09 14:14:07 -05:00
xgupta 94fac81fcc [Branch-Rename] Fix some links
According to the [[ https://foundation.llvm.org/docs/branch-rename/ | status of branch rename ]], the master branch of the LLVM repository is removed on 28 Jan 2021.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D95766
2021-02-01 16:43:21 +05:30
KareemErgawy-TomTom 279e7ea63b [MLIR][LinAlg][Docs] Add missing example code and other small fixes.
Fixes a few small issues in the docs. It seems one of the examples was missing
the expected MLIR output due to a copy-paste typo.

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D95599
2021-01-28 11:49:36 +01:00
Alex Zinenko 9a60ad216d [mlir] Clarify docs around LLVM dialect-compatible types
Explicitly mention that there is exactly one MLIR type that corresponds
to a given LLVM IR type.
2021-01-19 13:42:16 +01:00
Valentin Clement cf0173de69 [mlir] Add better support for f80 and f128
Add builtin f80 and f128 following @schweitz proposition
https://llvm.discourse.group/t/rfc-adding-better-support-for-higher-precision-floating-point/2526/5

Reviewed By: ftynse, rriddle

Differential Revision: https://reviews.llvm.org/D94737
2021-01-15 10:29:48 -05:00
Lei Zhang 6b9fa8a50d [mlir][linalg] Add docstring support for named op spec
Depends on D94335

Reviewed By: nicolasvasilache, hanchung

Differential Revision: https://reviews.llvm.org/D94548
2021-01-14 09:57:56 -05:00
Lei Zhang 3bc7555ffa [mlir][linalg] Use attributes in named ops' indexing maps
This commit adds support for parsing attribute uses in indexing
maps. These attribute uses are represented as affine symbols in
the resultant indexing maps because we can only know their
concrete value (which are coming from op attributes and are
constants) for specific op instances. The `indxing_maps()`
calls are synthesized to read these attributes and create affine
constants to replace the placeholder affine symbols and simplify.

Depends on D94240

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D94335
2021-01-13 10:04:49 -05:00
Alex Zinenko 7fd1850813 [mlir] Update LLVM dialect type documentation
Recent commits reconfigured LLVM dialect types to use built-in types whenever
possible. Update the documentation accordingly.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D94485
2021-01-12 22:38:24 +01:00
Alex Zinenko bd30a796fc [mlir] use built-in vector types instead of LLVM dialect types when possible
Continue the convergence between LLVM dialect and built-in types by using the
built-in vector type whenever possible, that is for fixed vectors of built-in
integers and built-in floats. LLVM dialect vector type is still in use for
pointers, less frequent floating point types that do not have a built-in
equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class
has been removed in favor of free functions capable of inspecting both built-in
and LLVM dialect vector types: `LLVM::getVectorElementType`,
`LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is
necessary to design an implemented the extensions to built-in types so as to
remove the `LLVMFixedVectorType` entirely.

Note that the default output format for the built-in vectors does not have
whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the
LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This
required changing the FileCheck patterns in several tests.

Reviewed By: mehdi_amini, silvas

Differential Revision: https://reviews.llvm.org/D94405
2021-01-12 10:04:28 +01:00
Alex Zinenko dd5165a920 [mlir] replace LLVM dialect float types with built-ins
Continue the convergence between LLVM dialect and built-in types by replacing
the bfloat, half, float and double LLVM dialect types with their built-in
counterparts. At the API level, this is a direct replacement. At the syntax
level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively,
to be compatible with the built-in type syntax. The old keywords can still be
parsed but produce a deprecation warning and will be eventually removed.

Depends On D94178

Reviewed By: mehdi_amini, silvas, antiagainst

Differential Revision: https://reviews.llvm.org/D94179
2021-01-08 17:38:12 +01:00
Alex Zinenko 2230bf99c7 [mlir] replace LLVMIntegerType with built-in integer type
The LLVM dialect type system has been closed until now, i.e. did not support
types from other dialects inside containers. While this has had obvious
benefits of deriving from a common base class, it has led to some simple types
being almost identical with the built-in types, namely integer and floating
point types. This in turn has led to a lot of larger-scale complexity: simple
types must still be converted, numerous operations that correspond to LLVM IR
intrinsics are replicated to produce versions operating on either LLVM dialect
or built-in types leading to quasi-duplicate dialects, lowering to the LLVM
dialect is essentially required to be one-shot because of type conversion, etc.
In this light, it is reasonable to trade off some local complexity in the
internal implementation of LLVM dialect types for removing larger-scale system
complexity. Previous commits to the LLVM dialect type system have adapted the
API to support types from other dialects.

Replace LLVMIntegerType with the built-in IntegerType plus additional checks
that such types are signless (these are isolated in a utility function that
replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility
to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice.

Reviewed By: mehdi_amini, silvas, antiagainst

Differential Revision: https://reviews.llvm.org/D94178
2021-01-07 19:48:31 +01:00
Kazuaki Ishizaki 2b638ed5a1 [mlir] NFC: fix trivial typos
fix typos under docs, test, and tools directories

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D94158
2021-01-07 02:36:02 +09:00
lewuathe 4ae7952e2b [mlir] Fix MathJax rendering in Affine doc
MathJax is not properly imported in Affine doc. It causes the invalid rendering
of math formulas in the Affine doc page.

https://mlir.llvm.org/docs/Dialects/Affine/#affine-expressions

Importing MathJax code from CDN resolved the rendering issue as follows.

{F14942131}

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D94004
2021-01-06 02:11:36 +00:00
Lei Zhang 930c74f12d [mlir][spirv] NFC: rename SPIR-V conversion files for consistency
This commit renames various SPIR-V related conversion files for
consistency. It drops the "Convert" prefix to various files and
fixes various comment headers.

Reviewed By: hanchung, ThomasRaoux

Differential Revision: https://reviews.llvm.org/D93489
2020-12-23 14:36:46 -05:00
nicolasvasilache b7ae1d3d2b [mlir][Linalg] Revisit the Linalg on tensors abstraction
This revision drops init_tensor arguments from Linalg on tensors and instead uniformizes the output buffers and output tensors to be consistent.
This significantly simplifies the usage of Linalg on tensors and is a stepping stone for
its evolution towards a mixed tensor and shape abstraction discussed in https://llvm.discourse.group/t/linalg-and-shapes/2421/19.

Differential Revision: https://reviews.llvm.org/D93469
2020-12-21 12:29:10 -08:00
Nicolas Vasilache b88ed4ec8e [mlir][Linlag] Reflow Linalg.md - NFC
Markdown formatting seems to now be available, reflowing the doc without changing any content.
2020-12-18 16:15:58 +00:00
Richard Uhler a48172cf1c Add brief description of dialects doc section.
Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D93466
2020-12-17 18:37:34 +00:00
Lei Zhang 0117865412 [mlir][spirv] NFC: Shuffle code around to better follow convention
This commit shuffles SPIR-V code around to better follow MLIR
convention. Specifically,

* Created IR/, Transforms/, Linking/, and Utils/ subdirectories and
  moved suitable code inside.
* Created SPIRVEnums.{h|cpp} for SPIR-V C/C++ enums generated from
  SPIR-V spec. Previously they are cluttered inside SPIRVTypes.{h|cpp}.
* Fixed include guards in various header files (both .h and .td).
* Moved serialization tests under test/Target/SPIRV.
* Renamed TableGen backend -gen-spirv-op-utils into -gen-spirv-attr-utils
  as it is only generating utility functions for attributes.

Reviewed By: mravishankar

Differential Revision: https://reviews.llvm.org/D93407
2020-12-17 11:03:26 -05:00
Alex Zinenko eb4917d121 [mlir] Fix syntax error in markdown documentation 2020-12-17 14:09:31 +01:00
Alex Zinenko ccdd8c7759 [mlir] Move LLVM Dialect Op documentation to ODS
This was long overdue. The initial documentation for the LLVM dialect was
introduced before ODS had support for long descriptions. This is now possible,
so the documentation is moved to ODS, which can serve as a single source of
truth. The high-level description of the dialect structure is updated to
reflect that.

Depends On: D93315

Reviewed By: rriddle, mehdi_amini

Differential Revision: https://reviews.llvm.org/D93425
2020-12-17 12:32:35 +01:00
Alex Zinenko c2751250f3 [mlir] partially update LLVM dialect documentation
Rewrite the parts of the documentation that became stale: context/module
handling and type system. Expand the type system description.

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D93315
2020-12-17 12:32:34 +01:00
River Riddle 09f7a55fad [mlir][Types][NFC] Move all of the builtin Type classes to BuiltinTypes.h
This is part of a larger refactoring the better congregates the builtin structures under the BuiltinDialect. This also removes the problematic "standard" naming that clashes with the "standard" dialect, which is not defined within IR/. A temporary forward is placed in StandardTypes.h to allow time for downstream users to replaced references.

Differential Revision: https://reviews.llvm.org/D92435
2020-12-03 18:02:10 -08:00
ergawy 2074fec5be [MLIR][LLVM] Fix a tiny typo in the dialect docs.
Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D92333
2020-12-01 20:06:41 +00:00
ergawy 2f3adc54b5 [MLIR][SPIRV] Rename `spv._module_end` to `spv.mlir.endmodule`
This commit does the renaming mentioned in the title in order to bring
'spv' dialect closer to the MLIR naming conventions.

Reviewed By: antiagainst

Differential Revision: https://reviews.llvm.org/D91792
2020-11-19 13:25:13 -05:00
ergawy 9bd50abc4c [MLIR][SPIRV] Rename `spv._merge` to `spv.mlir.merge`
This commit does the renaming mentioned in the title in order to bring
'spv' dialect closer to the MLIR naming conventions.

Reviewed By: antiagainst

Differential Revision: https://reviews.llvm.org/D91797
2020-11-19 10:04:35 -05:00
ergawy adf9f64a02 [MLIR][SPIRV] Rename `spv._reference_of` to `spv.mlir.referenceof`
This commit does the renaming mentioned in the title in order to bring
'spv' dialect closer to the MLIR naming conventions.

Reviewed By: antiagainst

Differential Revision: https://reviews.llvm.org/D91715
2020-11-18 13:27:29 -05:00
ergawy 9793edd5bf [MLIR][SPIRV] Rename `spv._address_of` to `spv.mlir.addressof`
This commit does the renaming mentioned in the title in order to bring
`spv` dialect closer to the MLIR naming conventions.

Reviewed By: antiagainst

Differential Revision: https://reviews.llvm.org/D91609
2020-11-17 12:12:27 -05:00
Mehdi Amini 60a95b0dd7 Include the generated documentation for list of ops in the TOSA dialect 2020-11-08 00:09:35 +00:00
Suraj Sudhir b28121133d TOSA MLIR Dialect
This is the TOSA MLIR Dialect described in the following MLIR RFC: https://llvm.discourse.group/t/rfc-tosa-dialect-in-mlir/1971/24

Reviewed By: stellaraccident

Differential Revision: https://reviews.llvm.org/D90411
2020-11-07 08:38:09 -08:00
Benjamin Kramer 6e2b267d1c Promote transpose from linalg to standard dialect
While affine maps are part of the builtin memref type, there is very
limited support for manipulating them in the standard dialect. Add
transpose to the set of ops to complement the existing view/subview ops.
This is a metadata transformation that encodes the transpose into the
strides of a memref.

I'm planning to use this when lowering operations on strided memrefs,
using the transpose to remove the stride without adding a dependency on
linalg dialect.

Differential Revision: https://reviews.llvm.org/D88651
2020-10-05 10:58:20 +02:00
Lei Zhang 1f0b43638e [spirv] Move device info from resource limit into target env
Vendor/device information are not resource limits. Moving to
target environment directly for better organization.

Reviewed By: mravishankar

Differential Revision: https://reviews.llvm.org/D87911
2020-09-18 17:41:07 -04:00
Nicolas Vasilache 93fd30bac3 [mlir][Linalg] Evolve named ops to use assembly form and support linalg on tensors.
This revision allows representing a reduction at the level of linalg on tensors for named ops. When a structured op has a reduction and returns tensor(s), new conventions are added and documented.

As an illustration, the syntax for a `linalg.matmul` writing into a buffer is:

```
  linalg.matmul ins(%a, %b : memref<?x?xf32>, tensor<?x?xf32>)
               outs(%c : memref<?x?xf32>)
```

, whereas the syntax for a `linalg.matmul` returning a new tensor is:

```
  %d = linalg.matmul ins(%a, %b : tensor<?x?xf32>, memref<?x?xf32>)
                    init(%c : memref<?x?xf32>)
                      -> tensor<?x?xf32>
```

Other parts of linalg will be extended accordingly to allow mixed buffer/tensor semantics in the presence of reductions.
2020-09-18 06:14:30 -04:00
Kazuaki Ishizaki 603a8a60ba [mlir] NFC: fix trivial typos in documents
Reviewed By: mravishankar

Differential Revision: https://reviews.llvm.org/D86563
2020-08-27 03:50:34 +09:00
Alex Zinenko 215c2df647 [mlir] Mention mandatory RFC process for changes in Standard dialect
We have been asking for this systematically, mention it in the documentation.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D85902
2020-08-14 11:31:12 +02:00
MaheshRavishankar 25e8668e88 [mlir][SPIR-V] Fix wrongly placed Rationale section.
Differential Revision: https://reviews.llvm.org/D85461
2020-08-06 11:51:42 -07:00
Vincent Zhao b8943e7cea [MLIR][Linalg] Fixed obsolete examples in the MLIR Linalg Dialect doc
This diff fixes some obsolete examples in the Linalg dialect documentation: https://mlir.llvm.org/docs/Dialects/Linalg/

These examples are used to explain the basic properties of the Linalg dialect, which are not automatically generated from TableGen and are using out-of-date MLIR/Linalg syntax.

This diff extends each example by adding essential attributes and changing its syntax to make it processible by `mlir-opt`. There is also a command attached to each example that says how the example can be processed.

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D84229
2020-07-28 19:42:59 +00:00
Kazuaki Ishizaki 06b90586a4 [mlir]: NFC: Fix trivial typo in documents and comments
Differential Revision: https://reviews.llvm.org/D84400
2020-07-23 23:40:57 +09:00
MaheshRavishankar 44e1a93ccf [mlir][SPIR-V] Adding rationale for not using memref descriptors
SPIR-V lowering does not use `MemrefDescriptor`s when lowering memref
types. This adds rationale for the choice made.

Differential Revision: https://reviews.llvm.org/D84184
2020-07-21 07:28:59 -07:00
Alex Zinenko cba733edf5 [mlir] LLVM dialect: use addressof instead of constant to create function pointers
`llvm.mlir.constant` was originally introduced as an LLVM dialect counterpart
to `std.constant`. As such, it was supporting "function pointer" constants
derived from the symbol name. This is different from `std.constant` that allows
for creation of a "function" constant since MLIR, unlike LLVM IR, supports
this. Later, `llvm.mlir.addressof` was introduced as an Op that obtains a
constant pointer to a global in the LLVM dialect. It naturally extends to
functions (in LLVM IR, functions are globals) and should be used for defining
"function pointer" values instead.

Fixes PR46344.

Differential Revision: https://reviews.llvm.org/D82667
2020-06-29 12:21:33 +02:00
Alex Zinenko 36150c3637 [mlir] Affine symbols: do not expect AffineScope to always exist
In the affine symbol and dimension check, the code currently assumes
`getAffineScope` and its users `isValidDim` and `isValidSymbol` are only called
on values defined in regions that have a parent Op with `AffineScope` trait.
This is not necessarily the case, and these functions may be called on valid IR
that does not satisfy this assumption. Return `nullptr` from `getAffineScope`
if there is no parent op with `AffineScope` trait. Treat this case
conservatively in `isValidSymbol` by only accepting as symbols the values that
are guaranteed to be symbols (constants, and certain operations). No
modifications are necessary to `isValidDim` that delegates most of the work to
`isValidDim`.

Differential Revision: https://reviews.llvm.org/D81753
2020-06-15 17:55:49 +02:00
Jakub Lichman 2beacda4f6 [mlir][Linalg][Doc] Fix of misleading example in Property 2
Code example in MLIR Linalg doc fixed because it referenced non-existing variables and some parameters were of wrong types.

Differential Revision: https://reviews.llvm.org/D81633
2020-06-11 10:50:34 +02:00
Uday Bondhugula 57d361bd2f [MLIR][NFC] Rename op trait PolyhedralScope -> AffineScope
Rename op trait PolyhedralScope -> AffineScope for consistency.

Differential Revision: https://reviews.llvm.org/D79503
2020-05-07 00:19:56 +05:30
Uday Bondhugula 480345381a [MLIR] Introduce op trait PolyhedralScope (revised)
(A previous version of this, dd2c639c3c, was
reverted.)

Introduce op trait PolyhedralScope for ops to define a new scope for
polyhedral optimization / affine dialect purposes, thus generalizing
such scopes beyond FuncOp. Ops to which this trait is attached will
define a new scope for the consideration of SSA values as valid symbols
for the purposes of polyhedral analysis and optimization. Update methods
that check for dim/symbol validity to work based on this trait.

Differential Revision: https://reviews.llvm.org/D79060
2020-04-29 16:08:23 +05:30
Kazuaki Ishizaki b2f5fd84e8 [mlir] NFC: fix trivial typo
Differential Revision: https://reviews.llvm.org/D79065
2020-04-29 14:47:56 +09:00
Dmitri Gribenko ef06016d73 Revert "[MLIR] Introduce op trait PolyhedralScope"
This reverts commit dd2c639c3c. It broke a
few things -- the explanation will be posted to the review thread.
2020-04-28 14:50:57 +02:00
Uday Bondhugula dd2c639c3c [MLIR] Introduce op trait PolyhedralScope
Introduce op trait `PolyhedralScope` for ops to define a new scope for
polyhedral optimization / affine dialect purposes, thus generalizing
such scopes beyond FuncOp. Ops to which this trait is attached will
define a new scope for the consideration of SSA values as valid symbols
for the purposes of polyhedral analysis and optimization. Update methods
that check for dim/symbol validity to work based on this trait.

Differential Revision: https://reviews.llvm.org/D78863
2020-04-28 09:55:31 +05:30