Commit Graph

23 Commits

Author SHA1 Message Date
Nicolas Vasilache 47cbd9f922 [mlir][Vector] NFC - Improve VectorInterfaces
This revision improves and makes better use of OpInterfaces for the Vector dialect.

Differential Revision: https://reviews.llvm.org/D84053
2020-07-20 08:24:22 -04:00
Rahul Joshi a3ad8f92b4 [MLIR] Add type checking capability to RegionBranchOpInterface
- Add function `verifyTypes` that Op's can call to do type checking verification
  along the control flow edges described the Op's RegionBranchOpInterface.
- We cannot rely on the verify methods on the OpInterface because the interface
  functions assume valid Ops, so they may crash if invoked on unverified Ops.
  (For example, scf.for getSuccessorRegions() calls getRegionIterArgs(), which
  dereferences getBody() block. If the scf.for is invalid with no body, this
  can lead to a segfault). `verifyTypes` can be called post op-verification to
  avoid this.

Differential Revision: https://reviews.llvm.org/D82829
2020-07-15 11:14:07 -07:00
Nicolas Vasilache 05c65dc0fe [mlir][Vector] Add a VectorUnrollInterface and expose UnrollVectorPattern.
The UnrollVectorPattern is can be used in a programmable fashion by:
```
OwningRewritePatternList patterns;
    patterns.insert<UnrollVectorPattern<AddFOp>>(ArrayRef<int64_t>{2, 2}, ctx);
    patterns.insert<UnrollVectorPattern<vector::ContractionOp>>(
        ArrayRef<int64_t>{2, 2, 2}, ctx);
    ...
    applyPatternsAndFoldGreedily(getFunction(), patterns);
```

Differential revision: https://reviews.llvm.org/D83064
2020-07-06 08:09:06 -04:00
Ehsan Toosi 0f03b2bfda [mlir] Add redundant copy removal transform
This pass removes redundant dialect-independent Copy operations in different
situations like the following:

%from = ...
%to = ...
... (no user/alias for %to)
copy(%from, %to)
... (no user/alias for %from)
dealloc %from
use(%to)

Differential Revision: https://reviews.llvm.org/D82757
2020-07-03 15:36:25 +02:00
Rahul Joshi d891d738d9 [MLIR][NFC] Adopt variadic isa<>
Differential Revision: https://reviews.llvm.org/D82489
2020-06-24 17:02:44 -07:00
Stephen Neuendorffer 444720c250 [MLIR][cmake] refactor lib/Interfaces/CMakeLists.txt
Reduce the boilerplate here

Differential Revision: https://reviews.llvm.org/D79896
2020-05-15 14:37:09 -07:00
Stephen Neuendorffer eb623ae832 [MLIR] Continue renaming of "SideEffects"
MLIRSideEffects -> MLIRSideEffectInterfaces
SideEffects.h -> SideEffectInterfaces.h
SideEffects.cpp -> SideEffectInterface.cpp

Note that I haven't renamed TableGen/SideEffects.h or TableGen/SideEffects.cpp

find -name "*.h" -exec sed -i "s/SideEffects.h/SideEffectInterfaces.h/" "{}" \;
find -name "CMakeLists.txt" -exec sed -i "s/MLIRSideEffects/MLIRSideEffectInterfaces/" "{}" \;

Differential Revision: https://reviews.llvm.org/D79890
2020-05-15 14:37:09 -07:00
Stephen Neuendorffer ce3bbeb915 [MLIR] refactor cmake specification of tablegen'd interfaces.
Introduce add_mlir_interface to avoid lots of boilerplate

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

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

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

Fix bug in sorting helper function.

Differential Revision: https://reviews.llvm.org/D79463
2020-05-07 12:33:36 -07:00
Stephen Neuendorffer 5469f434bb [MLIR] Reapply: Adjust libMLIR building to more closely follow libClang
This reverts commit ab1ca6e60f.
2020-05-04 20:47:57 -07:00
Stephen Neuendorffer ab1ca6e60f Revert "[MLIR] Adjust libMLIR building to more closely follow libClang"
This reverts commit 4f0f436749.

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

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

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

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

[MLIR] Fix libMLIR.so and LLVM_LINK_LLVM_DYLIB

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

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

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

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

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

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

[MLIR] Move from using target_link_libraries to LINK_LIBS

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

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

Three commits have been squashed to avoid intermediate build breakage.
2020-05-04 11:40:46 -07:00
River Riddle 0752d98ccf [mlir] Simplify BranchOpInterface by using MutableOperandRange
This range allows for performing many different operations on successor operands, including erasing/adding/setting. This removes the need for the explicit canEraseSuccessorOperand and eraseSuccessorOperand methods.

Differential Revision: https://reviews.llvm.org/D79077
2020-04-29 16:48:15 -07:00
Stephen Neuendorffer fef4ddf2f4 [MLIR] Fix typo in lib/Interfaces
This broke BUILD_SHARED_LIBS=on
2020-04-24 15:39:19 -07:00
Lei Zhang 2458cd27f1 [mlir] Add a ViewLikeOpInterface
This can help provide a common interface for view-like
ops so that for example Linalg's dependency analysis
can avoid relying on concrete ops.

Differential Revision: https://reviews.llvm.org/D78645
2020-04-24 10:02:56 -04:00
Stephen Neuendorffer 26805f0b64 [MLIR][cmake] Use DEPENDS instead of add_dependencies()
add_llvm_library() sometimes needs access to the dependencies in order to
generate new targets.  Using DEPENDS allows this.

Differential Revision: https://reviews.llvm.org/D78321
2020-04-16 15:53:13 -07:00
Stephen Neuendorffer 6bc775a1fc [MLIR] Interfaces need to used add_mlir_library
The Interface libraries were moved from Analysis, but declared in
cmake using add_llvm_library().  This breaks LLVM_BUILD_LLVM_DYLIB
builds.

Differential Revision: https://reviews.llvm.org/D76463
2020-03-19 16:44:24 -07:00
River Riddle 4df44c4f9c [mlir] Only treat "Alloc" effects as dead if they are for operation results.
Allocate could be used for an "output" of an operation in the case of buffer-style operations.
2020-03-14 13:53:56 -07:00
River Riddle 43959a2592 [mlir][NFC] Move the LoopLike interface out of Transforms/ and into Interfaces/
Differential Revision: https://reviews.llvm.org/D76155
2020-03-14 13:37:56 -07:00
River Riddle 0ddba0bd59 [mlir][SideEffects] Replace HasNoSideEffect with the memory effect interfaces.
HasNoSideEffect can now be implemented using the MemoryEffectInterface, removing the need to check multiple things for the same information. This also removes an easy foot-gun for users as 'Operation::hasNoSideEffect' would ignore operations that dynamically, or recursively, have no side effects. This also leads to an immediate improvement in some of the existing users, such as DCE, now that they have access to more information.

Differential Revision: https://reviews.llvm.org/D76036
2020-03-12 14:26:15 -07:00
Jacques Pienaar 36e018b941 [mlir] Add derived attribute op interface
Interface provides uniform access to the the derived attribute query method.
2020-03-12 10:32:24 -07:00
River Riddle 153720a0a5 [mlir][NFC] Move the interfaces and traits for side effects out of IR/ to Interfaces/
Summary:
Interfaces/ is the designated directory for these types of interfaces, and also removes the need for including them directly in IR/.

Differential Revision: https://reviews.llvm.org/D75886
2020-03-10 12:45:45 -07:00
River Riddle 7ce1e7ab07 [mlir][NFC] Move the operation interfaces out of Analysis/ and into a new Interfaces/ directory.
The interfaces themselves aren't really analyses, they may be used by analyses though. Having them in Analysis can also create cyclic dependencies if an analysis depends on a specific dialect, that also provides one of the interfaces.

Differential Revision: https://reviews.llvm.org/D75867
2020-03-10 12:45:45 -07:00