Commit Graph

1062 Commits

Author SHA1 Message Date
River Riddle b9c876bd7e [mlir] Add initial support for an alias analysis framework in MLIR
This revision adds a new `AliasAnalysis` class that represents the main alias analysis interface in MLIR. The purpose of this class is not to hold the aliasing logic itself, but to provide an interface into various different alias analysis implementations. As it evolves this should allow for users to plug in specialized alias analysis implementations for their own needs, and have them immediately usable by other analyses and transformations.

This revision also adds an initial simple generic alias, LocalAliasAnalysis, that provides support for performing stateless local alias queries between values. This class is similar in scope to LLVM's BasicAA.

Differential Revision: https://reviews.llvm.org/D92343
2021-02-09 14:21:27 -08:00
Lei Zhang 4c640e49c9 [mlir][linalg] Verify indexing map required attributes
Indexing maps for named ops can reference attributes so that
we can synthesize the indexing map dynamically. This supports
cases like strides for convolution ops. However, it does cause
an issue: now the indexing_maps() function call is dependent
on those attributes.

Linalg ops inherit LinalgOpInterfaceTraits, which calls
verifyStructuredOpInterface() to verify the interface.
verifyStructuredOpInterface() further calls indexing_maps().
Note that trait verification is done before the op itself,
where ODS generates the verification for those attributes.
So we can have indexing_maps() referencing non-existing or
invalid attribute, before the ODS-generated verification
kick in.

There isn't a dependency handling mechansim for traits.
This commit adds new interface methods to query whether an
op hasDynamicIndexingMaps() and then perform
verifyIndexingMapRequiredAttributes() in
verifyStructuredOpInterface() to handle the dependency issue.

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D96297
2021-02-09 08:48:29 -05:00
Tres Popp c2c83e97c3 Revert "Revert "Reorder MLIRContext location in BuiltinAttributes.h""
This reverts commit 511dd4f438 along with
a couple fixes.

Original message:
Now the context is the first, rather than the last input.

This better matches the rest of the infrastructure and makes
it easier to move these types to being declaratively specified.

Phabricator: https://reviews.llvm.org/D96111
2021-02-08 10:39:58 +01:00
Tres Popp 511dd4f438 Revert "Reorder MLIRContext location in BuiltinAttributes.h"
This reverts commit 7827753f98.
2021-02-08 09:32:42 +01:00
Tres Popp 7827753f98 Reorder MLIRContext location in BuiltinAttributes.h
Now the context is the first, rather than the last input.

This better matches the rest of the infrastructure and makes
it easier to move these types to being declaratively specified.

Differential Revision: https://reviews.llvm.org/D96111
2021-02-08 09:28:09 +01:00
River Riddle e21adfa32d [mlir] Mark LogicalResult as LLVM_NODISCARD
This makes ignoring a result explicit by the user, and helps to prevent accidental errors with dropped results. Marking LogicalResult as no discard was always the intention from the beginning, but got lost along the way.

Differential Revision: https://reviews.llvm.org/D95841
2021-02-04 15:10:10 -08:00
Lei Zhang 63dc26450b Revert "[mlir][ODS] Use StringLiteral instead of StringRef when applicable"
This reverts commit 953086ddbb because
it breaks GCC 5 build:

  error: could not convert '(const char*)""' from 'const char*' to 'llvm::StringLiteral'
     static ::llvm::StringLiteral getDialectNamespace() { return ""; }
2021-02-04 13:59:37 -05:00
Vladislav Vinogradov 953086ddbb [mlir][ODS] Use StringLiteral instead of StringRef when applicable
Use `StringLiteral` for function return type if it is known to return
constant string literals only.

This will make it visible to API users, that such values can be safely
stored, since they refers to constant data, which will never be deallocated.

`StringRef` is general is not safe to store for a long term,
since it might refer to temporal data allocated in heap.

Reviewed By: mehdi_amini, bkramer

Differential Revision: https://reviews.llvm.org/D95945
2021-02-04 17:35:15 +00:00
Nicolas Vasilache e4a503a26d [mlir][Linalg] Introduce a ContractionOpInterface
This revision takes advantage of recent extensions to vectorization to refactor contraction detection into a bona fide Linalg interface.
The mlit-linalg-ods-gen parser is extended to support adding such interfaces.
The detection that was originally enabling vectorization is refactored to serve as both a test on a generic LinalgOp as well as to verify ops that declare to conform to that interface.

This is plugged through Linalg transforms and strategies but it quickly becomes evident that the complexity and rigidity of the C++ class based templating does not pay for itself.
Therefore, this revision changes the API for vectorization patterns to get rid of templates as much as possible.
Variadic templates are relegated to the internals of LinalgTransformationFilter as much as possible and away from the user-facing APIs.

It is expected other patterns / transformations will follow the same path and drop as much C++ templating as possible from the class definition.

Differential revision: https://reviews.llvm.org/D95973
2021-02-04 16:53:24 +00:00
Nicolas Vasilache 1029c82c1e [mlir][Linalg] NFC - Extract a standalone LinalgInterfaces
This separation improves the layering and paves the way for more interfaces coming up in the future.

Differential revision: https://reviews.llvm.org/D95941
2021-02-04 07:19:38 +00:00
Christian Sigg 8d73bee4ed [mlir] Add gpu async integration test.
Reviewed By: herhut

Differential Revision: https://reviews.llvm.org/D94421
2021-02-03 21:45:23 +01:00
Christian Sigg 4a35941dbd Delete CUDA context after linking device code.
Differential Revision: https://reviews.llvm.org/D95857
2021-02-03 20:10:12 +01:00
Christian Sigg 8a43ec7faa Set GPU context before {cu,hip}MemHostRegister.
Differential Revision: https://reviews.llvm.org/D95856
2021-02-03 20:00:36 +01:00
Vladislav Vinogradov f1bdf9fa9b [mlir][NFC] Use explicit `mlir` namespace in generated code
This makes the generated code independent from actual namespace of its users.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D95520
2021-02-02 18:24:43 +00:00
MaheshRavishankar 342d4662e1 [mlir] Add custom directive hooks for printing mixed integer or value operands.
Add printer and parser hooks for a custom directive that allows
parsing and printing of idioms that can represent a list of values
each of which is either an integer or an SSA value. For example in

`subview %source[%offset_0, 1] [4, %size_1] [%stride_0, 3]`

each of the list (which represents offset, size and strides) is a mix
of either statically know integer values or dynamically computed SSA
values. Since this is used in many places adding a custom directive to
parse/print this idiom allows using assembly format on operations
which use this idiom.

Differential Revision: https://reviews.llvm.org/D95773
2021-02-01 19:03:49 -08:00
Christian Sigg a4b7d52f3a [mlir] Fix missing null termination in cuLinkAddData argument.
Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D95679
2021-02-01 09:32:50 +01:00
MaheshRavishankar 98835e3d98 [mlir][Linalg] Enable TileAndFusePattern to work with tensors.
Differential Revision: https://reviews.llvm.org/D94531
2021-01-28 14:13:01 -08:00
Christian Sigg 5bdc771fc9 [mlir] Make cuda/rocm-runtime-wrappers not depend on LLVMSupport.
Depending on the headers only is fine, but we do not want to use any symbols from LLVMSupport. If we do, static registration of cl options is linked in as well, and loading multiple such libraries in the cuda/rocm-runner fails because the same cl options are registered multiple times.

The cuda/rocm-runners also depend on LLVMSupport, so one could think that already loading a single such library would fail. It does not because the map of cl options is not shared between the runner and the loaded libraries (but it is shared across all loaded libraries, presumably because it has external linkage, in contrast to the static registration which has internal linkage).

This change is a preparation step for dynamically loading the mlir_async_runtime.so and cuda-runtime-wrappers.so in the same test. The async runtime depends on LLVMSupport in a more fundamental way (llvm::ThreadPool), and as explained above there can only be one.

This change also switches to add_mlir_library to make it consistent with the other runner_utils libraries.

Reviewed By: herhut

Differential Revision: https://reviews.llvm.org/D95613
2021-01-28 17:25:01 +01:00
Christian Sigg 8262cd8a0e [mlir] Set CUDA/ROCm context before creating resources.
The current context is thread-local state, and in preparation of GPU async execution (on multiple threads) we need to set the context before calling API that create resources.

Reviewed By: herhut

Differential Revision: https://reviews.llvm.org/D94495
2021-01-26 19:07:06 +01:00
Stella Laurenzo fd226c9b02 [mlir][Python] Roll up of python API fixes.
* As discussed, fixes the ordering or (operands, results) -> (results, operands) in various `create` like methods.
* Fixes a syntax error in an ODS accessor method.
* Removes the linalg example in favor of a test case that exercises the same.
* Fixes FuncOp visibility to properly use None instead of the empty string and defaults it to None.
* Implements what was documented for requiring that trailing __init__ args `loc` and `ip` are keyword only.
* Adds a check to `InsertionPoint.insert` so that if attempting to insert past the terminator, an exception is raised telling you what to do instead. Previously, this would crash downstream (i.e. when trying to print the resultant module).
* Renames `_ods_build_default` -> `build_generic` and documents it.
* Removes `result` from the list of prohibited words and for single-result ops, defaults to naming the result `result`, thereby matching expectations and what is already implemented on the base class.
* This was intended to be a relatively small set of changes to be inlined with the broader support for ODS generating the most specific builder, but it spidered out once actually testing various combinations, so rolling up separately.

Differential Revision: https://reviews.llvm.org/D95320
2021-01-24 19:02:59 -08:00
River Riddle 29d420e0bf [mlir][OpFormatGen] Add support for anchoring optional groups with types
This revision adds support for using either operand or result types to anchor an optional group. It also removes the arbitrary restriction that type directives must refer to variables in the same group, which is overly limiting for a declarative format syntax.

Fixes PR#48784

Differential Revision: https://reviews.llvm.org/D95109
2021-01-22 12:07:27 -08:00
Mehdi Amini 922b26cde4 Add Python bindings for the builtin dialect
This includes some minor customization for FuncOp and ModuleOp.

Differential Revision: https://reviews.llvm.org/D95022
2021-01-21 22:44:44 +00:00
Christian Sigg bd3a387ee7 Revert [mlir] Link mlir_runner_utils statically into cuda/rocm-runtime-wrappers (cf50f4f764)
There are cmake failures that I do not know how to fix.

Differential Revision: https://reviews.llvm.org/D95162
2021-01-21 22:38:59 +01:00
River Riddle 825c2b4a41 [mlir][OpFormatGen] Fix incorrect kind used for RegionsDirective
I attempted to write a test case for this, but the situations in which the kind is used for RegionDirective and ResultsDirective have zero overlap; meaning that there isn't a situation in which sharing the kind creates a conflict.

Differential Revision: https://reviews.llvm.org/D94988
2021-01-20 16:50:59 -08:00
Tobias Gysi 4c1eaf26ae [mlir] fix the rocm runtime wrapper to account for cuda / rocm api differences
The patch adapts the rocm runtime wrapper due to subtle differences between the cuda and the rocm/hip runtime api.

Reviewed By: csigg

Differential Revision: https://reviews.llvm.org/D95027
2021-01-20 18:48:32 +01:00
Christian Sigg cf50f4f764 [mlir] Link mlir_runner_utils statically into cuda/rocm-runtime-wrappers.
The runtime-wrappers depend on LLVMSupport, pulling in static initialization code (e.g. command line arguments). Dynamically loading multiple such libraries results in ODR violoations.

So far this has not been an issue, but in D94421, I would like to load both the async-runtime and the cuda-runtime-wrappers as part of a cuda-runner integration test. When doing this, code that asserts that an option category is only registered once fails (note that I've only experienced this in Google's bazel where the async-runtime depends on LLVMSupport, but a similar issue would happen in cmake if more than one runtime-wrapper starts to depend on LLVMSupport).

The underlying issue is that we have a mix of static and dynamic linking. If all dependencies were loaded as shared objects (i.e. if LLVMSupport was linked dynamically to the runtime wrappers), each dependency would only get loaded once. However, linking dependencies dynamically would require special attention to paths (one could dynamically load the dependencies first given explicit paths). The simpler approach seems to be to link all dependencies statically into a single shared object.

This change basically applies the same logic that we have in the c_runner_utils: we have a shared object target that can be loaded dynamically, and we have a static library target that can be linked to other runtime-wrapper shared object targets.

Reviewed By: herhut

Differential Revision: https://reviews.llvm.org/D94399
2021-01-20 12:10:16 +01:00
Stella Laurenzo 894d88a759 [mlir][python] Add facility for extending generated python ODS.
* This isn't exclusive with other mechanisms for more ODS centric op definitions, but based on discussions, we feel that we will always benefit from a python escape hatch, and that is the most natural way to write things that don't fit the mold.
* I suspect this facility needs further tweaking, and once it settles, I'll document it and add more tests.
* Added extensions for linalg, since it is unusable without them and continued to evolve my e2e example.

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D94752
2021-01-19 13:20:26 -08:00
Stella Laurenzo 71b6b010e6 [mlir][python] Factor out standalone OpView._ods_build_default class method.
* This allows us to hoist trait level information for regions and sized-variadic to class level attributes (_ODS_REGIONS, _ODS_OPERAND_SEGMENTS, _ODS_RESULT_SEGMENTS).
* Eliminates some splicey python generated code in favor of a native helper for it.
* Makes it possible to implement custom, variadic and region based builders with one line of python, without needing to manually code access to the segment attributes.
* Needs follow-on work for region based callbacks and support for SingleBlockImplicitTerminator.
* A follow-up will actually add ODS support for generating custom Python builders that delegate to this new method.
* Also includes the start of an e2e sample for constructing linalg ops where this limitation was discovered (working progressively through this example and cleaning up as I go).

Differential Revision: https://reviews.llvm.org/D94738
2021-01-19 09:29:57 -08:00
Mehdi Amini 7dadcd02d6 Fix a few GCC compiler warnings (NFC) 2021-01-19 06:00:04 +00:00
Vladislav Vinogradov aca240b4f6 [mlir] Fix cross-compilation (Linalg ODS gen)
Use cross-compilation approach for `mlir-linalg-ods-gen` application
similar to TblGen tools.

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D94598
2021-01-18 11:57:55 +01:00
Lei Zhang 0acc260b57 [mlir][linalg] Support generating builders for named op attributes
This commit adds support to generate an additional builder for
each named op that has attributes. This gives better experience
when creating the named ops.

Along the way adds support for i64.

Reviewed By: hanchung

Differential Revision: https://reviews.llvm.org/D94733
2021-01-15 09:00:30 -05:00
River Riddle 93592b726c [mlir][OpFormatGen] Format enum attribute cases as keywords when possible
In the overwhelmingly common case, enum attribute case strings represent valid identifiers in MLIR syntax. This revision updates the format generator to format as a keyword in these cases, removing the need to wrap values in a string. The parser still retains the ability to parse the string form, but the printer will use the keyword form when applicable.

Differential Revision: https://reviews.llvm.org/D94575
2021-01-14 11:35:49 -08:00
River Riddle 00a61b327d [mlir][ODS] Add new RangedTypesMatchWith operation predicate
This is a variant of TypesMatchWith that provides support for variadic arguments. This is necessary because ranges generally can't use the default operator== comparators for checking equality.

Differential Revision: https://reviews.llvm.org/D94574
2021-01-14 11:35:49 -08: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
Lei Zhang 8349fa0fdd [mlir][spirv] NFC: split deserialization into multiple source files
This avoids large source files and gives a better structure. It also
allows leveraging compilation parallelism.

Reviewed By: mravishankar

Differential Revision: https://reviews.llvm.org/D94360
2021-01-12 11:21:03 -05:00
Lei Zhang 4086072f8a Reland "[mlir][linalg] Support parsing attributes in named op spec"
With this, now we can specify a list of attributes on named ops
generated from the spec. The format is defined as

```
attr-id ::= bare-id (`?`)?
attr-typedef ::= type (`[` `]`)?
attr-def ::= attr-id `:` attr-typedef

tc-attr-def ::= `attr` `(` attr-def-list `)`
tc-def ::= `def` bare-id
  `(`tensor-def-list`)` `->` `(` tensor-def-list`)`
  (tc-attr-def)?
```

For example,

```
ods_def<SomeCppOp>
def some_op(...) -> (...)
attr(
  f32_attr: f32,
  i32_attr: i32,
  array_attr : f32[],
  optional_attr? : f32
)
```

where `?` means optional attribute and `[]` means array type.

Reviewed By: hanchung, nicolasvasilache

Differential Revision: https://reviews.llvm.org/D94240
2021-01-12 10:57:46 -05:00
Valentin Clement 0bd9a13691 [mlir][openacc] Use TableGen information for default enum
Use TableGen and information in ACC.td for the Default enum in the OpenACC dialect.
This patch generalize what was done for OpenMP for directives.

Follow up patch after D93576

Reviewed By: kiranchandramohan

Differential Revision: https://reviews.llvm.org/D93710
2021-01-12 09:42:42 -05:00
Mehdi Amini 110775809a Revert "[mlir][linalg] Support parsing attributes in named op spec"
This reverts commit df86f15f0c.

The gcc-5 build was broken by this change:

  mlir/tools/mlir-linalg-ods-gen/mlir-linalg-ods-gen.cpp:1275:77:   required from here
  /usr/include/c++/5/ext/new_allocator.h:120:4: error: no matching function for call to 'std::pair<const std::__cxx11::basic_string<char>, {anonymous}::TCParser::RegisteredAttr>::pair(llvm::StringRef&, {anonymous}::TCParser::RegisteredAttr'
2021-01-11 20:43:42 +00:00
River Riddle 948be58258 [mlir][TypeDefGen] Add support for adding builders when generating a TypeDef
This allows for specifying additional get/getChecked methods that should be generated on the type, and acts similarly to how OpBuilders work. TypeBuilders have two additional components though:
* InferredContextParam
  - Bit indicating that the context parameter of a get method is inferred from one of the builder parameters
* checkedBody
  - A code block representing the body of the equivalent getChecked method.

Differential Revision: https://reviews.llvm.org/D94274
2021-01-11 12:06:22 -08:00
River Riddle 2074177301 [mlir][ODS] Add a C++ abstraction for OpBuilders
This removes the need for OpDefinitionsGen to use raw tablegen API, and will also
simplify adding builders to TypeDefs as well.

Differential Revision: https://reviews.llvm.org/D94273
2021-01-11 12:06:22 -08:00
Lei Zhang df86f15f0c [mlir][linalg] Support parsing attributes in named op spec
With this, now we can specify a list of attributes on named ops
generated from the spec. The format is defined as

```
attr-id ::= bare-id (`?`)?
attr-typedef ::= type (`[` `]`)?
attr-def ::= attr-id `:` attr-typedef

tc-attr-def ::= `attr` `(` attr-def-list `)`
tc-def ::= `def` bare-id
  `(`tensor-def-list`)` `->` `(` tensor-def-list`)`
  (tc-attr-def)?
```

For example,

```
ods_def<SomeCppOp>
def some_op(...) -> (...)
attr(
  f32_attr: f32,
  i32_attr: i32,
  array_attr : f32[],
  optional_attr? : f32
)
```

where `?` means optional attribute and `[]` means array type.

Reviewed By: hanchung, nicolasvasilache

Differential Revision: https://reviews.llvm.org/D94240
2021-01-11 09:05:20 -05:00
Mehdi Amini f02e61a8b9 Fix MLIR DRR matching when attributes are interleaved with operands
The ODSOperand indexing should ignore the attributes.

Differential Revision: https://reviews.llvm.org/D94281
2021-01-08 03:18:26 +00:00
River Riddle 41d919aa29 [mlir][TypeDefGen] Remove the need to define parser/printer for singleton types
This allows for singleton types without an explicit parser/printer to simply use
the mnemonic as the assembly format, removing the need for these types to provide the parser/printer
fields.

Differential Revision: https://reviews.llvm.org/D94194
2021-01-06 15:00:14 -08:00
River Riddle e0a93e4b65 [mlir][ODS] Rename several uses of 'description' to 'summary'
Right now constraint/predicate traits/etc. use their "description" field as a one line human readable string. This breaks the current convention, by which a "description" may be multi-line. This revision renames the "description" field in these cases to "summary" which matches what the string is actually used as. This also unbreaks the use of TypeDefs(and eventually AttrDefs) in conjunction with existing type constraint facilities like `Optional`.

Differential Revision: https://reviews.llvm.org/D94133
2021-01-06 14:18:58 -08: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
Tres Popp cbda2cba4f [mlir] Fully specify removeAttr return type
This was added without full specification like other generated methods.
This then leads to other downstream dialects failing to compile the
generated code when they are not in the mlir namespace.

Differential Revision: https://reviews.llvm.org/D94132
2021-01-06 00:52:35 +01:00
Felipe de Azevedo Piovezan 86d68e2885 [mlir] Gen removeAttr methods with tablegen
If an operation defines an optional attribute (OptionalAttr or
UnitAttr), transformations may wish to remove these attributes while
maintaining invariants established by the operation. Currently, the only
way to do this is by calling `Operation::removeAttr("attrName")`, which
requires developers to know the exact name of the attribute used by
table-gen. Furthermore, if the attribute name changes, this won't be
detected at compile time. Instead, `removeAttr` would return an empty
attribute and no errors would be raised, unless the caller checks for
the returned value.

This patch adds table gen support for generating `remove<AttrName>Attr`
methods for OptionalAttributes defined by operations.

Implementation choice: to preserve camelCase for the method's name, the
first character of an attribute called `myAttr` is changed to upper case
in order to preserve the coding style, so the final method would be
called `removeMyAttr`.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D93903
2021-01-05 18:48:09 +00:00
Dan Zheng 7afd5cfbc7 [NFC] Fix -Wrange-loop-analysis warnings.
Remove unnecessary `&` from loop variables.

Fix warnings: "loop variable is always a copy because the range does not
return a reference".

```
[240/2862] Building CXX object tools/mlir/tools/mlir-tblgen/CMakeFiles/mlir-tblgen.dir/TypeDefGen.cpp.o
llvm-project/mlir/tools/mlir-tblgen/TypeDefGen.cpp:50:25: warning: loop variable 'typeDef' is always a copy because the range of type 'llvm::iterator_range<llvm::mapped_iterator<std::__1::__wrap_iter<llvm::Record **>, (lambda at llvm-project/mlir/tools/mlir-tblgen/TypeDefGen.cpp:40:16), mlir::tblgen::TypeDef> >' does not return a reference [-Wrange-loop-analysis]
    for (const TypeDef &typeDef : defs)
                        ^
llvm-project/mlir/tools/mlir-tblgen/TypeDefGen.cpp:50:10: note: use non-reference type 'mlir::tblgen::TypeDef'
    for (const TypeDef &typeDef : defs)
         ^~~~~~~~~~~~~~~~~~~~~~~~
llvm-project/mlir/tools/mlir-tblgen/TypeDefGen.cpp:64:23: warning: loop variable 'typeDef' is always a copy because the range of type 'llvm::iterator_range<llvm::mapped_iterator<std::__1::__wrap_iter<llvm::Record **>, (lambda at llvm-project/mlir/tools/mlir-tblgen/TypeDefGen.cpp:40:16), mlir::tblgen::TypeDef> >' does not return a reference [-Wrange-loop-analysis]
  for (const TypeDef &typeDef : defs)
                      ^
llvm-project/mlir/tools/mlir-tblgen/TypeDefGen.cpp:64:8: note: use non-reference type 'mlir::tblgen::TypeDef'
  for (const TypeDef &typeDef : defs)
       ^~~~~~~~~~~~~~~~~~~~~~~~
2 warnings generated.

[1934/2862] Building CXX object tools...Files/toyc-ch4.dir/mlir/MLIRGen.cpp.o
llvm-project/mlir/examples/toy/Ch4/mlir/MLIRGen.cpp:139:22: warning: loop variable 'name_value' is always a copy because the range of type 'detail::zippy<detail::zip_shortest, ArrayRef<unique_ptr<VariableExprAST, default_delete<VariableExprAST> > > &, MutableArrayRef<BlockArgument> >' does not return a reference [-Wrange-loop-analysis]
    for (const auto &name_value :
                     ^
llvm-project/mlir/examples/toy/Ch4/mlir/MLIRGen.cpp:139:10: note: use non-reference type 'std::__1::tuple<const std::__1::unique_ptr<toy::VariableExprAST, std::__1::default_delete<toy::VariableExprAST> > &, mlir::BlockArgument &>'
    for (const auto &name_value :
         ^~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.

[1940/2862] Building CXX object tools...Files/toyc-ch5.dir/mlir/MLIRGen.cpp.o
llvm-project/mlir/examples/toy/Ch5/mlir/MLIRGen.cpp:139:22: warning: loop variable 'name_value' is always a copy because the range of type 'detail::zippy<detail::zip_shortest, ArrayRef<unique_ptr<VariableExprAST, default_delete<VariableExprAST> > > &, MutableArrayRef<BlockArgument> >' does not return a reference [-Wrange-loop-analysis]
    for (const auto &name_value :
                     ^
llvm-project/mlir/examples/toy/Ch5/mlir/MLIRGen.cpp:139:10: note: use non-reference type 'std::__1::tuple<const std::__1::unique_ptr<toy::VariableExprAST, std::__1::default_delete<toy::VariableExprAST> > &, mlir::BlockArgument &>'
    for (const auto &name_value :
         ^~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
```

Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D94003
2021-01-05 18:44:17 +00:00
Alex Zinenko c69c9e0f0f [mlir] Remove LLVMType, LLVM dialect types now derive Type directly
BEGIN_PUBLIC
[mlir] Remove LLVMType, LLVM dialect types now derive Type directly

This class has become a simple `isa` hook with no proper functionality.
Removing will allow us to eventually make the LLVM dialect type infrastructure
open, i.e., support non-LLVM types inside container types, which itself will
make the type conversion more progressive.

Introduce a call `LLVM::isCompatibleType` to be used instead of
`isa<LLVMType>`. For now, this is strictly equivalent.
END_PUBLIC

Depends On D93681

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D93713
2021-01-05 17:36:54 +01:00
Stella Laurenzo 8a1f1a100c [mlir][python] Aggressively avoid name collisions in generated python ODS code.
* When porting npcomp to use these bindings, I ran into enough patterns of collisions that I decided to be somewhat draconian about not polluting the namespace.
* With these changes all of the npcomp dialects generate and pass what tests we have.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D93920
2020-12-29 17:43:04 -08:00
Mehdi Amini 58ce477676 Fix DRR pattern when attributes and operands are interleaved and a dag subtree appears in the rewrite
This fixes an incorrect fatal error in TableGen. This code probably comes
from before attributes were allowed to interleave with operands in ODS.

Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D93915
2020-12-30 00:19:38 +00:00
Chris Lattner 9eb3e564d3 [ODS] Make the getType() method on a OneResult instruction return a specific type.
Implement Bug 46698, making ODS synthesize a getType() method that returns a
specific C++ class for OneResult methods where we know that class.  This eliminates
a common source of casts in things like:

   myOp.getType().cast<FIRRTLType>().getPassive()

because we know that myOp always returns a FIRRTLType.  This also encourages
op authors to type their results more tightly (which is also good for
verification).

I chose to implement this by splitting the OneResult trait into itself plus a
OneTypedResult trait, given that many things are using `hasTrait<OneResult>`
to conditionalize various logic.

While this changes makes many many ops get more specific getType() results, it
is generally drop-in compatible with the previous behavior because 'x.cast<T>()'
is allowed when x is already known to be a T.  The one exception to this is that
we need declarations of the types used by ops, which is why a couple headers
needed additional #includes.

I updated a few things in tree to remove the now-redundant `.cast<>`'s, but there
are probably many more than can be removed.

Differential Revision: https://reviews.llvm.org/D93790
2020-12-26 13:52:40 -08:00
Lei Zhang fc41777702 [mlir][spirv] De-template serialization
Previously for each op we generate a separate serialization
method for it. Those serialization methods duplicate the logic
of parsing operands/results/attributes and such.

This commit creates a generic method and let suitable op-specific
serialization method to call into it.

wc -l SPIRVSerialization.inc: before 8304; after: 5597 (So -2707)

Reviewed By: hanchung, ThomasRaoux

Differential Revision: https://reviews.llvm.org/D93535
2020-12-23 14:54:26 -05:00
Lei Zhang ae895ac4b9 [mlir][spirv] De-template deserialization
Previously for each op we generate a separate deserialization
method for it. Those deserialization methods duplicate the logic
of parsing operands/results/attributes and such.

This commit creates a generic method and let suitable op-specific
deserialization method to call into it.

wc -l SPIRVSerialization.inc: before 13290; after: 8304 (So -4986)

Reviewed By: hanchung, ThomasRaoux

Differential Revision: https://reviews.llvm.org/D93504
2020-12-23 14:45:46 -05: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
ergawy 1d0dc9be6d [MLIR][SPIRV] Add rewrite pattern to convert select+cmp into GLSL clamp.
Adds rewrite patterns to convert select+cmp instructions into clamp
instructions whenever possible. Support is added to convert:

- FOrdLessThan, FOrdLessThanEqual to GLSLFClampOp.
- SLessThan, SLessThanEqual to GLSLSClampOp.
- ULessThan, ULessThanEqual to GLSLUClampOp.

Reviewed By: mravishankar

Differential Revision: https://reviews.llvm.org/D93618
2020-12-23 15:47:19 +01:00
Christian Sigg df6cbd37f5 [mlir] Lower gpu.memcpy to GPU runtime calls.
Reviewed By: herhut

Differential Revision: https://reviews.llvm.org/D93204
2020-12-22 22:49:19 +01:00
Alex Zinenko 2f5569f6f6 [mlir] remove deprecated string-based OpBuilder from ODS
It has been deprecated with a warning for two months, removing.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D93623
2020-12-22 09:57:49 +01: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
River Riddle fc5cf50e89 [mlir] Remove the MutableDictionaryAttr class
This class used to serve a few useful purposes:
* Allowed containing a null DictionaryAttr
* Provided some simple mutable API around a DictionaryAttr

The first of which is no longer an issue now that there is much better caching support for attributes in general, and a cache in the context for empty dictionaries. The second results in more trouble than it's worth because it mutates the internal dictionary on every action, leading to a potentially large number of dictionary copies. NamedAttrList is a much better alternative for the second use case, and should be modified as needed to better fit it's usage as a DictionaryAttrBuilder.

Differential Revision: https://reviews.llvm.org/D93442
2020-12-17 17:18:42 -08: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
River Riddle 95019de8a1 [mlir][IR] Define the singleton builtin types in ODS instead of C++
This exposes several issues with the current generation that this revision also fixes.
 * TypeDef now allows specifying the base class to use when generating.
 * TypeDef now inherits from DialectType, which allows for using it as a TypeConstraint
 * Parser/Printers are now no longer generated in the header(removing duplicate symbols), and are now only generated when necessary.
    - Now that generatedTypeParser/Printer are only generated in the definition file,
      existing users will need to manually expose this functionality when necessary.
 * ::get() is no longer generated for singleton types, because it isn't necessary.

Differential Revision: https://reviews.llvm.org/D93270
2020-12-15 13:42:19 -08:00
River Riddle b3ee7f1f31 [mlir][OpDefGen] Add support for generating local functions for shared utilities
This revision adds a new `StaticVerifierFunctionEmitter` class that emits local static functions in the .cpp file for shared operation verification. This class deduplicates shared operation verification code by emitting static functions alongside the op definitions. These methods are local to the definition file, and are invoked within the operation verify methods. The first bit of shared verification is for the type constraints used when verifying operands and results. An example is shown below:

```
static LogicalResult localVerify(...) {
  ...
}

LogicalResult OpA::verify(...) {
  if (failed(localVerify(...)))
    return failure();
  ...
}

LogicalResult OpB::verify(...) {
  if (failed(localVerify(...)))
    return failure();
  ...
}
```

This allowed for saving >400kb of code size from a downstream TensorFlow project (~15% of MLIR code size).

Differential Revision: https://reviews.llvm.org/D91381
2020-12-14 14:21:30 -08:00
River Riddle c234b65cef [mlir][OpFormat] Add support for emitting newlines from the custom format of an operation
This revision adds a new `printNewline` hook to OpAsmPrinter that allows for printing a newline within the custom format of an operation, that is then indented to the start of the operation. Support for the declarative assembly format is also added, in the form of a `\n` literal.

Differential Revision: https://reviews.llvm.org/D93151
2020-12-14 12:00:43 -08:00
Christian Sigg a1eb154421 [flang] Use mlir::OpState::operator->() to get to methods of mlir::Operation.
This is a preparation step to remove those methods from OpState.

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D93194
2020-12-14 20:04:53 +01:00
Christian Sigg 1ffc1aaa09 [mlir] Use mlir::OpState::operator->() to get to methods of mlir::Operation.
This is a preparation step to remove those methods from OpState.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D93098
2020-12-13 09:58:16 +01:00
Brian Gesiak 09b0e0884a [mlir] Print bad size in AttrSizedOperandSegments
When printing verification errors for ops with the incorrect number of
operand segments, print the required number as well as the actual
number. Split off from D93005.

Differential Revision: https://reviews.llvm.org/D93145
2020-12-12 13:12:31 -05:00
Christian Sigg 0bf4a82a5a [mlir] Use mlir::OpState::operator->() to get to methods of mlir::Operation. This is a preparation step to remove the corresponding methods from OpState.
Reviewed By: silvas, rriddle

Differential Revision: https://reviews.llvm.org/D92878
2020-12-09 12:11:32 +01:00
River Riddle 7924fb34f3 [mlir][OpFormatGen] Add support for optional enum attributes
The check for formatting enum attributes was missing a call to get the base attribute, which is necessary to strip off the top-level OptionalAttr<> wrapper.

Differential Revision: https://reviews.llvm.org/D92713
2020-12-04 21:00:44 -08:00
Rahul Joshi fe7fdcac87 [MLIR] Fix parseFunctionLikeOp() to fail parsing empty regions
- Change parseOptionalRegion to return an OptionalParseResult.
- Change parseFunctionLikeOp() to fail parsing if the function body was parsed but was
  empty.
- See https://llvm.discourse.group/t/funcop-parsing-bug/2164

Differential Revision: https://reviews.llvm.org/D91886
2020-12-04 09:09:59 -08:00
Rahul Joshi 245233423e [MLIR] Generate inferReturnTypes declaration using InferTypeOpInterface trait.
- Instead of hardcoding the parameters and return types of 'inferReturnTypes', use the
  InferTypeOpInterface trait to generate the method declaration.
- Fix InferTypeOfInterface to use fully qualified type for inferReturnTypes results.

Differential Revision: https://reviews.llvm.org/D92585
2020-12-04 09:05:53 -08:00
David Blaikie 30b1ae5916 [mlir] Make conversion functions inline instead of static to avoid -Wunused-function 2020-12-03 13:09:36 -08:00
Paul C. Anagnostopoulos 415fab6f67 [TableGen] Eliminate the 'code' type
Update the documentation.

Rework various backends that relied on the code type.

Differential Revision: https://reviews.llvm.org/D92269
2020-12-03 10:19:11 -05:00
Christian Sigg c4a0405902 Add `Operation* OpState::operator->()` to provide more convenient access to members of Operation.
Given that OpState already implicit converts to Operator*, this seems reasonable.

The alternative would be to add more functions to OpState which forward to Operation.

Reviewed By: rriddle, ftynse

Differential Revision: https://reviews.llvm.org/D92266
2020-12-02 15:46:20 +01:00
River Riddle abfd1a8b3b [mlir][PDL] Add support for PDL bytecode and expose PDL support to OwningRewritePatternList
PDL patterns are now supported via a new `PDLPatternModule` class. This class contains a ModuleOp with the pdl::PatternOp operations representing the patterns, as well as a collection of registered C++ functions for native constraints/creations/rewrites/etc. that may be invoked via the pdl patterns. Instances of this class are added to an OwningRewritePatternList in the same fashion as C++ RewritePatterns, i.e. via the `insert` method.

The PDL bytecode is an in-memory representation of the PDL interpreter dialect that can be efficiently interpreted/executed. The representation of the bytecode boils down to a code array(for opcodes/memory locations/etc) and a memory buffer(for storing attributes/operations/values/any other data necessary). The bytecode operations are effectively a 1-1 mapping to the PDLInterp dialect operations, with a few exceptions in cases where the in-memory representation of the bytecode can be more efficient than the MLIR representation. For example, a generic `AreEqual` bytecode op can be used to represent AreEqualOp, CheckAttributeOp, and CheckTypeOp.

The execution of the bytecode is split into two phases: matching and rewriting. When matching, all of the matched patterns are collected to avoid the overhead of re-running parts of the matcher. These matched patterns are then considered alongside the native C++ patterns, which rewrite immediately in-place via `RewritePattern::matchAndRewrite`,  for the given root operation. When a PDL pattern is matched and has the highest benefit, it is passed back to the bytecode to execute its rewriter.

Differential Revision: https://reviews.llvm.org/D89107
2020-12-01 15:05:50 -08:00
Rahul Joshi 6b043ecdb7 [MLIR] Fix genTypeInterfaceMethods() to work correctly with InferTypeOpInterface
- Change InferTypeOpInterface::inferResultTypes to use fully qualified types matching
  the ones generated by genTypeInterfaceMethods, so the redundancy can be detected.
- Move genTypeInterfaceMethods() before genOpInterfaceMethods() so that the
  inferResultTypes method generated by genTypeInterfaceMethods() takes precedence
  over the declaration that might be generated by genOpInterfaceMethods()
- Modified an op in the test dialect to exercise this (the modified op would fail to
  generate valid C++ code due to duplicate inferResultTypes methods).

Differential Revision: https://reviews.llvm.org/D92414
2020-12-01 13:36:25 -08:00
Ray (I-Jui) Sung ff2e22853f Don't count attributes when addressing operands.
Fixes out-of-bound access in generated nested DAG rewriter matching code.

Reviewed By: tpopp

Differential Revision: https://reviews.llvm.org/D92075
2020-12-01 01:21:36 +00:00
Nicolas Vasilache 78c7118746 [mlir] Make mlir-cpu-runner depend on native instead of X86 2020-11-30 15:11:34 +00:00
Nicolas Vasilache 047400ed82 [mlir][LLVMIR] Add support for InlineAsmOp
The InlineAsmOp mirrors the underlying LLVM semantics with a notable
exception: the embedded `asm_string` is not allowed to define or reference
any symbol or any global variable: only the operands of the op may be read,
written, or referenced.
Attempting to define or reference any symbol or any global behavior is
considered undefined behavior at this time.

The asm dialect syntax is currently specified with an integer (0 [default] for the "att dialect", 1 for the intel dialect) to circumvent the ODS limitation on string enums.

Translation to LLVM is provided and raises the fact that the asm constraints string must be well-formed with respect to in/out operands. No check is performed on the asm_string.

An InlineAsm instruction in LLVM is a special call operation to a function that is constructed on the fly.
It does not fit the current model of MLIR calls with symbols.
As a consequence, the current implementation constructs the function type in ModuleTranslation.cpp.
This should be refactored in the future.

The mlir-cpu-runner is augmented with the global initialization of the X86 asm parser to allow proper execution in JIT mode. Previously, only the X86 asm printer was initialized.

Differential revision: https://reviews.llvm.org/D92166
2020-11-30 08:32:02 +00:00
Jacques Pienaar e534cee26a [mlir] Add a shape function library op
Op with mapping from ops to corresponding shape functions for those op
in the library and mechanism to associate shape functions to functions.
The mapping of operand to shape function is kept separate from the shape
functions themselves as the operation is associated to the shape
function and not vice versa, and one could have a common library of
shape functions that can be used in different contexts.

Use fully qualified names and require a name for shape fn lib ops for
now and an explicit print/parse (based around the generated one & GPU
module op ones).

This commit reverts d9da4c3e73. Fixes
missing headers (don't know how that was working locally).

Differential Revision: https://reviews.llvm.org/D91672
2020-11-29 11:15:30 -08:00
Mehdi Amini d9da4c3e73 Revert "[mlir] Add a shape function library op"
This reverts commit 6dd9596b19.

Build is broken.
2020-11-29 05:28:42 +00:00
Jacques Pienaar 6dd9596b19 [mlir] Add a shape function library op
Op with mapping from ops to corresponding shape functions for those op
in the library and mechanism to associate shape functions to functions.
The mapping of operand to shape function is kept separate from the shape
functions themselves as the operation is associated to the shape
function and not vice versa, and one could have a common library of
shape functions that can be used in different contexts.

Use fully qualified names and require a name for shape fn lib ops for
now and an explicit print/parse (based around the generated one & GPU
module op ones).

Differential Revision: https://reviews.llvm.org/D91672
2020-11-28 15:53:59 -08:00
Christian Sigg 5535696c38 [mlir] Add gpu.allocate, gpu.deallocate ops with LLVM lowering to runtime function calls.
The ops are very similar to the std variants, but support async GPU execution.

gpu.alloc does not currently support an alignment attribute, and the new ops do not have
canonicalizers/folders like their std siblings do.

Reviewed By: herhut

Differential Revision: https://reviews.llvm.org/D91698
2020-11-27 09:40:59 +01:00
Ulysse Beaugnon 1eded173a9 [MLIR] Fix TableGen generator for attribute interfaces.
Use the correct interface base type name when generating attribute interfaces
with TabeGen.

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D92023
2020-11-24 14:06:35 +01:00
Alex Zinenko 029e199dbf [mlir] Make attributes mutable in Python bindings
Attributes represent additional data about an operation and are intended to be
modifiable during the lifetime of the operation. In the dialect-specific Python
bindings, attributes are exposed as properties on the operation class. Allow
for assigning values to these properties. Also support creating new and
deleting existing attributes through the generic "attributes" property of an
operation. Any validity checking must be performed by the op verifier after the
mutation, similarly to C++. Operations are not invalidated in the process: no
dangling pointers can be created as all attributes are owned by the context and
will remain live even if they are not used in any operation.

Introduce a Python Test dialect by analogy with the Test dialect and to avoid
polluting the latter with Python-specific constructs. Use this dialect to
implement a test for the attribute access and mutation API.

Reviewed By: stellaraccident, mehdi_amini

Differential Revision: https://reviews.llvm.org/D91652
2020-11-24 09:16:25 +01:00
MaheshRavishankar e65a5e5b00 [mlir][Linalg] Fuse sequence of Linalg operation (on buffers)
Enhance the tile+fuse logic to allow fusing a sequence of operations.

Make sure the value used to obtain tile shape is a
SubViewOp/SubTensorOp. Current logic used to get the bounds of loop
depends on the use of `getOrCreateRange` method on `SubViewOp` and
`SubTensorOp`. Make sure that the value/dim used to compute the range
is from such ops.  This fix is a reasonable WAR, but a btter fix would
be to make `getOrCreateRange` method be a method of `ViewInterface`.

Differential Revision: https://reviews.llvm.org/D90991
2020-11-23 10:30:51 -08:00
John Demme 95956c1c9a [MLIR] ODS typedef gen fixes & improvements
- Fixes bug 48242 point 3 crash.
- Makes the improvments from points 1 & 2.

https://bugs.llvm.org/show_bug.cgi?id=48262

```
   def RTLValueType : Type<CPred<"isRTLValueType($_self)">, "Type"> {
     string cppType = "::mlir::Type";
   }
```
Works now, but merely by happenstance. Parameters expects a `TypeParameter` class def or a string representing a c++ type but doesn't enforce it.

Reviewed By: lattner

Differential Revision: https://reviews.llvm.org/D91939
2020-11-22 16:06:14 -08:00
Mikhail Goncharov 0caa82e2ac Revert "[mlir][Linalg] Fuse sequence of Linalg operation (on buffers)"
This reverts commit f8284d21a8.

Revert "[mlir][Linalg] NFC: Expose some utility functions used for promotion."

This reverts commit 0c59f51592.

Revert "Remove unused isZero function"

This reverts commit 0f9f0a4046.

Change f8284d21 led to multiple failures in IREE compilation.
2020-11-20 13:12:54 +01:00
MaheshRavishankar f8284d21a8 [mlir][Linalg] Fuse sequence of Linalg operation (on buffers)
Enhance the tile+fuse logic to allow fusing a sequence of operations.

Differential Revision: https://reviews.llvm.org/D90991
2020-11-19 19:03:06 -08:00
River Riddle 65fcddff24 [mlir][BuiltinDialect] Resolve comments from D91571
* Move ops to a BuiltinOps.h
* Add file comments
2020-11-19 11:12:49 -08:00
Lei Zhang 9e39a5d9a6 [mlir][linalg] Start a named ops to generic ops pass
This commit starts a new pass and patterns for converting Linalg
named ops to generic ops. This enables us to leverage the flexbility
from generic ops during transformations. Right now only linalg.conv
is supported; others will be added when useful.

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D91357
2020-11-19 09:21:06 -05:00
Ji Kim 58ce4a8b11 [mlir][TableGen] Support intrinsics with multiple returns and overloaded operands.
For intrinsics with multiple returns where one or more operands are overloaded, the overloaded type is inferred from the corresponding field of the resulting struct, instead of accessing the result directly.

As such, the hasResult parameter of LLVM_IntrOpBase (and derived classes) is replaced with numResults. TableGen for intrinsics also updated to populate this field with the total number of results.

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D91680
2020-11-19 09:59:42 +01:00
River Riddle c0958b7b4c [mlir] Add support for referencing a SymbolRefAttr in a SideEffectInstance
This allows for operations that exclusively affect symbol operations to better describe their side effects.

Differential Revision: https://reviews.llvm.org/D91581
2020-11-18 18:38:43 -08:00
Aart Bik eced4a8e6f [mlir] [sparse] start of sparse tensor compiler support
As discussed in https://llvm.discourse.group/t/mlir-support-for-sparse-tensors/2020
this CL is the start of sparse tensor compiler support in MLIR. Starting with a
"dense" kernel expressed in the Linalg dialect together with per-dimension
sparsity annotations on the tensors, the compiler automatically lowers the
kernel to sparse code using the methods described in Fredrik Kjolstad's thesis.

Many details are still TBD. For example, the sparse "bufferization" is purely
done locally since we don't have a global solution for propagating sparsity
yet. Furthermore, code to input and output the sparse tensors is missing.
Nevertheless, with some hand modifications, the generated MLIR can be
easily converted into runnable code already.

Reviewed By: nicolasvasilache, ftynse

Differential Revision: https://reviews.llvm.org/D90994
2020-11-17 13:10:42 -08:00
Alex Zinenko f3dab16dc7 [mlir] Add a _get_default_loc_context utility to Python bindings
This utility function is helpful for dialect-specific builders that need
to access the context through location, and the location itself may be
either provided as an argument or expected to be recovered from the
implicit location stack.

Reviewed By: stellaraccident

Differential Revision: https://reviews.llvm.org/D91623
2020-11-17 17:55:47 +01:00
Alex Zinenko 88f25bda13 [mlir] Allow for using interface class name in ODS interface definitions
It may be necessary for interface methods to process or return variables with
the interface class type, in particular for attribute and type interfaces that
can return modified attributes and types that implement the same interface.
However, the code generated by ODS in this case would not compile because the
signature (and the body if provided) appear in the definition of the Model
class and before the interface class, which derives from the Model. Change the ODS
interface method generator to emit only method declarations in the Model class
itself, and emit method definitions after the interface class. Mark as "inline"
since their definitions are still emitted in the header and are no longer
implicitly inline. Add a forward declaration of the interface class before the
Concept+Model classes to make the class name usable in declarations.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D91499
2020-11-17 14:28:55 +01:00
Alex Zinenko c5a6712f8c [mlir] Add basic support for attributes in ODS-generated Python bindings
In ODS, attributes of an operation can be provided as a part of the "arguments"
field, together with operands. Such attributes are accepted by the op builder
and have accessors generated.

Implement similar functionality for ODS-generated op-specific Python bindings:
the `__init__` method now accepts arguments together with operands, in the same
order as in the ODS `arguments` field; the instance properties are introduced
to OpView classes to access the attributes.

This initial implementation accepts and returns instances of the corresponding
attribute class, and not the underlying values since the mapping scheme of the
value types between C++, C and Python is not yet clear. Default-valued
attributes are not supported as that would require Python to be able to parse
C++ literals.

Since attributes in ODS are tightely related to the actual C++ type system,
provide a separate Tablegen file with the mapping between ODS storage type for
attributes (typically, the underlying C++ attribute class), and the
corresponding class name. So far, this might look unnecessary since all names
match exactly, but this is not necessarily the cases for non-standard,
out-of-tree attributes, which may also be placed in non-default namespaces or
Python modules. This also allows out-of-tree users to generate Python bindings
without having to modify the bindings generator itself. Storage type was
preferred over the Tablegen "def" of the attribute class because ODS
essentially encodes attribute _constraints_ rather than classes, e.g. there may
be many Tablegen "def"s in the ODS that correspond to the same attribute type
with additional constraints

The presence of the explicit mapping requires the change in the .td file
structure: instead of just calling the bindings generator directly on the main
ODS file of the dialect, it becomes necessary to create a new file that
includes the main ODS file of the dialect and provides the mapping for
attribute types. Arguably, this approach offers better separability of the
Python bindings in the build system as the main dialect no longer needs to know
that it is being processed by the bindings generator.

Reviewed By: stellaraccident

Differential Revision: https://reviews.llvm.org/D91542
2020-11-17 11:47:37 +01:00
River Riddle 73ca690df8 [mlir][NFC] Remove references to Module.h and Function.h
These includes have been deprecated in favor of BuiltinDialect.h, which contains the definitions of ModuleOp and FuncOp.

Differential Revision: https://reviews.llvm.org/D91572
2020-11-17 00:55:47 -08:00
Sean Silva 7c62c6313b [mlir] Add DecomposeCallGraphTypes pass.
This replaces the old type decomposition logic that was previously mixed
into bufferization, and makes it easily accessible.

This also deletes TestFinalizingBufferize, because after we remove the type
decomposition, it doesn't do anything that is not already provided by
func-bufferize.

Differential Revision: https://reviews.llvm.org/D90899
2020-11-16 12:25:35 -08:00
Jean-Michel Gorius e47805c995 [mlir] Add plus, star and optional less/greater parsing
The tokens are already handled by the lexer. This revision exposes them
through the parser interface.

This revision also adds missing functions for question mark parsing and
completes the list of valid punctuation tokens in the documentation.

Differential Revision: https://reviews.llvm.org/D90907
2020-11-12 13:28:31 +01:00
Alex Zinenko f9265de8c6 [mlir] Generate Op builders for Python bindings
Add an ODS-backed generator of default builders. This currently does not
support operation with attribute arguments, for which the builder is
just ignored. Attribute support will be introduced separately for
builders and accessors.

Default builders are always generated with the same number of result and
operand groups as the ODS specification, i.e. one group per each operand
or result. Optional elements accept None but cannot be omitted. Variadic
groups accept iterable objects and cannot be replaced with a single
object.

For some operations, it is possible to infer the result type given the
traits, but most traits rely on inline pieces of C++ that we cannot
(yet) forward to Python bindings. Since the Ops where the inference is
possible (having the `SameOperandAndResultTypes` trait or
`TypeMatchesWith` without transform field) are a small minority, they
also require the result type to make the builder syntax more consistent.

Reviewed By: stellaraccident

Differential Revision: https://reviews.llvm.org/D91190
2020-11-12 11:29:23 +01:00
Eugene Zhulenev bb0d5f767d [mlir] Add NumberOfExecutions analysis + update RegionBranchOpInterface interface to query number of region invocations
Implements RFC discussed in: https://llvm.discourse.group/t/rfc-operationinstancesinterface-or-any-better-name/2158/10

Reviewed By: silvas, ftynse, rriddle

Differential Revision: https://reviews.llvm.org/D90922
2020-11-11 01:43:17 -08:00
Christian Sigg 3307a7c046 [mlir][gpu] Add missing initialization of gpu runtime wrappers.
Reviewed By: herhut

Differential Revision: https://reviews.llvm.org/D91148
2020-11-11 10:34:21 +01:00
Christian Sigg 5dfe6545d4 [mlir] Allow omitting spaces in assemblyFormat with a `` literal.
I would like to use this for D90589 to switch std.alloc to assemblyFormat.
Hopefully it will be useful in other places as well.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D91068
2020-11-11 09:34:43 +01:00
Mehdi Amini dc43f78565 Add basic Python bindings for the PassManager and bind libTransforms
This only exposes the ability to round-trip a textual pipeline at the
moment.
To exercise it, we also bind the libTransforms in a new Python extension. This
does not include any interesting bindings, but it includes all the
mechanism to add separate native extensions and load them dynamically.
As such passes in libTransforms are only registered after `import
mlir.transforms`.
To support this global registration, the TableGen backend is also
extended to bind to the C API the group registration for passes.

Reviewed By: stellaraccident

Differential Revision: https://reviews.llvm.org/D90819
2020-11-10 19:55:21 +00:00
Alex Zinenko fd407e1f1e [mlir] ODS-backed python binding generator for custom op classes
Introduce an ODS/Tablegen backend producing Op wrappers for Python bindings
based on the ODS operation definition. Usage:

  mlir-tblgen -gen-python-op-bindings -Iinclude <path/to/Ops.td> \
              -bind-dialect=<dialect-name>

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D90960
2020-11-10 10:58:29 +01:00
Alexander Belyaev 9d02e0e38d [mlir][std] Add ExpandOps pass.
The pass combines patterns of ExpandAtomic, ExpandMemRefReshape,
StdExpandDivs passes. The pass is meant to legalize STD for conversion to LLVM.

Differential Revision: https://reviews.llvm.org/D91082
2020-11-09 21:58:28 +01:00
Stella Laurenzo 08c1a0dda4 [mlir][CAPI] Proposal: Always building a libMLIRPublicAPI.so (re-apply).
Re-applies the reverted https://reviews.llvm.org/D90824 now that the link issue on BFD has been resolved.

This reverts commit bb9b5d3971.

Differential Revision: https://reviews.llvm.org/D91044
2020-11-08 16:57:51 -08:00
Stella Laurenzo 86b011777e Remove TOSA test passes from non test registration.
* Wires them in the same way that peer-dialect test passes are registered.
* Fixes the build for -DLLVM_INCLUDE_TESTS=OFF.

Differential Revision: https://reviews.llvm.org/D91022
2020-11-07 18:34:11 -08:00
Alex Zinenko bb9b5d3971 Revert "[mlir][CAPI] Proposal: Always building a libMLIRPublicAPI.so."
This reverts commit 80fe2f61fa.

Broke linkage with GNU ld. See original review thread for more details.
2020-11-06 18:59:58 +01:00
Stella Laurenzo 80fe2f61fa [mlir][CAPI] Proposal: Always building a libMLIRPublicAPI.so.
We were discussing on discord regarding the need for extension-based systems like Python to dynamically link against MLIR (or else you can only have one extension that depends on it). Currently, when I set that up, I piggy-backed off of the flag that enables build libLLVM.so and libMLIR.so and depended on libMLIR.so from the python extension if shared library building was enabled. However, this is less than ideal.

In the current setup, libMLIR.so exports both all symbols from the C++ API and the C-API. The former is a kitchen sink and the latter is curated. We should be splitting them and for things that are properly factored to depend on the C-API, they should have the option to *only* depend on the C-API, and we should build that shared library no matter what. Its presence isn't just an optimization: it is a key part of the system.

To do this right, I needed to:

* Introduce visibility macros into mlir-c/Support.h. These should work on both *nix and windows as-is.
* Create a new libMLIRPublicAPI.so with just the mlir-c object files.
* Compile the C-API with -fvisibility=hidden.
* Conditionally depend on the libMLIR.so from libMLIRPublicAPI.so if building libMLIR.so (otherwise, also links against the static libs and will produce a mondo libMLIRPublicAPI.so).
* Disable re-exporting of static library symbols that come in as transitive deps.

This gives us a dynamic linked C-API layer that is minimal and should work as-is on all platforms. Since we don't support libMLIR.so building on Windows yet (and it is not very DLL friendly), this will fall back to a mondo build of libMLIRPublicAPI.so, which has its uses (it is also the most size conscious way to go if you happen to know exactly what you need).

Sizes (release/stripped, Ubuntu 20.04):

Shared library build:
	libMLIRPublicAPI.so: 121Kb
	_mlir.cpython-38-x86_64-linux-gnu.so: 1.4Mb
	mlir-capi-ir-test: 135Kb
	libMLIR.so: 21Mb

Static build:
	libMLIRPublicAPI.so: 5.5Mb (since this is a "static" build, this includes the MLIR implementation as non-exported code).
	_mlir.cpython-38-x86_64-linux-gnu.so: 1.4Mb
	mlir-capi-ir-test: 44Kb

Things like npcomp and circt which bring their own dialects/transforms/etc would still need the shared library build and code that links against libMLIR.so (since it is all C++ interop stuff), but hopefully things that only depend on the public C-API can just have the one narrow dep.

I spot checked everything with nm, and it looks good in terms of what is exporting/importing from each layer.

I'm not in a hurry to land this, but if it is controversial, I'll probably split off the Support.h and API visibility macro changes, since we should set that pattern regardless.

Reviewed By: mehdi_amini, benvanik

Differential Revision: https://reviews.llvm.org/D90824
2020-11-06 09:00:56 -08:00
Sean Silva f7bc568266 [mlir] Remove AppendToArgumentsList functionality from BufferizeTypeConverter.
This functionality is superceded by BufferResultsToOutParams pass (see
https://reviews.llvm.org/D90071) for users the require buffers to be
out-params. That pass should be run immediately after all tensors are gone from
the program (before buffer optimizations and deallocation insertion), such as
immediately after a "finalizing" bufferize pass.

The -test-finalizing-bufferize pass now defaults to what used to be the
`allowMemrefFunctionResults=true` flag. and the
finalizing-bufferize-allowed-memref-results.mlir file is moved
to test/Transforms/finalizing-bufferize.mlir.

Differential Revision: https://reviews.llvm.org/D90778
2020-11-05 11:20:09 -08:00
Alexander Belyaev d413f4bc62 [mlir] Fix missing namespaces in OpBuildGen.cpp
Differential Revision: https://reviews.llvm.org/D90858
2020-11-05 18:11:01 +01:00
Alexander Belyaev 72c65b698e [mlir] Move TestDialect and its passes to mlir::test namespace.
TestDialect has many operations and they all live in ::mlir namespace.
Sometimes it is not clear whether the ops used in the code for the test passes
belong to Standard or to Test dialects.

Also, with this change it is easier to understand what test passes registered
in mlir-opt are actually passes in mlir/test.

Differential Revision: https://reviews.llvm.org/D90794
2020-11-05 15:29:15 +01:00
Nicolas Vasilache ecca7852d9 [mlir][Linalg] Side effects interface for Linalg ops
The LinalgDependenceGraph and alias analysis provide the necessary analysis for the Linalg fusion on buffers case.

However this is not enough for linalg on tensors which require proper memory effects to play nicely with DCE and other transformations.
This revision adds side effects to Linalg ops that were previously missing and has 2 consequences:
1. one example in the copy removal pass now fails since the linalg.generic op has side effects and the pass does not perform alias analysis / distinguish between reads and writes.
2. a few examples in fusion-tensor.mlir need to return the resulting tensor otherwise DCE automatically kicks in as part of greedy pattern application.

Differential Revision: https://reviews.llvm.org/D90762
2020-11-05 09:00:28 +00:00
Mehdi Amini aeb4b1a9d8 Add facilities to print/parse a pass pipeline through the C API
This also includes and exercise a register function for individual
passes.

Differential Revision: https://reviews.llvm.org/D90728
2020-11-04 17:29:49 +00:00
Mehdi Amini f61d1028fa Add a basic C API for the MLIR PassManager as well as a basic TableGen backend for creating passes
This is exposing the basic functionalities (create, nest, addPass, run) of
the PassManager through the C API in the new header: `include/mlir-c/Pass.h`.

In order to exercise it in the unit-test, a basic TableGen backend is
also provided to generate a simple C wrapper around the pass
constructor. It is used to expose the libTransforms passes to the C API.

Reviewed By: stellaraccident, ftynse

Differential Revision: https://reviews.llvm.org/D90667
2020-11-04 06:36:31 +00:00
Sean Silva 773ad135a3 [mlir][Bufferize] Rename TestBufferPlacement to TestFinalizingBufferize
BufferPlacement is no longer part of bufferization. However, this test
is an important test of "finalizing" bufferize passes.
A "finalizing" bufferize conversion is one that performs a "full"
conversion and expects all tensors to be gone from the program. This in
particular involves rewriting funcs (including block arguments of the
contained region), calls, and returns. The unique property of finalizing
bufferization passes is that they cannot be done via a local
transformation with suitable materializations to ensure composability
(as other bufferization passes do). For example, if a call is
rewritten, the callee needs to be rewritten otherwise the IR will end up
invalid. Thus, finalizing bufferization passes require an atomic change
to the entire program (e.g. the whole module).

This new designation makes it clear also that it shouldn't be testing
bufferization of linalg ops, so the tests have been updated to not use
linalg.generic ops. (linalg.copy is still used as the "copy" op for
copying into out-params)

Differential Revision: https://reviews.llvm.org/D89979
2020-11-02 12:42:32 -08:00
ergawy 90a8260cb4 [MLIR][SPIRV] Start module combiner.
This commit adds a new library that merges/combines a number of spv
modules into a combined one. The library has a single entry point:
combine(...).

To combine a number of MLIR spv modules, we move all the module-level ops
from all the input modules into one big combined module. To that end, the
combination process can proceed in 2 phases:

  (1) resolving conflicts between pairs of ops from different modules
  (2) deduplicate equivalent ops/sub-ops in the merged module. (TODO)

This patch implements only the first phase.

Reviewed By: antiagainst

Differential Revision: https://reviews.llvm.org/D90477
2020-10-30 16:55:43 -04:00
Geoffrey Martin-Noble 1142eaed9d Revert "[MLIR][SPIRV] Start module combiner."
This reverts commit 27324f2855.

Shared libs build is broken linking lib/libMLIRSPIRVModuleCombiner.so:

```
ModuleCombiner.cpp:
  undefined reference to `mlir::spirv::ModuleOp::addressing_model()
```

https://buildkite.com/mlir/mlir-core/builds/8988#e3d966b9-ea43-492e-a192-b28e71e9a15b
2020-10-30 13:34:15 -07:00
ergawy 27324f2855 [MLIR][SPIRV] Start module combiner.
This commit adds a new library that merges/combines a number of spv
modules into a combined one. The library has a single entry point:
combine(...).

To combine a number of MLIR spv modules, we move all the module-level ops
from all the input modules into one big combined module. To that end, the
combination process can proceed in 2 phases:

  (1) resolving conflicts between pairs of ops from different modules
  (2) deduplicate equivalent ops/sub-ops in the merged module. (TODO)

This patch implements only the first phase.

Reviewed By: antiagainst

Differential Revision: https://reviews.llvm.org/D90477
2020-10-30 14:58:17 -04:00
Mehdi Amini b3430ed05f Revert "[MLIR][SPIRV] Start module combiner"
This reverts commit 316593ce83.
Build is broken with:

TestModuleCombiner.cpp:(.text._ZN12_GLOBAL__N_122TestModuleCombinerPass14runOnOperationEv+0x195): undefined reference to `mlir::spirv::combine(llvm::MutableArrayRef<mlir::spirv::ModuleOp>, mlir::OpBuilder&, llvm::function_ref<void (mlir::spirv::ModuleOp, llvm::StringRef, llvm::StringRef)>)'
2020-10-30 15:09:21 +00:00
ergawy 316593ce83 [MLIR][SPIRV] Start module combiner
This commit adds a new library that merges/combines a number of spv
modules into a combined one. The library has a single entry point:
combine(...).

To combine a number of MLIR spv modules, we move all the module-level ops
from all the input modules into one big combined module. To that end, the
combination process can proceed in 2 phases:

  (1) resolving conflicts between pairs of ops from different modules
  (2) deduplicate equivalent ops/sub-ops in the merged module. (TODO)

This patch implements only the first phase.

Reviewed By: antiagainst

Differential Revision: https://reviews.llvm.org/D90022
2020-10-30 09:37:28 -04:00
Nicolas Vasilache 9b17bf2e54 [mlir][Linalg] Make Linalg fusion a test pass
Linalg "tile-and-fuse" is currently exposed as a Linalg pass "-linalg-fusion" but only the mechanics of the transformation are currently relevant.
Instead turn it into a "-test-linalg-greedy-fusion" pass which performs canonicalizations to enable more fusions to compose.
This allows dropping the OperationFolder which is not meant to be used with the pattern rewrite infrastructure.

Differential Revision: https://reviews.llvm.org/D90394
2020-10-29 15:18:51 +00:00
Christian Sigg 97b351a827 [mlir][gpu] Fix leaked stream and module when lowering gpu.launch_func to runtime calls.
Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D90370
2020-10-29 08:40:51 +01:00
Alexander Belyaev 7a996027b9 [mlir] Convert memref_reshape to memref_reinterpret_cast.
Differential Revision: https://reviews.llvm.org/D90235
2020-10-28 21:15:32 +01:00
Kazuaki Ishizaki 41b09f4eff [mlir] NFC: fix trivial typos
fix typos in comments and documents

Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D90089
2020-10-29 04:05:22 +09:00
John Demme 035e12e664 [MLIR] [ODS] Allowing attr-dict in custom directive
Enhance tblgen's declarative assembly format to allow `attr-dict` in
custom directives.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D89772
2020-10-28 01:24:16 +00:00
Eugene Zhulenev a297340d9e [mlir] Fix stack-use-after-scope in cuda/vulkan cpu runners
+fix rocm runner

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D90274
2020-10-27 17:26:08 -07:00
River Riddle ef728eaf6e [mlir][Interfaces] Generate a struct containing function pointers instead of a class with vtables
When compiling for code size, the use of a vtable causes a destructor(and constructor in certain cases) to be generated for the class. Interface models don't need a complex constructor or a destructor, so this can lead to many megabytes of code size increase(even in opt). This revision switches to a simpler struct of function pointers approach that accomplishes the same API requirements as before. This change requires no updates to user code, or any other code aside from the generator, as the user facing API is still exactly the same.

Differential Revision: https://reviews.llvm.org/D90085
2020-10-27 16:16:51 -07:00
Eugene Zhulenev f6c9f6eccd [mlir] JitRunner: add a config option to register symbols with ExecutionEngine at runtime
Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D90264
2020-10-27 15:57:34 -07:00
Alex Zinenko 89eab30e5c [mlir] use OpBuilderDAG instead of OpBuilder
A recent commit introduced a new syntax for specifying builder arguments in
ODS, which is better amenable to automated processing, and deprecated the old
form. Transition all dialects as well as Linalg ODS generator to use the new
syntax.

Add a deprecation notice to ODS generator.

Reviewed By: rriddle, jpienaar

Differential Revision: https://reviews.llvm.org/D90038
2020-10-27 10:21:49 +01:00
George Mitenkov 89808ce734 [MLIR][mlir-spirv-cpu-runner] A SPIR-V cpu runner prototype
This patch introduces a SPIR-V runner. The aim is to run a gpu
kernel on a CPU via GPU -> SPIRV -> LLVM conversions. This is a first
prototype, so more features will be added in due time.

- Overview
The runner follows similar flow as the other runners in-tree. However,
having converted the kernel to SPIR-V, we encode the bind attributes of
global variables that represent kernel arguments. Then SPIR-V module is
converted to LLVM. On the host side, we emulate passing the data to device
by creating in main module globals with the same symbolic name as in kernel
module. These global variables are later linked with ones from the nested
module. We copy data from kernel arguments to globals, call the kernel
function from nested module and then copy the data back.

- Current state
At the moment, the runner is capable of running 2 modules, nested one in
another. The kernel module must contain exactly one kernel function. Also,
the runner supports rank 1 integer memref types as arguments (to be scaled).

- Enhancement of JitRunner and ExecutionEngine
To translate nested modules to LLVM IR, JitRunner and ExecutionEngine were
altered to take an optional (default to `nullptr`) function reference that
is a custom LLVM IR module builder. This allows to customize LLVM IR module
creation from MLIR modules.

Reviewed By: ftynse, mravishankar

Differential Revision: https://reviews.llvm.org/D86108
2020-10-26 09:09:29 -04:00
Mehdi Amini 4bde9aa964 Add CMake dependency from MLIRJitRunner on all dialects
This dependency was already existing indirectly, but is now more direct
since the registration relies on a inline function. This fixes the
link of the tools with BFD.
2020-10-24 01:24:05 +00:00
Mehdi Amini e7021232e6 Remove global dialect registration
This has been deprecated for >1month now and removal was announced in:

https://llvm.discourse.group/t/rfc-revamp-dialect-registration/1559/11

Differential Revision: https://reviews.llvm.org/D86356
2020-10-24 00:35:55 +00:00
Mehdi Amini 3a4b832b1b Topologically sort the library to link to mlir-cpu-runner which is required with some linkers like BFD (NFC) 2020-10-24 00:35:55 +00:00
Mehdi Amini 6a72635881 Revert "Remove global dialect registration"
This reverts commit b22e2e4c6e.

Investigating broken builds
2020-10-23 21:26:48 +00:00
Mehdi Amini b22e2e4c6e Remove global dialect registration
This has been deprecated for >1month now and removal was announced in:

https://llvm.discourse.group/t/rfc-revamp-dialect-registration/1559/11

Differential Revision: https://reviews.llvm.org/D86356
2020-10-23 20:41:44 +00:00
Alex Zinenko 6ec3872845 [mlir] ODS: support TableGen dag objects to specify OpBuilder parameters
Historically, custom builder specification in OpBuilder has been accepting the
formal parameter list for the builder method as a raw string containing C++.
While this worked well to connect the signature and the body, this became
problematic when ODS needs to manipulate the parameter list, e.g. to inject
OpBuilder or to trim default values when generating the definition. This has
also become inconsistent with other method declarations, in particular in
interface definitions.

Introduce the possibility to define OpBuilder formal parameters using a
TableGen dag similarly to other methods. Additionally, introduce a mechanism to
declare parameters with default values using an additional class. This
mechanism can be reused in other methods. The string-based builder signature
declaration is deprecated and will be removed after a transition period.

Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D89470
2020-10-21 11:42:50 +02:00
Christian Sigg f9b8a0b96b [mlir] Allow space literals (` `) in assemblyFormat.
Spaces are only printed, not parsed.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D89585
2020-10-19 07:25:28 +02:00
John Demme f402e682d0 [MLIR] ODS TypeDefs: getChecked() and internal enhancements
Have the ODS TypeDef generator write the getChecked() definition.
Also add to TypeParamCommaFormatter a `JustParams` format and
refactor around that.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D89438
2020-10-19 01:10:05 +00:00
Rob Suderman c096377905 Fixed a failure when const matcher fails, added a test to catch
Differential Revision: https://reviews.llvm.org/D89593
2020-10-16 15:02:24 -07:00
Rob Suderman 2bf423b021 [mlir] RewriterGen NativeCodeCall matcher with ConstantOp matcher
Added an underlying matcher for generic constant ops. This
included a rewriter of RewriterGen to make variable use more
clear.

Differential Revision: https://reviews.llvm.org/D89161
2020-10-15 16:32:20 -07:00
David Blaikie 4c1c88bbc1 Add missing 'override' 2020-10-15 15:15:53 -07:00
rdzhabarov 008c0ea6a4 [DDR] Introduce implicit equality check for the source pattern operands with the same name.
This CL allows user to specify the same name for the operands in the source pattern which implicitly enforces equality on operands with the same name.
E.g., Pat<(OpA $a, $b, $a) ... > would create a matching rule for checking equality for the first and the last operands. Equality of the operands is enforced at any depth, e.g., OpA ($a, $b, OpB($a, $c, OpC ($a))).

Example usage: Pat<(Reshape $arg0, (Shape $arg0)), (replaceWithValue $arg0)>

Note, this feature only covers operands but not attributes.
Current use cases are based on the operand equality and explicitly add the constraint into the pattern. Attribute equality will be worked out on the different CL.

Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D89254
2020-10-14 11:05:13 -07:00
Jacques Pienaar f4ad76deb8 [mlir] More changes to avoid args now inserted.NFC
Migrates a bit more from the old/to be deprecated form.
2020-10-14 10:47:45 -07:00
Kevin Petit acb7827d62 [mlir][vulkan-runner] Fix buffer usage flags
The buffers are used as source or destination of transfer commands
so always add VK_BUFFER_USAGE_TRANSFER_{DST,SRC}_BIT to their usage
flags.

Signed-off-by: Kevin Petit <kevin.petit@arm.com>
2020-10-14 16:29:32 +01:00
Nicolas Vasilache af5be38a01 [mlir][Linalg] Make a Linalg CodegenStrategy available.
This revision adds a programmable codegen strategy from linalg based on staged rewrite patterns. Testing is exercised on a simple linalg.matmul op.

Differential Revision: https://reviews.llvm.org/D89374
2020-10-14 11:11:26 +00:00
Mehdi Amini 0b793c4be0 Revert "[DDR] Introduce implicit equality check for the source pattern operands with the same name."
This reverts commit 7271c1bcb9.

This broke the gcc-5 build:

/usr/include/c++/5/ext/new_allocator.h:120:4: error: no matching function for call to 'std::pair<const std::__cxx11::basic_string<char>, mlir::tblgen::SymbolInfoMap::SymbolInfo>::pair(llvm::StringRef&, mlir::tblgen::SymbolInfoMap::SymbolInfo)'
  { ::new((void *)__p) _Up(std::forward<_Args>(__args)...); }
    ^
In file included from /usr/include/c++/5/utility:70:0,
                 from llvm/include/llvm/Support/type_traits.h:18,
                 from llvm/include/llvm/Support/Casting.h:18,
                 from mlir/include/mlir/Support/LLVM.h:24,
                 from mlir/include/mlir/TableGen/Pattern.h:17,
                 from mlir/lib/TableGen/Pattern.cpp:14:
/usr/include/c++/5/bits/stl_pair.h:206:9: note: candidate: template<class ... _Args1, long unsigned int ..._Indexes1, class ... _Args2, long unsigned int ..._Indexes2> std::pair<_T1, _T2>::pair(std::tuple<_Args1 ...>&, std::tuple<_Args2 ...>&, std::_Index_tuple<_Indexes1 ...>, std::_Index_tuple<_Indexes2 ...>)
         pair(tuple<_Args1...>&, tuple<_Args2...>&,
         ^
2020-10-14 00:37:10 +00:00