Commit Graph

1141 Commits

Author SHA1 Message Date
Rahul Joshi 245233423e [MLIR] Generate inferReturnTypes declaration using InferTypeOpInterface trait.
- Instead of hardcoding the parameters and return types of 'inferReturnTypes', use the
  InferTypeOpInterface trait to generate the method declaration.
- Fix InferTypeOfInterface to use fully qualified type for inferReturnTypes results.

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

Rework various backends that relied on the code type.

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

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

Reviewed By: rriddle, ftynse

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

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

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

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

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

Reviewed By: tpopp

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

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

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

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

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

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

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

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

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

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

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

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

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

Reviewed By: herhut

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

Reviewed By: ftynse

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

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

Reviewed By: stellaraccident, mehdi_amini

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

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

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

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

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

Reviewed By: lattner

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

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

This reverts commit 0c59f51592.

Revert "Remove unused isZero function"

This reverts commit 0f9f0a4046.

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

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

Reviewed By: nicolasvasilache

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

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

Reviewed By: ftynse

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

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

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

Reviewed By: nicolasvasilache, ftynse

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

Reviewed By: stellaraccident

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

Reviewed By: rriddle

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

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

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

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

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

Reviewed By: stellaraccident

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

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

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

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

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

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

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

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

Reviewed By: stellaraccident

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

Reviewed By: silvas, ftynse, rriddle

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

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

Reviewed By: rriddle

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

Reviewed By: stellaraccident

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

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

Reviewed By: mehdi_amini

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

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

This reverts commit bb9b5d3971.

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

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

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

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

To do this right, I needed to:

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

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

Sizes (release/stripped, Ubuntu 20.04):

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

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

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

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

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

Reviewed By: mehdi_amini, benvanik

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

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

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

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

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

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

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

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

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

Reviewed By: stellaraccident, ftynse

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

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

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

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

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

This patch implements only the first phase.

Reviewed By: antiagainst

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

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

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

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

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

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

This patch implements only the first phase.

Reviewed By: antiagainst

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

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

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

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

This patch implements only the first phase.

Reviewed By: antiagainst

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

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

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

Reviewed By: jpienaar

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

Reviewed By: rriddle

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

Reviewed By: mehdi_amini

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

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

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

Add a deprecation notice to ODS generator.

Reviewed By: rriddle, jpienaar

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

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

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

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

Reviewed By: ftynse, mravishankar

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

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

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

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

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

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

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

Reviewed By: jpienaar

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

Reviewed By: rriddle

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

Reviewed By: rriddle

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

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

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

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

Reviewed By: jpienaar

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

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

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

This broke the gcc-5 build:

/usr/include/c++/5/ext/new_allocator.h:120:4: error: no matching function for call to 'std::pair<const std::__cxx11::basic_string<char>, mlir::tblgen::SymbolInfoMap::SymbolInfo>::pair(llvm::StringRef&, mlir::tblgen::SymbolInfoMap::SymbolInfo)'
  { ::new((void *)__p) _Up(std::forward<_Args>(__args)...); }
    ^
In file included from /usr/include/c++/5/utility:70:0,
                 from llvm/include/llvm/Support/type_traits.h:18,
                 from llvm/include/llvm/Support/Casting.h:18,
                 from mlir/include/mlir/Support/LLVM.h:24,
                 from mlir/include/mlir/TableGen/Pattern.h:17,
                 from mlir/lib/TableGen/Pattern.cpp:14:
/usr/include/c++/5/bits/stl_pair.h:206:9: note: candidate: template<class ... _Args1, long unsigned int ..._Indexes1, class ... _Args2, long unsigned int ..._Indexes2> std::pair<_T1, _T2>::pair(std::tuple<_Args1 ...>&, std::tuple<_Args2 ...>&, std::_Index_tuple<_Indexes1 ...>, std::_Index_tuple<_Indexes2 ...>)
         pair(tuple<_Args1...>&, tuple<_Args2...>&,
         ^
2020-10-14 00:37:10 +00:00
John Demme 5fe53c4128 [MLIR] Add support for defining Types in tblgen
Adds a TypeDef class to OpBase and backing generation code. Allows one
to define the Type, its parameters, and printer/parser methods in ODS.
Can generate the Type C++ class, accessors, storage class, per-parameter
custom allocators (for the storage constructor), and documentation.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D86904
2020-10-14 00:32:18 +00:00
rdzhabarov 7271c1bcb9 [DDR] Introduce implicit equality check for the source pattern operands with the same name.
This CL allows user to specify the same name for the operands in the source pattern which implicitly enforces equality on operands with the same name.
E.g., Pat<(OpA $a, $b, $a) ... > would create a matching rule for checking equality for the first and the last operands. Equality of the operands is enforced at any depth, e.g., OpA ($a, $b, OpB($a, $c, OpC ($a))).

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

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

Differential Revision: https://reviews.llvm.org/D89254
2020-10-13 16:05:14 -07:00
ahmedsabie c0b3abd19a [MLIR] Add a foldTrait() mechanism to allow traits to define folding and test it with an Involution trait
This is the same diff as https://reviews.llvm.org/D88809/ except side effect
free check is removed for involution and a FIXME is added until the dependency
is resolved for shared builds. The old diff has more details on possible fixes.

Reviewed By: rriddle, andyly

Differential Revision: https://reviews.llvm.org/D89333
2020-10-13 21:26:21 +00:00
Benjamin Kramer 97e48aadbd [mlir-cuda-runner] Unbreak the build
CMake Error at llvm/cmake/modules/AddLLVM.cmake:870 (add_dependencies):
  The dependency target "Core" of target "mlir-cuda-runner" does not exist.
Call Stack (most recent call first):
  llvm/cmake/modules/AddLLVM.cmake:1169 (add_llvm_executable)
  mlir/tools/mlir-cuda-runner/CMakeLists.txt:69 (add_llvm_tool)

CMake Error at llvm/cmake/modules/AddLLVM.cmake:870 (add_dependencies):
  The dependency target "LINK_COMPONENTS" of target "mlir-cuda-runner" does
  not exist.
Call Stack (most recent call first):
  llvm/cmake/modules/AddLLVM.cmake:1169 (add_llvm_executable)
  mlir/tools/mlir-cuda-runner/CMakeLists.txt:69 (add_llvm_tool)

CMake Error at llvm/cmake/modules/AddLLVM.cmake:870 (add_dependencies):
  The dependency target "Support" of target "mlir-cuda-runner" does not
  exist.
Call Stack (most recent call first):
  llvm/cmake/modules/AddLLVM.cmake:1169 (add_llvm_executable)
  mlir/tools/mlir-cuda-runner/CMakeLists.txt:69 (add_llvm_tool)
2020-10-13 22:36:08 +02:00
Lei Zhang 08e4e08d71 [mlir-vulkan-runner] Clean up some stale CMake configurations 2020-10-13 10:15:54 -04:00
Christian Sigg 01dc85c173 [mlir][gpu] Adding gpu runtime wrapper functions for async execution.
Reviewed By: herhut

Differential Revision: https://reviews.llvm.org/D89037
2020-10-12 14:07:27 +02:00
Nicolas Vasilache 69d3247f35 [mlir][Linalg] NFC - Automate the printing of canonicalizers and folders for nameds Linalg ops.
This revision reduces the number of places that specific information needs to be modified when adding new named Linalg ops.

Differential Revision: https://reviews.llvm.org/D89223
2020-10-12 11:22:29 +00:00
Nicolas Vasilache 422aaf31da [mlir][Linalg] Add named Linalg ops on tensor to buffer support.
This revision introduces support for buffer allocation for any named linalg op.
To avoid template instantiating many ops, a new ConversionPattern is created to capture the LinalgOp interface.

Some APIs are updated to remain consistent with MLIR style:
`OwningRewritePatternList * -> OwningRewritePatternList &`
`BufferAssignmentTypeConverter * -> BufferAssignmentTypeConverter &`

Differential revision: https://reviews.llvm.org/D89226
2020-10-12 11:20:23 +00:00
Nicolas Vasilache 60cf8453d0 Revert "Revert "Give attributes C++ namespaces.""
This reverts commit df295fac6c.

Reactivates a spuriously rolled back change.
2020-10-12 08:23:54 +00:00
Nicolas Vasilache df295fac6c Revert "Give attributes C++ namespaces."
This reverts commit 0a34492f36.

This change turned out to be very intrusive wrt some internal projects.
Reverting until this can be sorted out.
2020-10-09 19:41:41 +00:00
Andrzej Warzynski dcd9be43e5 [mlir] Fix shared libs build
Reverts one breaking change introduced in
https://reviews.llvm.org/D88846.

Differential Revision: https://reviews.llvm.org/D89111
2020-10-09 16:38:42 +01:00
Mehdi Amini 5367a8b67f Revert "[MLIR] Add a foldTrait() mechanism to allow traits to define folding and test it with an Involution trait"
This reverts commit 1ceaffd95a.

The build is broken with  -DBUILD_SHARED_LIBS=ON ; seems like a possible
layering issue to investigate:

tools/mlir/lib/IR/CMakeFiles/obj.MLIRIR.dir/Operation.cpp.o: In function `mlir::MemoryEffectOpInterface::hasNoEffect(mlir::Operation*)':
Operation.cpp:(.text._ZN4mlir23MemoryEffectOpInterface11hasNoEffectEPNS_9OperationE[_ZN4mlir23MemoryEffectOpInterface11hasNoEffectEPNS_9OperationE]+0x9c): undefined reference to `mlir::MemoryEffectOpInterface::getEffects(llvm::SmallVectorImpl<mlir::SideEffects::EffectInstance<mlir::MemoryEffects::Effect> >&)'
2020-10-09 06:16:42 +00:00
Federico Lebrón 0a34492f36 Give attributes C++ namespaces.
Reviewed By: mehdi_amini, jpienaar

Differential Revision: https://reviews.llvm.org/D89014
2020-10-09 05:36:27 +00:00
Serge Guelton d94f70fb98 [mlir] Improve LLVM shlib support
mlir-tblgen was incompatible with libLLVM, due to explicit linkage with
libLLVMSupport etc.
As it cannot link with libLLVM, make sure all lib it uses are not using libLLVM
either.

As a side effect, also remove some explicit references to LLVM libs and use
components instead.

Differential Revision: https://reviews.llvm.org/D88846
2020-10-09 07:17:56 +02:00
ahmedsabie 1ceaffd95a [MLIR] Add a foldTrait() mechanism to allow traits to define folding and test it with an Involution trait
This change allows folds to be done on a newly introduced involution trait rather than having to manually rewrite this optimization for every instance of an involution

Reviewed By: rriddle, andyly, stephenneuendorffer

Differential Revision: https://reviews.llvm.org/D88809
2020-10-09 03:25:53 +00:00
Christian Sigg cc83dc191c Import llvm::StringSwitch into mlir namespace.
Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D88971
2020-10-08 11:39:24 +02:00
Konrad Dobros c9f1c50fc0 [mlir][spirv] Fix extended insts deserialization generation
This change replaces container used for storing temporary
strings for generated code to std::list.
SmallVector may reallocate internal data, which will invalidate
references when more than one extended instruction set is
generated.

Reviewed By: mravishankar, antiagainst

Differential Revision: https://reviews.llvm.org/D88626
2020-10-06 13:34:58 -04:00
Stephen Neuendorffer b0dce6b37f Revert "[RFC] Factor out repetitive cmake patterns for llvm-style projects"
This reverts commit e9b87f43bd.

There are issues with macros generating macros without an obvious simple fix
so I'm going to revert this and try something different.
2020-10-04 15:17:34 -07:00
Stephen Neuendorffer e9b87f43bd [RFC] Factor out repetitive cmake patterns for llvm-style projects
New projects (particularly out of tree) have a tendency to hijack the existing
llvm configuration options and build targets (add_llvm_library,
add_llvm_tool).  This can lead to some confusion.

1) When querying a configuration variable, do we care about how LLVM was
configured, or how these options were configured for the out of tree project?
2) LLVM has lots of defaults, which are easy to miss
(e.g. LLVM_BUILD_TOOLS=ON).  These options all need to be duplicated in the
CMakeLists.txt for the project.

In addition, with LLVM Incubators coming online, we need better ways for these
incubators to do things the "LLVM way" without alot of futzing.  Ideally, this
would happen in a way that eases importing into the LLVM monorepo when
projects mature.

This patch creates some generic infrastructure in llvm/cmake/modules and
refactors MLIR to use this infrastructure.  This should expand to include
add_xxx_library, which is by far the most complicated bit of building a
project correctly, since it has to deal with lots of shared library
configuration bits.  (MLIR currently hijacks the LLVM infrastructure for
building libMLIR.so, so this needs to get refactored anyway.)

Differential Revision: https://reviews.llvm.org/D85140
2020-10-03 17:12:35 -07:00
Jacques Pienaar 9b851527d5 Add indented raw_ostream class
Class simplifies keeping track of the indentation while emitting. For every new line the current indentation is simply prefixed (if not at start of line, then it just emits as normal). Add a simple Region helper that makes it easy to have the C++ scope match the emitted scope.

Use this in op doc generator and rewrite generator.

This reverts revert commit be185b6a73 addresses shared lib failure by fixing up cmake files.

Differential Revision: https://reviews.llvm.org/D84107
2020-10-03 15:17:38 -07:00
Jacques Pienaar be185b6a73 Revert "Add indented raw_ostream class"
This reverts commit 78530ce653.

Fails on shared_lib build.
2020-10-03 09:41:35 -07:00
Jacques Pienaar 78530ce653 Add indented raw_ostream class
Class simplifies keeping track of the indentation while emitting. For every new line the current indentation is simply prefixed (if not at start of line, then it just emits as normal). Add a simple Region helper that makes it easy to have the C++ scope match the emitted scope.

Use this in op doc generator and rewrite generator.

Differential Revision: https://reviews.llvm.org/D84107
2020-10-03 08:53:43 -07:00
MaheshRavishankar c694588fc5 [mlir][Linalg] Add pattern to tile and fuse Linalg operations on buffers.
The pattern is structured similar to other patterns like
LinalgTilingPattern. The fusion patterns takes options that allows you
to fuse with producers of multiple operands at once.
- The pattern fuses only at the level that is known to be legal, i.e
  if a reduction loop in the consumer is tiled, then fusion should
  happen "before" this loop. Some refactoring of the fusion code is
  needed to fuse only where it is legal.
- Since the fusion on buffers uses the LinalgDependenceGraph that is
  not mutable in place the fusion pattern keeps the original
  operations in the IR, but are tagged with a marker that can be later
  used to find the original operations.

This change also fixes an issue with tiling and
distribution/interchange where if the tile size of a loop were 0 it
wasnt account for in these.

Differential Revision: https://reviews.llvm.org/D88435
2020-09-30 14:56:58 -07:00
John Demme 76419525fb Common code preparation for tblgen-types patch
Cleanup and add methods which https://reviews.llvm.org/D86904 requires. Breaking up to lower review load.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D88267
2020-09-26 02:47:48 +00:00
Rahul Joshi 2d128b04d9 [NFC] Fix build warnings 2020-09-25 09:35:41 -07:00
Mike Urbach d14cfe1034 [mlir][OpFormatGen] Update "custom" directives for attributes.
This tweaks the generated code for parsing attributes with a custom
directive to call `addAttribute` on the `OperationState` directly,
and adds a newline after this call. Previously, the generated code
would call `addAttribute` on the `OperationState` field `attributes`,
which has no such method and fails to compile. Furthermore, the lack
of newline would generate code with incorrectly formatted single line
`if` statements. Added tests for parsing and printing attributes with
a custom directive.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D87860
2020-09-23 18:33:39 +00:00
Rahul Joshi a6ae695017 [MLIR][NFC] Adopt use of BlockRange in place of ArrayRef<Block *>
- Use BlockRange in ODS generated builders as well as other places throughout the code

Differential Revision: https://reviews.llvm.org/D87955
2020-09-23 09:21:54 -07:00
Rahul Joshi 9744606614 [MLIR] Change default builders generated by TableGen to use TypeRange for result types
- Change the default builders to use TypeRange instead of ArrayRef<Type>
- Custom builders defined in LinalgStructuredOps now conflict with the default
  separate param ones, but the default collective params one is still needed. Resolve
  this by replicating the collective param builder as a custom builder and skipping
  the generation of default builders for these ops.

Differential Revision: https://reviews.llvm.org/D87926
2020-09-23 09:06:07 -07:00
Jacques Pienaar 80deb1e106 [mlir][ods] Custom builder with no params
Incorrect generation of custom build method without any params.
2020-09-23 08:11:13 -07:00
Mehdi Amini fb1de7ed92 Implement a new kind of Pass: dynamic pass pipeline
Instead of performing a transformation, such pass yields a new pass pipeline
to run on the currently visited operation.
This feature can be used for example to implement a sub-pipeline that
would run only on an operation with specific attributes. Another example
would be to compute a cost model and dynamic schedule a pipeline based
on the result of this analysis.

Discussion: https://llvm.discourse.group/t/rfc-dynamic-pass-pipeline/1637

Recommit after fixing an ASAN issue: the callback lambda needs to be
allocated to a temporary to have its lifetime extended to the end of the
current block instead of just the current call expression.

Reviewed By: silvas

Differential Revision: https://reviews.llvm.org/D86392
2020-09-22 18:51:54 +00:00
Jacques Pienaar 2a6db92ca9 [mlir][ods] Make OpBuilder and OperationState optional
The OpBuilder is required to start with OpBuilder and OperationState, so remove
the need for the user to specify it. To make it simpler to update callers,
retain the legacy behavior for now and skip injecting OpBuilder/OperationState
when params start with OpBuilder.

Related to bug 47442.

Differential Revision: https://reviews.llvm.org/D88050
2020-09-22 10:04:21 -07:00
Thomas Joerg 0356a413a4 Revert "Implement a new kind of Pass: dynamic pass pipeline"
This reverts commit 385c3f43fc.

Test  mlir/test/Pass:dynamic-pipeline-fail-on-parent.mlir.test fails
when run with ASAN:

ERROR: AddressSanitizer: stack-use-after-scope on address ...

Reviewed By: bkramer, pifon2a

Differential Revision: https://reviews.llvm.org/D88079
2020-09-22 12:00:30 +02:00
Nicolas Vasilache ed229132f1 [mlir][Linalg] Uniformize linalg.generic with named ops.
This revision allows representing a reduction at the level of linalg on tensors for generic ops by uniformizing with the named ops approach.
2020-09-22 04:13:22 -04:00
Mehdi Amini 385c3f43fc Implement a new kind of Pass: dynamic pass pipeline
Instead of performing a transformation, such pass yields a new pass pipeline
to run on the currently visited operation.
This feature can be used for example to implement a sub-pipeline that
would run only on an operation with specific attributes. Another example
would be to compute a cost model and dynamic schedule a pipeline based
on the result of this analysis.

Discussion: https://llvm.discourse.group/t/rfc-dynamic-pass-pipeline/1637

Reviewed By: silvas

Differential Revision: https://reviews.llvm.org/D86392
2020-09-22 01:24:25 +00:00
jerryyin f87ceb63eb [AMDGPU] Adding mutex to guard lld:🧝:link interface use
check-mlir target run tests simultaneously with multiple threads. This caused multiple threads to invoke the `lld:🧝:link()` interface at the same time. Since the interface does not have a thread-safe implementation, add a metex to prevent multi-threaded access.

I discovered this by looking the the failure stack trace. lld/ELF/symbolTable.cpp, SymbolTable::insert() hit into an assert with related to Epoch Trackers. The root cause is to due to there is no protection around the symMap (update) which is implemented in non-thread safe data structure: denseMap.

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

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

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

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

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

Other parts of linalg will be extended accordingly to allow mixed buffer/tensor semantics in the presence of reductions.
2020-09-18 06:14:30 -04:00
Rahul Joshi 8069844577 [MLIR][TableGen] Automatic detection and elimination of redundant methods
- Change OpClass new method addition to find and eliminate any existing methods that
  are made redundant by the newly added method, as well as detect if the newly added
  method will be redundant and return nullptr in that case.
- To facilitate that, add the notion of resolved and unresolved parameters, where resolved
  parameters have each parameter type known, so that redundancy checks on methods
  with same name but different parameter types can be done.
- Eliminate existing code to avoid adding conflicting/redundant build methods and rely
  on this new mechanism to eliminate conflicting build methods.

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

Differential Revision: https://reviews.llvm.org/D87059
2020-09-17 16:04:37 -07:00
Navdeep Kumar 0602e8f77f [MLIR][Affine] Add parametric tile size support for affine.for tiling
Add support to tile affine.for ops with parametric sizes (i.e., SSA
values). Currently supports hyper-rectangular loop nests with constant
lower bounds only. Move methods

  - moveLoopBody(*)
  - getTileableBands(*)
  - checkTilingLegality(*)
  - tilePerfectlyNested(*)
  - constructTiledIndexSetHyperRect(*)

to allow reuse with constant tile size API. Add a test pass -test-affine
-parametric-tile to test parametric tiling.

Differential Revision: https://reviews.llvm.org/D87353
2020-09-17 23:39:14 +05:30
jerryyin fb18202836 [AMDGPU] Fix ROCm unit test memref initialization 2020-09-17 09:48:05 -07:00
jerryyin e4a198eeee [AMDGPU] Bump to ROCm 3.7 dependency hip_hcc->amdhip64
Differential Revision: https://reviews.llvm.org/D87773
2020-09-17 06:45:51 -07:00
Federico Lebrón 7d1ed69c8a Make namespace handling uniform across dialect backends.
Now backends spell out which namespace they want to be in, instead of relying on
clients #including them inside already-opened namespaces. This also means that
cppNamespaces should be fully qualified, and there's no implicit "::mlir::"
prepended to them anymore.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D86811
2020-09-14 20:33:31 +00:00
Nicolas Vasilache e6f2f17f05 [mlir][Linalg] Refactor StructuredOpInterface - NFC
This revision refactors and cleans up a bunch of things to simplify StructuredOpInterface
before work can proceed on Linalg on tensors:
- break out pieces of the StructuredOps trait that are part of the StructuredOpInterface,
- drop referenceIterators and referenceIndexingMaps that end up being more confusing than useful,
- drop NamedStructuredOpTrait
2020-09-11 07:53:12 -04:00
MaheshRavishankar 0a391c6079 [mlir][Analysis] Allow Slice Analysis to work with linalg::LinalgOp
Differential Revision: https://reviews.llvm.org/D87307
2020-09-10 18:54:22 -07:00
Jakub Lichman 67b37f571c [mlir] Conv ops vectorization pass
In this commit a new way of convolution ops lowering is introduced.
The conv op vectorization pass lowers linalg convolution ops
into vector contractions. This lowering is possible when conv op
is first tiled by 1 along specific dimensions which transforms
it into dot product between input and kernel subview memory buffers.
This pass converts such conv op into vector contraction and does
all necessary vector transfers that make it work.

Differential Revision: https://reviews.llvm.org/D86619
2020-09-08 08:47:42 +00:00
Mehdi Amini 63d1dc6665 Add a doc/tutorial on traversing the IR
Reviewed By: stephenneuendorffer

Differential Revision: https://reviews.llvm.org/D87221
2020-09-08 00:07:03 +00:00
Marius Brehler c633842f13 [mlir] Fix includes in mlir-translate
Drops the include on InitAllDialects.h, as dialects are now initialized in the translation passes.

Differential Revision: https://reviews.llvm.org/D87129
2020-09-04 15:22:38 +02:00
Lei Zhang 7939b76e2a [mlir] Support default valued attribute in StructsGen
Its handling is similar to optional attributes, except for the
getter method.

Reviewed By: rsuderman

Differential Revision: https://reviews.llvm.org/D87055
2020-09-03 09:46:44 -04:00
Mehdi Amini 6478caa034 Tweak `mlir-linalg-ods-gen` library dependency: only MLIRIR is needed, not the entire parser (NFC) 2020-09-02 23:58:32 +00:00
Thomas Raoux 8d65504223 [mlir][vulkan-runner] Explicitly export vulkan-runtime-wrapper entry points.
This ensure that the symbols are being exported no matter what default
visibility is set.
2020-09-01 15:37:54 -07:00
Mehdi Amini f54914081f Fix mlir-reduce to explicitly register dialects and disable the global dialect registry by default
Clients who rely on the Context loading dialects from the global
registry can call `mlir::enableGlobalDialectRegistry(true);` before
creating an MLIRContext

Differential Revision: https://reviews.llvm.org/D86897
2020-08-31 22:54:58 +00:00
River Riddle eaeadce9bd [mlir][OpFormatGen] Add initial support for regions in the custom op assembly format
This adds some initial support for regions and does not support formatting the specific arguments of a region. For now this can be achieved by using a custom directive that formats the arguments and then parses the region.

Differential Revision: https://reviews.llvm.org/D86760
2020-08-31 13:26:24 -07:00
River Riddle 24b88920fe [mlir][ODS] Add new SymbolNameAttr and add support for in assemblyFormat
Symbol names are a special form of StringAttr that get treated specially in certain areas, such as formatting. This revision adds a special derived attr for them in ODS and adds support in the assemblyFormat for formatting them properly.

Differential Revision: https://reviews.llvm.org/D86759
2020-08-31 13:26:23 -07:00
River Riddle 88c6e25e4f [mlir][OpFormatGen] Add support for specifiy "custom" directives.
This revision adds support for custom directives to the declarative assembly format. This allows for users to use C++ for printing and parsing subsections of an otherwise declaratively specified format. The custom directive is structured as follows:

```
custom-directive ::= `custom` `<` UserDirective `>` `(` Params `)`
```

`user-directive` is used as a suffix when this directive is used during printing and parsing. When parsing, `parseUserDirective` will be invoked. When printing, `printUserDirective` will be invoked. The first parameter to these methods must be a reference to either the OpAsmParser, or OpAsmPrinter. The type of rest of the parameters is dependent on the `Params` specified in the assembly format.

Differential Revision: https://reviews.llvm.org/D84719
2020-08-31 13:26:23 -07:00
Mehdi Amini 719548d63d Fix gcc warning by explicitly initializing the base class copy ctor (NFC)
Full diagnostic was:

warning: base class ‘class mlir::OptReductionBase<mlir::OptReductionPass>’ should be explicitly initialized in the copy constructor [-Wextra]
2020-08-30 17:46:51 +00:00
Kamlesh Kumar deb99610ab Improve doc comments for several methods returning bools
Differential Revision: https://reviews.llvm.org/D86848
2020-08-30 13:33:05 +05:30
Kazuaki Ishizaki a23d055912 [mlir] NFC: fix trivial typo under test and tools
Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D86648
2020-08-27 15:37:42 +09:00
Ni Hui df2efd7700 Fix MLIR build with MLIR_INCLUDE_TESTS=OFF
error message

/usr/bin/ld: CMakeFiles/mlir-opt.dir/mlir-opt.cpp.o: in function `main':
mlir-opt.cpp:(.text.startup.main+0xb9): undefined reference to `mlir::registerTestDialect(mlir::DialectRegistry&)'

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D86592
2020-08-27 04:04:20 +00:00
River Riddle d289a97f91 [mlir][PDL] Add a PDL Interpreter Dialect
The PDL Interpreter dialect provides a lower level abstraction compared to the PDL dialect, and is targeted towards low level optimization and interpreter code generation. The dialect operations encapsulates low-level pattern match and rewrite "primitives", such as navigating the IR (Operation::getOperand), creating new operations (OpBuilder::create), etc. Many of the operations within this dialect also fuse branching control flow with some form of a predicate comparison operation. This type of fusion reduces the amount of work that an interpreter must do when executing.

An example of this representation is shown below:

```mlir
// The following high level PDL pattern:
pdl.pattern : benefit(1) {
  %resultType = pdl.type
  %inputOperand = pdl.input
  %root, %results = pdl.operation "foo.op"(%inputOperand) -> %resultType
  pdl.rewrite %root {
    pdl.replace %root with (%inputOperand)
  }
}

// May be represented in the interpreter dialect as follows:
module {
  func @matcher(%arg0: !pdl.operation) {
    pdl_interp.check_operation_name of %arg0 is "foo.op" -> ^bb2, ^bb1
  ^bb1:
    pdl_interp.return
  ^bb2:
    pdl_interp.check_operand_count of %arg0 is 1 -> ^bb3, ^bb1
  ^bb3:
    pdl_interp.check_result_count of %arg0 is 1 -> ^bb4, ^bb1
  ^bb4:
    %0 = pdl_interp.get_operand 0 of %arg0
    pdl_interp.is_not_null %0 : !pdl.value -> ^bb5, ^bb1
  ^bb5:
    %1 = pdl_interp.get_result 0 of %arg0
    pdl_interp.is_not_null %1 : !pdl.value -> ^bb6, ^bb1
  ^bb6:
    pdl_interp.record_match @rewriters::@rewriter(%0, %arg0 : !pdl.value, !pdl.operation) : benefit(1), loc([%arg0]), root("foo.op") -> ^bb1
  }
  module @rewriters {
    func @rewriter(%arg0: !pdl.value, %arg1: !pdl.operation) {
      pdl_interp.replace %arg1 with(%arg0)
      pdl_interp.return
    }
  }
}
```

Differential Revision: https://reviews.llvm.org/D84579
2020-08-26 05:22:27 -07:00
Eric Christopher 1a2a34a38a Add NDEBUG checks around debug only loop to avoid unused variable
warnings.
2020-08-24 17:58:57 -07:00
Mehdi Amini f164534ca8 Add a `dialect_registration` callback for "translations" registered with mlir-translate
This will allow out-of-tree translation to register the dialects they expect
to see in their input, on the model of getDependentDialects() for passes.

Differential Revision: https://reviews.llvm.org/D86409
2020-08-23 01:00:39 +00:00
Mehdi Amini 96cb8cdeb0 Refactor `mlir-translate` to extract the `main()` logic in a helper on the model of `MlirOptMain()` (NFC)
Differential Revision: https://reviews.llvm.org/D86408
2020-08-23 01:00:31 +00:00
Mauricio Sifontes 21f8d41468 Refactor Reduction Tree Pass
Refactor the way the reduction tree pass works in the MLIR Reduce tool by introducing a set of utilities that facilitate the implementation of new Reducer classes to be used in the passes.

This will allow for the fast implementation of general transformations to operate on all mlir modules as well as custom transformations for different dialects.

These utilities allow for the implementation of Reducer classes by simply defining a method that indexes the operations/blocks/regions to be transformed and a method to perform the deletion or transfomration based on the indexes.

Create the transformSpace class member in the ReductionNode class to keep track of the indexes that have already been transformed or deleted at a current level.

Delete the FunctionReducer class and replace it with the OpReducer class to reflect this new API while performing the same transformation and allowing the instantiation of a reduction pass for different types of operations at the module's highest hierarchichal level.

Modify the SinglePath Traversal method to reflect the use of the new API.

Reviewed: jpienaar

Differential Revision: https://reviews.llvm.org/D85591
2020-08-21 04:59:24 +00:00
River Riddle 3fb3927bd3 [mlir] Add a new "Pattern Descriptor Language" (PDL) dialect.
PDL presents a high level abstraction for the rewrite pattern infrastructure available in MLIR. This abstraction allows for representing patterns transforming MLIR, as MLIR. This allows for applying all of the benefits that the general MLIR infrastructure provides, to the infrastructure itself. This means that pattern matching can be more easily verified for correctness, targeted by frontends, and optimized.

PDL abstracts over various different aspects of patterns and core MLIR data structures. Patterns are specified via a `pdl.pattern` operation. These operations contain a region body for the "matcher" code, and terminate with a `pdl.rewrite` that either dispatches to an external rewriter or contains a region for the rewrite specified via `pdl`. The types of values in `pdl` are handle types to MLIR C++ types, with `!pdl.attribute`, `!pdl.operation`, and `!pdl.type` directly mapping to `mlir::Attribute`, `mlir::Operation*`, and `mlir::Value` respectively.

An example pattern is shown below:

```mlir
// pdl.pattern contains metadata similarly to a `RewritePattern`.
pdl.pattern : benefit(1) {
  // External input operand values are specified via `pdl.input` operations.
  // Result types are constrainted via `pdl.type` operations.

  %resultType = pdl.type
  %inputOperand = pdl.input
  %root, %results = pdl.operation "foo.op"(%inputOperand) -> %resultType
  pdl.rewrite(%root) {
    pdl.replace %root with (%inputOperand)
  }
}
```

This is a culmination of the work originally discussed here: https://groups.google.com/a/tensorflow.org/g/mlir/c/j_bn74ByxlQ

Differential Revision: https://reviews.llvm.org/D84578
2020-08-19 13:13:06 -07:00
Mehdi Amini f9dc2b7079 Separate the Registration from Loading dialects in the Context
This changes the behavior of constructing MLIRContext to no longer load globally
registered dialects on construction. Instead Dialects are only loaded explicitly
on demand:
- the Parser is lazily loading Dialects in the context as it encounters them
during parsing. This is the only purpose for registering dialects and not load
them in the context.
- Passes are expected to declare the dialects they will create entity from
(Operations, Attributes, or Types), and the PassManager is loading Dialects into
the Context when starting a pipeline.

This changes simplifies the configuration of the registration: a compiler only
need to load the dialect for the IR it will emit, and the optimizer is
self-contained and load the required Dialects. For example in the Toy tutorial,
the compiler only needs to load the Toy dialect in the Context, all the others
(linalg, affine, std, LLVM, ...) are automatically loaded depending on the
optimization pipeline enabled.

To adjust to this change, stop using the existing dialect registration: the
global registry will be removed soon.

1) For passes, you need to override the method:

virtual void getDependentDialects(DialectRegistry &registry) const {}

and registery on the provided registry any dialect that this pass can produce.
Passes defined in TableGen can provide this list in the dependentDialects list
field.

2) For dialects, on construction you can register dependent dialects using the
provided MLIRContext: `context.getOrLoadDialect<DialectName>()`
This is useful if a dialect may canonicalize or have interfaces involving
another dialect.

3) For loading IR, dialect that can be in the input file must be explicitly
registered with the context. `MlirOptMain()` is taking an explicit registry for
this purpose. See how the standalone-opt.cpp example is setup:

  mlir::DialectRegistry registry;
  registry.insert<mlir::standalone::StandaloneDialect>();
  registry.insert<mlir::StandardOpsDialect>();

Only operations from these two dialects can be in the input file. To include all
of the dialects in MLIR Core, you can populate the registry this way:

  mlir::registerAllDialects(registry);

4) For `mlir-translate` callback, as well as frontend, Dialects can be loaded in
the context before emitting the IR: context.getOrLoadDialect<ToyDialect>()

Differential Revision: https://reviews.llvm.org/D85622
2020-08-19 01:19:03 +00:00
Mehdi Amini e75bc5c791 Revert "Separate the Registration from Loading dialects in the Context"
This reverts commit d14cf45735.
The build is broken with GCC-5.
2020-08-19 01:19:03 +00:00
Mehdi Amini d14cf45735 Separate the Registration from Loading dialects in the Context
This changes the behavior of constructing MLIRContext to no longer load globally
registered dialects on construction. Instead Dialects are only loaded explicitly
on demand:
- the Parser is lazily loading Dialects in the context as it encounters them
during parsing. This is the only purpose for registering dialects and not load
them in the context.
- Passes are expected to declare the dialects they will create entity from
(Operations, Attributes, or Types), and the PassManager is loading Dialects into
the Context when starting a pipeline.

This changes simplifies the configuration of the registration: a compiler only
need to load the dialect for the IR it will emit, and the optimizer is
self-contained and load the required Dialects. For example in the Toy tutorial,
the compiler only needs to load the Toy dialect in the Context, all the others
(linalg, affine, std, LLVM, ...) are automatically loaded depending on the
optimization pipeline enabled.

To adjust to this change, stop using the existing dialect registration: the
global registry will be removed soon.

1) For passes, you need to override the method:

virtual void getDependentDialects(DialectRegistry &registry) const {}

and registery on the provided registry any dialect that this pass can produce.
Passes defined in TableGen can provide this list in the dependentDialects list
field.

2) For dialects, on construction you can register dependent dialects using the
provided MLIRContext: `context.getOrLoadDialect<DialectName>()`
This is useful if a dialect may canonicalize or have interfaces involving
another dialect.

3) For loading IR, dialect that can be in the input file must be explicitly
registered with the context. `MlirOptMain()` is taking an explicit registry for
this purpose. See how the standalone-opt.cpp example is setup:

  mlir::DialectRegistry registry;
  registry.insert<mlir::standalone::StandaloneDialect>();
  registry.insert<mlir::StandardOpsDialect>();

Only operations from these two dialects can be in the input file. To include all
of the dialects in MLIR Core, you can populate the registry this way:

  mlir::registerAllDialects(registry);

4) For `mlir-translate` callback, as well as frontend, Dialects can be loaded in
the context before emitting the IR: context.getOrLoadDialect<ToyDialect>()

Differential Revision: https://reviews.llvm.org/D85622
2020-08-18 23:23:56 +00:00
Mehdi Amini d84fe55e0d Revert "Separate the Registration from Loading dialects in the Context"
This reverts commit e1de2b7550.
Broke a build bot.
2020-08-18 22:16:34 +00:00
Mehdi Amini e1de2b7550 Separate the Registration from Loading dialects in the Context
This changes the behavior of constructing MLIRContext to no longer load globally
registered dialects on construction. Instead Dialects are only loaded explicitly
on demand:
- the Parser is lazily loading Dialects in the context as it encounters them
during parsing. This is the only purpose for registering dialects and not load
them in the context.
- Passes are expected to declare the dialects they will create entity from
(Operations, Attributes, or Types), and the PassManager is loading Dialects into
the Context when starting a pipeline.

This changes simplifies the configuration of the registration: a compiler only
need to load the dialect for the IR it will emit, and the optimizer is
self-contained and load the required Dialects. For example in the Toy tutorial,
the compiler only needs to load the Toy dialect in the Context, all the others
(linalg, affine, std, LLVM, ...) are automatically loaded depending on the
optimization pipeline enabled.

To adjust to this change, stop using the existing dialect registration: the
global registry will be removed soon.

1) For passes, you need to override the method:

virtual void getDependentDialects(DialectRegistry &registry) const {}

and registery on the provided registry any dialect that this pass can produce.
Passes defined in TableGen can provide this list in the dependentDialects list
field.

2) For dialects, on construction you can register dependent dialects using the
provided MLIRContext: `context.getOrLoadDialect<DialectName>()`
This is useful if a dialect may canonicalize or have interfaces involving
another dialect.

3) For loading IR, dialect that can be in the input file must be explicitly
registered with the context. `MlirOptMain()` is taking an explicit registry for
this purpose. See how the standalone-opt.cpp example is setup:

  mlir::DialectRegistry registry;
  mlir::registerDialect<mlir::standalone::StandaloneDialect>();
  mlir::registerDialect<mlir::StandardOpsDialect>();

Only operations from these two dialects can be in the input file. To include all
of the dialects in MLIR Core, you can populate the registry this way:

  mlir::registerAllDialects(registry);

4) For `mlir-translate` callback, as well as frontend, Dialects can be loaded in
the context before emitting the IR: context.getOrLoadDialect<ToyDialect>()
2020-08-18 21:14:39 +00:00
Mauricio Sifontes 8f4859d351 Create Optimization Pass Wrapper for MLIR Reduce
Create a reduction pass that accepts an optimization pass as argument
and only replaces the golden module in the pipeline if the output of the
optimization pass is smaller than the input and still exhibits the
interesting behavior.

Add a -test-pass option to test individual passes in the MLIR Reduce
tool.

Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D84783
2020-08-18 16:47:10 +00:00
Mehdi Amini 54ce344314 Refactor mlir-opt setup in a new helper function (NFC)
This will help refactoring some of the tools to prepare for the explicit registration of
Dialects.

Differential Revision: https://reviews.llvm.org/D86023
2020-08-15 20:09:06 +00:00
Mehdi Amini 25ee851746 Revert "Separate the Registration from Loading dialects in the Context"
This reverts commit 2056393387.

Build is broken on a few bots
2020-08-15 09:21:47 +00:00
Mehdi Amini 2056393387 Separate the Registration from Loading dialects in the Context
This changes the behavior of constructing MLIRContext to no longer load globally registered dialects on construction. Instead Dialects are only loaded explicitly on demand:
- the Parser is lazily loading Dialects in the context as it encounters them during parsing. This is the only purpose for registering dialects and not load them in the context.
- Passes are expected to declare the dialects they will create entity from (Operations, Attributes, or Types), and the PassManager is loading Dialects into the Context when starting a pipeline.

This changes simplifies the configuration of the registration: a compiler only need to load the dialect for the IR it will emit, and the optimizer is self-contained and load the required Dialects. For example in the Toy tutorial, the compiler only needs to load the Toy dialect in the Context, all the others (linalg, affine, std, LLVM, ...) are automatically loaded depending on the optimization pipeline enabled.

Differential Revision: https://reviews.llvm.org/D85622
2020-08-15 08:07:31 +00:00
Mehdi Amini ba92dadf05 Revert "Separate the Registration from Loading dialects in the Context"
This was landed by accident, will reland with the right comments
addressed from the reviews.
Also revert dependent build fixes.
2020-08-15 07:35:10 +00:00
Mehdi Amini ebf521e784 Separate the Registration from Loading dialects in the Context
This changes the behavior of constructing MLIRContext to no longer load globally registered dialects on construction. Instead Dialects are only loaded explicitly on demand:
- the Parser is lazily loading Dialects in the context as it encounters them during parsing. This is the only purpose for registering dialects and not load them in the context.
- Passes are expected to declare the dialects they will create entity from (Operations, Attributes, or Types), and the PassManager is loading Dialects into the Context when starting a pipeline.

This changes simplifies the configuration of the registration: a compiler only need to load the dialect for the IR it will emit, and the optimizer is self-contained and load the required Dialects. For example in the Toy tutorial, the compiler only needs to load the Toy dialect in the Context, all the others (linalg, affine, std, LLVM, ...) are automatically loaded depending on the optimization pipeline enabled.
2020-08-14 09:40:27 +00:00
Alexander Belyaev fed9ff5117 [mlir] Test CallOp STD->LLVM conversion.
This exercises the corner case that was fixed in
https://reviews.llvm.org/rG8979a9cdf226066196f1710903d13492e6929563.

The bug can be reproduced when there is a @callee with a custom type argument and @caller has a producer of this argument passed to the @callee.

Example:
func @callee(!test.test_type) -> i32
func @caller() -> i32 {
  %arg = "test.type_producer"() : () -> !test.test_type
  %out = call @callee(%arg) : (!test.test_type) -> i32
  return %out : i32
}

Even though there is a type conversion for !test.test_type, the output IR (before the fix) contained a DialectCastOp:

module {
  llvm.func @callee(!llvm.ptr<i8>) -> !llvm.i32
  llvm.func @caller() -> !llvm.i32 {
    %0 = llvm.mlir.null : !llvm.ptr<i8>
    %1 = llvm.mlir.cast %0 : !llvm.ptr<i8> to !test.test_type
    %2 = llvm.call @callee(%1) : (!test.test_type) -> !llvm.i32
    llvm.return %2 : !llvm.i32
  }
}

instead of

module {
  llvm.func @callee(!llvm.ptr<i8>) -> !llvm.i32
  llvm.func @caller() -> !llvm.i32 {
    %0 = llvm.mlir.null : !llvm.ptr<i8>
    %1 = llvm.call @callee(%0) : (!llvm.ptr<i8>) -> !llvm.i32
    llvm.return %1 : !llvm.i32
  }
}

Differential Revision: https://reviews.llvm.org/D85914
2020-08-13 19:10:21 +02:00
Kiran Chandramohan fc544dcf2d [NFC][MLIR][OpenMP] Add comments and test for OpenMP enum declaration utility
Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D85857
2020-08-14 23:22:23 +01:00
Kiran Chandramohan e6c5e6efd0 [MLIR,OpenMP] Lowering of parallel operation: proc_bind clause 2/n
This patch adds the translation of the proc_bind clause in a
parallel operation.

The values that can be specified for the proc_bind clause are
specified in the OMP.td tablegen file in the llvm/Frontend/OpenMP
directory. From this single source of truth enumeration for
proc_bind is generated in llvm and mlir (used in specification of
the parallel Operation in the OpenMP dialect). A function to return
the enum value from the string representation is also generated.
A new header file (DirectiveEmitter.h) containing definitions of
classes directive, clause, clauseval etc is created so that it can
be used in mlir as well.

Reviewers: clementval, jdoerfert, DavidTruby

Differential Revision: https://reviews.llvm.org/D84347
2020-08-12 08:03:13 +01:00
Jacques Pienaar 29429d1a44 [drr] Add $_loc special directive for NativeCodeCall
Allows propagating the location to ops created via NativeCodeCall.

Differential Revision: https://reviews.llvm.org/D85704
2020-08-11 14:06:17 -07:00
Christian Sigg 2c48e3629c [MLIR] Adding gpu.host_register op and lower it to a runtime call.
Reviewed By: herhut

Differential Revision: https://reviews.llvm.org/D85631
2020-08-10 22:46:17 +02:00
Christian Sigg 0d4b7adb82 [MLIR] Make gpu.launch_func rewrite pattern part of the LLVM lowering pass.
Reviewed By: herhut

Differential Revision: https://reviews.llvm.org/D85073
2020-08-10 19:28:30 +02:00
Rahul Joshi 13d05787d0 [MLIR][TableGen] Fix ambiguous build methods when inferring result types.
- Fix ODS framework to suppress build methods that infer result types and are
  ambiguous with collective variants. This applies to operations with a single variadic
  inputs whose result types can be inferred.
- Extended OpBuildGenTest to test these kinds of ops.

Differential Revision: https://reviews.llvm.org/D85060
2020-08-10 10:05:06 -07:00
Jacques Pienaar 4b211b94d7 [mlir][drr] Make error easier to understand
Changes error from
  error: referencing unbound symbol ''
to
  error: raw string not supported as argument
2020-08-09 18:02:08 -07:00
Mehdi Amini eebd0a57fc Remove unused class member (NFC)
Fix include/mlir/Reducer/ReductionNode.h:79:18: warning: private field 'parent' is not used [-Wunused-private-field]
2020-08-08 05:36:41 +00:00
Mauricio Sifontes 27d0e14da9 Create Reduction Tree Pass
Implement the Reduction Tree Pass framework as part of the MLIR Reduce tool. This is a parametarizable pass that allows for the implementation of custom reductions passes in the tool.
Implement the FunctionReducer class as an example of a Reducer class parameter for the instantiation of a Reduction Tree Pass.
Create a pass pipeline with a Reduction Tree Pass with the FunctionReducer class specified as parameter.

Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D83969
2020-08-07 23:17:31 +00:00
Mehdi Amini 575b22b5d1 Revisit Dialect registration: require and store a TypeID on dialects
This patch moves the registration to a method in the MLIRContext: getOrCreateDialect<ConcreteDialect>()

This method requires dialect to provide a static getDialectNamespace()
and store a TypeID on the Dialect itself, which allows to lazyily
create a dialect when not yet loaded in the context.
As a side effect, it means that duplicated registration of the same
dialect is not an issue anymore.

To limit the boilerplate, TableGen dialect generation is modified to
emit the constructor entirely and invoke separately a "init()" method
that the user implements.

Differential Revision: https://reviews.llvm.org/D85495
2020-08-07 15:57:08 +00:00
Alex Zinenko db1c197bf8 [mlir] take LLVMContext in MLIR-to-LLVM-IR translation
Due to the original type system implementation, LLVMDialect in MLIR contains an
LLVMContext in which the relevant objects (types, metadata) are created. When
an MLIR module using the LLVM dialect (and related intrinsic-based dialects
NVVM, ROCDL, AVX512) is converted to LLVM IR, it could only live in the
LLVMContext owned by the dialect. The type system no longer relies on the
LLVMContext, so this limitation can be removed. Instead, translation functions
now take a reference to an LLVMContext in which the LLVM IR module should be
constructed. The caller of the translation functions is responsible for
ensuring the same LLVMContext is not used concurrently as the translation no
longer uses a dialect-wide context lock.

As an additional bonus, this change removes the need to recreate the LLVM IR
module in a different LLVMContext through printing and parsing back, decreasing
the compilation overhead in JIT and GPU-kernel-to-blob passes.

Reviewed By: rriddle, mehdi_amini

Differential Revision: https://reviews.llvm.org/D85443
2020-08-07 14:22:30 +02:00
Christian Sigg 45676a8936 [MLIR] Change GpuLaunchFuncToGpuRuntimeCallsPass to wrap a RewritePattern with the same functionality.
The RewritePattern will become one of several, and will be part of the LLVM conversion pass (instead of a separate pass following LLVM conversion).

Reviewed By: herhut

Differential Revision: https://reviews.llvm.org/D84946
2020-08-06 11:55:46 +02:00
Alex Zinenko b2ab375d1f [mlir] use the new stateful LLVM type translator by default
Previous type model in the LLVM dialect did not support identified structure
types properly and therefore could use stateless translations implemented as
free functions. The new model supports identified structs and must keep track
of the identified structure types present in the target context (LLVMContext or
MLIRContext) to avoid creating duplicate structs due to LLVM's type
auto-renaming. Expose the stateful type translation classes and use them during
translation, storing the state as part of ModuleTranslation.

Drop the test type translation mechanism that is no longer necessary and update
the tests to exercise type translation as part of the main translation flow.

Update the code in vector-to-LLVM dialect conversion that relied on stateless
translation to use the new class in a stateless manner.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D85297
2020-08-06 00:36:33 +02:00
Alex Zinenko 4e491570b5 [mlir] Remove LLVMTypeTestDialect
This dialect was introduced during the bring-up of the new LLVM dialect type
system for testing purposes. The main LLVM dialect now uses the new type system
and the test dialect is no longer necessary, so remove it.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D85224
2020-08-05 14:39:36 +02:00
Alex Zinenko d4fbbab2e4 [mlir] translate types between MLIR LLVM dialect and LLVM IR
With new LLVM dialect type modeling, the dialect types no longer wrap LLVM IR
types. Therefore, they need to be translated to and from LLVM IR during export
and import. Introduce the relevant functionality for translating types. It is
currently exercised by an ad-hoc type translation roundtripping test that will
be subsumed by the actual translation test when the type system transition is
complete.

Depends On D84339

Reviewed By: herhut

Differential Revision: https://reviews.llvm.org/D85019
2020-08-04 13:42:43 +02:00
River Riddle 8c39e70679 [mlir][OpFormatGen] Add support for eliding UnitAttr when used to anchor an optional group
Unit attributes are given meaning by their existence, and thus have no meaningful value beyond "is it present". As such, in the format of an operation unit attributes are generally used to guard the printing of other elements and aren't generally printed themselves; as the presence of the group when parsing means that the unit attribute should be added. This revision adds support to the declarative format for eliding unit attributes in situations where they anchor an optional group, but aren't the first element.

For example,
```
let assemblyFormat = "(`is_optional` $unit_attr^)? attr-dict";
```

would print `foo.op is_optional` when $unit_attr is present, instead of the current `foo.op is_optional unit`.

Differential Revision: https://reviews.llvm.org/D84577
2020-08-03 14:31:41 -07:00
Alex Zinenko 0c40af6b59 [mlir] First-party modeling of LLVM types
The current modeling of LLVM IR types in MLIR is based on the LLVMType class
that wraps a raw `llvm::Type *` and delegates uniquing, printing and parsing to
LLVM itself. This model makes thread-safe type manipulation hard and is being
progressively replaced with a cleaner MLIR model that replicates the type
system.  Introduce a set of classes reflecting the LLVM IR type system in MLIR
instead of wrapping the existing types. These are currently introduced as
separate classes without affecting the dialect flow, and are exercised through
a test dialect. Once feature parity is reached, the old implementation will be
gradually substituted with the new one.

Depends On D84171

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D84339
2020-08-03 15:45:29 +02:00
River Riddle 2a6c8b2e95 [mlir][PassIncGen] Refactor how pass registration is generated
The current output is a bit clunky and requires including files+macros everywhere, or manually wrapping the file inclusion in a registration function. This revision refactors the pass backend to automatically generate `registerFooPass`/`registerFooPasses` functions that wrap the pass registration. `gen-pass-decls` now takes a `-name` input that specifies a tag name for the group of passes that are being generated. For each pass, the generator now produces a `registerFooPass` where `Foo` is the name of the definition specified in tablegen. It also generates a `registerGroupPasses`, where `Group` is the tag provided via the `-name` input parameter, that registers all of the passes present.

Differential Revision: https://reviews.llvm.org/D84983
2020-07-31 13:20:37 -07:00
Tobias Gysi 77c3b016c4 [mlir] fix error handling in rocm runtime wrapper
The patch fixes minor issues in the rocm runtime wrapper due to api differences between CUDA and HIP.

Reviewed By: herhut

Differential Revision: https://reviews.llvm.org/D84861
2020-07-29 22:08:42 +02:00
Alex Zinenko aec38c619d [mlir] LLVMType: make getUnderlyingType private
The current modeling of LLVM IR types in MLIR is based on the LLVMType class
that wraps a raw `llvm::Type *` and delegates uniquing, printing and parsing to
LLVM itself. This is model makes thread-safe type manipulation hard and is
being progressively replaced with a cleaner MLIR model that replicates the type
system. In the new model, LLVMType will no longer have an underlying LLVM IR
type. Restrict access to this type in the current model in preparation for the
change.

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D84389
2020-07-29 13:43:38 +02:00
MaheshRavishankar e5608cacfd [mlir][GPUToSPIRV] Add a test pass to set workgroup size for kernel
functions.

This allows using command line flags to lowere from GPU to SPIR-V. The
pass added is only for testing/example purposes. Most uses cases will
need more fine-grained control on setting workgroup sizes for kernel
functions.

Differential Revision: https://reviews.llvm.org/D84619
2020-07-28 12:10:30 -07:00
Christian Sigg c64c04bbaa Clean up cuda-runtime-wrappers API.
Do not return error code, instead return created resource handles or void. Error reporting is done by the library function.

Reviewed By: herhut

Differential Revision: https://reviews.llvm.org/D84660
2020-07-28 16:34:08 +02:00
Christian Sigg 2dd7a9cc2d [MLIR] NFC: Rename mcuMemHostRegister* to mgpuMemHostRegister* to make it consistent with the other cuda-runner functions and ROCm.
Summary: Rename mcuMemHostRegister* to mgpuMemHostRegister*.

Reviewers: herhut

Reviewed By: herhut

Subscribers: yaxunl, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, stephenneuendorffer, Joonsoo, grosul1, Kayjukh, jurahul, msifontes

Tags: #mlir

Differential Revision: https://reviews.llvm.org/D84583
2020-07-27 15:48:05 +02:00
Alex Zinenko a51829913d [mlir] Support for mutable types
Introduce support for mutable storage in the StorageUniquer infrastructure.
This makes MLIR have key-value storage instead of just uniqued key storage. A
storage instance now contains a unique immutable key and a mutable value, both
stored in the arena allocator that belongs to the context. This is a
preconditio for supporting recursive types that require delayed initialization,
in particular LLVM structure types.  The functionality is exercised in the test
pass with trivial self-recursive type. So far, recursive types can only be
printed in parsed in a closed type system. Removing this restriction is left
for future work.

Differential Revision: https://reviews.llvm.org/D84171
2020-07-27 13:07:44 +02:00
Kazuaki Ishizaki 06b90586a4 [mlir]: NFC: Fix trivial typo in documents and comments
Differential Revision: https://reviews.llvm.org/D84400
2020-07-23 23:40:57 +09:00
Rahul Joshi 764931d248 [MLIR][TableGen] Add default value for named attributes for 2 more build methods
- Added more default values for `attributes` parameter for 2 more build methods
- Extend the op-decls.td unit test to test these build methods.

Differential Revision: https://reviews.llvm.org/D83839
2020-07-16 09:32:19 -07:00
River Riddle 6b476e2426 [mlir] Add support for parsing optional Attribute values.
This adds a `parseOptionalAttribute` method to the OpAsmParser that allows for parsing optional attributes, in a similar fashion to how optional types are parsed. This also enables the use of attribute values as the first element of an assembly format optional group.

Differential Revision: https://reviews.llvm.org/D83712
2020-07-14 13:14:59 -07:00
Rahul Joshi 256d44811e [MLIR] [TableGen] Avoid generating an assert which is always true.
- Avoid generating "assert(resultTypes.size() >= 0u)" which is always true

Differential Revision: https://reviews.llvm.org/D83735
2020-07-14 09:19:52 -07:00
Jacques Pienaar 3ae43a580e [ods] Enable getting forward decls allow
Summary: Currently forward decls are included with all the op classes. But there are cases (say when splitting up headers) where one wants the forward decls but not all the classes. Add an option to enable this. This does not change any current behavior (some further refactoring is probably due here).

Differential Revision: https://reviews.llvm.org/D83727
2020-07-14 06:52:32 -07:00
Rahul Joshi 0d988da6d1 [MLIR] Change ODS collective params build method to provide an empty default value for named attributes
- Provide default value for `ArrayRef<NamedAttribute> attributes` parameter of
  the collective params build method.
- Change the `genSeparateArgParamBuilder` function to not generate build methods
  that may be ambiguous with the new collective params build method.
- This change should help eliminate passing empty NamedAttribue ArrayRef when the
  collective params build method is used
- Extend op-decl.td unit test to make sure the ambiguous build methods are not
  generated.

Differential Revision: https://reviews.llvm.org/D83517
2020-07-13 13:35:44 -07:00
River Riddle 572c2905ae [mlir][ODS] Add support for specifying the namespace of an interface.
The namespace can be specified using the `cppNamespace` field. This matches the functionality already present on dialects, enums, etc. This fixes problems with using interfaces on operations in a different namespace than the interface was defined in.

Differential Revision: https://reviews.llvm.org/D83604
2020-07-12 14:18:32 -07:00
Yash Jain 102828249c [MLIR] Parallelize affine.for op to 1-D affine.parallel op
Introduce pass to convert parallel affine.for op into 1-D affine.parallel op.
Run using --affine-parallelize. Removes test-detect-parallel: pass for checking
parallel affine.for ops.

Signed-off-by: Yash Jain <yash.jain@polymagelabs.com>

Differential Revision: https://reviews.llvm.org/D83193
2020-07-11 21:33:25 +05:30
Mauricio Sifontes 16e9ccb2be Create TestReducer pass
- Create a pass that generates bugs based on trivially defined behavior for the purpose of testing the MLIR Reduce Tool.
- Implement the functionality inside the pass to crash mlir-opt in the presence of an operation with the name "crashOp".
- Register the pass as a test pass in the mlir-opt tool.

Reviewed by: jpienaar

Differential Revision: https://reviews.llvm.org/D83422
2020-07-11 00:46:57 +00:00
Mauricio Sifontes ec04ce4623 Create the MLIR Reduce framework
Create the framework and testing environment for MLIR Reduce - a tool
with the objective to reduce large test cases into smaller ones while
preserving their interesting behavior.

Implement the functionality to parse command line arguments, parse the
MLIR test cases into modules and run the interestingness tests on
the modules.

Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D82803
2020-07-07 23:42:53 +00:00
Mehdi Amini e10e034f4b Revert "Create the framework and testing environment for MLIR Reduce - a tool"
This reverts commit 28a45d54a7.

Windows bot is broken with:

LLVM ERROR: Error running interestingness test: posix_spawn failed: Permission denied
2020-07-07 15:47:09 +00:00
River Riddle 9db53a1827 [mlir][NFC] Remove usernames and google bug numbers from TODO comments.
These were largely leftover from when MLIR was a google project, and don't really follow LLVM guidelines.
2020-07-07 01:40:52 -07:00
Martin Waitz 72df59d590 [mlir] resolve types from attributes in assemblyFormat
An operation can specify that an operation or result type matches the
type of another operation, result, or attribute via the `AllTypesMatch`
or `TypesMatchWith` constraints.

Use these constraints to also automatically resolve types in the
automatically generated assembly parser.
This way, only the attribute needs to be listed in `assemblyFormat`,
e.g. for constant operations.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D78434
2020-07-07 04:40:01 +00:00
Mauricio Sifontes 28a45d54a7 Create the framework and testing environment for MLIR Reduce - a tool
with the objective to reduce large test cases into smaller ones while
preserving their interesting behavior.

Implement the framework to parse the command line arguments, parse the
input MLIR test case into a module and call reduction passes on the MLIR module.

Implement the Tester class which allows the different reduction passes to test the
interesting behavior of the generated reduced variants of the test case and keep track
of the most reduced generated variant.
2020-07-07 01:59:11 +00:00
Jacques Pienaar 2a19672af5 [mlir] Change ODS to have include and exclude regex
This makes it easier to have a "remainder" include rule. And also makes it easier to read the command line flag.
2020-07-06 09:55:10 -07:00
Mehdi Amini fbc06b2280 Revert "[MLIR] Parallelize affine.for op to 1-D affine.parallel op"
This reverts commit 5f2843857f.
This broke the build when -DDBUILD_SHARED_LIBS=ON is used.
2020-07-04 20:55:47 +00:00
Yash Jain 5f2843857f [MLIR] Parallelize affine.for op to 1-D affine.parallel op
Introduce pass to convert parallel affine.for op into 1-D
affine.parallel op. Run using --affine-parallelize. Removes
test-detect-parallel: pass for checking parallel affine.for ops.

Differential Revision: https://reviews.llvm.org/D82672
2020-07-04 19:09:23 +05:30
River Riddle c59aec0ca1 [mlir][OpFormatGen] Add support for resolving variadic types from non-variadic
This enables better support for traits such as SameOperandsAndResultType, and other situations in which a variadic operand may be resolved from a non-variadic.

Differential Revision: https://reviews.llvm.org/D83011
2020-07-01 22:27:08 -07:00
River Riddle 2e2cdd0a52 [mlir] Refactor InterfaceGen to support generating interfaces for Attributes and Types.
This revision adds support to ODS for generating interfaces for attributes and types, in addition to operations. These interfaces can be specified using `AttrInterface` and `TypeInterface` in place of `OpInterface`. All of the features of `OpInterface` are supported except for the `verify` method, which does not have a matching representation in the Attribute/Type world. Generating these interface can be done using `gen-(attr|type)-interface-(defs|decls|docs)`.

Differential Revision: https://reviews.llvm.org/D81884
2020-06-30 15:52:33 -07:00
Jacques Pienaar 71b9d89df7 [ods] Update Operator to record Arg->[Attr|Operand]Index mapping
Also fixed bug in type inferface generator to address bug where operands and
attributes are interleaved.

Differential Revision: https://reviews.llvm.org/D82819
2020-06-29 16:40:52 -07:00
Thomas Raoux 0e76c0a9ad [mlir][vulkan-runner] Make vulkan runner use GPU device memory
To be able to have more meaningful performance out of workloadsi going through
the vulkan-runner we need to use buffers from GPU device memory as access to
system memory is significantly slower for GPU with dedicated memory. This adds
code to do a copy through staging buffer as GPU memory cannot always be mapped
on the host.

Differential Revision: https://reviews.llvm.org/D82504
2020-06-26 08:03:06 -07:00
Jean-Michel Gorius 05b4ff0a4b [mlir-tblgen] Use fully qualified names in generated code files
Using fully qualified names wherever possible avoids ambiguous class and function names. This is a follow-up to D82371.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D82471
2020-06-26 15:05:33 +02:00
Rahul Joshi d891d738d9 [MLIR][NFC] Adopt variadic isa<>
Differential Revision: https://reviews.llvm.org/D82489
2020-06-24 17:02:44 -07:00
Jean-Michel Gorius 1db1a08dda [mlir] Avoid pontentially ambiguous class name
Summary: The Pass class exists in both the mlir and the llvm namespaces. Use the fully qualified class name to avoid any ambiguities.

Reviewers: rriddle

Reviewed By: rriddle

Subscribers: mehdi_amini, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, stephenneuendorffer, Joonsoo, grosul1, jurahul, msifontes

Tags: #mlir

Differential Revision: https://reviews.llvm.org/D82371
2020-06-23 21:24:43 +02:00
Wen-Heng (Jack) Chung b7c4912996 [mlir][mlir-rocm-runner] Remove compile-time warning. NFC.
Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, stephenneuendorffer, Joonsoo, grosul1, Kayjukh, jurahul, msifontes

Tags: #mlir

Differential Revision: https://reviews.llvm.org/D82333
2020-06-22 21:58:40 -05:00
Jacques Pienaar ada0d41dbc [mlir][ods] Allow filtering of ops
Add option to filter which op the OpDefinitionsGen run on. This enables having multiple ops together in the same TD file but generating different CC files for them (useful if one wants to use multiclasses or split out 1 dialect into multiple different libraries). There is probably more general query here (e.g., split out all ops that don't have a verify method, or that are commutative) but filtering based on op name (e.g., test.a_op) seemed a reasonable start and didn't require inventing a query specification mechanism here.

Differential Revision: https://reviews.llvm.org/D82319
2020-06-22 14:56:54 -07:00
AlexEichenberger 01641197ee [MLIR] Remove TableGen redundant calls to native calls when creating new operations in DRR TableGen files
Summary:
Currently, the TableGen rewrite generates redundant native calls in MLIR DRR files. This is a problem as some native calls may involve significant computations (e.g. when performing constant propagation where every values in a large tensor is touched).

The pattern was as follow:

```c++
if (native-call(args)) tblgen_attrs.emplace_back(rewriter, attribute, native-call(args))
```

The replacement pattern compute `native-call(args)` once and then use it both in the `if` condition and the `emplace_back` call.

Differential Revision: https://reviews.llvm.org/D82101
2020-06-22 08:12:04 -07:00
Thomas Raoux afd43a7a78 [mlir][vulkan-runner] add support for memref of i8, i16 types in vulkan runner
This extends the types supported as kernel arguments when using vulkan runner.

Differential Revision: https://reviews.llvm.org/D82068
2020-06-18 13:24:51 -07:00
Hanhan Wang 9cb10296ec [mlir] Add support for lowering tanh to LLVMIR.
Summary:
Fixed build of D81618

Add a pattern for expanding tanh op into exp form.
A `tanh` is expanded into:
   1) 1-exp^{-2x} / 1+exp^{-2x}, if x => 0
   2) exp^{2x}-1 / exp^{2x}+1  , if x < 0.

Differential Revision: https://reviews.llvm.org/D82040
2020-06-18 10:42:13 -07:00
Nicolas Vasilache eae76faeea [mlir][Linalg] Retire C++ MatmulOp in favor of a linalg-ods-gen'd op.
Summary:
This revision replaces MatmulOp, now that DRR rules have been dropped.
This revision also fixes minor parsing bugs and a plugs a few holes to get e2e paths working (e.g. library call emission).

During the replacement the i32 version had to be dropped because only the EDSC operators +, *, etc support type inference.

Deciding on a type-polymorphic behavior, and implementing it, is left for future work.

Reviewers: aartbik

Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, jurahul, msifontes

Tags: #mlir

Differential Revision: https://reviews.llvm.org/D81935
2020-06-16 10:46:35 -04:00
Kirill Bobyrev 9b72b47ed6 Revert "[mlir][Linalg] Retire C++ MatmulOp in favor of a linalg-ods-gen'd op."
This reverts commit 8c6c49f293.

As discussed offline, this patch breaks internal builds and tests so I'm
reverting it for now.
2020-06-16 11:02:28 +02:00
Nicolas Vasilache 8c6c49f293 [mlir][Linalg] Retire C++ MatmulOp in favor of a linalg-ods-gen'd op.
This revision replaces MatmulOp, now that DRR rules have been dropped.
This revision also fixes minor parsing bugs and a plugs a few holes to get e2e paths working (e.g. library call emission).

During the replacement the i32 version had to be dropped because only the EDSC operators +, *, etc support type inference.

Deciding on a type-polymorphic behavior, and implementing it, is left for future work.

Differential Revision: https://reviews.llvm.org/D79762
2020-06-15 18:14:15 -04:00
Mehdi Amini a9a21bb4b6 Revert "[mlir] Add support for lowering tanh to LLVMIR."
This reverts commit 32c757e4f8.

Broke the build bot:

******************** TEST 'MLIR :: Examples/standalone/test.toy' FAILED ********************
[...]
/tmp/ci-KIMiRFcVZt/lib/libMLIRLinalgToLLVM.a(LinalgToLLVM.cpp.o): In function `(anonymous namespace)::ConvertLinalgToLLVMPass::runOnOperation()':
LinalgToLLVM.cpp:(.text._ZN12_GLOBAL__N_123ConvertLinalgToLLVMPass14runOnOperationEv+0x100): undefined reference to `mlir::populateExpandTanhPattern(mlir::OwningRewritePatternList&, mlir::MLIRContext*)'
2020-06-15 18:46:57 +00:00
Hanhan Wang 32c757e4f8 [mlir] Add support for lowering tanh to LLVMIR.
Summary:
Add a pattern for expanding tanh op into exp form.
A `tanh` is expanded into:
   1) 1-exp^{-2x} / 1+exp^{-2x}, if x => 0
   2) exp^{2x}-1 / exp^{2x}+1  , if x < 0.

Differential Revision: https://reviews.llvm.org/D81618
2020-06-15 10:29:31 -07:00
Alexander Belyaev e9ac792748 [mlir] Fix some of the warnings in MLIR code.
Summary:
* extra ';' in the following files:
    mlir/lib/Dialect/Linalg/Transforms/Transforms.cpp
    mlir/lib/Dialect/Shape/IR/Shape.cpp

* base class ‘mlir::ConvertVectorToSCFBase<ConvertVectorToSCFPass>’
  should be explicitly initialized in the copy constructor [-Wextra] in
    mlir/lib/Conversion/VectorToSCF/VectorToSCF.cpp

* warning: ‘bool Expression::operator==(const Expression&) const’
  defined but not used [-Wunused-function] in
    mlir/tools/mlir-linalg-ods-gen/mlir-linalg-ods-gen.cpp

Differential Revision: https://reviews.llvm.org/D81673
2020-06-11 22:18:32 +02:00
Ehsan Toosi 4214031d43 [mlir] Introduce allowMemrefFunctionResults for the helper operation converters of buffer placement
This parameter gives the developers the freedom to choose their desired function
signature conversion for preparing their functions for buffer placement. It is
introduced for BufferAssignmentFuncOpConverter, and also for
BufferAssignmentReturnOpConverter, and BufferAssignmentCallOpConverter to adapt
the return and call operations with the selected function signature conversion.
If the parameter is set, buffer placement won't also deallocate the returned
buffers.

Differential Revision: https://reviews.llvm.org/D81137
2020-06-08 09:25:41 +02:00
Wen-Heng (Jack) Chung 47073ccd4e [mlir][mlir-rocm-runner] Detect HIP version and AMD ISA version.
Summary:
Prior to ROCm / HIP 3.5, HSA code object V2 is the default binary format.
Starting from ROCm 3.5, HSA code object V3 becomes default.

Also invoke `rocm_agent_enumerator` to detect proper AMD ISA version on the
system. Use `gfx900` as the fallback value.

Reviewers: jerryyin yaxunl

Subscribers: mgorny, yaxunl, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, jurahul, msifontes

Tags: #mlir

Differential Revision: https://reviews.llvm.org/D81309
2020-06-05 22:15:23 -05:00
Jacques Pienaar b0921f68e1 [mlir] Add verify method to adaptor
This allows verifying op-indepent attributes (e.g., attributes that do not require the op to have been created) before constructing an operation. These include checking whether required attributes are defined or constraints on attributes (such as I32 attribute). This is not perfect (e.g., if one had a disjunctive constraint where one part relied on the op and the other doesn't, then this would not try and extract the op independent from the op dependent).

The next step is to move these out to a trait that could be verified earlier than in the generated method. The first use case is for inferring the return type while constructing the op. At that point you don't have an Operation yet and that ends up in one having to duplicate the same checks, e.g., verify that attribute A is defined before querying A in shape function which requires that duplication. Instead this allows one to invoke a method to verify all the traits and, if this is checked first during verification, then all other traits could use attributes knowing they have been verified.

It is a little bit funny to have these on the adaptor, but I see the adaptor as a place to collect information about the op before the op is constructed (e.g., avoiding stringly typed accessors, verifying what is possible to verify before the op is constructed) while being cheap to use even with constructed op (so layer of indirection between the op constructed/being constructed). And from that point of view it made sense to me.

Differential Revision: https://reviews.llvm.org/D80842
2020-06-05 09:47:37 -07:00
Wen-Heng (Jack) Chung 2fd6403a6d [mlir][gpu] Introduce mlir-rocm-runner.
Summary:
`mlir-rocm-runner` is introduced in this commit to execute GPU modules on ROCm
platform. A small wrapper to encapsulate ROCm's HIP runtime API is also inside
the commit.

Due to behavior of ROCm, raw pointers inside memrefs passed to `gpu.launch`
must be modified on the host side to properly capture the pointer values
addressable on the GPU.

LLVM MC is used to assemble AMD GCN ISA coming out from
`ConvertGPUKernelToBlobPass` to binary form, and LLD is used to produce a shared
ELF object which could be loaded by ROCm HIP runtime.

gfx900 is the default target be used right now, although it could be altered via
an option in `mlir-rocm-runner`. Future revisions may consider using ROCm Agent
Enumerator to detect the right target on the system.

Notice AMDGPU Code Object V2 is used in this revision. Future enhancements may
upgrade to AMDGPU Code Object V3.

Bitcode libraries in ROCm-Device-Libs, which implements math routines exposed in
`rocdl` dialect are not yet linked, and is left as a TODO in the logic.

Reviewers: herhut

Subscribers: mgorny, tpr, dexonsmith, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, csigg, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, jurahul, llvm-commits

Tags: #mlir, #llvm

Differential Revision: https://reviews.llvm.org/D80676
2020-06-05 09:46:39 -05:00
Nicolas Vasilache 3463d9835b [mlir][Linalg] Add a hoistViewAllocOps helper function
This revision adds a helper function to hoist alloc/dealloc pairs and
alloca op out of immediately enclosing scf::ForOp if both conditions are true:
   1. all operands are defined outside the loop.
   2. all uses are ViewLikeOp or DeallocOp.

This is now considered Linalg-specific and will be generalized on a per-need basis.

Differential Revision: https://reviews.llvm.org/D81152
2020-06-04 18:59:03 -04:00
Nicolas Vasilache aa93659c9f [mlir][SCF] Add utility to clone an scf.ForOp while appending new yield values.
This utility factors out the machinery required to add iterArgs and yield values to an scf.ForOp.

Differential Revision: https://reviews.llvm.org/D80656
2020-05-29 07:28:17 -04:00
Benjamin Kramer b9bb3ad3ed Unbreak the build of mlir-cuda-runner 2020-05-29 12:18:48 +02:00
Nicolas Vasilache 5f9e0466f2 [mlir][Vector] Fix vector.transfer alignment calculation
https://reviews.llvm.org/D79246 introduces alignment propagation for vector transfer operations. Unfortunately, the alignment calculation is incorrect and can result in crashes.

This revision fixes the calculation by using the natural alignment of the memref elemental type, instead of the resulting vector type.

If more alignment is desired, it can be done in 2 ways:
1. use a proper vector.type_cast to transform a memref<axbxcxdxf32> into a memref<axbxvector<cxdxf32>> giving a natural alignment of vector<cxdxf32>
2. add an alignment attribute to vector transfer operations and propagate it.

With this change the alignment in the relevant tests goes down from 128 to 4.

Lastly, a few minor cleanups are performed and the custom `isMinorIdentityMap` is deprecated.

Differential Revision: https://reviews.llvm.org/D80734
2020-05-28 17:58:51 -04:00
Jacques Pienaar fefe4366c3 [mlir] Use ValueRange instead of ArrayRef<Value>
This allows constructing operand adaptor from existing op (useful for commonalizing verification as I want to do in a follow up).

I also add ability to use member initializers for the generated adaptor constructors for convenience.

Differential Revision: https://reviews.llvm.org/D80667
2020-05-28 09:05:24 -07:00
Wen-Heng (Jack) Chung 061fb8eb2d [mlir][gpu][mlir-cuda-runner] Refactor ConvertKernelFuncToCubin to be generic.
Make ConvertKernelFuncToCubin pass to be generic:

- Rename to ConvertKernelFuncToBlob.
- Allow specifying triple, target chip, target features.
- Initializing LLVM backend is supplied by a callback function.
- Lowering process from MLIR module to LLVM module is via another callback.
- Change mlir-cuda-runner to adopt the revised pass.
- Add new tests for lowering to ROCm HSA code object (HSACO).
- Tests for CUDA and ROCm are kept in separate directories.

Differential Revision: https://reviews.llvm.org/D80142
2020-05-28 09:08:28 -05:00
Jacques Pienaar 31f40f603d [mlir] Add simple generator for return types
Take advantage of equality constrains to generate the type inference interface.
This is used for equality and trivially built types. The type inference method
is only generated when no type inference trait is specified already.

This reorders verification that changes some test error messages.

Differential Revision: https://reviews.llvm.org/D80484
2020-05-27 08:45:55 -07:00
Christian Sigg 222e0e58a8 [MLIR] Helper class referencing MemRefType to unify runner implementations.
Summary:
Add DynamicMemRefType which can reference one of the statically ranked StridedMemRefType or a UnrankedMemRefType so that runner utils only need to be implemented once.

There is definitely room for more clean up and unification, but I will keep that for follow-ups.

Reviewers: nicolasvasilache

Reviewed By: nicolasvasilache

Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, jurahul, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D80513
2020-05-26 16:32:36 +02:00
Jacques Pienaar 4b8632e174 [mlir] Expand operand adapter to take attributes
* Enables using with more variadic sized operands;
* Generate convenience accessors for attributes;
  - The accessor are named the same as their name in ODS and returns attribute
    type (not convenience type) and no derived attributes.

This is first step to changing adapter to support verifying argument
constraints before the op is even created. This does not change the name of
adaptor nor does it require it except for ops with variadic operands to keep this change smaller.

Considered creating separate adapter but decided against that given operands also require attributes in general (and definitely for verification of operands and attributes).

Differential Revision: https://reviews.llvm.org/D80420
2020-05-24 21:06:47 -07:00
Thomas Raoux 15389cdc5b [mlir][spirv] Add remaining cooperative matrix instructions
Adds support for cooperative matrix support for arithmetic and cast
instructions. It also adds cooperative matrix store, muladd and matrixlength
instructions which are part of the extension.

Differential Revision: https://reviews.llvm.org/D80181
2020-05-21 11:55:33 -07:00
Wen-Heng (Jack) Chung 2cbbc266ec [mlir][gpu] Refactor ConvertGpuLaunchFuncToCudaCalls pass.
Due to similar APIs between CUDA and ROCm (HIP),
ConvertGpuLaunchFuncToCudaCalls pass could be used on both platforms with some
refactoring.

In this commit:

- Migrate ConvertLaunchFuncToCudaCalls from GPUToCUDA to GPUCommon, and rename.
- Rename runtime wrapper APIs be platform-neutral.
- Let GPU binary annotation attribute be specifiable as a PassOption.
- Naming changes within the implementation and tests.

Subsequent patches would introduce ROCm-specific tests and runtime wrapper
APIs.

Differential Revision: https://reviews.llvm.org/D80167
2020-05-21 08:53:47 -05:00
Mehdi Amini 5c3ebd7725 Revert "[mlir][gpu] Refactor ConvertGpuLaunchFuncToCudaCalls pass."
This reverts commit cdb6f05e2d.

The build is broken with:

  You have called ADD_LIBRARY for library obj.MLIRGPUtoCUDATransforms without any source files. This typically indicates a problem with your CMakeLists.txt file
2020-05-21 03:44:35 +00:00
Wen-Heng (Jack) Chung cdb6f05e2d [mlir][gpu] Refactor ConvertGpuLaunchFuncToCudaCalls pass.
Due to similar APIs between CUDA and ROCm (HIP),
ConvertGpuLaunchFuncToCudaCalls pass could be used on both platforms with some
refactoring.

In this commit:

- Migrate ConvertLaunchFuncToCudaCalls from GPUToCUDA to GPUCommon, and rename.
- Rename runtime wrapper APIs be platform-neutral.
- Let GPU binary annotation attribute be specifiable as a PassOption.
- Naming changes within the implementation and tests.

Subsequent patches would introduce ROCm-specific tests and runtime wrapper
APIs.

Differential Revision: https://reviews.llvm.org/D80167
2020-05-20 16:11:48 -05:00
Thomas Raoux 92577e6a0f [mlir][vulkan-runner] Minor fix in timestamp flag for vulkan runner.
The first timestamp query should use VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT.

Differential Revision: https://reviews.llvm.org/D80183
2020-05-19 18:56:48 -07:00
Kuangyuan Chen fb8204b210 [mlir][ods] Fix ops with both attribute-sized operands and results
Enclose verifier code for AttrSizedOperandSegments and AttrSizedResultSegments
in a nested code block to avoid symbol collision.

Differential Revision: https://reviews.llvm.org/D80250
2020-05-19 20:29:54 -04:00
Stephen Neuendorffer b54635e0ec [MLIR] LLVMMLIRTableGen -> MLIRTableGen
Like all MLIR libraries, this should start with 'MLIR'

Differential Revision: https://reviews.llvm.org/D80102
2020-05-19 14:49:32 -07:00
MaheshRavishankar d5b1643c74 [mlir][SPIRV] Fix blocks nested too deeply error.
Issue arises due to a giant if/else if/else/... construct. Changing
them to just ifs.

Differential Revision: https://reviews.llvm.org/D80245
2020-05-19 14:29:56 -07:00
Christian Sigg 62adfed30a Unrank mcuMemHostRegister tensor argument.
Reviewers: herhut

Reviewed By: herhut

Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, jurahul, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D80118
2020-05-19 13:58:54 +02:00
Lei Zhang 715b7d8aa5 [mlir][vulkan-runner] Add back accidentially removed header include
Differential Revision: https://reviews.llvm.org/D80149
2020-05-18 15:19:24 -04:00
Alexandre Rames 23dc948d36 [MLIR] Use `MLIR_INCLUDE_TESTS` to conditionally compile tests.
This is equivalent to what is done for other projects (e.g. clang).

Differential Revision: https://reviews.llvm.org/D80022
2020-05-18 18:47:37 +02:00
Tobias Gysi a4cb9bec1c [mlir] Support optional attributes in assembly formats
Summary: This revision adds support for assembly formats with optional attributes. It elides optional attributes that are part of the syntax from the attribute dictionary.

Reviewers: ftynse, Kayjukh

Reviewed By: ftynse, Kayjukh

Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, jurahul, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D80113
2020-05-18 18:34:35 +02:00
Stephen Neuendorffer f88c7fe46b [MLIR][cmake][NFC] Update linkage checker for mlir-opt
New CMakeLists.txt for MLIRStandardOpsTransforms was incorrect, but wasn't
caught by the check.

Differential Revision: https://reviews.llvm.org/D80075
2020-05-17 13:46:52 -07:00
Stephen Neuendorffer ec44e08940 [MLIR] Move JitRunner to live with ExecutionEngine
The JitRunner library is logically very close to the execution engine,
and shares similar dependencies.

find -name "*.cpp" -exec sed -i "s/Support\/JitRunner/ExecutionEngine\/JitRunner/" "{}" \;

Differential Revision: https://reviews.llvm.org/D79899
2020-05-15 14:37:10 -07:00
Alex Zinenko 4ead2cf76c [mlir] Rename conversions involving ex-Loop dialect to mention SCF
The following Conversions are affected: LoopToStandard -> SCFToStandard,
LoopsToGPU -> SCFToGPU, VectorToLoops -> VectorToSCF. Full file paths are
affected. Additionally, drop the 'Convert' prefix from filenames living under
lib/Conversion where applicable.

API names and CLI options for pass testing are also renamed when applicable. In
particular, LoopsToGPU contains several passes that apply to different kinds of
loops (`for` or `parallel`), for which the original names are preserved.

Differential Revision: https://reviews.llvm.org/D79940
2020-05-15 10:45:11 +02:00
Lei Zhang a4441fcd12 [mlir][vulkan-runner] Avoid dependency on LLVM libraries
The Vulkan runtime wrapper will be compiled to a shared library
that are loaded by the JIT runner. Depending on LLVM libraries
means that LLVM symbols will be compiled into the shared library.
That can cause problems if we are using it with other shared
libraries depending on LLVM, notably Mesa, the open-source graphics
driver framework. The Vulkan API wrappers invoked by the JIT runner
links to the system libvulkan.so. If it's Mesa providing the
implementation, Mesa will normally try to load the system libLLVM.so
for its shader compilation. That causes issues because the JIT runner
already loaded the Vulkan runtime wrapper which has LLVM sybmols
compiled in. So system linker will instruct Mesa to use those symbols
instead.

Differential Revision: https://reviews.llvm.org/D79860
2020-05-13 13:42:34 -04:00
Stephen Neuendorffer 661b234cbc [MLIR] Rename SideEffects.td -> SideEffectInterfaces.td
This normalize the name of the tablegen file with the name of the generated
files (SideEffectInterfaces.h.inc) and the other Interface tablegen files,
which all end in Interface(s).td

Differential Revision: https://reviews.llvm.org/D79517
2020-05-12 12:21:42 -07:00
Jacques Pienaar 5eae715a31 [mlir] Add NamedAttrList
This is a wrapper around vector of NamedAttributes that keeps track of whether sorted and does some minimal effort to remain sorted (doing more, e.g., appending attributes in sorted order, could be done in follow up). It contains whether sorted and if a DictionaryAttr is queried, it caches the returned DictionaryAttr along with whether sorted.

Change MutableDictionaryAttr to always return a non-null Attribute even when empty (reserve null cases for errors). To this end change the getter to take a context as input so that the empty DictionaryAttr could be queried. Also create one instance of the empty dictionary attribute that could be reused without needing to lock context etc.

Update infer type op interface to use DictionaryAttr and use NamedAttrList to avoid incurring multiple conversion costs.

Fix bug in sorting helper function.

Differential Revision: https://reviews.llvm.org/D79463
2020-05-07 12:33:36 -07:00
Lei Zhang 5db5002e65 [mlir] Remove unnecessary DEPENDS for MLIRMlirOptMain
https://github.com/llvm/llvm-project/commit/c296d2dc53d5c11c
fixes the dependency issue by turning LINK_LIBS to PUBLIC.
These explicit DEPENDS are not needed anymore.

Differential Revision: https://reviews.llvm.org/D79574
2020-05-07 13:59:05 -04:00
Lei Zhang c2414c2039 [mlir][vulkan-runner] Remove duplicated/uncessary link libraries
vulkan-runtime-wrappers does not need MLIRSPIRVSerialization,
which is used by the ConvertGpuLaunchFuncToVulkanLaunchFunc pass
under the hood.

Differential Revision: https://reviews.llvm.org/D79577
2020-05-07 13:57:26 -04:00
Lei Zhang 16027bbc3b [mlir][spirv] Serialize all operands together if possible
SPIR-V ops can mix operands and attributes in the definition. These
operands and attributes are serialized in the exact order of the definition
to match SPIR-V binary format requirements. It can cause excessive
generated code bloat because we are emitting code to handle each
operand/attribute separately. So here we probe first to check whether all
the operands are ahead of attributes. Then we can serialize all operands
together.

This removes ~1000 lines of code from the generated inc file.

Differential Revision: https://reviews.llvm.org/D79446
2020-05-07 09:32:03 -04:00
Lei Zhang a2634748cd [mlir][spirv] Remove template functions for getting op's opcode
These template functions are used in the serializer, where we can
actually directly query the opcode from the op's definition and
use that in the auto-generated serialization logic.

This removes a set of templates accounting for 319 lines from
the auto-generated inc file.

Differential Revision: https://reviews.llvm.org/D79444
2020-05-07 09:32:03 -04:00
Stephen Neuendorffer c296d2dc53 [MLIR] mlir-opt needs PUBLIC dependence
We see intermittent build errors on the windows buildbot because
mlir-opt is including Linalg headers which haven't been built yet.
This dependence should be resolved by declaring a PUBLIC dependence
on the Linalg library when building MLIROptMain.
2020-05-05 12:39:28 -07:00
Andy Davis 93d1108801 [MLIR][LoopOps] Adds the loop unroll transformation for loop::ForOp.
Summary:
Adds the loop unroll transformation for loop::ForOp.
Adds support for promoting the body of single-iteration loop::ForOps into its containing block.
Adds check tests for loop::ForOps with dynamic and static lower/upper bounds and step.
Care was taken to share code (where possible) with the AffineForOp unroll transformation to ease maintenance and potential future transition to a LoopLike construct on which loop transformations for different loop types can implemented.

Reviewers: ftynse, nicolasvasilache

Reviewed By: ftynse

Subscribers: bondhugula, mgorny, zzheng, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D79184
2020-05-05 10:42:36 -07:00
Lei Zhang 6fb7e9a195 [mlir] Add missing dependency to MLIRMlirOptMain
Differential Revision: https://reviews.llvm.org/D79429
2020-05-05 13:32:00 -04:00
Stephen Neuendorffer 5469f434bb [MLIR] Reapply: Adjust libMLIR building to more closely follow libClang
This reverts commit ab1ca6e60f.
2020-05-04 20:47:57 -07:00
River Riddle 6bce7d8d67 [mlir][mlir-opt] Disable multithreading when parsing the input module.
This removes the unnecessary/costly context synchronization when parsing, as the context is guaranteed to not be used by any other threads.
2020-05-04 17:29:56 -07:00
Stephen Neuendorffer ab1ca6e60f Revert "[MLIR] Adjust libMLIR building to more closely follow libClang"
This reverts commit 4f0f436749.

This seems to show some compile dependence problems, and also breaks flang.
2020-05-04 12:40:12 -07:00
Valentin Churavy 4f0f436749 [MLIR] Adjust libMLIR building to more closely follow libClang
- Exports MLIR targets to be used out-of-tree.
- mimicks `add_clang_library` and `add_flang_library`.
- Fixes libMLIR.so

After https://reviews.llvm.org/D77515 libMLIR.so was no longer containing
any object files. We originally had a cludge there that made it work with
the static initalizers and when switchting away from that to the way the
clang shlib does it, I noticed that MLIR doesn't create a `obj.{name}` target,
and doesn't export it's targets to `lib/cmake/mlir`.

This is due to MLIR using `add_llvm_library` under the hood, which adds
the target to `llvmexports`.

Differential Revision: https://reviews.llvm.org/D78773

[MLIR] Fix libMLIR.so and LLVM_LINK_LLVM_DYLIB

Primarily, this patch moves all mlir references to LLVM libraries into
either LLVM_LINK_COMPONENTS or LINK_COMPONENTS.  This enables magic in
the llvm cmake files to automatically replace reference to LLVM components
with references to libLLVM.so when necessary.  Among other things, this
completes fixing libMLIR.so, which has been broken for some configurations
since D77515.

Unlike previously, the pattern is now that mlir libraries should almost
always use add_mlir_library.  Previously, some libraries still used
add_llvm_library.  However, this confuses the export of targets for use
out of tree because libraries specified with add_llvm_library are exported
by LLVM.  Instead users which don't need/can't be linked into libMLIR.so
can specify EXCLUDE_FROM_LIBMLIR

A common error mode is linking with LLVM libraries outside of LINK_COMPONENTS.
This almost always results in symbol confusion or multiply defined options
in LLVM when the same object file is included as a static library and
as part of libLLVM.so.  To catch these errors more directly, there's now
mlir_check_all_link_libraries.

To simplify usage of add_mlir_library, we assume that all mlir
libraries depend on LLVMSupport, so it's not necessary to separately specify
it.

tested with:
BUILD_SHARED_LIBS=on,
BUILD_SHARED_LIBS=off + LLVM_BUILD_LLVM_DYLIB,
BUILD_SHARED_LIBS=off + LLVM_BUILD_LLVM_DYLIB + LLVM_LINK_LLVM_DYLIB.

By: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Differential Revision: https://reviews.llvm.org/D79067

[MLIR] Move from using target_link_libraries to LINK_LIBS

This allows us to correctly generate dependencies for derived targets,
such as targets which are created for object libraries.

By: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Differential Revision: https://reviews.llvm.org/D79243

Three commits have been squashed to avoid intermediate build breakage.
2020-05-04 11:40:46 -07:00
Denis Khalikov 29b955f97c [mlir][spirv] Handle debug information during (de)serialization.
Summary:
This is an initial version, currently supports OpString and OpLine
for autogenerated operations during (de)serialization.

Differential Revision: https://reviews.llvm.org/D79091
2020-05-01 14:11:54 +03:00
Nicolas Vasilache 0d61dcf606 [mlir][EDSC] Make use of InsertGuard
Summary:
This revision cleans up a layer of complexity in ScopedContext and uses InsertGuard instead of previously manual bookkeeping.
The method `getBuilder` is renamed to `getBuilderRef` and spurious copies of OpBuilder are tracked.

This results in some canonicalizations not happening anymore in the Linalg matmul to vector test. This test is retired because relying on DRRs for this has been shaky at best. The solution will be better support to write fused passes in C++ with more idiomatic pattern composition and application.

Differential Revision: https://reviews.llvm.org/D79208
2020-04-30 18:04:31 -04:00
River Riddle ac2aaa3788 [mlir][OpInterfaceGen] Emit the utility Trait decl as a class and not using directive
This fixes the build on MSVC where it is unable to handle template-template using directives properly.
2020-04-30 11:07:58 -07:00
Nicolas Vasilache 3bdd7fcc34 [mlir][Linalg] Add support to lower named ops to loops.
This revision adds support to allow named ops to lower to loops.
Linalg.batch_matmul successfully lowers to loops and to LLVM.

In the process, this test also activates linalg to affine loops.
However padded convolutions to not lower to affine.load atm so this revision overrides the type of underlying load / store operation.

Differential Revision: https://reviews.llvm.org/D79135
2020-04-30 13:45:17 -04:00
River Riddle 0752d98ccf [mlir] Simplify BranchOpInterface by using MutableOperandRange
This range allows for performing many different operations on successor operands, including erasing/adding/setting. This removes the need for the explicit canEraseSuccessorOperand and eraseSuccessorOperand methods.

Differential Revision: https://reviews.llvm.org/D79077
2020-04-29 16:48:15 -07:00
River Riddle 91dae57087 [mlir][DeclareOpInterfaceMethods] Allow specifying a set of methods to force declaration generation for.
Currently a declaration won't be generated if the method has a default implementation. Meaning that operations that wan't to override the default have to explicitly declare the method in the extraClassDeclarations. This revision adds an optional list parameter to DeclareOpInterfaceMethods to allow for specifying a set of methods that should always have the declarations generated, even if there is a default.

Differential Revision: https://reviews.llvm.org/D79030
2020-04-29 16:48:15 -07:00
River Riddle 108abd2f2e [mlir] Add a new MutableOperandRange class for adding/remove operands
This class allows for mutating an operand range in-place, and provides vector like API for adding/erasing/setting. ODS now uses this class to generate mutable wrappers for named operands, with the name `MutableOperandRange <operand-name>Mutable()`

Differential Revision: https://reviews.llvm.org/D78892
2020-04-29 16:48:14 -07:00
Martin Erhart edb77864ef [mlir][assemblyFormat] Fix bug when using AttrSizedOperandSegments trait with only non-buildable operand types
Summary:
When creating an operation with
* `AttrSizedOperandSegments` trait
* Variadic operands of only non-buildable types
* assemblyFormat to automatically generate the parser
the `builder` local variable is used, but never declared.
This adds a fix as well as a test for this case as existing ones use buildable types only.

Reviewers: rriddle, Kayjukh, grosser

Reviewed By: Kayjukh

Subscribers: mehdi_amini, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, frgossen, llvm-commits

Tags: #mlir, #llvm

Differential Revision: https://reviews.llvm.org/D79004
2020-04-28 18:27:05 +02:00
Alex Zinenko bb1d976feb [mlir][flang] use OpBuilder& instead of Builder* in <Op>::build methods
As we start defining more complex Ops, we increasingly see the need for
Ops-with-regions to be able to construct Ops within their regions in
their ::build methods. However, these methods only have access to
Builder, and not OpBuilder. Creating a local instance of OpBuilder
inside ::build and using it fails to trigger the operation creation
hooks in derived builders (e.g., ConversionPatternRewriter). In this
case, we risk breaking the logic of the derived builder. At the same
time, OpBuilder::create, which is by far the largest user of ::build
already passes "this" as the first argument, so an OpBuilder instance is
already available.

Update all ::build methods in all Ops in MLIR and Flang to take
"OpBuilder &" instead of "Builder *". Note the change from pointer and
to reference to comply with the common style in MLIR, this also ensures
all other users must change their ::build methods.

Differential Revision: https://reviews.llvm.org/D78713
2020-04-28 10:42:08 +02:00
Ehsan Toosi 5c352e69e7 Providing buffer assignment for MLIR
We have provided a generic buffer assignment transformation ported from
TensorFlow. This generic transformation pass automatically analyzes the values
and their aliases (also in other blocks) and returns the valid positions for
Alloc and Dealloc operations. To find these positions, the algorithm uses the
block Dominator and Post-Dominator analyses. In our proposed algorithm, we have
considered aliasing, liveness, nested regions, branches, conditional branches,
critical edges, and independency to custom block terminators. This
implementation doesn't support block loops. However, we have considered this in
our design. For this purpose, it is only required to have a loop analysis to
insert Alloc and Dealloc operations outside of these loops in some special
cases.

Differential Revision: https://reviews.llvm.org/D78484
2020-04-28 10:17:59 +02:00
River Riddle 7c221a7d4f [mlir][Symbol] Change Symbol from a Trait into an OpInterface.
This provides a much cleaner interface into Symbols, and allows for users to start injecting op-specific information. For example, derived op can now inject when a symbol can be discarded if use_empty. This would let us drop unused external functions, which generally have public visibility.

This revision also adds a new `extraTraitClassDeclaration` field to ODS OpInterface to allow for injecting declarations into the trait class that gets attached to the operations.

Differential Revision: https://reviews.llvm.org/D78522
2020-04-27 13:04:49 -07:00
Tres Popp 2d2d696137 [MLIR] Propagate input side effect information
Summary:
Previously operations like std.load created methods for obtaining their
effects but did not inherit from the SideEffect interfaces when their
parameters were decorated with the information. The resulting situation
was that passes had no information on the SideEffects of std.load/store
and had to treat them more cautiously. This adds the inheritance
information when creating the methods.

As a side effect, many tests are modified, as they were using std.load
for testing and this oepration would be folded away as part of pattern
rewriting. Tests are modified to use store or to reutn the result of the
std.load.

Reviewers: mravishankar, antiagainst, nicolasvasilache, herhut, aartbik, ftynse!

Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, csigg, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, bader, grosul1, frgossen, Kayjukh, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D78802
2020-04-27 11:35:52 +02:00
River Riddle 4dfd1b5fcb [mlir] Optimize operand storage such that all operations can have resizable operand lists
This revision refactors the structure of the operand storage such that there is no additional memory cost for resizable operand lists until it is required. This is done by using two different internal representations for the operand storage:
* One using trailing operands
* One using a dynamically allocated std::vector<OpOperand>

This allows for removing the resizable operand list bit, and will free up APIs from needing to workaround non-resizable operand lists.

Differential Revision: https://reviews.llvm.org/D78875
2020-04-26 21:34:01 -07:00
Lei Zhang 60f1d26366 Revert "[mlir][drr] NFC: avoid SmallVector when collecting substitution values"
This reverts commit 2f8b164ca2, which
causes a breakage on Clang 5.
2020-04-24 15:33:03 -04:00
Lei Zhang 2f8b164ca2 [mlir][drr] NFC: avoid SmallVector when collecting substitution values
Now both Operation::operand_range and Operation::result_range have
.begin() and .end() for ranged-based for loop and we have
ValueRange for wrapping a single Value. We can remove the SmallVector
materialization!

Differential Revision: https://reviews.llvm.org/D78766
2020-04-24 09:36:47 -04:00
Nicolas Vasilache 367229e100 [mlir][EDSC] Retire ValueHandle
The EDSC discussion [thread](https://llvm.discourse.group/t/evolving-builder-apis-based-on-lessons-learned-from-edsc/879) points out that ValueHandle has become an unnecessary level of abstraction since MLIR switch from `Value *` to `Value` everywhere.

This revision removes this level of indirection.
2020-04-23 11:01:16 -04:00
Denis Khalikov 1009177d49 [mlir][vulkan-runner] Add support for integer types.
Summary:
Add support for memrefs with element type as integer type
and simple test.

Differential Revision: https://reviews.llvm.org/D78560
2020-04-22 19:42:39 +03:00
Nicolas Vasilache 538ac26f25 [mlir][Linalg] Create a named batch_matmul op and pipe it through.
This revision is the first in a set of improvements that aim at allowing
more generalized named Linalg op generation from a mathematical
specification.

This revision allows creating a new op and checks that the parser,
printer and verifier are hooked up properly.

This opened up a few design points that will be addressed in the future:
1. A named linalg op has a static region builder instead of an
explicitly parsed region. This is not currently compatible with
assemblyFormat so a custom parser / printer are needed.
2. The convention for structured ops and tensor return values needs to
evolve to allow tensor-land and buffer land specifications to agree
3. ReferenceIndexingMaps and referenceIterators will need to become
static to allow building attributes at parse time.
4. Error messages will be improved once we have 3. and we pretty print
in custom form.

Differential Revision: https://reviews.llvm.org/D78327
2020-04-21 12:09:46 -04:00
Jacques Pienaar 9ba37b3bf2 [mlir][ods] Add materialize derived attribute method
Summary:
Generate method to generate a DictionaryAttr with attribute values of
derived attribute. If a conversion back from the derived attribute C++
type to Attribute is not defined, then attempting to materialize such an
op's derived attributes would result in runtime failure.

This allows to treat derived attributes and attributes of an op in more
uniform manner where needed. The derived attributes are not added to the
operation but returned as new attribute instead.

Differential Revision: https://reviews.llvm.org/D78302
2020-04-20 13:13:04 -07:00
Alex Zinenko f072942fe2 [mlir] ODS: support operations with resizable operand lists
MLIR supports operations with resizable operand lists, but this property must
be indicated during the construction of such operations. It can be done
programmatically by calling a function on OperationState. Introduce an
ODS-internal trait `ResizableOperandList` to indicate such operations are use
it when generating the bodies of various `build` functions as well as the
`parse` function when the declarative assembly format is used.

Differential Revision: https://reviews.llvm.org/D78292
2020-04-16 23:30:34 +02:00
Uday Bondhugula af5e83f569 [MLIR] Introduce utility to hoist affine if/else conditions
This revision introduces a utility to unswitch affine.for/parallel loops
by hoisting affine.if operations past surrounding affine.for/parallel.
The hoisting works for both perfect/imperfect nests and in the presence
of else blocks. The hoisting is currently to as outermost a level as
possible.  Uses a test pass to test the utility.
Add convenience method Operation::getParentWithTrait<Trait>.

Depends on D77487.

Differential Revision: https://reviews.llvm.org/D77870
2020-04-16 00:32:34 +05:30
River Riddle 229e392b4e [llvm][StringExtras] Merge StringExtras from MLIR into LLVM
Summary:
This revision adds two utilities currently present in MLIR to LLVM StringExtras:

* convertToSnakeFromCamelCase
Convert a string from a camel case naming scheme, to a snake case scheme

* convertToCamelFromSnakeCase
Convert a string from a snake case naming scheme, to a camel case scheme

Differential Revision: https://reviews.llvm.org/D78167
2020-04-14 18:57:22 -07:00
River Riddle 92f1562f3d [mlir][NFC] Remove the STLExtras.h header file now that it has been merged into LLVM.
Now that no more utilities exist within, this file can be deleted.

Differential Revision: https://reviews.llvm.org/D78079
2020-04-14 15:14:41 -07:00
River Riddle ebf190fcda [llvm][ADT] Move TypeSwitch class from MLIR to LLVM
This class implements a switch-like dispatch statement for a value of 'T' using dyn_cast functionality. Each `Case<T>` takes a callable to be invoked if the root value isa<T>, the callable is invoked with the result of dyn_cast<T>() as a parameter.

Differential Revision: https://reviews.llvm.org/D78070
2020-04-14 15:14:41 -07:00
River Riddle 2f21a57966 [llvm][STLExtras] Move the algorithm `interleave*` methods from MLIR to LLVM
These have proved incredibly useful for interleaving values between a range w.r.t to streams. After this revision, the mlir/Support/STLExtras.h is empty. A followup revision will remove it from the tree.

Differential Revision: https://reviews.llvm.org/D78067
2020-04-14 15:14:40 -07:00
Chris Lattner 74e6a5b2a3 Eliminate all uses of Identifier::is() in the source tree, this doesn't remove the definition of it (yet). NFC.
Reviewers: mravishankar, antiagainst, herhut, rriddle!

Subscribers: jholewinski, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, nicolasvasilache, csigg, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, bader, grosul1, frgossen, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D78042
2020-04-13 11:49:31 -07:00
River Riddle 2e8188ff48 [mlir][NFC] Mark a debug only variable as (void) to avoid unused warning 2020-04-13 00:48:17 -07:00
River Riddle decac2d9ea [mlir][EnumGen] Generate utility symbolizeEnum and stringifyEnum methods during EnumGen
Summary:
This revision adds generation of two utility methods during EnumGen:
```
llvm::Optional<EnumType> symbolizeEnum<EnumType>(llvm::StringRef)
<stringifyResult> stringifyEnum(EnumType);
```

This provides a generic interface for stringifying/symbolizing any enum that can be used in a template environment.

Differential Revision: https://reviews.llvm.org/D77937
2020-04-12 19:08:08 -07:00
River Riddle 8938dea44a [mlir][IR] Manually register command line options for MLIRContext and AsmPrinter
Summary: This revision makes the registration of command line options for these two files manual with `registerMLIRContextCLOptions` and `registerAsmPrinterCLOptions` methods. This removes the last remaining static constructors within lib/.

Differential Revision: https://reviews.llvm.org/D77960
2020-04-11 23:13:00 -07:00
Stephen Neuendorffer 4956871c0e [MLIR] CMake cleanup for mlir-opt
A few libraries which are also Dialect libraries where independently
in the link line for mlir-opt.  Remove them.

Differential Revision: https://reviews.llvm.org/D77927
2020-04-11 22:02:16 -07:00
Stephen Neuendorffer 4c18e1d3af [MLIR] add cmake abstraction for translation libraries
Differential Revision: https://reviews.llvm.org/D77926
2020-04-11 22:02:16 -07:00
River Riddle a517191a47 [mlir][NFC] Refactor ClassID into a TypeID class.
Summary: ClassID is a bit janky right now as it involves passing a magic pointer around. This revision hides the internal implementation mechanism within a new class TypeID. This class is a value-typed wrapper around the original ClassID implementation.

Differential Revision: https://reviews.llvm.org/D77768
2020-04-10 23:52:33 -07:00
River Riddle 7824768b2e [mlir][Pass] Add a new `Pass::getArgument` hook
Summary: This hook allows for passes to specify the command line argument without the need for registration. More concretely this will allow for generating pass crash reproducers without needing to have the passes registered. This should remove the need for production tools to register passes, leaving that solely to development tools like mlir-opt.

Differential Revision: https://reviews.llvm.org/D77907
2020-04-10 22:50:14 -07:00
River Riddle aba1acc89c [mlir][ODS] Add support for optional operands and results with a new Optional directive.
Summary: This revision adds support for specifying operands or results as "optional". This is a special case of variadic where the number of elements is either 0 or 1. Operands and results of this kind will have accessors generated using Value instead of the range types, making it more natural to interface with.

Differential Revision: https://reviews.llvm.org/D77863
2020-04-10 14:12:06 -07:00
Jacques Pienaar d6b32e39ae [mlir][drr] Allow specifying string in location
Summary:
The string in the location is used to provide metadata for the fused location
or create a NamedLoc. This allows tagging individual locations to convey
additional rewrite information.

Differential Revision: https://reviews.llvm.org/D77840
2020-04-10 12:43:22 -07:00
Nicolas Vasilache 882ba48474 [mlir][Linalg] Create a tool to generate named Linalg ops from a Tensor Comprehensions-like specification.
Summary:

This revision adds a tool that generates the ODS and C++ implementation for "named" Linalg ops according to the [RFC discussion](https://llvm.discourse.group/t/rfc-declarative-named-ops-in-the-linalg-dialect/745).

While the mechanisms and language aspects are by no means set in stone, this revision allows connecting the pieces end-to-end from a mathematical-like specification.

Some implementation details and short-term decisions taken for the purpose of bootstrapping and that are not set in stone include:

    1. using a "[Tensor Comprehension](https://arxiv.org/abs/1802.04730)-inspired" syntax
    2. implicit and eager discovery of dims and symbols when parsing
    3. using EDSC ops to specify the computation (e.g. std_addf, std_mul_f, ...)

A followup revision will connect this tool to tablegen mechanisms and allow the emission of named Linalg ops that automatically lower to various loop forms and run end to end.

For the following "Tensor Comprehension-inspired" string:

```
    def batch_matmul(A: f32(Batch, M, K), B: f32(K, N)) -> (C: f32(Batch, M, N)) {
      C(b, m, n) = std_addf<k>(std_mulf(A(b, m, k), B(k, n)));
    }
```

With -gen-ods-decl=1, this emits (modulo formatting):

```
      def batch_matmulOp : LinalgNamedStructured_Op<"batch_matmul", [
        NInputs<2>,
        NOutputs<1>,
        NamedStructuredOpTraits]> {
          let arguments = (ins Variadic<LinalgOperand>:$views);
          let results = (outs Variadic<AnyRankedTensor>:$output_tensors);
          let extraClassDeclaration = [{
            llvm::Optional<SmallVector<StringRef, 8>> referenceIterators();
            llvm::Optional<SmallVector<AffineMap, 8>> referenceIndexingMaps();
            void regionBuilder(ArrayRef<BlockArgument> args);
          }];
          let hasFolder = 1;
      }
```

With -gen-ods-impl, this emits (modulo formatting):

```
      llvm::Optional<SmallVector<StringRef, 8>> batch_matmul::referenceIterators() {
          return SmallVector<StringRef, 8>{ getParallelIteratorTypeName(),
                                            getParallelIteratorTypeName(),
                                            getParallelIteratorTypeName(),
                                            getReductionIteratorTypeName() };
      }
      llvm::Optional<SmallVector<AffineMap, 8>> batch_matmul::referenceIndexingMaps()
      {
        MLIRContext *context = getContext();
        AffineExpr d0, d1, d2, d3;
        bindDims(context, d0, d1, d2, d3);
        return SmallVector<AffineMap, 8>{
            AffineMap::get(4, 0, {d0, d1, d3}),
            AffineMap::get(4, 0, {d3, d2}),
            AffineMap::get(4, 0, {d0, d1, d2}) };
      }
      void batch_matmul::regionBuilder(ArrayRef<BlockArgument> args) {
        using namespace edsc;
        using namespace intrinsics;
        ValueHandle _0(args[0]), _1(args[1]), _2(args[2]);

        ValueHandle _4 = std_mulf(_0, _1);
        ValueHandle _5 = std_addf(_2, _4);
        (linalg_yield(ValueRange{ _5 }));
      }
```

Differential Revision: https://reviews.llvm.org/D77067
2020-04-10 13:59:25 -04:00
Jonathan Roelofs 223154d267 [mlir] Remove need for static global ctors from mlir-translate
Summary: https://bugs.llvm.org/show_bug.cgi?id=45436

Reviewers: mehdi_amini, mravishankar, antiagainst, rriddle, stephenneuendorffer

Reviewed By: mehdi_amini, rriddle, stephenneuendorffer

Subscribers: frgossen, stephenneuendorffer, jholewinski, mgorny, rriddle, jpienaar, burmako, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, Joonsoo, bader, grosul1, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D77515
2020-04-08 16:52:33 -06:00
Nicolas Vasilache 6fb6a4d7f9 [mlir][Linalg] Add a test for a fused Linalg pass based on DRR to go from matmul to vectors
This revision builds a simple "fused pass" consisting of 2 levels of tiling, memory promotion and vectorization using linalg transformations written as composable pattern rewrites.
2020-04-08 16:54:40 -04:00
Lukas Sommer d86ece13d9 Keep output file after successful execution of mlir-opt
Invoke `keep()` on the output file of `mlir-opt` in case the invocation of `MlirOptMain` was successful, to make sure the output file is not deleted on exit from `mlir-opt`.
Fixes a similar problem in `standalone-opt` from the example for an out-of-tree, standalone MLIR dialect.

This revision also adds a missing parameter to the invocation of `MlirOptMain` in `standalone-opt`.

Differential Revision: https://reviews.llvm.org/D77643
2020-04-08 03:37:45 +00:00
River Riddle 8b7e669e68 [mlir][AsmFormat] Avoid invalidating the iterator when verifying attributes
Summary: 'it' may get invalidated when recursing into optional groups. This revision refactors the inner loop to avoid the need to compare the iterator after invalidation.

Differential Revision: https://reviews.llvm.org/D77686
2020-04-07 15:54:56 -07:00
Stephen Neuendorffer 19fec004e2 [MLIR] Add note for file-line numbers in tablegen errors for assembly formats
Error messages for the custom assembly format are difficult to understand
because there are no line numbers.  This happens because the assembly format
is parsed as a standalone line, separate from it's parent file, with no useful
location information.  Fixing this properly probably requires quite a bit
of invasive plumbing through the SourceMgr, similar to how included files
are handled

This proposal is a less invasive short term solution.  When generating an
error message we generate an additional note which at least properly describes
the operation definition the error occured in, if not the actual line number
of the assemblyFormat definition.

A typical message is like:

error: type of operand #0, named 'operand', is not buildable and a buildable type cannot be inferred
  $operand type($result) attr-dict
  ^
/src/llvm-project/mlir/test/mlir-tblgen/op-format-spec.td:296:1: note: in custom assembly format for this operation
def ZCoverageInvalidC : TestFormat_Op<"variable_invalid_c", [{
^
note: suggest adding a type constraint to the operation or adding a 'type($operand)' directive to the custom assembly format
  $operand type($result) attr-dict
  ^

Differential Revision: https://reviews.llvm.org/D77488
2020-04-07 15:06:51 -07:00
Stephen Neuendorffer 75f60c698f [MLIR] Cleanup mlir-tblgen error messages for custom assembly formats.
The messages are somewhat cryptic, since they are not complete sentences,
include lots of ambiguous words, like 'format' which are hard to parse,
and include names from the users code which may, or may not make sense in
the context of the message.  Start to clean this up and provide some
guidance for fixes.

Also, add a test for one of the messages which didn't have a test at all.

Differential Revision: https://reviews.llvm.org/D77449
2020-04-07 15:06:50 -07:00
River Riddle 1834ad4a69 [mlir][Pass] Update the PassGen to generate base classes instead of utilities
Summary:
This is much cleaner, and fits the same structure as many other tablegen backends. This was not done originally as the CRTP in the pass classes made it overly verbose/complex.

Differential Revision: https://reviews.llvm.org/D77367
2020-04-07 14:08:52 -07:00
Jacques Pienaar 3f7439b280 [mlir][DRR] Add location directive
Summary:
Add directive to indicate the location to give to op being created. This
directive is optional and if unused the location will still be the fused
location of all source operations.

Currently this directive only works with other op locations, reusing an
existing op location or a fusion of op locations. But doesn't yet support
supplying metadata for the FusedLoc.

Based off initial revision by antiagainst@ and effectively mirrors GlobalIsel
debug_locations directive.

Differential Revision: https://reviews.llvm.org/D77649
2020-04-07 13:38:25 -07:00
Stella Laurenzo f5deb0878d Remove FxpMathOps dialect and Quantizer tool.
Summary:
* Removal of FxpMathOps was discussed on the mailing list.
* Will send a courtesy note about also removing the Quantizer (which had some dependencies on FxpMathOps).
* These were only ever used for experimental purposes and we know how to get them back from history as needed.
* There is a new proposal for more generalized quantization tooling, so moving these older experiments out of the way helps clean things up.

Subscribers: mgorny, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D77479
2020-04-07 13:22:39 -07:00