Commit Graph

642 Commits

Author SHA1 Message Date
aartbik 0d924700a6 [mlir] [VectorOps] Merge VectorReduction/VectorReductionV2 into one Op
Summary:
Paying off some technical debt in VectorOps, where I introduced a special
op for a fused accumulator into reduction to avoid some issues around
printing and parsing an optional accumulator. This CL merges the two
into one op again and does things the right way (still would be nice
to have "assemblyFormat" for optional operands though....).

Reviewers: nicolasvasilache, andydavis1, ftynse, rriddle

Reviewed By: nicolasvasilache

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

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D75699
2020-03-05 13:07:31 -08:00
River Riddle cb1777127c [mlir] Remove successor operands from the Operation class
Summary:
This revision removes all of the functionality related to successor operands on the core Operation class. This greatly simplifies a lot of handling of operands, as well as successors. For example, DialectConversion no longer needs a special "matchAndRewrite" for branching terminator operations.(Note, the existing method was also broken for operations with variadic successors!!)

This also enables terminator operations to define their own relationships with successor arguments, instead of the hardcoded "pass-through" behavior that exists today.

Differential Revision: https://reviews.llvm.org/D75318
2020-03-05 12:53:02 -08:00
River Riddle c98cff5ae4 [mlir] Automatically populate `operand_segment_sizes` in the auto-generated build methods.
This greatly simplifies the requirements for builders using this mechanism for managing variadic operands.

Differential Revision: https://reviews.llvm.org/D75317
2020-03-05 12:52:22 -08:00
River Riddle 988249a506 [mlir] Refactor a few users to no longer rely on the successor operand API of Operation.
The existing API for successor operands on operations is in the process of being removed. This revision simplifies a later one that completely removes the existing API.

Differential Revision: https://reviews.llvm.org/D75316
2020-03-05 12:51:59 -08:00
River Riddle 01f7431b5b [mlir][DeclarativeParser] Add support for formatting operations with AttrSizedOperandSegments.
This attribute details the segment sizes for operand groups within the operation. This revision add support for automatically populating this attribute in the declarative parser.

Differential Revision: https://reviews.llvm.org/D75315
2020-03-05 12:51:28 -08:00
River Riddle 621d7cca37 [mlir] Add a new BranchOpInterface to allow for opaquely interfacing with branching terminator operations.
This interface contains the necessary components to provide the same builtin behavior that terminators have. This will be used in future revisions to remove many of the hardcoded constraints placed on successors and successor operands. The interface initially contains three methods:

```c++
// Return a set of values corresponding to the operands for successor 'index', or None if the operands do not correspond to materialized values.
Optional<OperandRange> getSuccessorOperands(unsigned index);

// Return true if this terminator can have it's successor operands erased.
bool canEraseSuccessorOperand();

// Erase the operand of a successor. This is only valid to call if 'canEraseSuccessorOperand' returns true.
void eraseSuccessorOperand(unsigned succIdx, unsigned opIdx);
```

Differential Revision: https://reviews.llvm.org/D75314
2020-03-05 12:50:35 -08:00
River Riddle c0fd5e657e [mlir] Add traits for verifying the number of successors and providing relevant accessors.
This allows for simplifying OpDefGen, as well providing specializing accessors for the different successor counts. This mirrors the existing traits for operands and results.

Differential Revision: https://reviews.llvm.org/D75313
2020-03-05 12:49:59 -08:00
MaheshRavishankar 3f44495dfd [mlir][GPU] Expose the functionality to create a GPUFuncOp from a LaunchOp
The current setup of the GPU dialect is to model both the host and
device side codegen. For cases (like IREE) the host side modeling
might not directly fit its use case, but device-side codegen is still
valuable. First step in accessing just the device-side functionality
of the GPU dialect is to allow just creating a gpu.func operation from
a gpu.launch operation. In addition this change also "inlines"
operations into the gpu.func op at time of creation instead of this
being a later step.

Differential Revision: https://reviews.llvm.org/D75287
2020-03-05 11:03:51 -08:00
Chris Lattner c2b2472ca8 Fix a warning about an unreachable default in a switch statement.
Subscribers: mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D75663
2020-03-05 08:36:28 -08:00
Kiran Chandramohan 92a295eb39 [MLIR, OpenMP] Translation of OpenMP barrier construct to LLVM IR
Summary:
This patch adds support for translation of the OpenMP barrier construct to LLVM
IR. The OpenMP IRBuilder is used for this translation. In this patch the code
for translation is added to the existing LLVM dialect translation to LLVM IR.

The patch includes code changes and a testcase.

Reviewers: jdoerfert, nicolasvasilache, ftynse, rriddle, mehdi_amini

Reviewed By: ftynse, rriddle, mehdi_amini

Differential Revision: https://reviews.llvm.org/D72962
2020-03-05 11:59:36 +00:00
MaheshRavishankar 755c050200 [mlir][Linalg] Fix load/store operations generated while lower loops when
output has zero rank.

While lowering to loops, no indices should be used in the load/store
operation if the buffer is zero-rank.

Differential Revision: https://reviews.llvm.org/D75391
2020-03-04 17:04:30 -08:00
Lei Zhang 9600b55ac8 [mlir][spirv] Support integer signedness
This commit updates SPIR-V dialect to support integer signedness
by relaxing various checks for signless to just normal integers.

The hack for spv.Bitcast can now be removed.

Differential Revision: https://reviews.llvm.org/D75611
2020-03-04 15:14:11 -05:00
Lei Zhang 440ef33073 [mlir][spirv] Add get() method to TargetEnvAttr taking raw values
Also make the getResourceLimits() method more explicit about its return type.

Differential Revision: https://reviews.llvm.org/D75484
2020-03-04 14:01:26 -05:00
River Riddle d09d0bd7a0 [mlir][NFC] Sort the operations alphabetically and add header blocks
Summary:
The order of the operations has fallen out of sync as operations have been renamed and new ones have been added.

Differential Revision: https://reviews.llvm.org/D75540
2020-03-04 09:48:55 -08:00
Alex Zinenko aff6bf4ff8 [mlir] support conversion of parallel reduction loops to std
Recently introduced support for converting sequential reduction loops to
CFG of basic blocks in the Standard dialect makes it possible to perform
a staged conversion of parallel reduction loops into a similar CFG by
using sequential loops as an intermediate step. This is already the case
for parallel loops without reduction, so extend the pattern to support
an additional use case.

Differential Revision: https://reviews.llvm.org/D75599
2020-03-04 16:37:17 +01:00
Alexander Belyaev ffcb492327 [MLIR] Add a comment to `requiredOperandCount` arg in LoopOps.cpp.
Differential Revision: https://reviews.llvm.org/D75578
2020-03-04 15:48:23 +01:00
River Riddle c10896682d [mlir] Generate CmpFPredicate as an EnumAttr in tablegen
Summary: This allows for attaching the attribute to CmpF as a proper argument, and thus enables the removal of a bunch of c++ code.

Differential Revision: https://reviews.llvm.org/D75539
2020-03-03 13:19:25 -08:00
Alexander Belyaev 0145a26c65 [MLIR] Add explicit initial values for loop.parallel op.
Differential Revision: https://reviews.llvm.org/D75206
2020-03-03 15:36:10 +01:00
Mehdi Amini b12a7c88f7 Fix MLIR build by adding missing header after cleanup in af450eab 2020-03-01 01:11:44 +00: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 0810acc7f6 Revert "[MLIR] Remove redundant library dependencies"
This reverts commit c4c8fbde64.
2020-02-29 11:52:08 -08:00
Stephen Neuendorffer d675df0379 Revert "[MLIR] Move from add_dependencies() to DEPENDS"
This reverts commit 31e07d716a.
2020-02-29 11:52:08 -08:00
Stephen Neuendorffer dd046c9612 Revert "[MLIR] Add support for libMLIR.so"
This reverts commit e17d9c11d4.
It breaks the build.
2020-02-29 11:09:21 -08:00
Stephen Neuendorffer bc991500ac Revert "[MLIR] Fixes for BUILD_SHARED_LIBS=on"
This reverts commit 777e97cc1a.
2020-02-29 11:09:21 -08:00
Stephen Neuendorffer 777e97cc1a [MLIR] Fixes for BUILD_SHARED_LIBS=on
Differential Revision: https://reviews.llvm.org/D75308
2020-02-29 10:47:28 -08:00
Valentin Churavy e17d9c11d4 [MLIR] Add support for libMLIR.so
Putting this up mainly for discussion on
how this should be done. I am interested in MLIR from
the Julia side and we currently have a strong preference
to dynamically linking against the LLVM shared library,
and would like to have a MLIR shared library.

This patch adds a new cmake function add_mlir_library()
which accumulates a list of targets to be compiled into
libMLIR.so.  Note that not all libraries make sense to
be compiled into libMLIR.so.  In particular, we want
to avoid libraries which primarily exist to support
certain tools (such as mlir-opt and mlir-cpu-runner).

Note that the resulting libMLIR.so depends on LLVM, but
does not contain any LLVM components.  As a result, it
is necessary to link with libLLVM.so to avoid linkage
errors. So, libMLIR.so requires LLVM_BUILD_LLVM_DYLIB=on

FYI, Currently it appears that LLVM_LINK_LLVM_DYLIB is broken
because mlir-tblgen is linked against libLLVM.so and
and independent LLVM components.

Previous version of this patch broke depencies on TableGen
targets.  This appears to be because it compiled all
libraries to OBJECT libraries (probably because cmake
is generating different target names).  Avoiding object
libraries results in correct dependencies.

(updated by Stephen Neuendorffer)

Differential Revision: https://reviews.llvm.org/D73130
2020-02-29 10:47:27 -08:00
Stephen Neuendorffer 31e07d716a [MLIR] Move from add_dependencies() to DEPENDS
add_llvm_library and add_llvm_executable may need to create new targets with
appropriate dependencies.  As a result, it is not sufficient in some
configurations (namely LLVM_BUILD_LLVM_DYLIB=on) to only call
add_dependencies().  Instead, the explicit TableGen dependencies must
be passed to add_llvm_library() or add_llvm_executable() using the DEPENDS
keyword.

Differential Revision: https://reviews.llvm.org/D74930
2020-02-29 10:47:27 -08:00
Stephen Neuendorffer c4c8fbde64 [MLIR] Remove redundant library dependencies
In cmake, it is redundant to have a target list under target_link_libraries()
and add_dependency().  This patch removes the redundant dependency from
add_dependency().

Differential Revision: https://reviews.llvm.org/D74929
2020-02-29 10:47:27 -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 fed2acc7f5 Revert "[MLIR] Remove redundant library dependencies"
This reverts commit e1cb15c8f9.
2020-02-28 14:06:20 -08:00
Tim Shen 67c1615440 [MLIR] Add vector support for fpexp and fptrunc.
Differential Revision: https://reviews.llvm.org/D75150
2020-02-28 12:24:45 -08:00
Tim Shen 0d65000e11 [MLIR] Add llvm.mlir.cast op for semantic preserving cast between dialect types.
Summary: See discussion here: https://llvm.discourse.group/t/rfc-dialect-type-cast-op/538/11

Reviewers: ftynse

Subscribers: bixia, sanjoy.google, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, Joonsoo, llvm-commits

Differential Revision: https://reviews.llvm.org/D75141
2020-02-28 12:20:23 -08:00
Stephen Neuendorffer 67f2a43cf8 Revert "[MLIR] Move from add_dependencies() to DEPENDS"
This reverts commit 8a2b86b2c2.
2020-02-28 12:17:40 -08:00
Stephen Neuendorffer c6f3fc4999 Revert "[MLIR] Add support for libMLIR.so"
This reverts commit 1246e86716.
2020-02-28 12:17:39 -08:00
Stephen Neuendorffer 29c6721be2 Revert "[MLIR] Fixes for BUILD_SHARED_LIBS=on"
This reverts commit c767dc9394.
2020-02-28 12:17:39 -08:00
Stephen Neuendorffer c767dc9394 [MLIR] Fixes for BUILD_SHARED_LIBS=on
Differential Revision: https://reviews.llvm.org/D75308
2020-02-28 11:35:19 -08:00
Valentin Churavy 1246e86716 [MLIR] Add support for libMLIR.so
Putting this up mainly for discussion on
how this should be done. I am interested in MLIR from
the Julia side and we currently have a strong preference
to dynamically linking against the LLVM shared library,
and would like to have a MLIR shared library.

This patch adds a new cmake function add_mlir_library()
which accumulates a list of targets to be compiled into
libMLIR.so.  Note that not all libraries make sense to
be compiled into libMLIR.so.  In particular, we want
to avoid libraries which primarily exist to support
certain tools (such as mlir-opt and mlir-cpu-runner).

Note that the resulting libMLIR.so depends on LLVM, but
does not contain any LLVM components.  As a result, it
is necessary to link with libLLVM.so to avoid linkage
errors. So, libMLIR.so requires LLVM_BUILD_LLVM_DYLIB=on

FYI, Currently it appears that LLVM_LINK_LLVM_DYLIB is broken
because mlir-tblgen is linked against libLLVM.so and
and independent LLVM components

(updated by Stephen Neuendorffer)

Differential Revision: https://reviews.llvm.org/D73130
2020-02-28 11:35:19 -08:00
Stephen Neuendorffer 8a2b86b2c2 [MLIR] Move from add_dependencies() to DEPENDS
add_llvm_library and add_llvm_executable may need to create new targets with
appropriate dependencies.  As a result, it is not sufficient in some
configurations (namely LLVM_BUILD_LLVM_DYLIB=on) to only call
add_dependencies().  Instead, the explicit TableGen dependencies must
be passed to add_llvm_library() or add_llvm_executable() using the DEPENDS
keyword.

Differential Revision: https://reviews.llvm.org/D74930
2020-02-28 11:35:18 -08:00
Stephen Neuendorffer e1cb15c8f9 [MLIR] Remove redundant library dependencies
In cmake, it is redundant to have a target list under target_link_libraries()
and add_dependency().  This patch removes the redundant dependency from
add_dependency().

Differential Revision: https://reviews.llvm.org/D74929
2020-02-28 11:35:18 -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
Stephen Neuendorffer 5869552821 [MLIR] Refactor handling of dialect libraries
Instead of creating extra libraries we don't really need, collect a
list of all dialects and use that instead.

Differential Revision: https://reviews.llvm.org/D75221
2020-02-28 11:35:16 -08:00
Benjamin Kramer 5abf128d64 Add a pass that specializes parallel loops for easier unrolling and vectorization
This matches loops with a affine.min upper bound, limiting the trip
count to a constant, and rewrites them into two loops, one with constant
upper bound and one with variable upper bound. The assumption is that
the constant upper bound loop will be unrolled and vectorized, which is
preferable if this is the hot path.

Differential Revision: https://reviews.llvm.org/D75240
2020-02-28 19:47:23 +01:00
Stephan Herhut 9227a74b7e [MLIR][Loops] Expose transformations on loop.parallel in header (NFC).
Summary:
This change does not add any functionality but merely exposes existing
static functions to make the associated transformations available
outside of their testing passes.

Differential Revision: https://reviews.llvm.org/D75232
2020-02-27 19:54:20 +01:00
Alex Zinenko 54e5600e4d [mlir] fix wrong symbol order in AffineApplyNormalizer
Summary:
AffineApplyNormalizer provides common logic for folding affine maps that appear
in affine.apply into other affine operations that use the result of said
affine.apply. In the process, affine maps of both operations are composed.
During the composition `A.compose(B)` the symbols from the map A are placed
before those of the map B in a single concatenated symbol list. However,
AffineApplyNormalizer was ordering the operands of the operation being
normalized by iteratively appending the symbols into a single list accoridng to
the operand order, regardless of whether these operands are symbols of the
current operation or of the map that is being folded into it. This could lead
to wrong order of symbols and, when the symbols were bound to constant values,
to visibly incorrect folding of constants into affine maps as reported in
PR45031. Make sure symbols operands to the current operation are always placed
before symbols coming from the folded maps.

Update the test that was exercising the incorrect folder behavior. For some
reason, the order of symbol operands was swapped in the test input compared to
the previous operations, making it easy to assume the correct maps were
produced whereas they were swapping the symbols back due to the problem
described above.

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

Differential Revision: https://reviews.llvm.org/D75247
2020-02-27 15:15:29 +01:00
Lei Zhang 63779fb462 [mlir][spirv] Refactoring to avoid calling the same function twice 2020-02-26 15:36:54 -05:00
Lei Zhang 5bc6ff6455 [mlir][spirv] Add some folders for spv.LogicalAnd/spv.LogicalOr
This commit handles folding spv.LogicalAnd/spv.LogicalOr when
one of the operands is constant true/false.

Differential Revision: https://reviews.llvm.org/D75195
2020-02-26 15:13:37 -05:00
Lei Zhang 1e9321e97a [mlir][spirv] NFC: move folders and canonicalizers in a separate file
This gives us better file organization and faster compilation time
by avoid having a gigantic SPIRVOps.cpp file.
2020-02-26 12:41:14 -05:00
Nicolas Vasilache fcfd4fb686 [mlir][Linalg] NFC - Refactor LinalgStructuredOps towards "named" Linalg ops
This revision performs some basic refactoring towards more easily defining Linalg "named" ops. Such named ops form the backbone of operations that are ubiquitous in the ML application domain.
2020-02-26 09:24:38 -05:00
Alex Zinenko 5f9b543e8e [mlir] simplify affine maps and operands in affine.min/max
Affine dialect already has a map+operand simplification infrastructure in
place. Plug the recently added affine.min/max operations into this
infrastructure and add a simple test. More complex behavior of the simplifier
is already tested by other ops.

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

Differential Revision: https://reviews.llvm.org/D75058
2020-02-25 11:59:04 +01:00