Commit Graph

391 Commits

Author SHA1 Message Date
Geoffrey Martin-Noble db011775e4 Reland "[MLIR] Make structured op tests permutation invariant"
Relands with fix swapping DEPENDS for LINK_LIBS.

This reverts commit cd8cc00b9e.

Differential Revision: https://reviews.llvm.org/D97011
2021-02-18 18:09:49 -08:00
Mehdi Amini cd8cc00b9e Revert "[MLIR] Make structured op tests permutation invariant"
This reverts commit b9ff67099a.
The build is broken with -DBUILD_SHARED_LIBS=ON
2021-02-19 00:16:45 +00:00
Geoffrey Martin-Noble b9ff67099a [MLIR] Make structured op tests permutation invariant
Extracts the relevant dimensions from the map under test to build up the
maps to test against in a permutation-invariant way.

This also includes a fix to the indexing maps used by
isColumnMajorMatmul. The maps as currently written do not describe a
column-major matmul. The linalg named op column_major_matmul has the
correct maps (and notably fails the current test).

If `C = matmul(A, B)` we want an operation that given A in column major
format and B in column major format produces C in column major format.
Given that for a matrix, faux column major is just transpose.
`column_major_matmul(transpose(A), transpose(B)) = transpose(C)`. If
`A` is `NxK` and `B` is `KxM`, then `C` is `NxM`, so `transpose(A)` is
`KxN`, `transpose(B)` is `MxK` and `transpose(C)` is `MxN`, not `NxM`
as these maps currently have.

Reviewed By: nicolasvasilache

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

Working on a fix.

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

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

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

Differential Revision: https://reviews.llvm.org/D96425
2021-02-18 11:29:39 +01:00
Jacques Pienaar 381a65fa06 [mlir] Add clone method to ShapedType
Allow clients to create a new ShapedType of the same "container" type
but with different element or shape. First use case is when refining
shape during shape inference without needing to consider which
ShapedType is being refined.

Differential Revision: https://reviews.llvm.org/D96682
2021-02-15 11:04:16 -08:00
Alex Zinenko 34ea608a47 [mlir] Support repeated delayed registration of dialect interfaces
Dialects themselves do not support repeated addition of interfaces with the
same TypeID. However, in case of delayed registration, the registry may contain
such an interface, or have the same interface registered several times due to,
e.g., dependencies. Make sure we delayed registration does not attempt to add
an interface with the same TypeID more than once.

Reviewed By: mehdi_amini

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

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

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

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D96503
2021-02-12 17:49:44 +01:00
Mehdi Amini 09cfec6243 Fix CMake configuration for MLIR unittests
The CMake changes in 2aa1af9b1d to make it possible to build MLIR as a
standalone project unfortunately disabled all unit-tests from the
regular in-tree build.
2021-02-11 01:17:49 +00:00
Mehdi Amini 81987396ac Fix StridedMemRefType operator[] SFINAE to allow correctly selecting the `int64_t` overload for non-container operands 2021-02-10 20:02:11 +00:00
Mehdi Amini 9680ea5c98 Add convenience C++ helper to manipulate ranked strided memref
Reland 11f32a41c2 that was reverted in e49967fbd9 after fixing the build.

Differential Revision: https://reviews.llvm.org/D96192
2021-02-10 18:58:05 +00:00
Mehdi Amini e49967fbd9 Revert "Add convenience C++ helper to manipulate ranked strided memref"
This reverts commit 11f32a41c2.

The build is broken because this commit conflits with the refactoring of
the DialectRegistry APIs in the context. It'll reland shortly after
fixing the API usage.
2021-02-10 18:09:38 +00:00
Mehdi Amini 11f32a41c2 Add convenience C++ helper to manipulate ranked strided memref
Differential Revision: https://reviews.llvm.org/D96192
2021-02-10 17:40:36 +00:00
Alex Zinenko 2996a8d675 [mlir] avoid exposing mutable DialectRegistry from MLIRContext
MLIRContext allows its users to access directly to the DialectRegistry it
contains. While sometimes useful for registering additional dialects on an
already existing context, this breaks the encapsulation by essentially giving
raw accesses to a part of the context's internal state. Remove this mutable
access and instead provide a method to append a given DialectRegistry to the
one already contained in the context. Also provide a shortcut mechanism to
construct a context from an already existing registry, which seems to be a
common use case in the wild. Keep read-only access to the registry contained in
the context in case it needs to be copied or used for constructing another
context.

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

Depends On D96137

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D96331
2021-02-10 12:07:34 +01:00
Alex Zinenko 3da51522fb [mlir] enable delayed registration of dialect interfaces
This introduces a mechanism to register interfaces for a dialect without making
the dialect itself depend on the interface. The registration request happens on
DialectRegistry and, if the dialect has not been loaded yet, the actual
registration is delayed until the dialect is loaded. It requires
DialectRegistry to become aware of the context that contains it and the context
to expose methods for querying if a dialect is loaded.

This mechanism will enable a simple extension mechanism for dialects that can
have interfaces defined outside of the dialect code. It is particularly helpful
for, e.g., translation to LLVM IR where we don't want the dialect itself to
depend on LLVM IR libraries.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D96137
2021-02-10 12:07:32 +01:00
Tres Popp c2c83e97c3 Revert "Revert "Reorder MLIRContext location in BuiltinAttributes.h""
This reverts commit 511dd4f438 along with
a couple fixes.

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

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

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

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

Differential Revision: https://reviews.llvm.org/D96111
2021-02-08 09:28:09 +01:00
Mehdi Amini d6efb6fc86 Rework ExecutionEngine::invoke() to make it more friendly to use from C++
This new invoke will pack a list of argument before calling the
`invokePacked` method. It accepts returned value as output argument
wrapped in `ExecutionEngine::Result<T>`, and delegate the packing of
arguments to a trait to allow for customization for some types.

Reviewed By: ftynse

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

Differential Revision: https://reviews.llvm.org/D95841
2021-02-04 15:10:10 -08:00
karimnosseir 0af2527536 Update ElementsAttr::isValidIndex to handle ElementsAttr with a scalar. Scalar will have rank 0.
Update ElementsAttr::isValidIndex to handle ElementsAttr with a scalar. Scalar will have rank 0.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D95663
2021-01-29 16:56:00 -08:00
Arjun P 14056dfb4d [MLIR] Add support for extracting an integer sample point (if one exists) from an unbounded FlatAffineConstraints.
With this, we have complete support for finding integer sample points in FlatAffineConstraints.

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D95047
2021-01-22 22:28:38 +05:30
Arjun P 9f32f1d6fb [MLIR] Support checking if two FlatAffineConstraints are equal
This patch adds support for checking if two PresburgerSets are equal. In particular, one can check if two FlatAffineConstraints are equal by constructing PrebsurgerSets from them and comparing these.

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D94915
2021-01-18 21:46:01 +05:30
Arjun P 6ebeba88f5 Support emptiness checks for unbounded FlatAffineConstraints.
With this, we have complete support for emptiness checks. This also paves the way for future support to check if two FlatAffineConstraints are equal.

Reviewed By: ftynse

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

Differential Revision: https://reviews.llvm.org/D94133
2021-01-06 14:18:58 -08:00
River Riddle 1b97cdf885 [mlir][IR][NFC] Move context/location parameters of builtin Type::get methods to the start of the parameter list
This better matches the rest of the infrastructure, is much simpler, and makes it easier to move these types to being declaratively specified.

Differential Revision: https://reviews.llvm.org/D93432
2020-12-17 13:01:36 -08:00
Lei Zhang 0117865412 [mlir][spirv] NFC: Shuffle code around to better follow convention
This commit shuffles SPIR-V code around to better follow MLIR
convention. Specifically,

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

Reviewed By: mravishankar

Differential Revision: https://reviews.llvm.org/D93407
2020-12-17 11:03:26 -05:00
Christian Sigg a1eb154421 [flang] Use mlir::OpState::operator->() to get to methods of mlir::Operation.
This is a preparation step to remove those methods from OpState.

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D93194
2020-12-14 20:04:53 +01:00
ergawy ecab63894b [MLIR][SPIRV] Refactoring serialization and deserialization
This commit splits SPIR-V's serialization and deserialization code
into separate libraries. The motiviation being that the serializer
is used more often the deserializer and therefore lumping them
together unnecessarily increases binary size for the most common
case.

This commit also moves these libraries into the Target/ directory
to follow MLIR convention.

Reviewed By: antiagainst

Differential Revision: https://reviews.llvm.org/D91548
2020-12-14 12:28:16 -05:00
River Riddle c7cae0e4fa [mlir][Attributes][NFC] Move all builtin Attribute classes to BuiltinAttributes.h
This mirrors the file structure of Types.

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

Differential Revision: https://reviews.llvm.org/D92435
2020-12-03 18:02:10 -08:00
Marius Brehler c5d017267d [mlir] Add build configuration for Quant unittest 2020-11-25 21:59:05 +01: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
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
Rahul Joshi b7382ed3fe [MLIR] Extend Symbol verification to reject public symbol declarations.
- Extend the Symbol interface with `isDeclaration` to identify operations that declare
  a symbol as opposed to define it.
- Extend verification to disallow public declarations as per the discussion in
   https://llvm.discourse.group/t/rfc-symbol-definition-declaration-x-visibility-checks/2140
- Adopt the new interface for `FuncOp` and fix test and code to not have/create public
  function declarations.

Differential Revision: https://reviews.llvm.org/D91456
2020-11-16 16:05:32 -08: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
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
Mehdi Amini 008b9d97cb Make the implicit nesting behavior of the PassManager user-controllable and default to false
This is an error prone behavior, I frequently have ~20 min debugging sessions when I hit
an unexpected implicit nesting. This default makes the C++ API safer for users.

Depends On D90669

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D90671
2020-11-03 11:17:44 +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 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
James Molloy 8bdbe29519 [mlir] Fix bug in computing operation order
When attempting to compute a differential orderIndex we were calculating the
bailout condition correctly, but then an errant "+ 1" meant the orderIndex we
created was invalid.

Added test.

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D89115
2020-10-09 12:18:52 +01:00
Arjun P 63dead2096 Introduce subtraction for FlatAffineConstraints
Subtraction is a foundational arithmetic operation that is often used when computing, for example, data transfer sets or cache hits. Since the result of subtraction need not be a convex polytope, a new class `PresburgerSet` is introduced to represent unions of convex polytopes.

Reviewed By: ftynse, bondhugula

Differential Revision: https://reviews.llvm.org/D87068
2020-10-07 17:31:06 +02: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
Rahul Joshi 08e4f07852 [MLIR][NFC] Adopt use of TypeRange in build() methods.
- Use TypeRange instead of ArrayRef<Type> where possible.
- Change some of the custom builders to also use TypeRange

Differential Revision: https://reviews.llvm.org/D87944
2020-09-23 09:07:57 -07: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 1284dc34ab Use an Identifier instead of an OperationName internally for OpPassManager identification (NFC)
This allows to defers the check for traits to the execution instead of forcing it on the pipeline creation.
In particular, this is making our pipeline creation tolerant to dialects not being loaded in the context yet.

Reviewed By: rriddle, GMNGeoffrey

Differential Revision: https://reviews.llvm.org/D86915
2020-09-02 21:46:05 +00:00
Mehdi Amini c39c21610d Rename AnalysisManager::slice in AnalysisManager::nest (NFC)
The naming wasn't reflecting the intent of this API, "nest" is aligning
it with the pass manager API.
2020-08-28 20:41:07 +00:00
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
Arjun P 33f574672f [MLIR] Redundancy detection for FlatAffineConstraints using Simplex
This patch adds the capability to perform constraint redundancy checks for `FlatAffineConstraints` using `Simplex`, via a new member function `FlatAffineConstraints::removeRedundantConstraints`. The pre-existing redundancy detection algorithm runs a full rational emptiness check for each inequality separately for checking redundancy. Leveraging the existing `Simplex` infrastructure, in this patch we have an algorithm for redundancy checks that can check each constraint by performing pivots on the tableau, which provides an alternative to running Fourier-Motzkin elimination for each constraint separately.

Differential Revision: https://reviews.llvm.org/D84935
2020-08-20 13:38:51 +05:30
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
Rahul Joshi 9a4b30cf84 [MLIR] Add support for defining and using Op specific analysis
- Add variants of getAnalysis() and friends that operate on a specific derived
  operation types.
- Add OpPassManager::getAnalysis() to always call the base getAnalysis() with OpT.
- With this, an OperationPass can call getAnalysis<> using an analysis type that
  is generic (works on Operation *) or specific to the OpT for the pass. Anything
  else will fail to compile.
- Extend AnalysisManager unit test to test this, and add a new PassManager unit
  test to test this functionality in the context of an OperationPass.

Differential Revision: https://reviews.llvm.org/D84897
2020-08-17 09:00:47 -07: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
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
River Riddle fff39b62bb [mlir][Attribute] Remove usages of Attribute::getKind
This is in preparation for removing the use of "kinds" within attributes and types in MLIR.

Differential Revision: https://reviews.llvm.org/D85370
2020-08-07 13:43:25 -07: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
Rahul Joshi 0b161def6c [MLIR] Add unit test for tblgen Op build methods
- Initiate the unit test with a test that tests variants of build() methods
  generated for ops with variadic operands and results.
- The intent is to migrate unit .td tests in mlir/test/mlir-tblgen that check for
  generated C++ code to these unit tests which test both that the generated code
  compiles and also is functionally correct.

Differential Revision: https://reviews.llvm.org/D84074
2020-07-28 15:43:37 -07:00
Logan Smith a52aea0ba6 Use INTERFACE_COMPILE_OPTIONS to disable -Wsuggest-override for any target that links to gtest
This cleans up several CMakeLists.txt's where -Wno-suggest-override was manually specified. These test targets now inherit this flag from the gtest target.

Some unittests CMakeLists.txt's, in particular Flang and LLDB, are not touched by this patch. Flang manually adds the gtest sources itself in some configurations, rather than linking to LLVM's gtest target, so this fix would be insufficient to cover those cases. Similarly, LLDB has subdirectories that manually add the gtest headers to their include path without linking to the gtest target, so those subdirectories still need -Wno-suggest-override to be manually specified to compile without warnings.

Differential Revision: https://reviews.llvm.org/D84554
2020-07-27 08:37:01 -07:00
Logan Smith 77e0e9e17d Reapply "Try enabling -Wsuggest-override again, using add_compile_options instead of add_compile_definitions for disabling it in unittests/ directories."
add_compile_options is more sensitive to its location in the file than add_definitions--it only takes effect for sources that are added after it. This updated patch ensures that the add_compile_options is done before adding any source files that depend on it.

Using add_definitions caused the flag to be passed to rc.exe on Windows and thus broke Windows builds.
2020-07-22 17:50:19 -07:00
Logan Smith 97a0f80c46 Revert "Try enabling -Wsuggest-override again, using add_compile_options instead of add_compile_definitions for disabling it in unittests/ directories."
This reverts commit 388c9fb1af.
2020-07-22 15:07:01 -07:00
Logan Smith 388c9fb1af Try enabling -Wsuggest-override again, using add_compile_options instead of add_compile_definitions for disabling it in unittests/ directories.
Using add_compile_definitions caused the flag to be passed to rc.exe on Windows and thus broke Windows builds.
2020-07-22 14:19:34 -07:00
Hans Wennborg 3eec657825 Revert "Enable -Wsuggest-override in the LLVM build" and the follow-ups.
After lots of follow-up fixes, there are still problems, such as
-Wno-suggest-override getting passed to the Windows Resource Compiler
because it was added with add_definitions in the CMake file.

Rather than piling on another fix, let's revert so this can be re-landed
when there's a proper fix.

This reverts commit 21c0b4c1e8.
This reverts commit 81d68ad27b.
This reverts commit a361aa5249.
This reverts commit fa42b7cf29.
This reverts commit 955f87f947.
This reverts commit 8b16e45f66.
This reverts commit 308a127a38.
This reverts commit 274b6b0c7a.
This reverts commit 1c7037a2a5.
2020-07-22 20:23:58 +02:00
Logan Smith 21c0b4c1e8 Disable -Wsuggest-override for all remaining unittests/ directories 2020-07-21 17:48:36 -07:00
Lei Zhang 2dd9e43579 [spirv] Use owning module ref to avoid leaks and fix ASAN tests
Differential Revision: https://reviews.llvm.org/D83982
2020-07-16 17:30:59 -04:00
Rahul Joshi 032810f589 [NFC] Fix comment style in MLIR unittests to conform to LLVM coding standards.
Differential Revision: https://reviews.llvm.org/D83632
2020-07-12 07:27:02 -07:00
Lei Zhang b80508703f [mlir][spirv] Introduce OwningSPIRVModuleRef for ownership
Similar to OwningModuleRef, OwningSPIRVModuleRef signals ownership
transfer clearly. This is useful for APIs like spirv::deserialize,
where a spirv::ModuleOp is returned by deserializing SPIR-V binary
module.

This addresses the ASAN error as reported in
https://bugs.llvm.org/show_bug.cgi?id=46272

Differential Revision: https://reviews.llvm.org/D81652
2020-07-07 08:29:27 -04: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
Arjun P 10a898b3ec [MLIR] Exact integer emptiness checks for FlatAffineConstraints
This patch adds the capability to perform exact integer emptiness checks for FlatAffineConstraints using the General Basis Reduction algorithm (GBR). Previously, only a heuristic was available for emptiness checks, which was not guaranteed to always give a conclusive result.

This patch adds a `Simplex` class, which can be constructed using a `FlatAffineConstraints`, and can find an integer sample point (if one exists) using the GBR algorithm. Additionally, it adds two classes `Matrix` and `Fraction`, which are used by `Simplex`.

The integer emptiness check functionality can be accessed through the new `FlatAffineConstraints::isIntegerEmpty()` function, which runs the existing heuristic first and, if that proves to be inconclusive, runs the GBR algorithm to produce a conclusive result.

Differential Revision: https://reviews.llvm.org/D80860
2020-07-02 19:53:27 +05:30
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
HazemAbdelhafez d7e6f116f4 [mlir][spirv] Enhance structure type member decoration handling
Modify structure type in SPIR-V dialect to support:
1) Multiple decorations per structure member
2) Key-value based decorations (e.g., MatrixStride)

This commit kept the Offset decoration separate from members'
decorations container for easier implementation and logical clarity.
As such, all references to Structure layoutinfo are now offsetinfo,
and any member layout defining decoration (e.g., RowMajor for Matrix)
will be add to the members' decorations container along with its
value if any.

Differential Revision: https://reviews.llvm.org/D81426
2020-06-12 17:57:14 -04:00
Mehdi Amini 6f0ce46873 Revert "[mlir][spirv] Enhance structure type member decoration handling"
This reverts commit 5d74df5b03.

This broke the MSVC build:  <bits/stdint-uintn.h> isn't available on Windows
2020-06-12 05:01:24 +00:00
HazemAbdelhafez 5d74df5b03 [mlir][spirv] Enhance structure type member decoration handling
Modify structure type in SPIR-V dialect to support:
1) Multiple decorations per structure member
2) Key-value based decorations (e.g., MatrixStride)

This commit kept the Offset decoration separate from members'
decorations container for easier implementation and logical clarity.
As such, all references to Structure layoutinfo are now offsetinfo,
and any member layout defining decoration (e.g., RowMajor for Matrix)
will be add to the members' decorations container along with its
value if any.

Differential Revision: https://reviews.llvm.org/D81426
2020-06-11 19:52:13 -04:00
Mehdi Amini 1cf14860db Revert "[mlir][spirv] Enhance structure type member decoration handling"
This reverts commit 4b7aa6c8c1.

This broke gcc builds.
2020-06-11 00:52:03 +00:00
HazemAbdelhafez 4b7aa6c8c1 [mlir][spirv] Enhance structure type member decoration handling
Modify structure type in SPIR-V dialect to support:
1) Multiple decorations per structure member
2) Key-value based decorations (e.g., MatrixStride)

This commit kept the Offset decoration separate from members'
decorations container for easier implementation and logical clarity.
As such, all references to Structure layoutinfo are now offsetinfo,
and any member layout defining decoration (e.g., RowMajor for Matrix)
will be add to the members' decorations container along with its
value if any.

Differential Revision: https://reviews.llvm.org/D81426
2020-06-10 19:25:03 -04:00
Diego Caballero 7d59f49bda [mlir] Fix representation of BF16 constants
This patch is a follow-up on https://reviews.llvm.org/D81127

BF16 constants were represented as 64-bit floating point values due to the lack
of support for BF16 in APFloat. APFloat was recently extended to support
BF16 so this patch is fixing the BF16 constant representation to be 16-bit.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D81218
2020-06-05 17:43:06 -07: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
River Riddle 24ad385884 [mlir][DenseElementsAttr] Add support for opaque APFloat/APInt complex values.
This revision allows for creating DenseElementsAttrs and accessing elements using std::complex<APInt>/std::complex<APFloat>. This allows for opaquely accessing and transforming complex values. This is used by the printer/parser to provide pretty printing for complex values. The form for complex values matches that of std::complex, i.e.:

```
// `(` element `,` element `)`
dense<(10,10)> : tensor<complex<i64>>
```

Differential Revision: https://reviews.llvm.org/D79296
2020-05-05 12:42:37 -07:00
River Riddle da2a6f4e3b [mlir][DenseElementsAttr] Add support for ComplexType elements
This revision adds support for storing ComplexType elements inside of a DenseElementsAttr. We store complex objects as an array of two elements, matching the  definition of std::complex. There is no current attribute storage for ComplexType, but DenseElementsAttr provides API for access/creation using std::complex<>. Given that the internal implementation of DenseElementsAttr is already fairly opaque, the only real complexity here is in the printing/parsing. This revision keeps it simple for now and always uses hex when printing complex elements. A followup will add prettier syntax for this.

Differential Revision: https://reviews.llvm.org/D79281
2020-05-05 12:42:37 -07:00
River Riddle 0d5caa8940 [mlir][DenseStringElementsAttr] Add support for the Attribute based get* methods.
This was missed in the original revision. This allows for using the opaque Attribute accessors when the elements are strings.
2020-05-01 16:34:35 -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
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
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
River Riddle 910fff1c1d [mlir][DenseStringAttr] Fix support for splat detection and iteration
This revision also adds proper tests for splat detection.
2020-04-26 13:53:57 -07:00
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 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 204c3b5516 [llvm][STLExtras] Move various iterator/range utilities from MLIR to LLVM
This revision moves the various range utilities present in MLIR to LLVM to enable greater reuse. This revision moves the following utilities:

* indexed_accessor_*
This is set of utility iterator/range base classes that allow for building a range class where the iterators are represented by an object+index pair.

* make_second_range
Given a range of pairs, returns a range iterating over the `second` elements.

* hasSingleElement
Returns if the given range has 1 element. size() == 1 checks end up being very common, but size() is not always O(1) (e.g., ilist). This method provides O(1) checks for those cases.

Differential Revision: https://reviews.llvm.org/D78064
2020-04-14 15:14:40 -07: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
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
Mehdi Amini bab5bcf8fd Add a flag on the context to protect against creation of operations in unregistered dialects
Differential Revision: https://reviews.llvm.org/D76903
2020-03-30 19:37:31 +00:00
Rob Suderman 363dd3f394 [mlir][NFC] Rename QuantOps to Quant
Summary:
Renamed QuantOps to Quant to avoid the Ops suffix. All dialects will contain
ops, so the Ops suffix is redundant.

Differential Revision: https://reviews.llvm.org/D76318
2020-03-17 15:16:47 -07:00
Lei Zhang 3148f10b17 [mlir][spirv] Use spv.vce in spv.module and wire up (de)serialization
This commits changes the definition of spv.module to use the #spv.vce
attribute for specifying (version, capabilities, extensions) triple
so that we can have better API and custom assembly form. Since now
we have proper modelling of the triple, (de)serialization is wired up
to use them.

With the new UpdateVCEPass, we don't need to manually specify the
required extensions and capabilities anymore when creating a spv.module.
One just need to call UpdateVCEPass before serialization to get the
needed version/extensions/capabilities.

Differential Revision: https://reviews.llvm.org/D75872
2020-03-12 19:37:45 -04:00
Stephen Neuendorffer 798e661567 Revert "[MLIR] Move from using target_link_libraries to LINK_LIBS for llvm libraries."
This reverts commit 7a6c689771.
This breaks the build with cmake 3.13.4, but succeeds with cmake 3.15.3
2020-02-29 11:52:08 -08:00
Stephen Neuendorffer 7a6c689771 [MLIR] Move from using target_link_libraries to LINK_LIBS for llvm libraries.
When compiling libLLVM.so, add_llvm_library() manipulates the link libraries
being used.  This means that when using add_llvm_library(), we need to pass
the list of libraries to be linked (using the LINK_LIBS keyword) instead of
using the standard target_link_libraries call.  This is preparation for
properly dealing with creating libMLIR.so as well.

Differential Revision: https://reviews.llvm.org/D74864
2020-02-29 10:47:26 -08:00
Stephen Neuendorffer dc1056a3f1 Revert "[MLIR] Move from using target_link_libraries to LINK_LIBS for llvm libraries."
This reverts commit 2f265e3528.
2020-02-28 14:13:30 -08:00
Stephen Neuendorffer 2f265e3528 [MLIR] Move from using target_link_libraries to LINK_LIBS for llvm libraries.
When compiling libLLVM.so, add_llvm_library() manipulates the link libraries
being used.  This means that when using add_llvm_library(), we need to pass
the list of libraries to be linked (using the LINK_LIBS keyword) instead of
using the standard target_link_libraries call.  This is preparation for
properly dealing with creating libMLIR.so as well.

Differential Revision: https://reviews.llvm.org/D74864
2020-02-28 11:35:17 -08:00
Tamas Berghammer 066a76a234 Support OptionalAttr inside a StructAttr
Differential revision: https://reviews.llvm.org/D74768
2020-02-19 12:47:04 +00:00
Mehdi Amini c64770506b Remove static registration for dialects, and the "alwayslink" hack for passes
In the previous state, we were relying on forcing the linker to include
all libraries in the final binary and the global initializer to self-register
every piece of the system. This change help moving away from this model, and
allow users to compose pieces more freely. The current change is only "fixing"
the dialect registration and avoiding relying on "whole link" for the passes.
The translation is still relying on the global registry, and some refactoring
is needed to make this all more convenient.

Differential Revision: https://reviews.llvm.org/D74461
2020-02-12 09:13:02 +00:00
Alex Zinenko fdc496a3d3 [mlir] EnumsGen: dissociate string form of integer enum from C++ symbol name
Summary:
In some cases, one may want to use different names for C++ symbol of an
enumerand from its string representation. In particular, in the LLVM dialect
for, e.g., Linkage, we would like to preserve the same enumerand names as LLVM
API and the same textual IR form as LLVM IR, yet the two are different
(CamelCase vs snake_case with additional limitations on not being a C++
keyword).

Modify EnumAttrCaseInfo in OpBase.td to include both the integer value and its
string representation. By default, this representation is the same as C++
symbol name. Introduce new IntStrAttrCaseBase that allows one to use different
names. Exercise it for LLVM Dialect Linkage attribute. Other attributes will
follow as separate changes.

Differential Revision: https://reviews.llvm.org/D73362
2020-01-30 17:04:00 +01:00
Benjamin Kramer c2b7e4e88a Rewrite test not to rely on StrEq with StringRef
StrEq has some magic inside that should do the explicit conversion from
StringRef to std::string, but apparently this doesn't work with GCC 5.

Just use EXPECT_EQ, it does the same thing with less magic.
2020-01-29 21:43:08 +01:00
Benjamin Kramer adcd026838 Make llvm::StringRef to std::string conversions explicit.
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.
2020-01-28 23:25:25 +01:00
Mehdi Amini 308571074c Mass update the MLIR license header to mention "Part of the LLVM project"
This is an artifact from merging MLIR into LLVM, the file headers are
now aligned with the rest of the project.
2020-01-26 03:58:30 +00:00
River Riddle 68c8b6c4cd [mlir] Use getDenseElementBitwidth instead of Type::getElementTypeBitWidth.
Summary: Some data values have a different storage width than the corresponding MLIR type, e.g. bfloat is currently stored as a double.

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D72478
2020-01-09 14:51:44 -08:00
River Riddle 0d9ca98c1a [mlir] Fix indexed_accessor_range to properly forward the derived class.
Summary: This fixes the return value of helper methods on the base range class.

Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D72127
2020-01-03 13:30:18 -08:00
Lei Zhang 5d5d5838ce [mlir] Enhance classof() checks in StructsGen
Previously we only check that each field is of the correct
mlir::Attribute subclass. This commit enhances to also consider
the attribute's types, by leveraging the constraints already
encoded in TableGen attribute definitions.

Reviewed By: rsuderman

Differential Revision: https://reviews.llvm.org/D72162
2020-01-03 15:13:16 -05:00
River Riddle e62a69561f NFC: Replace ValuePtr with Value and remove it now that Value is value-typed.
ValuePtr was a temporary typedef during the transition to a value-typed Value.

PiperOrigin-RevId: 286945714
2019-12-23 16:36:53 -08:00
Mehdi Amini 56222a0694 Adjust License.txt file to use the LLVM license
PiperOrigin-RevId: 286906740
2019-12-23 15:33:37 -08:00
River Riddle 35807bc4c5 NFC: Introduce new ValuePtr/ValueRef typedefs to simplify the transition to Value being value-typed.
This is an initial step to refactoring the representation of OpResult as proposed in: https://groups.google.com/a/tensorflow.org/g/mlir/c/XXzzKhqqF_0/m/v6bKb08WCgAJ

This change will make it much simpler to incrementally transition all of the existing code to use value-typed semantics.

PiperOrigin-RevId: 286844725
2019-12-22 22:00:23 -08:00
River Riddle f44cf23297 Add a new utility class TypeSwitch to ADT.
This class provides a simplified mechanism for defining a switch over a set of types using llvm casting functionality. More specifically, this allows for defining a switch over a value of type T where each case corresponds to a type(CaseT) that can be used with dyn_cast<CaseT>(...). An example is shown below:

// Traditional piece of code:
Operation *op = ...;
if (auto constant = dyn_cast<ConstantOp>(op))
  ...;
else if (auto return = dyn_cast<ReturnOp>(op))
  ...;
else
  ...;

// New piece of code:
Operation *op = ...;
TypeSwitch<Operation *>(op)
  .Case<ConstantOp>([](ConstantOp constant) { ... })
  .Case<ReturnOp>([](ReturnOp return) { ... })
  .Default([](Operation *op) { ... });

Aside from the above, TypeSwitch supports return values, void return, multiple types per case, etc. The usability is intended to be very similar to StringSwitch.

(Using c++14 template lambdas makes everything even nicer)
More complex example of how this makes certain things easier:
LogicalResult process(Constant op);
LogicalResult process(ReturnOp op);
LogicalResult process(FuncOp op);

TypeSwitch<Operation *, LogicalResult>(op)
  .Case<ConstantOp, ReturnOp, FuncOp>([](auto op) { return process(op); })
  .Default([](Operation *op) { return op->emitError() << "could not be processed"; });

PiperOrigin-RevId: 286003613
2019-12-17 10:08:06 -08:00
Kazuaki Ishizaki 84a6182ddd minor spelling tweaks
Closes tensorflow/mlir#290

COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/290 from kiszk:spelling_tweaks_201912 9d9afd16a723dd65754a04698b3976f150a6054a
PiperOrigin-RevId: 284169681
2019-12-06 05:59:30 -08:00
River Riddle 4741ec6af0 Allow analyses to provide a hook 'isInvalidated' to determine if they are truly invalidated.
The hook has the following form:
*   `bool isInvalidated(const AnalysisManager::PreservedAnalyses &)`

Given a preserved analysis set, the analysis returns true if it should truly be
invalidated. This allows for more fine-tuned invalidation in cases where an
analysis wasn't explicitly marked preserved, but may be preserved(or
invalidated) based upon other properties; such as analyses sets.

PiperOrigin-RevId: 283582889
2019-12-03 11:14:20 -08:00
Lei Zhang 2fa865719b Move BitEnumAttr from SPIRVBase.td to OpBase.td
BitEnumAttr is a mechanism for modelling attributes whose value is
a bitfield. It should not be scoped to the SPIR-V dialect and can
be used by other dialects too.

This CL is mostly shuffling code around and adding tests and docs.
Functionality changes are:

* Fixed to use `getZExtValue()` instead of `getSExtValue()` when
  getting the value from the underlying IntegerAttr for a case.
* Changed to auto-detect whether there is a case whose value is
  all bits unset (i.e., zero). If so handle it specially in all
  helper methods.

PiperOrigin-RevId: 277964926
2019-11-01 11:18:19 -07:00
Kazuaki Ishizaki f28c5aca17 Fix minor spelling tweaks (NFC)
Closes tensorflow/mlir#175

PiperOrigin-RevId: 275726876
2019-10-20 09:44:36 -07:00
River Riddle 2acc220f17 NFC: Remove trivial builder get methods.
These don't add any value, and some are even more restrictive than the respective static 'get' method.

PiperOrigin-RevId: 275391240
2019-10-17 20:08:34 -07:00
Jacques Pienaar c57f202c8c Switch explicit create methods to match generated build's order
The generated build methods have result type before the arguments (operands and attributes, which are also now adjacent in the explicit create method). This also results in changing the create method's ordering to match most build method's ordering.

PiperOrigin-RevId: 271755054
2019-09-28 09:35:58 -07:00
Mahesh Ravishankar 75906bd565 Handle OpMemberName instruction in SPIR-V deserializer.
Sdd support in deserializer for OpMemberName instruction. For now
the name is just processed and not associated with the
spirv::StructType being built. That needs an enhancement to
spirv::StructTypes itself.
Add tests to check for errors reported during deserialization with
some refactoring to common out some utility functions.
PiperOrigin-RevId: 270794524
2019-09-23 17:11:18 -07:00
River Riddle c61991ef01 Refactor DiagnosticEngine to support multiple registered diagnostic handlers.
This fixes a problem with current save-restore pattern of diagnostics handlers, as there may be a thread race between when the previous handler is destroyed. For example, this occurs when using multiple ParallelDiagnosticHandlers asynchronously:

Handler A
Handler B | - LifeTime - |    Restore A here.
Handler C | --- LifeTime ---| Restore B after it has been destroyed.

The new design allows for multiple handlers to be registered in a stack like fashion. Handlers can return success() to signal that they have fully processed a diagnostic, or failure to propagate otherwise.

PiperOrigin-RevId: 270720625
2019-09-23 11:25:14 -07:00
River Riddle 729727ebc7 NFC: Pass OperationState by reference instead of by pointer.
MLIR follows the LLVM convention of passing by reference instead of by pointer.

PiperOrigin-RevId: 270396945
2019-09-20 19:47:32 -07:00
Alex Zinenko 5709aeb993 SDBM: support sum expressions on the LHS of stripe expressions
Introduce support for applying the stripe operator to sum expressions, as in
  (x + A) # B = x + A - (x + A) mod B.
This is required to represent a combination of tiling and padding in the SDBM
framework, and is a valid SDBM construct that was not originally supported.

PiperOrigin-RevId: 269758807
2019-09-18 02:17:34 -07:00
Alex Zinenko a15e0ce1ba Simplify SDBM expressions more aggressively in operators and conversions
Extend SDBM simplification patterns to support more cases where the addition of
two expressions each involving one or two variables would result in a sum
expression that only contains one variable and thus remains in the SDBM domain.
This is made possible by the new canonical structure of SDBM where the constant
term appears once.  This simplification will be necessary to support
round-tripping of stripe expressions containing constant terms on the LHS
through affine expressions.

PiperOrigin-RevId: 269757732
2019-09-18 02:09:08 -07:00
Alex Zinenko cb3ecb5291 Overhaul the SDBM expression kind hierarchy
Swap the allowed nesting of sum and diff expressions: now a diff expression can
contain a sum expression, but only on the left hand side.  A difference of two
expressions sum must be canonicalized by grouping their constant terms in a
single expression.  This change of sturcture became possible thanks to the
introduction of the "direct" super-kind.  It is necessary to enable support of
sum expressions on the left hand side of the stripe expression.

SDBM expressions are now grouped into the following structure
- expression
  - varying
    - direct
      - sum <- (term, constant)
      - term
        - symbol
        - dimension
        - stripe <- (term, constant)
    - negation <- (direct)
    - difference <- (direct, term)
  - constant
The notation <- (...) denotes the types of subexpressions a compound
expression can combine.

PiperOrigin-RevId: 269337222
2019-09-16 08:16:06 -07:00
Alex Zinenko e94db619d9 Introduce SDBMDirect expression into the SDBM expression hierarchy
Direct expressions are those that do not negate any of the variables they
involve.  They include input expressions (dimensions and symbols), stripe and
sum expressions, and combinations of those.  Reifying direct expressions as a
class is a precondition for enabling additions on the LHS of a stripe
expression.

PiperOrigin-RevId: 269336031
2019-09-16 08:09:01 -07:00
Alex Zinenko e15356f8ed Rename SDBMPositiveExpr to SDBMTermExpr
This better reflects how this kind of expressions is used and avoids the
potential confusion since the expression can take negative values.  Term
expressions comprise dimensions, symbols and stripe expressions.  In an SDBM
domain, a stripe expression always corresponds to a variable, input or
temporary.  This expression can appear anywhere an input variable can,
including on the LHS of other stripe expressions.

PiperOrigin-RevId: 268486066
2019-09-11 10:18:29 -07:00
Alex Zinenko 9037f28cb4 Fix typos in SDBMTest.cpp
PiperOrigin-RevId: 268443146
2019-09-11 06:11:36 -07:00
Jacques Pienaar af27f4c746 Avoid sign-compare warning
PiperOrigin-RevId: 268132321
2019-09-09 19:36:31 -07:00
Lei Zhang 5a7014c390 Add missing link dependency to MLIRTableGenTests
PiperOrigin-RevId: 266561495
2019-08-31 09:50:33 -07:00
Rob Suderman 140757050b Fix StructsGenTest.cpp CMakeFile build error
PiperOrigin-RevId: 266452719
2019-08-30 14:10:17 -07:00
Rob Suderman 8f90a442c3 Added a TableGen generator for structured data
Similar to enum, added a generator for structured data. This provide Dictionary that stores a fixed set of values and guarantees the values are valid. It is intended to store a fixed number of values by a given name.

PiperOrigin-RevId: 266437460
2019-08-30 12:52:13 -07:00
River Riddle 29099e03ce Generalize the analysis manager framework to work on any operation at any nesting.
The pass manager is moving towards being able to run on operations at arbitrary nesting. An operation may have both parent and child operations, and the AnalysisManager must be able to handle this generalization. The AnalysisManager class now contains generic 'getCachedParentAnalysis' and 'getChildAnalysis/getCachedChildAnalysis' functions to query analyses on parent/child operations. This removes the hard coded nesting relationship between Module/Function.

PiperOrigin-RevId: 266003636
2019-08-28 15:11:17 -07:00
Lei Zhang 3af6b53381 [spirv] Fix the entry block to start with OpLabel
Each basic block in SPIR-V must start with an OpLabel instruction.
We don't support control flow yet, so this CL just makes sure that
the entry block follows this rule and is valid.

PiperOrigin-RevId: 265718841
2019-08-27 10:51:26 -07:00
Denis Khalikov 8f2dfb51d4 [spirv] Add Block decoration for spv.struct.
Add Block decoration for top-level spv.struct.

Closes tensorflow/mlir#102

PiperOrigin-RevId: 265716241
2019-08-27 10:41:42 -07:00
River Riddle 2f59f76876 NFC: Remove the explicit context from Operation::create and OperationState.
The context can easily be recovered from the Location in these situations.

PiperOrigin-RevId: 265578574
2019-08-26 17:34:48 -07:00
River Riddle ba0fa92524 NFC: Move LLVMIR, SDBM, and StandardOps to the Dialect/ directory.
PiperOrigin-RevId: 264193915
2019-08-19 11:01:25 -07:00
Mahesh Ravishankar 3867ed86eb Add missing include file to StringExtrasTest.cpp
Use of std::isupper and std::islower need <cctype> header file. Fix
that and also fix the header of a file to match the file name.

PiperOrigin-RevId: 260816852
2019-07-30 16:11:40 -07:00
Mahesh Ravishankar 1de519a753 Add support for (de)serialization of SPIR-V Op Decorations
All non-argument attributes specified for an operation are treated as
decorations on the result value and (de)serialized using OpDecorate
instruction. An error is generated if an attribute is not an argument,
and the name doesn't correspond to a Decoration enum. Name of the
attributes that represent decoerations are to be the snake-case-ified
version of the Decoration name.
Add utility methods to convert to snake-case and camel-case.

PiperOrigin-RevId: 260792638
2019-07-30 14:15:03 -07:00
Lei Zhang 4a55bd5f28 [spirv] Add basic infrastructure for negative deserializer tests
We are relying on serializer to construct positive cases to drive
the test for deserializer. This leaves negative cases untested.

This CL adds a basic test fixture for covering the negative
corner cases to enforce a more robust deserializer.

Refactored common SPIR-V building methods out of serializer to
share it with the deserialization test.

PiperOrigin-RevId: 260742733
2019-07-30 11:55:33 -07:00
River Riddle fec20e590f NFC: Rename Module to ModuleOp.
Module is a legacy name that only exists as a typedef of ModuleOp.

PiperOrigin-RevId: 257427248
2019-07-10 10:11:21 -07:00
River Riddle 6b6dc59f30 Update ModuleOp::create(...) to take a Location instead of a context.
This allows for giving a Module a more interesting location than 'Unknown'.

PiperOrigin-RevId: 257310117
2019-07-10 10:11:00 -07:00
River Riddle 8c44367891 NFC: Rename Function to FuncOp.
PiperOrigin-RevId: 257293379
2019-07-10 10:10:53 -07:00
River Riddle 206e55cc16 NFC: Refactor Module to be value typed.
As with Functions, Module will soon become an operation, which are value-typed. This eases the transition from Module to ModuleOp. A new class, OwningModuleRef is provided to allow for owning a reference to a Module, and will auto-delete the held module on destruction.

PiperOrigin-RevId: 256196193
2019-07-02 16:43:36 -07:00
Lei Zhang 509411c229 [ODS] NFC: Rename EnumAttr to StrEnumAttr to be consistent with IntEnumAttr
PiperOrigin-RevId: 256169019
2019-07-02 10:28:36 -07:00
River Riddle 54cd6a7e97 NFC: Refactor Function to be value typed.
Move the data members out of Function and into a new impl storage class 'FunctionStorage'. This allows for Function to become value typed, which will greatly simplify the transition of Function to FuncOp(given that FuncOp is also value typed).

PiperOrigin-RevId: 255983022
2019-07-01 11:39:00 -07:00
Lei Zhang 9dd182e0fa [ODS] Introduce IntEnumAttr
In ODS, right now we use StringAttrs to emulate enum attributes. It is
suboptimal if the op actually can and wants to store the enum as a
single integer value; we are paying extra cost on storing and comparing
the attribute value.

This CL introduces a new enum attribute subclass that are backed by
IntegerAttr. The downside with IntegerAttr-backed enum attributes is
that the assembly form now uses integer values, which is less obvious
than the StringAttr-backed ones. However, that can be remedied by
defining custom assembly form with the help of the conversion utility
functions generated via EnumsGen.

Choices are given to the dialect writers to decide which one to use for
their enum attributes.

PiperOrigin-RevId: 255935542
2019-07-01 09:55:47 -07:00
River Riddle 30bbd91056 Simplify usages of SplatElementsAttr now that it inherits from DenseElementsAttr.
PiperOrigin-RevId: 253910543
2019-06-19 23:07:34 -07:00
River Riddle 2b67821b90 Fix the detection of boolean splat values in DenseElementsAttr for arrays with <=15 values.
PiperOrigin-RevId: 253711372
2019-06-19 23:05:19 -07:00
River Riddle 5624bc289e Add an overloaded 'get' method to DenseElementsAttr that accepts an initializer_list.
PiperOrigin-RevId: 253234385
2019-06-19 23:02:21 -07:00
Alex Zinenko b582338f62 Explicitly construct ArrayRef in AttributeTest.cpp
Some compilers find initializer list constructors from boolean literals
ambiguous between ArrayRef<bool> and ArrayRef<Attribute>.  Call the
ArrayRef<bool> constructor explicitly to disambiguate.

PiperOrigin-RevId: 253224859
2019-06-19 23:02:12 -07:00
River Riddle 6a0555a875 Refactor SplatElementsAttr to inherit from DenseElementsAttr as opposed to being a separate Attribute type. DenseElementsAttr provides a better internal representation for splat values as well as better API for accessing elements.
PiperOrigin-RevId: 253138287
2019-06-19 23:01:52 -07:00
River Riddle 2c9269124a NFC: Fix a narrowing conversion from size_t to int64_t when constructing a VectorType.
PiperOrigin-RevId: 253125435
2019-06-19 23:01:42 -07:00
River Riddle d8cd96bc8b Refactor DenseElementsAttr to support auto-splatting the dense data on construction. This essentially means that we always auto-detect splat data and only store the minimum amount of data necessary. Support for parsing dense splats, and removing SplatElementsAttr(now that it is redundant) will come in followup cls
PiperOrigin-RevId: 252720561
2019-06-19 22:59:15 -07:00
Lei Zhang 1be9fc6611 [TableGen] Generating enum definitions and utility functions
Enum attributes can be defined using `EnumAttr`, which requires all its cases
to be defined with `EnumAttrCase`. To facilitate the interaction between
`EnumAttr`s and their C++ consumers, add a new EnumsGen TableGen backend
to generate a few common utilities, including an enum class, `llvm::DenseMapInfo`
for the enum class, conversion functions from/to strings.

This is controlled via the `-gen-enum-decls` and `-gen-enum-defs` command-line
options of `mlir-tblgen`.

PiperOrigin-RevId: 252209623
2019-06-09 16:24:08 -07:00
River Riddle b790a2f396 Remove the explicit attribute kinds for DenseIntElementsAttr and DenseFPElementsAttr in favor of just one DenseElementsAttr. Now that attribute has the ability to define 'classof(Attribute attr)' methods, these derived classes can just be specializations of the main attribute class.
PiperOrigin-RevId: 251948820
2019-06-09 16:22:05 -07:00
Jacques Pienaar 8b4c214046 Use TestDialect to test traits instead of unittest.
--

PiperOrigin-RevId: 249916947
2019-06-01 20:01:12 -07:00
Alex Zinenko 6aae7b2e9a CMake build: force-link SDBM lib into SDBM unit tests
Otherwise, GCC < 7 does not link in the dialect registration, fails to look up
    the dialect in the context and cannot construct SDBM objects.

--

PiperOrigin-RevId: 249259758
2019-06-01 19:54:53 -07:00
Alex Zinenko 3b500c694d Move SDBM uniquer into the SDBM dialect
MLIRContext does not have to be aware of the SDBM unique data structures
    directly.  Move the SDBM storage uniquer from MLIRContext to the SDBM dialect
    instance.  Expressions that previously required a context to be constructed now
    require an instance of the dialect in order to access the uniquer.  While they
    could look up the dialect in the context, it would have introduced a rather
    expensive lookup into each construction.  Instead, the caller is expected to
    obtain the dialect instance and cache it.

--

PiperOrigin-RevId: 249245199
2019-06-01 19:54:43 -07:00
Alex Zinenko 6804cf2429 Move SDBM infrastructure into a new SDBM dialect
We now have sufficient extensibility in dialects to move attribute components
    such as SDBM out of the core IR into a dedicated dialect and make them
    optional.  Introduce an SDBM dialect and move the code.  This is a mostly
    non-functional change.

--

PiperOrigin-RevId: 249244802
2019-06-01 19:54:33 -07:00
Alex Zinenko 1b94395ed8 Fix -Wsign-compare in OperationSupportTest.cpp
A couple of warnings was produced when compiling this test due to comaprisons
    with a signed literal.  Used unsigned literals instead.

--

PiperOrigin-RevId: 249242970
2019-06-01 19:54:13 -07:00
Alex Zinenko c74996d199 AffineExpr: factor uniqu'ing out of MLIRContext.cpp
Affine expressions are designed as components of an attribute and are unique'd
    in the MLIRContext.  When affine expressions were implemented, uniqu'ing
    objects in a context required to modify MLIRContext implementation.  This is no
    longer the case as generic StorageUniquer has been introduced.  Port the
    AffineExpr construction to use the new infrastructure by introducing an
    affineUniquer into the MLIRContext.

--

PiperOrigin-RevId: 249207539
2019-06-01 19:53:43 -07:00
Alex Zinenko 34cbd26d64 Use FileCheck to test SDBM
SDBM has an output format representing the unterlying matrix and stripe
    expressions.  Move the SDBM tests from unit testing framework to
    FileCheck-based tests, printing them to the standard output and using FileCheck
    to test the output.  Tests that check the API proper (e.g. that SDBM
    expressions have a specific subtype) and that rely on non-syntatic properties
    (equality of the set of constraints) are not ported.

--

PiperOrigin-RevId: 249006055
2019-05-20 13:48:53 -07:00
Alex Zinenko 69ef8642df Overload arithmetic operators for SDBM expressions
Provide an "unsafe" version of the overloaded arithmetic operators for SDBM
    expressions.  These operators expect the operands to be of the right SDBM
    expression subtype and assert if they are not.  They also perform simple
    folding operations as well as some semantically correct operations that
    construct an SDBM expression of a different subtype, e.g., a difference
    expression if the RHS of an operator+ is a negated variable.  These operators
    are scoped in a namespace to allow for a future "safe" version of the operators
    that propagates null expressions to denote the error state when expressions
    have wrong subtypes.

--

PiperOrigin-RevId: 248704153
2019-05-20 13:45:34 -07:00
Alex Zinenko f06ab26acf Implement SDBM and conversion between SDBM and lists of SDBMExpr
Implement the storage class for striped difference-bound matrices (SDBM) as a
    container with a difference bounds matrix and a list of stripe expressions.  An
    SDBM defines an integer set.  Provide conversion mechanisms between lists of
    SDBM expressions treated as equalities with zero or less-than-or-equal
    inequalities with zero.

--

PiperOrigin-RevId: 248702871
2019-05-20 13:45:26 -07:00
Jacques Pienaar e489e59246 Don't fail verifying unranked shapes as being the same as this could be valid at runtime.
tensor<*xf32> could be a tensor<1xf32> at runtime but this verifyShapeMatch would return failure and say function is invalid.

--

PiperOrigin-RevId: 248583038
2019-05-20 13:44:33 -07:00
Geoffrey Martin-Noble 090662c5f3 Rename VectorOrTensorType to ShapedType
This is in preparation for making it also support/be a parent class of MemRefType. MemRefs have similar shape/rank/element semantics and it would be useful to be able to use these same utilities for them.

    This CL should not change any semantics and only change variables, types, string literals, and comments. In follow-up CLs I will prepare all callers to handle MemRef types or remove their dependence on ShapedType.

    Discussion/Rationale in https://groups.google.com/a/tensorflow.org/forum/#!topic/mlir/cHLoyfGu8y8

--

PiperOrigin-RevId: 248476449
2019-05-20 13:43:58 -07:00
Stella Laurenzo d4d8dc8db9 Start to introduce the "Quantizer" tool, which is responsible for transforming a computation expressed in floating point to one operating in terms of quantized types (where possible), either using quant-aware-training hints where available or post-training statistics.
This is being integrated from an experimental side repository piece by piece over the course of several patches and will ultimately include full build support, documentation and e2e tests.

--

PiperOrigin-RevId: 248259895
2019-05-20 13:42:30 -07:00
Stella Laurenzo d4dcf7de9e Move Quantization -> Dialect/QuantOps, FxpMathOps -> Dialect/FxpMathOps.
Adding the additional layer of directory was discussed offline and matches the Target/ tree. The names match the defacto convention we seem to be following where the C++ namespace is ^(.+)Ops/$ matched against the directory name.

    This is in preparation for patching the Quantizer into this tree, which would have been confusing without moving the Quantization dialect to its more proper home. It is left to others to move other dialects if desired.

    Tested:
      ninja check-mlir

--

PiperOrigin-RevId: 248171982
2019-05-20 13:41:55 -07:00
River Riddle d39a30626e Use the DialectSymbolRegistry to reserve space in the Attribute::Kind enum to allow for dialects to define attribute kinds. The currently defined attributes kinds have now been moved to StandardAttributes.
--

PiperOrigin-RevId: 247988373
2019-05-20 13:40:03 -07:00
Jacques Pienaar dcab80115f Add SameOperandsAndResultElementType trait.
This trait only works for tensor and vector types at the moment, verifying that the element type of an op with only tensor and vector types match. Added a unit test for it as there is no op currently in core that uses this trait.

--

PiperOrigin-RevId: 246661697
2019-05-06 08:28:59 -07:00
Alex Zinenko 9de199676f Implement the conversion between SDBMExpr and AffineExpr
Since SDBM expressions are a subset of affine expressions, they can be
    converted to affine expressions in a straightforward way.  The inverse
    conversion may fail when the affine expression is not an SDBM.  Implement the
    inverse convresion assuming affine expressions are simplified and
    canonicalizied, detect subtractive and multiplicative forms of the stripe
    operation.

--

PiperOrigin-RevId: 245494735
2019-05-06 08:18:31 -07:00
Alex Zinenko 24d0f60d31 Start building SDBM infrastructure
Striped difference-bound matrix expressions are a subset of affine expressions
    supporting low-complexity algorithms that can be useful for loop
    transformations.  This introduces the basic data data structures for building
    such expressions and unique'ing them in a MLIRContext.

--

PiperOrigin-RevId: 245380206
2019-05-06 08:17:42 -07:00
Lei Zhang 05dfb1c7e0 Fix MLIRTableGenTests target_link_libraries typo
--

PiperOrigin-RevId: 244168112
2019-04-18 11:50:19 -07:00
Lei Zhang 48a6aa6c51 [TableGen] Better support for predicate and rewrite rule specification
Currently predicates are written with positional placeholders `{N}` and rely on
    `formatv` as the engine to do substitution. The problem with this approach is that
    the definitions of those positional placeholders are not consistent; they are
    entirely up to the defining predicate of question. For example, `{0}` in various
    attribute constraints is used to mean the attribute, while it is used to main the
    builder for certain attribute transformations. This can become very confusing.

    This CL introduces `tgfmt` as a new mechanism to better support for predicate and
    rewrite rule specification. Instead of entirely relying on positional placeholders,
    `tgfmt` support both positional and special placeholders. The former is used for
    DAG operands. The latter, including $_builder, $_op, $_self, are used as special
    "hooks" to entities in the context. With this, the predicate and rewrite rules
    specification can be more consistent is more readable.

--

PiperOrigin-RevId: 243249671
2019-04-18 11:47:27 -07:00
Stella Laurenzo 13bb8f491a Initial release of the Quantization dialect
Includes a draft of documentation for the quantization setup.

Given how many comments such docs have garnered in the past, I've biased towards a lightly edited first-draft so that people can argue about terminology, approach and structure without having spent too much time on it.

Note that the sections under "Uniform quantization" were cribbed nearly verbatim from internal documentation that Daniel wrote.

PiperOrigin-RevId: 241768668
2019-04-03 19:20:12 -07:00
River Riddle dfc58742a2 Rename the 'namePrefix' field in the Dialect class to 'name' and tidy some comments to make it clear that 'name' refers to the dialect namespace.
--

PiperOrigin-RevId: 241103116
2019-03-30 11:23:55 -07:00
Jacques Pienaar 1273af232c Add build files and update README.
* Add initial version of build files;
    * Update README with instructions to download and build MLIR from github;

--

PiperOrigin-RevId: 241102092
2019-03-30 11:23:22 -07:00
River Riddle 6f24bf82f9 Assert that registered dialects have unique names. This creates a guarantee that the namespace of a dialect can be used a unique key.
--

PiperOrigin-RevId: 241049578
2019-03-29 17:57:41 -07:00
River Riddle af9760fe18 Replace remaining usages of the Instruction class with Operation.
PiperOrigin-RevId: 240777521
2019-03-29 17:50:04 -07:00
River Riddle 9ffdc930c0 Rename the Instruction class to Operation. This just renames the class, usages of Instruction will still refer to a typedef in the interim.
This is step 1/N to renaming Instruction to Operation.

PiperOrigin-RevId: 240431520
2019-03-29 17:42:50 -07:00
Lei Zhang eeadfbc170 Change getBroadcastedShape() to return result shape via parameter
This is a more efficient way than returning SmallVector directly.

PiperOrigin-RevId: 239407024
2019-03-29 17:25:38 -07:00
Lei Zhang 7972dcef84 Pull shape broadcast out as a stand-alone utility function
So that we can use this function to deduce broadcasted shapes elsewhere.

Also added support for unknown dimensions, by following TensorFlow behavior.

PiperOrigin-RevId: 237846065
2019-03-29 17:12:11 -07:00
River Riddle 2d2b40bce5 Add basic infrastructure for instrumenting pass execution and analysis computation. A virtual class, PassInstrumentation, is provided to allow for different parts of the pass manager infrastructure. The currently available hooks allow for instrumenting:
* before/after pass execution
* after a pass fails
* before/after an analysis is computed

After getting this infrastructure in place, we can start providing common developer utilities like pass timing, IR printing after pass execution, etc.

PiperOrigin-RevId: 237709692
2019-03-29 17:10:06 -07:00
River Riddle d43f630de8 NFC: Remove 'Result' from the analysis manager api to better reflect the implementation. There is no distinction between analysis computation and result.
PiperOrigin-RevId: 237093101
2019-03-29 17:02:12 -07:00
River Riddle 1d87b62afe Add support for preserving specific analyses in the analysis manager. Passes can now preserve specific analyses via 'markAnalysesPreserved'.
Example:

markAnalysesPreserved<DominanceInfo>();
markAnalysesPreserved<DominanceInfo, PostDominanceInfo>();

PiperOrigin-RevId: 237081454
2019-03-29 17:01:41 -07:00
River Riddle 7b0b344c5e Add a unittests directory for MLIR and start adding tests for OperandStorage from InstructionSupport.h.
PiperOrigin-RevId: 236911640
2019-03-29 16:58:05 -07:00