Commit Graph

1248 Commits

Author SHA1 Message Date
Mehdi Amini 1cc29f027f Revert "Emit strong definition for TypeID storage in Op/Type/Attributes definition"
This reverts commit b349d4c5e1.
This broke a bot that exposes some missing CMake dependencies that need
to be fixed first.
2021-07-28 06:04:53 +00:00
Mehdi Amini b349d4c5e1 Emit strong definition for TypeID storage in Op/Type/Attributes definition
By making an explicit template specialization for the TypeID provided by these classes,
the compiler will not emit an inline weak definition and rely on the linker to unique it.
Instead a single definition will be emitted in the C++ file alongside the implementation
for these classes. That will turn into a linker error what is now a hard-to-debug runtime
behavior where instances of the same class may be using a different TypeID inside of
different DSOs.

Differential Revision: https://reviews.llvm.org/D105903
2021-07-28 05:38:43 +00:00
Eugene Zhulenev d94426d22a [mlir] Math: add algebraic simplification patterns to math transforms
Reviewed By: bkramer

Differential Revision: https://reviews.llvm.org/D106822
2021-07-27 09:22:33 -07:00
Marius Brehler 49d840c35c [mlir] Improve description of interface options
Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D106539
2021-07-22 19:35:56 +02:00
Chia-hung Duan d7314b3c09 [mlir-tblgen] Support binding multi-results of NativeCodeCall
We are able to bind NativeCodeCall result as binding operation. To make
table-gen have better understanding in the form of helper function,
we need to specify the number of return values in the NativeCodeCall
template. A VoidNativeCodeCall is added for void case.

Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D102160
2021-07-21 11:23:22 +08:00
Chia-hung Duan b4001ae885 [mlir-tblgen] Fix failed matching when binds same operand of an op in different depth
For example, we will generate incorrect code for the pattern,

def : Pat<((FooOp (FooOp, $a, $b), $b)), (...)>;

We didn't allow $b to be bond twice with same operand of same op.

Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D105677
2021-07-20 15:43:09 +08:00
Chia-hung Duan 9bdf1ab70b [mlir-tblgen] Slightly improve the diagnostic message in pattern match
Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D105883
2021-07-19 09:19:51 +08:00
John Demme b4c93ece8e [MLIR] [Python ODS] Use @builtins.property for cases where 'property' is already defined
In cases where an operation has an argument or result named 'property', the
ODS-generated python fails on import because the `@property` resolves to the
`property` operation argument instead of the builtin `@property` decorator. We
should always use the fully qualified decorator name.

Reviewed By: mikeurbach

Differential Revision: https://reviews.llvm.org/D106106
2021-07-15 19:39:03 -07:00
Alex Zinenko 75e5f0aac9 [mlir] factor memref-to-llvm lowering out of std-to-llvm
After the MemRef has been split out of the Standard dialect, the
conversion to the LLVM dialect remained as a huge monolithic pass.
This is undesirable for the same complexity management reasons as having
a huge Standard dialect itself, and is even more confusing given the
existence of a separate dialect. Extract the conversion of the MemRef
dialect operations to LLVM into a separate library and a separate
conversion pass.

Reviewed By: herhut, silvas

Differential Revision: https://reviews.llvm.org/D105625
2021-07-09 14:49:52 +02:00
Alex Zinenko b5d847b1b9 [mlir] factor out common parts of the converstion to the LLVM dialect
"Standard-to-LLVM" conversion is one of the oldest passes in existence. It has
become quite large due to the size of the Standard dialect itself, which is
being split into multiple smaller dialects. Furthermore, several conversion
features are useful for any dialect that is being converted to the LLVM
dialect, which, without this refactoring, creates a dependency from those
conversions to the "standard-to-llvm" one.

Put several of the reusable utilities from this conversion to a separate
library, namely:
- type converter from builtin to LLVM dialect types;
- utility for building and accessing values of LLVM structure type;
- utility for building and accessing values that represent memref in the LLVM
  dialect;
- lowering options applicable everywhere.

Additionally, remove the type wrapping/unwrapping notion from the type
converter that is no longer relevant since LLVM types has been reimplemented as
first-class MLIR types.

Reviewed By: pifon2a

Differential Revision: https://reviews.llvm.org/D105534
2021-07-07 10:51:08 +02:00
Uday Bondhugula 4acf3807e3 [MLIR] Split out GPU ops library from Transforms
Split out GPU ops library from GPU transforms. This allows libraries to
depend on GPU Ops without needing/building its transforms.

Differential Revision: https://reviews.llvm.org/D105472
2021-07-07 11:26:49 +05:30
Marius Brehler 96e3fb2416 [mlir] Unbreak building mlir-reduce
Unbreaks building mlir-reduce when `DLLVM_INCLUDE_TESTS` is set to OFF.
The dependency MLIRTestDialect is only available if building with tests.

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D105434
2021-07-05 17:08:53 +02:00
Chia-hung Duan 1a001dede8 [mlir-reduce] Improve diagnostic message and clean build dependency
Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D104443
2021-07-05 10:15:35 +08:00
Chia-hung Duan db9df434fa [mlir-tblgen] Avoid ODS verifier duplication
Different constraints may share the same predicate, in this case, we
will generate duplicate ODS verification function.

Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D104369
2021-07-05 10:09:41 +08:00
Stella Laurenzo 485cc55edf [mlir] Generare .cpp.inc files for dialects.
* Previously, we were only generating .h.inc files. We foresee the need to also generate implementations and this is a step towards that.
* Discussed in https://llvm.discourse.group/t/generating-cpp-inc-files-for-dialects/3732/2
* Deviates from the discussion above by generating a default constructor in the .cpp.inc file (and adding a tablegen bit that disables this in case if this is user provided).
* Generating the destructor started as a way to flush out the missing includes (produces a link error), but it is a strict improvement on its own that is worth doing (i.e. by emitting key methods in the .cpp file, we root vtables in one translation unit, which is a non-controversial improvement).

Differential Revision: https://reviews.llvm.org/D105070
2021-06-29 20:10:30 +00:00
Tobias Gysi bbf4436a82 [mlir][linalg] Remove the StructuredOp capture mechanism.
After https://reviews.llvm.org/D104109, structured ops support scalar inputs. As a result, the capture mechanism meant to pass non-shaped parameters got redundant. The patch removes the capture semantics after the FillOp migrated to use scalar operands https://reviews.llvm.org/D104121.

Differential Revision: https://reviews.llvm.org/D104785
2021-06-28 07:57:40 +00:00
Tobias Gysi 25bb616490 [mlir][linalg][python] Add attribute support to the YAML codegen.
Extend the yaml code generation to support the index attributes that https://reviews.llvm.org/D104711 added to the OpDSL.

Differential Revision: https://reviews.llvm.org/D104712
2021-06-24 12:33:48 +00:00
River Riddle c43e8c0eef [mlir][OpDefGen] Don't emit attribute name getters when there are no attributes
This avoids generating otherwise unnecessary methods.
2021-06-23 03:03:54 +00:00
River Riddle 6000749804 [mlir] Fix build on gcc-5 after D104167 2021-06-22 21:16:02 +00:00
River Riddle e4e31e19bb [mlir][OpGen] Cache Identifiers for known attribute names in AbstractOperation.
Operations currently rely on the string name of attributes during attribute lookup/removal/replacement, in build methods, and more. This unfortunately means that some of the most used APIs in MLIR require string comparisons, additional hashing(+mutex locking) to construct Identifiers, and more. This revision remedies this by caching identifiers for all of the attributes of the operation in its corresponding AbstractOperation. Just updating the autogenerated usages brings up to a 15% reduction in compile time, greatly reducing the cost of interacting with the attributes of an operation. This number can grow even higher as we use these methods in handwritten C++ code.

Methods for accessing these cached identifiers are exposed via `<attr-name>AttrName` methods on the derived operation class. Moving forward, users should generally use these methods over raw strings when an attribute name is necessary.

Differential Revision: https://reviews.llvm.org/D104167
2021-06-22 19:56:05 +00:00
Vladislav Vinogradov 628e136738 [mlir][ODS] Fix copy ctor for generate Pass classes
Redirect the copy ctor to the actual class instead of
overwriting it with `TypeID` based ctor.

This allows the final Pass classes to have extra fields and logic for their copy.

Reviewed By: lattner

Differential Revision: https://reviews.llvm.org/D104302
2021-06-21 14:07:31 +03:00
River Riddle d1baf28954 [mlir] Add support to SourceMgrDiagnosticHandler for filtering FileLineColLocs
This revision adds support for passing a functor to SourceMgrDiagnosticHandler for filtering out FileLineColLocs when emitting a diagnostic. More specifically, this can be useful in situations where there may be large CallSiteLocs with locations that aren't necessarily important/useful for users.

For now the filtering support is limited to FileLineColLocs, but conceptually we could allow filtering for all locations types if a need arises in the future.

Differential Revision: https://reviews.llvm.org/D103649
2021-06-18 21:12:28 +00:00
Alex Zinenko a4f81b2054 [mlir] ODS: emit interface traits outside of the interface class
ODS currently emits the interface trait class as a nested class inside the
interface class. As an unintended consequence, the default implementations of
interface methods have implicit access to static fields of the interface class,
e.g. those declared in `extraClassDeclaration`, including private methods (!),
or in the parent class. This may break the use of default implementations for
external models, which are not defined in the interface class, and generally
complexifies the abstraction.

Emit intraface traits outside of the interface class itself to avoid accidental
implicit visibility. Public static fields can still be accessed via explicit
qualification with a class name, e.g., `MyOpInterface::staticMethod()` instead
of `staticMethod`.

Update the documentation to clarify the role of `extraClassDeclaration` in
interfaces.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D104384
2021-06-17 10:25:35 +02:00
Mehdi Amini c8a3f561eb Decouple registring passes from specifying argument/description
This patch changes the (not recommended) static registration API from:

 static PassRegistration<MyPass> reg("my-pass", "My Pass Description.");

to:

 static PassRegistration<MyPass> reg;

And the explicit registration from:

  void registerPass("my-pass", "My Pass Description.",
                    [] { return createMyPass(); });

To:

  void registerPass([] { return createMyPass(); });

It is expected that Pass implementations overrides the getArgument() method
instead. This will ensure that pipeline description can be printed and parsed
back.

Differential Revision: https://reviews.llvm.org/D104421
2021-06-16 23:41:50 +00:00
Alex Zinenko 61cf7c7258 [mlir] ODS: temporarily disbale external model in presence of extra class declarations
Default implementations of interfaces may rely on extra class
declarations, which aren't currently generated in the external model,
that in turn may rely on functions defined in the main Attribute/Type
class, which wouldn't be available on the external model.
2021-06-16 12:18:56 +02:00
Tobias Gysi ff2ef4d684 [mlir][linalg] Adapt yaml codegen to support scalar parameters.
The patch updates the C++ yaml code generation to support scalar operands as added in https://reviews.llvm.org/D104220.

Differential Revision: https://reviews.llvm.org/D104224
2021-06-15 15:20:48 +00:00
Alex Zinenko 9b2a1bcf6f [mlir] separable registration of attribute and type interfaces
It may be desirable to provide an interface implementation for an attribute or
a type without modifying the definition of said attribute or type. Notably,
this allows to implement interfaces for attributes and types outside of the
dialect that defines them and, in particular, provide interfaces for built-in
types. Provide the mechanism to do so.

Currently, separable registration requires the attribute or type to have been
registered with the context, i.e. for the dialect containing the attribute or
type to be loaded. This can be relaxed in the future using a mechanism similar
to delayed dialect interface registration.

See https://llvm.discourse.group/t/rfc-separable-attribute-type-interfaces/3637

Depends On D104233

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D104234
2021-06-15 15:20:27 +02:00
Alex Zinenko 8ed8855958 [mlir] ODS: do not emit trailing const for static methods
The generated C++ would be invalid.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D104233
2021-06-15 13:33:39 +02:00
Sean Silva 853a614864 [mlir:OpFormatGen] Add Support for `$_ctxt` in the transformer.
This is useful for "build tuple" type ops. In my case, in npcomp, I have
an op:

```
// Result type is `!torch.tuple<!torch.tensor, !torch.tensor>`.
torch.prim.TupleConstruct %0, %1 : !torch.tensor, !torch.tensor
```

and the context is required for the `Torch::TupleType::get` call (for
the case of an empty tuple).

The handling of these FmtContext's in the code is pretty ad-hoc -- I didn't
attempt to rationalize it and just made a targeted fix. As someone
unfamiliar with the code I had a hard time seeing how to more broadly fix
the situation.

Differential Revision: https://reviews.llvm.org/D104274
2021-06-14 18:02:55 -07:00
River Riddle 66e2708205 [mlir:Linalg] Populate LinalgOp patterns on LinalgDialect as opposed to each op
Interface patterns are unique in that they get added to every operation that also implements that interface, given that they aren't tied to individual operations. When the same interface pattern gets added to multiple operations (such as the current behavior with Linalg), an reference to each of these patterns is added to every op (meaning that an operation will now have N references to effectively the same pattern). This revision fixes this problematic behavior in Linalg, and can bring upwards of a 25% reduction in compile time in Linalg based workloads.

Differential Revision: https://reviews.llvm.org/D104160
2021-06-14 11:20:15 -07:00
Tobias Gysi 67b1c37d9f [mlir][linalg] Cleanup left over uses of deprecated LinalgOp methods.
Replace all remaining uses of deprecated Structured Op Interface methods. This patch is based on https://reviews.llvm.org/D103394.

Differential Revision: https://reviews.llvm.org/D103673
2021-06-04 08:48:02 +00:00
Chia-hung Duan 2f98dfe5b6 [mlir-reduce] Create MlirReduceLib
Move the core reducer algorithm into a library so that it'll be easier
for porting to different projects.

Depends On D101046

Reviewed By: jpienaar, rriddle

Differential Revision: https://reviews.llvm.org/D101607
2021-06-03 15:58:26 +08:00
Chia-hung Duan c484c7dd9d [mlir-reduce] Reducer refactor.
* A Reducer is a kind of RewritePattern, so it's just the same as
writing graph rewrite.
* ReductionTreePass operates on Operation rather than ModuleOp, so that
* we are able to reduce a nested structure(e.g., module in module) by
* self-nesting.

Reviewed By: jpienaar, rriddle

Differential Revision: https://reviews.llvm.org/D101046
2021-06-02 07:45:00 +08:00
Jacques Pienaar 5618a5a059 [mlir] Update cmake variable post D102976 2021-05-27 11:11:58 -07:00
Matthias Springer 108ca7a7e7 [mlir] Support dialect-wide canonicalization pattern registration
* Add `hasCanonicalizer` option to Dialect.
* Initialize canonicalizer with dialect-wide canonicalization patterns.
* Add test case to TestDialect.

Dialect-wide canonicalization patterns are useful if a canonicalization pattern does not conceptually associate with any single operation, i.e., it should not be registered as part of an operation's `getCanonicalizationPatterns` function. E.g., this is the case for canonicalization patterns that match an op interface.

Differential Revision: https://reviews.llvm.org/D103226
2021-05-27 17:35:21 +09:00
Alexander Belyaev 281ee42911 [mlir] Add a pass to distribute linalg::TiledLoopOp.
Differential Revision: https://reviews.llvm.org/D103194
2021-05-27 08:45:20 +02:00
Alexander Belyaev 9ecc8178d7 [mlir] Add support for fusion into TiledLoopOp.
Differential Revision: https://reviews.llvm.org/D102722
2021-05-21 18:13:45 +02:00
Nicolas Vasilache 8eb18a0f3e [mlir][Standard] NFC - Drop remaining EDSC usage
Drop the remaining EDSC subdirectories and update all uses.

Differential Revision: https://reviews.llvm.org/D102911
2021-05-21 10:40:39 +00:00
Konrad Kleine 0297506d20 [mlir] Rename MlirLspServerLib -> MLIRLspServerLib
I noticed while packaging mlir that most mlir library names start
with `libMLIR`. The only different libary was `libMlirLspServerLib.a`.

That's why I changed the library to be similarly named to the others.

Differential Revision: https://reviews.llvm.org/D102881
2021-05-21 10:25:54 +02:00
Nicolas Vasilache 4519ca3d2e [mlir][Linalg] NFC - Drop Linalg EDSC usage
Drop the Linalg dialect EDSC subdirectory and update all uses.

Differential Revision: https://reviews.llvm.org/D102848
2021-05-20 15:33:56 +00:00
Tobias Gysi 99a198641c [mlir][Python][linalg] Fix to limit size of SmallVector.
Stack allocate at most two ScalarAssign elements. Using the default number of inlined elements triggered a static assert in some setups (https://reviews.llvm.org/D102075).

Differential Revision: https://reviews.llvm.org/D102827
2021-05-20 07:24:41 +00:00
Tobias Gysi 9a2769db80 [mir][Python][linalg] Support OpDSL extensions in C++.
The patch extends the yaml code generation to support the following new OpDSL constructs:
- captures
- constants
- iteration index accesses
- predefined types
These changes have been introduced by revision
https://reviews.llvm.org/D101364.

Differential Revision: https://reviews.llvm.org/D102075
2021-05-19 13:36:56 +00:00
Thomas Köppe 58369fce30 Add a helper function to convert LogicalResult to int for return from main
At present, a lot of code contains main function bodies like "return failed(mlir::MlirOptMain(...);". This is unfortunate for two reasons: a) it uses ADL, which is maybe not what the free "failed" function was designed for; and b) it is a bit awkward to read, requring the reader to both understand the boolean nature of the value and the semantics of main's return value. (And it's also not portable, since 1 is not a portable success value.)

The replacement code, `return mlir::AsMainReturnCode(mlir::MlirOptMain(...))` is a bit more self-explanatory.

The change applies the new function to a few internal uses of MlirOptMain, too.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D102641
2021-05-19 00:12:39 +00:00
River Riddle 3fef2d26a3 [mlir][NFC] Move passes in test/lib/Transforms/ to a directory that mirrors what they test
test/lib/Transforms/ has bitrot and become somewhat of a dumping grounds for testing pretty much any part of the project. This revision cleans this up, and moves the files within to a directory that reflects what is actually being tested.

Differential Revision: https://reviews.llvm.org/D102456
2021-05-14 10:28:11 -07:00
Sean Silva 49755871ad [mlir][ODS]: Add per-op cppNamespace.
This is useful for dialects that have logical subparts.

Differential Revision: https://reviews.llvm.org/D102200
2021-05-11 10:48:05 -07:00
Chia-hung Duan 34b5482b33 Support NativeCodeCall binding in rewrite pattern.
We are able to bind the result from native function while rewriting
pattern. In matching pattern, if we want to get some values back, we can
do that by passing parameter as return value placeholder. Besides, add
the semantic of '$_self' in NativeCodeCall while matching, it'll be the
operation that defines certain operand.

Differential Revision: https://reviews.llvm.org/D100746
2021-05-10 09:29:27 +08:00
Aart Bik a2c9d4bb04 [mlir][sparse] Introduce proper sparsification passes
This revision migrates more code from Linalg into the new permanent home of
SparseTensor. It replaces the test passes with proper compiler passes.

NOTE: the actual removal of the last glue and clutter in Linalg will follow

Reviewed By: bixia

Differential Revision: https://reviews.llvm.org/D101811
2021-05-04 17:10:09 -07:00
Vitaly Buka 68ff493dfc [NFC] Fixed some D79714 warnings 2021-04-25 12:41:46 -07:00
thomasraoux d40a19c3a8 [mlir][linalg] Add pattern to push reshape after elementwise operation
This help expose more fusion opportunities.

Differential Revision: https://reviews.llvm.org/D100685
2021-04-21 21:22:39 -07:00
River Riddle 751c14fc42 [mlir][mlir-lsp] Add a new C++ LSP server for MLIR named mlir-lsp-server
This commits adds a basic LSP server for MLIR that supports resolving references and definitions. Several components of the setup are simplified to keep the size of this commit down, and will be built out in later commits. A followup commit will add a vscode language client that communicates with this server, paving the way for better IDE experience when interfacing with MLIR files.

The structure of this tool is similar to mlir-opt and mlir-translate, i.e. the implementation is structured as a library that users can call into to implement entry points that contain the dialects/passes that they are interested in.

Note: This commit contains several files, namely those in `mlir-lsp-server/lsp`, that have been copied from the LSP code in clangd and adapted for use in MLIR. This copying was decided as the best initial path forward (discussed offline by several stake holders in MLIR and clangd) given the different needs of our MLIR server, and the one for clangd. If a strong desire/need for unification arises in the future, the existence of these files in mlir-lsp-server can be reconsidered.

Differential Revision: https://reviews.llvm.org/D100439
2021-04-21 14:44:37 -07:00
Nico Weber fce0ef277d [mlir] some iwyu fixes after ba7a92c01e 2021-04-21 10:48:54 -04:00
River Riddle 4efb7754e0 [mlir][NFC] Add a using directive for llvm::SetVector
Differential Revision: https://reviews.llvm.org/D100436
2021-04-15 16:09:34 -07:00
River Riddle 94662ee0c1 [mlir] Add support for adding attribute+type traits/interfaces to tablegen defs
This matches the current support provided to operations, and allows attaching traits, interfaces, and using the DeclareInterfaceMethods utility. This was missed when attribute/type generation was first added.

Differential Revision: https://reviews.llvm.org/D100233
2021-04-15 11:41:51 -07:00
Mehdi Amini 90ae4d9030 Change add_mlir_doc CMake macro to take the tablegen command as last argument to allow extra flags
This is useful for expressing specific table-gen options, like selecting
a particular dialect to print.
Use it to fix the documentation for the `pdl_interp` dialect which is now
generating the first dialect it finds in its input which is `pdl`.

Differential Revision: https://reviews.llvm.org/D100517
2021-04-15 02:59:40 +00:00
Chia-hung Duan 222d30d32c Use PassPipelineCLParser in mlir-reduce
We are able to config the reducer pass pipeline through command-line.

Reviewed By: jpienaar, rriddle

Differential Revision: https://reviews.llvm.org/D100155
2021-04-14 14:35:55 -07:00
Chia-hung Duan 6b0cef3e02 Refactor the architecture of mlir-reduce
Add iterator for ReductionNode traversal and use range to indicate the
region we would like to keep. Refactor the interaction between
Pass/Tester/ReductionNode.
Now it'll be easier to add new traversal type and OpReducer

Reviewed By: jpienaar, rriddle

Differential Revision: https://reviews.llvm.org/D99713
2021-04-14 13:40:44 -07:00
Mehdi Amini a33b647100 Revert "Refactor the architecture of mlir-reduce"
This reverts commit a32846b1d0.

The build is broken with -DBUILD_SHARED_LIBS=ON:

tools/mlir/lib/Reducer/CMakeFiles/obj.MLIRReduce.dir/Tester.cpp.o: In function `mlir::Tester::isInteresting(mlir::ModuleOp) const':
Tester.cpp:(.text._ZNK4mlir6Tester13isInterestingENS_8ModuleOpE+0xa8): undefined reference to `mlir::OpPrintingFlags::OpPrintingFlags()'
Tester.cpp:(.text._ZNK4mlir6Tester13isInterestingENS_8ModuleOpE+0xc6): undefined reference to `mlir::Operation::print(llvm::raw_ostream&, mlir::OpPrintingFlags)'
2021-04-14 19:25:43 +00:00
Jacques Pienaar a32846b1d0 Refactor the architecture of mlir-reduce
Add iterator for ReductionNode traversal and use range to indicate the region we would like to keep. Refactor the interaction between Pass/Tester/ReductionNode.
Now it'll be easier to add new traversal type and OpReducer

Reviewed By: jpienaar, rriddle

Differential Revision: https://reviews.llvm.org/D99713
2021-04-14 10:16:30 -07:00
Lei Zhang 0deeaaca39 [mlir] Move memref.subview patterns to MemRef/Transforms/
These patterns have been used as a prerequisite step for lowering
to SPIR-V. But they don't involve SPIR-V dialect ops; they are
pure memref/vector op transformations. Given now we have a dedicated
MemRef dialect, moving them to Memref/Transforms/, which is a more
suitable place to host them, to allow used by others.

This commit just moves code around and renames patterns/passes
accordingly. CMakeLists.txt for existing MemRef libraries are
also improved along the way.

Reviewed By: mravishankar

Differential Revision: https://reviews.llvm.org/D100326
2021-04-12 16:38:22 -04:00
Jacques Pienaar 96caf3817f [mlir] Hoist out getRequestedOpDefinitions helper
Enables performing the same filtering in the op doc definition as in the op definition generator.

Differential Revision: https://reviews.llvm.org/D99793
2021-04-06 12:53:28 -07:00
MaheshRavishankar 944a2fe763 [mlir][Linalg] Add callbacks to fusion of elementwise operations to control fusion.
Right now Elementwise operations fusion in Linalg fuses everything it
can. This can run up against resource limits of the target hardware
without some checks. This patch adds a callback function that clients
can use to implement a cost function. When two elementwise operations
are deemed structurally fusable, the callback can be used to control
if the fusion applies.

Differential Revision: https://reviews.llvm.org/D99820
2021-04-05 16:08:47 -07:00
Aden Grue 3ba1b1cd20 Add a pattern to combine composed subview ops
Differential Revision: https://reviews.llvm.org/D99229
2021-04-01 10:56:57 -07:00
Vladislav Vinogradov 15b76e6ca0 [mlir][ODS] Fix `VariadicRegion` code generation for `NoTerminator` Ops
The issue was introduced in D98468.

The `{0}Regions` is an array of `std::unique_ptr<Region>` objects,
so it should be processed accordingly.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D99332
2021-03-26 14:24:36 +03:00
Mehdi Amini 973ddb7d6e Define a `NoTerminator` traits that allows operations with a single block region to not provide a terminator
In particular for Graph Regions, the terminator needs is just a
historical artifact of the generalization of MLIR from CFG region.
Operations like Module don't need a terminator, and before Module
migrated to be an operation with region there wasn't any needed.

To validate the feature, the ModuleOp is migrated to use this trait and
the ModuleTerminator operation is deleted.

This patch is likely to break clients, if you're in this case:

- you may iterate on a ModuleOp with `getBody()->without_terminator()`,
  the solution is simple: just remove the ->without_terminator!
- you created a builder with `Builder::atBlockTerminator(module_body)`,
  just use `Builder::atBlockEnd(module_body)` instead.
- you were handling ModuleTerminator: it isn't needed anymore.
- for generic code, a `Block::mayNotHaveTerminator()` may be used.

Differential Revision: https://reviews.llvm.org/D98468
2021-03-25 03:59:03 +00:00
Alex Zinenko b3386a734e [mlir] introduce data layout entry for index type
Index type is an integer type of target-specific bitwidth present in many MLIR
operations (loops, memory accesses). Converting values of this type to
fixed-size integers has always been problematic. Introduce a data layout entry
to specify the bitwidth of `index` in a given layout scope, defaulting to 64
bits, which is a commonly used assumption, e.g., in constants.

Port builtin-to-LLVM type conversion to use this data layout entry when
converting `index` type and untie it from pointer size. This is particularly
relevant for GPU targets. Keep a possibility to forcibly override the index
type in lowerings.

Depends On D98525

Reviewed By: herhut

Differential Revision: https://reviews.llvm.org/D98937
2021-03-24 15:13:42 +01:00
Mehdi Amini d905c10353 Add a mechanism for Dialects to provide a fallback for OpInterface
This mechanism makes it possible for a dialect to not register all
operations but still answer interface-based queries.
This can useful for dialects that are "open" or connected to an external
system and still interoperate with the compiler. It can also open up the
possibility to have a more extensible compiler at runtime: the compiler
does not need a pre-registration for each operation and the dialect can
inject behavior dynamically.

Reviewed By: rriddle, jpienaar

Differential Revision: https://reviews.llvm.org/D93085
2021-03-24 08:41:40 +00:00
River Riddle 76f3c2f3f3 [mlir][Pattern] Add better support for using interfaces/traits to match root operations in rewrite patterns
To match an interface or trait, users currently have to use the `MatchAny` tag. This tag can be quite problematic for compile time for things like the canonicalizer, as the `MatchAny` patterns may get applied to  *every* operation. This revision adds better support by bucketing interface/trait patterns based on which registered operations have them registered. This means that moving forward we will only attempt to match these patterns to operations that have this interface registered. Two simplify defining patterns that match traits and interfaces, two new utility classes have been added: OpTraitRewritePattern and OpInterfaceRewritePattern.

Differential Revision: https://reviews.llvm.org/D98986
2021-03-23 14:05:33 -07:00
Chris Lattner 782c534117 [ODS] Implement a new 'hasCanonicalizeMethod' bit for cann patterns.
This provides a simplified way to implement 'matchAndRewrite' style
canonicalization patterns for ops that don't need the full power of
RewritePatterns.  Using this style, you can implement a static method
with a signature like:

```
LogicalResult AssertOp::canonicalize(AssertOp op, PatternRewriter &rewriter) {
  return success();
}
```

instead of dealing with defining RewritePattern subclasses.  This also
adopts this for a few canonicalization patterns in the std dialect to
show how it works.

Differential Revision: https://reviews.llvm.org/D99143
2021-03-23 13:45:45 -07:00
River Riddle 6d6fe9ccc4 [mlir][OpAsmFormat] Add support for an "else" group on optional elements
The "else" group of an optional element is a collection of elements that get parsed/printed when the anchor of the main element group is *not* present. This is useful when there is a special syntax when an element is not present. The new syntax for an optional element is shown below:

```
optional-group: `(` elements `)` (`:` `(` else-elements `)`)? `?`
```

An example of how this might be used is shown below:

```tablegen
def FooOp : ... {
  let arguments = (ins UnitAttr:$foo);

  let assemblyFormat = "attr-dict (`foo_is_present` $foo^):(`foo_is_absent`)?";
}
```

would be formatted as such:

```mlir
// When the `foo` attribute is present:
foo.op foo_is_present

// When the `foo` attribute is not present:
foo.op foo_is_absent
```

Differential Revision: https://reviews.llvm.org/D99129
2021-03-22 18:19:23 -07:00
Chris Lattner dc4e913be9 [PatternMatch] Big mechanical rename OwningRewritePatternList -> RewritePatternSet and insert -> add. NFC
This doesn't change APIs, this just cleans up the many in-tree uses of these
names to use the new preferred names.  We'll keep the old names around for a
couple weeks to help transitions.

Differential Revision: https://reviews.llvm.org/D99127
2021-03-22 17:20:50 -07:00
Chris Lattner 1d909c9a35 Remove the extraneous MLIRContext argument from populateWithGenerated. NFC. 2021-03-21 10:38:35 -07:00
River Riddle caddfbd2a9 [mlir][docs] Remove the BuiltinDialect documentation from langref and generate it from ODS
Now that all of the builtin dialect is generated from ODS, its documentation in LangRef can be split out and replaced with references to Dialects/Builtin.md. LangRef is quite crusty right now and should really have a full cleanup done in a followup.

Differential Revision: https://reviews.llvm.org/D98562
2021-03-19 18:21:33 -07:00
River Riddle 1a75be0023 [mlir][NFC] Use the native range instead of APInt when computing operand ranges
This removes the need to construct an APInt for each value, given that it is guaranteed to contain 32 bit elements.

BEGIN_PUBLIC
    ...text exposed to open source public git repo...
END_PUBLIC
2021-03-19 17:11:46 -07:00
Christian Sigg a825fb2c07 [mlir] Remove mlir-rocm-runner
This change combines for ROCm what was done for CUDA in D97463, D98203, D98360, and D98396.

I did not try to compile SerializeToHsaco.cpp or test mlir/test/Integration/GPU/ROCM because I don't have an AMD card. I fixed the things that had obvious bit-rot though.

Reviewed By: whchung

Differential Revision: https://reviews.llvm.org/D98447
2021-03-19 00:24:10 -07:00
Vladislav Vinogradov 02834e1bd9 [mlir][ODS] Get rid of limitations in rewriters generator
Do not limit the number of arguments in rewriter pattern.

Introduce separate `FmtStrVecObject` class to handle
format of variadic `std::string` array.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D97839
2021-03-18 12:21:06 +03:00
Aart Bik f2557cf7ed [mlir][cpu-runner] register all llvm ir dialects
This fixes broken JIT functionality on emulator platforms.
With Alex' recent movement towards squashing llvm ir dialects
into target specific dialects, we now must ensure these dialects
are registered to the cpu runner to ensure JIT can lower this
to proper LLVM IR before handing this off to the backend.

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D98727
2021-03-17 10:05:46 -07:00
Vladislav Vinogradov fee9054232 [mlir][ODS] Support specialized Attribute class for Enums
Add a feature to `EnumAttr` definition to generate
specialized Attribute class for the particular enumeration.

This class will inherit `StringAttr` or `IntegerAttr` and
will override `classof` and `getValue` methods.

With this class the enumeration predicate can be checked with simple
RTTI calls (`isa`, `dyn_cast`) and it will return the typed enumeration
directly instead of raw string/integer.

Based on the following discussion:
https://llvm.discourse.group/t/rfc-add-enum-attribute-decorator-class/2252

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D97836
2021-03-17 16:44:24 +03:00
River Riddle caa7038a89 [mlir][IR] Move the remaining builtin attributes to ODS.
With this revision, all builtin attributes and types will have been moved to the ODS generator.

Differential Revision: https://reviews.llvm.org/D98474
2021-03-16 16:31:53 -07:00
River Riddle 425e11eea1 [mlir][AttrTypeDefGen] Add support for custom parameter comparators
Some parameters to attributes and types rely on special comparison routines other than operator== to ensure equality. This revision adds support for those parameters by allowing them to specify a `comparator` code block that determines if `$_lhs` and `$_rhs` are equal. An example of one of these paramters is APFloat, which requires `bitwiseIsEqual` for bitwise comparison (which we want for attribute equality).

Differential Revision: https://reviews.llvm.org/D98473
2021-03-16 16:31:53 -07:00
Alex Zinenko b868a3edad [mlir] fix SPIR-V CPU and Vulkan runners after e2310704d8
The commit in question changed the syntax but did not update the runner
tests. This also required registering the MemRef dialect for custom
parser to work correctly.
2021-03-15 18:36:58 +01:00
Alex Zinenko a88371490d [mlir] better formatting in interface docs
Start the description from a new line instead of putting the first
paragraph in the section header. Wrap the class name in backticks to
make it clear that it relates to the code.
2021-03-15 11:10:32 +01:00
Christian Sigg 1ef544d4a9 [mlir] Remove mlir-cuda-runner
Change CUDA integration tests to use mlir-opt + mlir-cpu-runner instead.

Depends On D98203

Reviewed By: herhut

Differential Revision: https://reviews.llvm.org/D98396
2021-03-12 14:06:43 +01:00
Alex Zinenko 3ba14fa0ce [mlir] Introduce data layout modeling subsystem
Data layout information allows to answer questions about the size and alignment
properties of a type. It enables, among others, the generation of various
linear memory addressing schemes for containers of abstract types and deeper
reasoning about vectors. This introduces the subsystem for modeling data
layouts in MLIR.

The data layout subsystem is designed to scale to MLIR's open type and
operation system. At the top level, it consists of attribute interfaces that
can be implemented by concrete data layout specifications; type interfaces that
should be implemented by types subject to data layout; operation interfaces
that must be implemented by operations that can serve as data layout scopes
(e.g., modules); and dialect interfaces for data layout properties unrelated to
specific types. Built-in types are handled specially to decrease the overall
query cost.

A concrete default implementation of these interfaces is provided in the new
Target dialect. Defaults for built-in types that match the current behavior are
also provided.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D97067
2021-03-11 16:54:47 +01:00
Christian Sigg bafe418d12 [mlir] Change test-gpu-to-cubin to derive from SerializeToBlobPass
Clean-up after D98279, remove one call to createConvertGPUKernelToBlobPass().

Depends On D98203

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D98360
2021-03-11 10:42:20 +01:00
Hanhan Wang d5d4fb635e [mlir][linalg] Add support for using scalar attributes in TC ops.
Reviewed By: antiagainst

Differential Revision: https://reviews.llvm.org/D97876
2021-03-10 01:51:12 -08:00
Mehdi Amini 890afad954 Fix Flang build after MLIR API changes around `generatedTypeParser` 2021-03-09 23:19:30 +00:00
Christian Sigg 840ff84d33 [mlir] Default for gpu-binary-annotation option.
Provide default for gpuBinaryAnnotation so that we don't need to specify it in tests.

The annotation likely only needs to be target specific if we want to lower to e.g. both CUDA and ROCDL.

Reviewed By: herhut, bondhugula

Differential Revision: https://reviews.llvm.org/D98168
2021-03-09 21:01:50 +01:00
Mehdi Amini 79f736c150 Switch generatedTypeParser/generatedAttributeParser to return an OptionalParseResult
This allows the caller to distinguish between a parse error or an
unmatched keyword. It fixes the redundant error that was emitted by the
caller when the generated parser would fail.

Differential Revision: https://reviews.llvm.org/D98162
2021-03-09 19:43:45 +00:00
Vladislav Vinogradov 2241b3986c [mlir][CMAKE] Fix cross-compilation build
Use `MLIR_LINALG_ODS_GEN` and `MLIR_LINALG_ODS_YAML_GEN` variables
instead of `MLIR_LINALG_ODS_GEN_EXE` and `MLIR_LINALG_ODS_YAML_GEN_EXE`.
The former are defined in PARENT SCOPE only, so the `if` condition
is never evaluates to `TRUE`.

The logic should be the following (taken from tblgen part):

1. `TOOL_NAME` - CACHE variable (default equal to target name).
   User can override it to actual executable path.
2. `TOOL_NAME_EXE` - internal variable, initialized to `${TOOL_NAME}` first.
   In case of cross-compilation (`LLVM_USE_HOST_TOOLS == TRUE`) if user
   didn't set own path to native executable via `TOOL_NAME` variable,
   CMake will create separate targets to build native tool and
   will override `TOOL_NAME_EXE` to the executable produced by this target.
3. `TOOL_NAME_TARGET` - internal variable, which points to tool target name.
   If the native tool is built as described above, it will point to the
   target correspondant to that native tool.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D98025
2021-03-09 10:51:56 +03:00
Stella Laurenzo e31c77b182 [mlir][python] Reorganize MLIR python into namespace packages.
* Only leaf packages are non-namespace packages. This allows most of the top levels to be split into different directories or deployment packages. In the previous state, the presence of __init__.py files at each level meant that the entire tree could only ever exist in one physical directory on the path.
* This changes the API usage slightly: `import mlir` will no longer do a deep import of `mlir.ir`, etc. This may necessitate some client code changes.
* Dialect gen code was restructured so that the user is responsible for providing the `my_dialect.py` file, which then must import its peer `_my_dialect_ops_gen`. This gives complete control of the dialect namespace to the user instead of to tablegen code, allowing further dialect-specific python APIs.
* Correspondingly, the previous extension modules `_my_dialect.py` are now `_my_dialect_ops_ext.py`.
* Now that the `linalg` namespace is open, moved the `linalg_opdsl` tool into it.
* This may require some corresponding downstream adjustments to npcomp, circt, et al:
  * Probably some shallow imports need to be converted to deep imports (i.e. not `import mlir` brings in the world).
  * Each tablegen generated dialect now needs an explicit `foo.py` which does a `from ._foo_ops_gen import *`. This is similar to the way that generated code operates in the C++ world.
  * If providing dialect op extensions, those need to be moved from `_foo.py` -> `_foo_ops_ext.py`.

Differential Revision: https://reviews.llvm.org/D98096
2021-03-08 23:01:34 -08:00
Mehdi Amini a7cac0d9a5 Fix Dialect doc generation to special case for the Builtin dialect empty name
This should fix the issue with an empty entry for the builtin dialect on
the website.

Differential Revision: https://reviews.llvm.org/D98074
2021-03-05 23:47:50 +00:00
Diego Caballero 2de6dbda66 [mlir] Add 'Skip' result to Operation visitor
This patch is a follow-up on D97217. It adds a new 'Skip' result to the Operation visitor
so that a callback can stop the ongoing visit of an operation/block/region and
continue visiting the next one without fully interrupting the walk. Skipping is
needed to be able to erase an operation/block in pre-order and do not continue
visiting the internals of that operation/block.

Related to the skipping mechanism, the patch also introduces the following changes:
 * Added new TestIRVisitors pass with basic testing for the IR visitors.
 * Fixed missing early increment ranges in visitor implementation.
 * Updated documentation of walk methods to include erasure information and walk
   order information.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D97820
2021-03-06 00:02:20 +02:00
Christian Sigg 5fedf30748 [mlir] Make cuInit() call thread-safe.
Reviewed By: herhut

Differential Revision: https://reviews.llvm.org/D98024
2021-03-05 16:06:15 +01:00
River Riddle 1447ec5182 [mlir][AttrDefGen] Add support for specifying the value type of an attribute
The value type of the attribute can be specified by either overriding the typeBuilder field on the AttrDef, or by providing a parameter of type `AttributeSelfTypeParameter`. This removes the need to define custom storage class constructors for attributes that have a value type other than NoneType.

Differential Revision: https://reviews.llvm.org/D97590
2021-03-04 13:04:05 -08:00
Arpith C. Jacob 4e393350c5 [mlir] Add an AccessGroup attribute to load/store LLVM dialect ops and generate the access_group LLVM metadata.
This also includes LLVM dialect ops created from intrinsics.

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D97944
2021-03-04 18:17:23 +01:00
Alex Zinenko 32c49c7d73 [mlir] ODS: change OpBuilderDAG to OpBuilder
We no longer have the non-DAG version.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D97856
2021-03-04 10:55:02 +01:00
Alex Zinenko 19db802e7b [mlir] make implementations of translation to LLVM IR interfaces private
There is no need for the interface implementations to be exposed, opaque
registration functions are sufficient for all users, similarly to passes.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D97852
2021-03-04 09:16:32 +01:00
River Riddle 83ef862fad [mlir] Add support for generating Attribute classes for ODS
The support for attributes closely maps that of Types (basically 1-1) given that Attributes are defined in exactly the same way as Types. All of the current ODS TypeDef classes get an Attr equivalent. The generation of the attribute classes themselves share the same generator as types.

Differential Revision: https://reviews.llvm.org/D97589
2021-03-03 16:41:49 -08:00
Hanhan Wang 497b7b8c00 [mlir][linalg] Delete unused vars if there are shaped-only operands.
Reviewed By: stella.stamenova

Differential Revision: https://reviews.llvm.org/D97851
2021-03-03 09:36:08 -08:00
Vladislav Vinogradov 5d613e42d3 [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.

Add `inline` and `constexpr` methods support to `OpMethod`.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D97390
2021-03-03 16:15:12 +03:00
Christian Sigg 9d7be77bf9 [mlir] Move cuda tests
Move test inputs to test/Integration directory.
Move runtime wrappers to ExecutionEngine.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D97463
2021-03-03 13:16:51 +01:00
Hanhan Wang c0f8115c73 [mlir][linalg] Only generate one var for an attrUse.
Some variables are unused after D97383 landed. We should generate one symbol for one attrUse.

Reviewed By: stellaraccident

Differential Revision: https://reviews.llvm.org/D97794
2021-03-02 12:48:20 -08:00
Stella Laurenzo d36a15de1f [mlir][linalg] Memoize indexing map generation.
Differential Revision: https://reviews.llvm.org/D97602
2021-03-01 21:15:40 -08:00
Stella Stamenova 801067f4c0 [mlir][lldb] Fix several gcc warnings in mlir and lldb
These warnings are raised when compiling with gcc due to either having too few or too many commas, or in the case of lldb, the possibility of a nullptr.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D97586
2021-03-01 13:48:22 -08:00
Stella Laurenzo 2ceedc3a20 [mlir][linalg] Add symbolic type conversion to linalg named ops.
This enables this kind of construct in the DSL to generate a named op that is polymorphic over numeric type variables `T` and `U`, generating the correct arithmetic casts at construction time:

```
@tc_def_op
def polymorphic_matmul(A=TensorDef(T1, S.M, S.K),
                       B=TensorDef(T2, S.K, S.N),
                       C=TensorDef(U, S.M, S.N, output=True)):
  implements(ContractionOpInterface)
  C[D.m, D.n] += cast(U, A[D.m, D.k]) * cast(U, B[D.k, D.n])
```

Presently, this only supports type variables that are bound to the element type of one of the arguments, although a further extension that allows binding a type variable to an attribute would allow some more expressiveness and may be useful for some formulations. This is left to a future patch. In addition, this patch does not yet materialize the verifier support which ensures that types are bound correctly (for such simple examples, failing to do so will yield IR that fails verification, it just won't yet fail with a precise error).

Note that the full grid of extensions/truncation/int<->float conversions are supported, but many of them are lossy and higher level code needs to be mindful of numerics (it is not the job of this level).

As-is, this should be sufficient for most integer matmul scenarios we work with in typical quantization schemes.

Differential Revision: https://reviews.llvm.org/D97603
2021-02-27 15:52:35 -08:00
Stella Laurenzo 5867c18e2c [mlir][linalg] Generate additional interfaces for named ops.
* Adds ContractionOpInterface to polymorphic_matmul.

Differential Revision: https://reviews.llvm.org/D97601
2021-02-27 15:43:41 -08:00
River Riddle e6260ad043 [mlir] Simplify various pieces of code now that Identifier has access to the Context/Dialect
This also exposed a bug in Dialect loading where it was not correctly identifying identifiers that had the dialect namespace as a prefix.

Differential Revision: https://reviews.llvm.org/D97431
2021-02-26 18:00:05 -08:00
Jacques Pienaar 91ab48ea6b [mlir] Add regions to OpAdaptor
Allows querying regions too via OpAdaptor's generated. This does not yet move region verification to adaptor nor require regions for ops where needed.

Differential Revision: https://reviews.llvm.org/D97519
2021-02-26 16:25:00 -08:00
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
Benjamin Kramer 4941fef9c4 [mlir] Silence some deprecation warnings after dffc487b07 2021-02-26 15:15:56 +01:00
Vladislav Vinogradov f4d78a5e3a [mlir][NFC] Add missing namespace qualifier to ODS generated code
Use `::mlir::Region` inside array ref for `VariadicRegion`.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D97376
2021-02-25 17:48:32 +03:00
Marius Brehler 699041123e [mlir] Fix emitting attribute documentation
This fixes the documentation emitted for type parameters. Also adds a
missing empty line, rendered as line break in mark down.

Co-authored-by: Simon Camphausen <simon.camphausen@iml.fraunhofer.de>

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D97267
2021-02-25 08:23:50 +01:00
Hanhan Wang 21895a2bef [mlir][linalg] Reuse the symbol if attribute uses are identical.
Depends On D97312

Reviewed By: antiagainst

Differential Revision: https://reviews.llvm.org/D97383
2021-02-24 11:42:13 -08:00
Hanhan Wang 705068cb8c [mlir][linalg] Support for using output values in TC definitions.
This will allow us to define select(pred, in, out) for TC ops, which is useful
for pooling ops.

Reviewed By: antiagainst

Differential Revision: https://reviews.llvm.org/D97312
2021-02-24 11:37:45 -08:00
Christian Sigg eb8d6af5e4 [mlir] Specify cuda-runner pass pipeline as command line options.
The cuda-runner registers two pass pipelines for nested passes,
so that we don't have to use verbose textual pass pipeline specification.

Reviewed By: herhut

Differential Revision: https://reviews.llvm.org/D97091
2021-02-24 14:36:52 +01:00
River Riddle 06e25d5645 [mlir][IR] Refactor the `getChecked` and `verifyConstructionInvariants` methods on Attributes/Types
`verifyConstructionInvariants` is intended to allow for verifying the invariants of an attribute/type on construction, and `getChecked` is intended to enable more graceful error handling aside from an assert. There are a few problems with the current implementation of these methods:
* `verifyConstructionInvariants` requires an mlir::Location for emitting errors, which is prohibitively costly in the situations that would most likely use them, e.g. the parser.
This creates an unfortunate code duplication between the verifier code and the parser code, given that the parser operates on llvm::SMLoc and it is an undesirable overhead to pre-emptively convert from that to an mlir::Location.
* `getChecked` effectively requires duplicating the definition of the `get` method, creating a quite clunky workflow due to the subtle different in its signature.

This revision aims to talk the above problems by refactoring the implementation to use a callback for error emission. Using a callback allows for deferring the costly part of error emission until it is actually necessary.

Due to the necessary signature change in each instance of these methods, this revision also takes this opportunity to cleanup the definition of these methods by:
* restructuring the signature of `getChecked` such that it can be generated from the same code block as the `get` method.
* renaming `verifyConstructionInvariants` to `verify` to match the naming scheme of the rest of the compiler.

Differential Revision: https://reviews.llvm.org/D97100
2021-02-22 17:37:49 -08:00
Kern Handa 2d62212b06 [mlir] Export CUDA and Vulkan runtime wrappers on Windows
Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D97140
2021-02-21 22:58:55 -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
Eugene Zhulenev f99ccf6516 [mlir] Add math polynomial approximation pass
This gives ~30x speedup compared to expanding Tanh into exp operations:

```
name                  old cpu/op  new cpu/op  delta
BM_mlir_Tanh_f32/10    253ns ± 3%    55ns ± 7%  -78.35%  (p=0.000 n=44+41)
BM_mlir_Tanh_f32/100  2.21µs ± 4%  0.14µs ± 8%  -93.85%  (p=0.000 n=48+49)
BM_mlir_Tanh_f32/1k   22.6µs ± 4%   0.7µs ± 5%  -96.68%  (p=0.000 n=32+42)
BM_mlir_Tanh_f32/10k   225µs ± 5%     7µs ± 6%  -96.88%  (p=0.000 n=49+55)

name                  old time/op             new time/op             delta
BM_mlir_Tanh_f32/10    259ns ± 1%               56ns ± 2%  -78.31%        (p=0.000 n=41+39)
BM_mlir_Tanh_f32/100  2.27µs ± 1%             0.14µs ± 5%  -93.89%        (p=0.000 n=46+49)
BM_mlir_Tanh_f32/1k   22.9µs ± 1%              0.8µs ± 4%  -96.67%        (p=0.000 n=30+42)
BM_mlir_Tanh_f32/10k   230µs ± 0%                7µs ± 3%  -96.88%        (p=0.000 n=37+55)
```

This approximations is based on Eigen::generic_fast_tanh function

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D96739
2021-02-19 12:43:36 -08:00
Alex Zinenko 12875ed976 [mlir] generate enum translation functions with unused attribute
The functions translating enums to LLVM IR are generated in a single
file included in many places, not all of which use all translations.
Generate functions with "unused" attribute to silence compiler warnings.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D96880
2021-02-18 09:44:40 +01:00
Alex Zinenko ce8f10d6cb [mlir] Simplify ModuleTranslation for LLVM IR
A series of preceding patches changed the mechanism for translating MLIR to
LLVM IR to use dialect interface with delayed registration. It is no longer
necessary for specific dialects to derive from ModuleTranslation. Remove all
virtual methods from ModuleTranslation and factor out the entry point to be a
free function.

Also perform some cleanups in ModuleTranslation internals.

Depends On D96774

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D96775
2021-02-16 18:42:52 +01:00
Alex Zinenko 1d6f08e61d [mlir] use new cmake targets in mlir-*-runner 2021-02-15 15:04:00 +01:00
Alex Zinenko 176379e0c8 [mlir] Use the interface-based translation for LLVM "intrinsic" dialects
Port the translation of five dialects that define LLVM IR intrinsics
(LLVMAVX512, LLVMArmNeon, LLVMArmSVE, NVVM, ROCDL) to the new dialect
interface-based mechanism. This allows us to remove individual translations
that were created for each of these dialects and just use one common
MLIR-to-LLVM-IR translation that potentially supports all dialects instead,
based on what is registered and including any combination of translatable
dialects. This removal was one of the main goals of the refactoring.

To support the addition of GPU-related metadata, the translation interface is
extended with the `amendOperation` function that allows the interface
implementation to post-process any translated operation with dialect attributes
from the dialect for which the interface is implemented regardless of the
operation's dialect. This is currently applied to "kernel" functions, but can
be used to construct other metadata in dialect-specific ways without
necessarily affecting operations.

Depends On D96591, D96504

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D96592
2021-02-15 14:43:07 +01:00
Fangrui Song 3643828b51 [CMake][mlir] Fix mlir-linalg-ods-gen/CMakeLists.txt after D96645 2021-02-13 14:16:38 -08:00
daquexian 6e31a6b7c2 fix linalg ods gen cross compiling like other gen executables
Signed-off-by: daquexian <daquexian566@gmail.com>

Reviewed By: vinograd47

Differential Revision: https://reviews.llvm.org/D96645
2021-02-13 19:17:46 +00:00
Praveen Narayanan a65fb1916c Add a "kind" attribute to ContractionOp and OuterProductOp.
Currently, vector.contract joins the intermediate result and the accumulator
argument (of ranks K) using summation. We desire more joining operations ---
such as max --- to help vector.contract express reductions. This change extends
Vector_ContractionOp to take an optional attribute (called "kind", of enum type
CombiningKind) specifying the joining operation to be add/mul/min/max for int/fp
, and and/or/xor for int only. By default this attribute has value "add".

To implement this we also need to extend vector.outerproduct, since
vector.contract gets transformed to vector.outerproduct (and that to
vector.fma). The extension for vector.outerproduct is also an optional kind
attribute that uses the same enum type and possible values. The default is
"add". In case of max/min we transform vector.outerproduct to a combination of
compare and select.

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D93280
2021-02-12 20:23:59 +00:00
Mehdi Amini aa4e466caa [mlir][Linalg] Improve region support in Linalg ops
This revision takes advantage of the newly extended `ref` directive in assembly format
to allow better region handling for LinalgOps. Specifically, FillOp and CopyOp now build their regions explicitly which allows retiring older behavior that relied on specific op knowledge in both lowering to loops and vectorization.

This reverts commit 3f22547fd1 and reland 973e133b76 with a workaround for
a gcc bug that does not accept lambda default parameters:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59949

Differential Revision: https://reviews.llvm.org/D96598
2021-02-12 19:11:24 +00:00
Mehdi Amini 3f22547fd1 Revert "[mlir][Linalg] Improve region support in Linalg ops."
This reverts commit 973e133b76.

It triggers an issue in gcc5 that require investigation, the build is
broken with:

/tmp/ccdpj3B9.s: Assembler messages:
/tmp/ccdpj3B9.s:5821: Error: symbol `_ZNSt17_Function_handlerIFvjjEUljjE2_E9_M_invokeERKSt9_Any_dataOjS6_' is already defined
/tmp/ccdpj3B9.s:5860: Error: symbol `_ZNSt14_Function_base13_Base_managerIUljjE2_E10_M_managerERSt9_Any_dataRKS3_St18_Manager_operation' is already defined
2021-02-12 18:15:51 +00:00
Alex Zinenko 66900b3eae [mlir] Use dialect interfaces to translate OpenMP dialect to LLVM IR
Migrate the translation of the OpenMP dialect operations to LLVM IR to the new
dialect-based mechanism.

Depends On D96503

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D96504
2021-02-12 18:37:47 +01:00
Alex Zinenko b77bac0572 [mlir] Introduce dialect interfaces for translation to LLVM IR
The existing approach to translation to the LLVM IR relies on a single
translation supporting the base LLVM dialect, extensible through inheritance to
support intrinsic-based dialects also derived from LLVM IR such as NVVM and
AVX512. This approach does not scale well as it requires additional
translations to be created for each new intrinsic-based dialect and does not
allow them to mix in the same module, contrary to the rest of the MLIR
infrastructure. Furthermore, OpenMP translation ingrained itself into the main
translation mechanism.

Start refactoring the translation to LLVM IR to operate using dialect
interfaces. Each dialect that contains ops translatable to LLVM IR can
implement the interface for translating them, and the top-level translation
driver can operate on interfaces without knowing about specific dialects.
Furthermore, the delayed dialect registration mechanism allows one to avoid a
dependency on LLVM IR in the dialect that is translated to it by implementing
the translation as a separate library and only registering it at the client
level.

This change introduces the new mechanism and factors out the translation of the
"main" LLVM dialect. The remaining dialects will follow suit.

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D96503
2021-02-12 17:49:44 +01:00
Nicolas Vasilache 973e133b76 [mlir][Linalg] Improve region support in Linalg ops.
This revision takes advantage of the newly extended `ref` directive in assembly format
to allow better region handling for LinalgOps. Specifically, FillOp and CopyOp now build their regions explicitly which allows retiring older behavior that relied on specific op knowledge in both lowering to loops and vectorization.

Differential Revision: https://reviews.llvm.org/D96598
2021-02-12 14:51:03 +00:00
Alex Zinenko 0881a4f1bf [mlir] make ModuleTranslation mapping fields private
ModuleTranslation contains multiple fields that keep track of the mappings
between various MLIR and LLVM IR components. The original ModuleTranslation
extension model was based on inheritance, with these fields being protected and
thus accessible in the ModuleTranslation and derived classes. The
inheritance-based model doesn't scale to translation of more than one derived
dialect and will be progressively replaced with a more flexible one based on
dialect interfaces and a translation state that is separate from
ModuleTranslation. This change prepares the replacement by making the mappings
private and providing public methods to access them.

Depends On D96436

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D96437
2021-02-11 14:50:49 +01:00
Alex Zinenko 9a08f760fe [mlir] Make JitRunnerMain main take a DialectRegistry
Historically, JitRunner has been registering all available dialects with the
context and depending on them without the real need. Make it take a registry
that contains only the dialects that are expected in the input and stop linking
in all dialects.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D96436
2021-02-11 14:50:48 +01:00
Alex Zinenko 2996a8d675 [mlir] avoid exposing mutable DialectRegistry from MLIRContext
MLIRContext allows its users to access directly to the DialectRegistry it
contains. While sometimes useful for registering additional dialects on an
already existing context, this breaks the encapsulation by essentially giving
raw accesses to a part of the context's internal state. Remove this mutable
access and instead provide a method to append a given DialectRegistry to the
one already contained in the context. Also provide a shortcut mechanism to
construct a context from an already existing registry, which seems to be a
common use case in the wild. Keep read-only access to the registry contained in
the context in case it needs to be copied or used for constructing another
context.

With this change, DialectRegistry is no longer concerned with loading the
dialects and deciding whether to invoke delayed interface registration. Loading
is concentrated in the MLIRContext, and the functionality of the registry
better reflects its name.

Depends On D96137

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D96331
2021-02-10 12:07:34 +01:00
Andrew Pritchard 018645b81b Fix side-effect detection in LLVMIRIntrinsicGen.
Previously it reported an op had side-effects iff it declared that it
didn't have any side-effects.  This had the undesirable result that
canonicalization would always delete any intrinsic calls that did memory
stores and returned void.

Reviewed By: ftynse, mehdi_amini

Differential Revision: https://reviews.llvm.org/D96369
2021-02-10 00:48:16 +00:00
River Riddle 6e3292b0b7 [mlir][OpFormatGen] Refactor `type_ref` into a more general `ref` directive
This allows for referencing nearly every component of an operation from within a custom directive.

It also fixes a bug with the current type_ref implementation, PR48478

Differential Revision: https://reviews.llvm.org/D96189
2021-02-09 14:33:48 -08:00
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