Commit Graph

20 Commits

Author SHA1 Message Date
River Riddle 195730a650 [mlir][NFC] Replace references to Identifier with StringAttr
This is part of the replacement of Identifier with StringAttr.

Differential Revision: https://reviews.llvm.org/D113953
2021-11-16 17:36:26 +00:00
Logan Chien 88125e8af1 [mlir] Fix attachInterface typo
This commit fixes the documentation typo regarding `attachInterface`.

Differential Revision: https://reviews.llvm.org/D108666
2021-08-24 15:17:52 -07:00
Sean Silva 7f7be19e6a [mlir] Add notes about using external interface application.
Differential Revision: https://reviews.llvm.org/D104489
2021-06-18 07:42:47 -07:00
Alex Zinenko 23cdf7b6ed [mlir] separable registration of operation interfaces
This is similar to attribute and type interfaces and mostly the same mechanism
(FallbackModel / ExternalModel, ODS generation). There are minor differences in
how the concept-based polymorphism is implemented for operations that are
accounted for by ODS backends, and this essentially adds a test and exposes the
API.

Reviewed By: rriddle

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

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

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

Reviewed By: rriddle

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

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

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

Depends On D104233

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D104234
2021-06-15 15:20:27 +02:00
Markus Böck d35bd98651 [mlir][doc] Fix links and references in top level docs directory
This is the fourth and final patch in a series of patches fixing markdown links and references inside the mlir documentation. This patch combined with the other three should fix almost every broken link on mlir.llvm.org as far as I can tell.

This patch in particular addresses all Markdown files in the top level docs directory.

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

Reviewed By: rriddle, jpienaar

Differential Revision: https://reviews.llvm.org/D93085
2021-03-24 08:41:40 +00:00
Andrew Young a55a0a3056
[mlir] Remove over specified memory effects
The standard and gpu dialect both have `alloc` operations which use the
memory effect `MemAlloc`.  In both cases, it is specified on both  the
operation itself and on the result.  This results in two memory effects
being created for these operations.  When `MemAlloc` is defined on an
operation, it represents some background effect which the compiler
cannot reason about, and  inhibits the ability of the compiler to
remove dead `std.alloc` operations.  This change removes the uneeded
`MemAlloc` effect from these operations and leaves the effect on the
result, which allows dead allocs to be erased.

There is the same problem, but to a lesser extent, with MemFree, MemRead
and MemWrite. Over-specifying these traits is not currently inhibiting
any optimization.

Differential Revision: https://reviews.llvm.org/D94662
2021-01-14 14:49:41 -08:00
River Riddle d1e0545445 [mlir][Interfaces] Tidy up the documentation for interfaces
The documentation has become a bit stale with age, and doesn't include great documentation for some newer concepts. This revision tidies up a majority of it, with some more cleanup to come in the future. The documentation for the declarative specification is also moved from OpDefinitions.md to Interfaces.md, which is a much more logical place for it to live.

Differential Revision: https://reviews.llvm.org/D92895
2020-12-09 15:34:07 -08:00
River Riddle 71eeb5ec4d [mlir] Add a new SymbolUserOpInterface class
The initial goal of this interface is to fix the current problems with verifying symbol user operations, but can extend beyond that in the future. The current problems with the verification of symbol uses are:
* Extremely inefficient:
Most current symbol users perform the symbol lookup using the slow O(N) string compare methods, which can lead to extremely long verification times in large modules.
* Invalid/break the constraints of verification pass
If the symbol reference is not-flat(and even if it is flat in some cases) a verifier for an operation is not permitted to touch the referenced operation because it may be in the process of being mutated by a different thread within the pass manager.

The new SymbolUserOpInterface exposes a method `verifySymbolUses` that will be invoked from the parent symbol table to allow for verifying the constraints of any referenced symbols. This method is passed a `SymbolTableCollection` to allow for O(1) lookups of any necessary symbol operation.

Differential Revision: https://reviews.llvm.org/D89512
2020-10-16 12:08:48 -07:00
Scott Todd 1c5aa8aeca [mlir] Update docs referencing OpTrait::Symbol.
Since https://reviews.llvm.org/D78522, Symbol is not a Trait itself.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D88512
2020-09-30 03:55:54 +00:00
Stephen Neuendorffer 628288658c [MLIR] Add RegionKindInterface
Some dialects have semantics which is not well represented by common
SSA structures with dominance constraints.  This patch allows
operations to declare the 'kind' of their contained regions.
Currently, two kinds are allowed: "SSACFG" and "Graph".  The only
difference between them at the moment is that SSACFG regions are
required to have dominance, while Graph regions are not required to
have dominance.  The intention is that this Interface would be
generated by ODS for existing operations, although this has not yet
been implemented. Presumably, if someone were interested in code
generation, we might also have a "CFG" dialect, which defines control
flow, but does not require SSA.

The new behavior is mostly identical to the previous behavior, since
registered operations without a RegionKindInterface are assumed to
contain SSACFG regions.  However, the behavior has changed for
unregistered operations.  Previously, these were checked for
dominance, however the new behavior allows dominance violations, in
order to allow the processing of unregistered dialects with Graph
regions.  One implication of this is that regions in unregistered
operations with more than one op are no longer CSE'd (since it
requires dominance info).

I've also reorganized the LangRef documentation to remove assertions
about "sequential execution", "SSA Values", and "Dominance".  Instead,
the core IR is simply "ordered" (i.e. totally ordered) and consists of
"Values".  I've also clarified some things about how control flow
passes between blocks in an SSACFG region. Control Flow must enter a
region at the entry block and follow terminator operation successors
or be returned to the containing op.  Graph regions do not define a
notion of control flow.

see discussion here:
https://llvm.discourse.group/t/rfc-allowing-dialects-to-relax-the-ssa-dominance-condition/833/53

Differential Revision: https://reviews.llvm.org/D80358
2020-07-15 14:27:05 -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
River Riddle 7d1452d837 [mlir] Refactor OpInterface internals to be faster and factor out common bits.
This revision adds a new support header, InterfaceSupport, to contain various generic bits of functionality for implementing "Interfaces". Interfaces embody a mechanism for attaching concept-based polymorphism to a type system. With this refactoring a new InterfaceMap type is added to allow for efficient interface lookups without going through an indirect call. This should provide a decent performance speedup without changing the size of AbstractOperation.

In a future revision, this functionality will also be used to bring Interface like functionality to Attributes and Types.

Differential Revision: https://reviews.llvm.org/D81882
2020-06-24 17:23:58 -07:00
Stephen Neuendorffer 2e628d008c [MLIR][docs] Update tutorial language around Op and Operation* and 'opaque'
Differential Revision: https://reviews.llvm.org/D79146
2020-05-01 11:26:38 -07:00
River Riddle 89b007037f [mlir][docs] Remove the MLIR prefix from several titles.
This prefix is already implied by the doc location and functions only as
filler.
2020-04-11 14:49:03 -07:00
River Riddle 55de49ac1c [mlir][docs] Refactor the layout of the docs folder
Summary:
This revision performs a few refactorings on the main docs folder. Namely it:
* Adds a new Rationale/ folder to contain various rationale documents
* Moves several "getting started" documents to the Tutorials/ folder
* Cleans up the titles of various documents

Differential Revision: https://reviews.llvm.org/D77934
2020-04-11 11:47:01 -07:00
Rob Suderman e708471395 [mlir][NFC] Cleanup AffineOps directory structure
Summary:
Change AffineOps Dialect structure to better group both IR and Tranforms. This included extracting transforms directly related to AffineOps. Also move AffineOps to Affine.

Differential Revision: https://reviews.llvm.org/D76161
2020-03-20 14:23:43 -07:00
Mehdi Amini 5b4a01d4a6 Adjust some MLIR paths and docs 2019-12-24 02:23:01 +00:00