aboutsummaryrefslogtreecommitdiff
path: root/mlir
AgeCommit message (Collapse)AuthorFilesLines
2021-01-26[mlir] sret and byval now require a type argument when constructed.Eric Schweitz2-2/+14
Fixes the LLVM code gen bugs and adds the missing tests. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D95378
2021-01-26[mlir] Set CUDA/ROCm context before creating resources.Christian Sigg2-8/+48
The current context is thread-local state, and in preparation of GPU async execution (on multiple threads) we need to set the context before calling API that create resources. Reviewed By: herhut Differential Revision: https://reviews.llvm.org/D94495
2021-01-26[mlir] Add Python bindings for IntegerSetAlex Zinenko4-18/+390
This follows up on the introduction of C API for the same object and is similar to AffineExpr and AffineMap. Reviewed By: stellaraccident Differential Revision: https://reviews.llvm.org/D95437
2021-01-26[mlir][nfc] Move `getInnermostParallelLoops` to SCF/Transforms/Utils.h.Alexander Belyaev3-24/+31
2021-01-26[mlir] drop unused staticsAlex Zinenko2-11/+0
2021-01-26[mlir] Async: add a separate pass to lower from async to async.coro and ↵Eugene Zhulenev13-502/+847
async.runtime Depends On D95000 Move async.execute outlining and async -> async.runtime lowering into the separate Async transformation pass Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D95311
2021-01-26[mlir:async] Use ODS to define async typesEugene Zhulenev7-197/+154
Depends On D94923 Migrate Async dialect to ODS `TypeDef` Reviewed By: ftynse, rriddle Differential Revision: https://reviews.llvm.org/D95000
2021-01-26Add vp2intersect to AVX512 dialect.Matthias Springer7-7/+118
Adds vp2intersect to the AVX512 dialect and defines a lowering to the LLVM dialect. Author: Matthias Springer <springerm@google.com> Differential Revision: https://reviews.llvm.org/D95301
2021-01-26[mlir][Python] Fix comments of 'getCapsule' and 'createFromCapsule'zhanghb971-12/+12
The `getCapsule` and `createFromCapsule` comments incorrectly state the `PyMlirContext` and `MlirContext` in `PyLocation`, `PyAttribute`, and `PyType` classes. Differential Revision: https://reviews.llvm.org/D95413
2021-01-25[mlir:Async] Use LLVM coro operations in async.coro loweringEugene Zhulenev5-132/+69
Instead of using llvm.call operations to call LLVM coro intrinsics use Coro operations from the LLVM dialect. (This was reviewed as a part of https://reviews.llvm.org/D94923 but was lost in arc land from local branch) Differential Revision: https://reviews.llvm.org/D95405
2021-01-25[mlir:Async] Add intermediate async.coro and async.runtime operations to ↵Eugene Zhulenev15-475/+1510
simplify Async to LLVM lowering [NFC] No new functionality, mostly a cleanup and one more abstraction level between Async and LLVM IR. Instead of lowering from Async to LLVM coroutines and Async Runtime API in one shot, do it progressively via async.coro and async.runtime operations. 1. Lower from async to async.runtime/coro (e.g. async.execute to function with coro setup and runtime calls) 2. Lower from async.runtime/coro to LLVM intrinsics and runtime API calls Intermediate coro/runtime operations will allow to run transformations on a higher level IR and do not try to match IR based on the LLVM::CallOp properties. Although async.coro is very close to LLVM coroutines, it is not exactly the same API, instead it is optimized for usability in async lowering, and misses a lot of details that are present in @llvm.coro intrinsic. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D94923
2021-01-25[mlir] Add C API for IntegerSetAlex Zinenko6-1/+351
Depends On D95357 Reviewed By: stellaraccident Differential Revision: https://reviews.llvm.org/D95368
2021-01-25[mlir][Affine] Add support for multi-store producer fusionDiego Caballero9-423/+922
This patch adds support for producer-consumer fusion scenarios with multiple producer stores to the AffineLoopFusion pass. The patch introduces some changes to the producer-consumer algorithm, including: * For a given consumer loop, producer-consumer fusion iterates over its producer candidates until a fixed point is reached. * Producer candidates are gathered beforehand for each iteration of the consumer loop and visited in reverse program order (not strictly guaranteed) to maximize the number of loops fused per iteration. In general, these changes were needed to simplify the multi-store producer support and remove some of the workarounds that were introduced in the past to support more fusion cases under the single-store producer limitation. This patch also preserves the existing functionality of AffineLoopFusion with one minor change in behavior. Producer-consumer fusion didn't fuse scenarios with escaping memrefs and multiple outgoing edges (from a single store). Multi-store producer scenarios will usually (always?) have multiple outgoing edges so we couldn't fuse any with escaping memrefs, which would greatly limit the applicability of this new feature. Therefore, the patch enables fusion for these scenarios. Please, see modified tests for specific details. Reviewed By: andydavis1, bondhugula Differential Revision: https://reviews.llvm.org/D92876
2021-01-25[mlir] Use more C99 comments in C API header filesAlex Zinenko8-409/+404
These were left over from the original reformatting commit. Reviewed By: stellaraccident Differential Revision: https://reviews.llvm.org/D95357
2021-01-25[mlir] Generalize OpFoldResult usage in ops with offsets, sizes and operands.Nicolas Vasilache15-395/+425
This revision starts evolving the APIs to manipulate ops with offsets, sizes and operands towards a ValueOrAttr abstraction that is already used in folding under the name OpFoldResult. The objective, in the future, is to allow such manipulations all the way to the level of ODS to avoid all the genuflexions involved in distinguishing between values and attributes for generic constant foldings. Once this evolution is accepted, the next step will be a mechanical OpFoldResult -> ValueOrAttr. Differential Revision: https://reviews.llvm.org/D95310
2021-01-25[mlir][Linalg] Fix incorrect erase orderNicolas Vasilache1-1/+4
2021-01-25[mlir][Linalg] Address missed review itemNicolas Vasilache2-1/+21
This revision addresses a remaining comment that was overlooked in https://reviews.llvm.org/D95243: the pad hoisting transformation is made to additionally bail out on side effecting ops other than LoopLikeOps.
2021-01-25[mlir][Linalg] Add a hoistPaddingOnTensors transformationNicolas Vasilache6-0/+482
This transformation anchors on a padding op whose result is only used as an input to a Linalg op and pulls it out of a given number of loops. The result is a packing of padded tailes of ops that is amortized just before the outermost loop from which the pad operation is hoisted. Differential revision: https://reviews.llvm.org/D95243
2021-01-25[mlir] Perfectly forward ImplicitLocOpBuilder ctors to OpBuilderBenjamin Kramer1-12/+3
This is both cleaner and less prone to creating a mess out of overload resolution.
2021-01-25[mlir][Linalg] Add a padding option to Linalg tilingNicolas Vasilache9-6/+301
This revision allows the base Linalg tiling pattern to optionally require padding to a constant bounding shape. When requested, a simple analysis is performed, similar to buffer promotion. A temporary `linalg.simple_pad` op is added to model padding for the purpose of connecting the dots. This will be replaced by a more fleshed out `linalg.pad_tensor` op when it is available. In the meantime, this temporary op serves the purpose of exhibiting the necessary properties required from a more fleshed out pad op, to compose with transformations properly. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D95149
2021-01-24[mlir][Python] Roll up of python API fixes.Stella Laurenzo12-199/+208
* As discussed, fixes the ordering or (operands, results) -> (results, operands) in various `create` like methods. * Fixes a syntax error in an ODS accessor method. * Removes the linalg example in favor of a test case that exercises the same. * Fixes FuncOp visibility to properly use None instead of the empty string and defaults it to None. * Implements what was documented for requiring that trailing __init__ args `loc` and `ip` are keyword only. * Adds a check to `InsertionPoint.insert` so that if attempting to insert past the terminator, an exception is raised telling you what to do instead. Previously, this would crash downstream (i.e. when trying to print the resultant module). * Renames `_ods_build_default` -> `build_generic` and documents it. * Removes `result` from the list of prohibited words and for single-result ops, defaults to naming the result `result`, thereby matching expectations and what is already implemented on the base class. * This was intended to be a relatively small set of changes to be inlined with the broader support for ODS generating the most specific builder, but it spidered out once actually testing various combinations, so rolling up separately. Differential Revision: https://reviews.llvm.org/D95320
2021-01-23[mlir][CAPI] Add result type inference to the CAPI.Stella Laurenzo3-15/+106
* Adds a flag to MlirOperationState to enable result type inference using the InferTypeOpInterface. * I chose this level of implementation for a couple of reasons: a) In the creation flow is naturally where generated and custom builder code will be invoking such a thing b) it is a bit more efficient to share the data structure and unpacking vs having a standalone entry-point c) we can always decide to expose more of these interfaces with first-class APIs, but that doesn't preclude that we will always want to use this one in this way (and less API surface area for common things is better for API stability and evolution). * I struggled to find an appropriate way to test it since we don't link the test dialect into anything CAPI accessible at present. I opted instead for one of the simplest ops I found in a regular dialect which implements the interface. * This does not do any trait-based type selection. That will be left to generated tablegen wrappers. Differential Revision: https://reviews.llvm.org/D95283
2021-01-22[mlir][Linalg] Make Fill operation work on tensors.MaheshRavishankar5-3/+96
Depends on D95109
2021-01-22[mlir][Linalg] Disable fusion of tensor_reshape op by expansion when ↵MaheshRavishankar5-48/+165
unit-dims are involved Fusion of generic/indexed_generic operations with tensor_reshape by expansion when the latter just adds/removes unit-dimensions is disabled since it just adds unit-trip count loops. Differential Revision: https://reviews.llvm.org/D94626
2021-01-22[mlir][OpFormatGen] Add support for anchoring optional groups with typesRiver Riddle5-66/+113
This revision adds support for using either operand or result types to anchor an optional group. It also removes the arbitrary restriction that type directives must refer to variables in the same group, which is overly limiting for a declarative format syntax. Fixes PR#48784 Differential Revision: https://reviews.llvm.org/D95109
2021-01-22Add more explicit assert for failuresJacques Pienaar1-1/+4
Differential Revision: https://reviews.llvm.org/D95201
2021-01-22[mlir][Linalg] Extend tile+fuse to work on Linalg operation on tensors.MaheshRavishankar5-44/+257
Differential Revision: https://reviews.llvm.org/D93086
2021-01-22[mlir][Linalg] NFC: Refactor LinalgDependenceGraphElem to allowMaheshRavishankar5-100/+211
representing dependence from producer result to consumer. With Linalg on tensors the dependence between operations can be from the result of the producer to the consumer. This change just does a NFC refactoring of the LinalgDependenceGraphElem to allow representing both OpResult and OpOperand*. Differential Revision: https://reviews.llvm.org/D95208
2021-01-22[mlir][spirv] Define spv.IsNan/spv.IsInf and add loweringsLei Zhang7-12/+223
spv.Ordered/spv.Unordered are meant for OpenCL Kernel capability. For Vulkan Shader capability, we should use spv.IsNan to check whether a number is NaN. Add a new pattern for converting `std.cmpf ord|uno` to spv.IsNan and bumped the pattern converting to spv.Ordered/spv.Unordered to a higher benefit. The SPIR-V target environment will properly select between these two patterns. Reviewed By: mravishankar Differential Revision: https://reviews.llvm.org/D95237
2021-01-22[mlir][spirv] Fix script for availability autogen and refresh opsLei Zhang10-141/+189
Previously we only autogen the availability for ops that are direct instantiating `SPV_Op` and expected other subclasses of `SPV_Op` to define aggregated availability for all ops. This is quite error prone and we can miss capabilities for certain ops. Also it's arguable to have multiple levels of subclasses and try to deduplicate too much: having the availability directly in the op can be quite explicit and clear. A few extra lines of declarative code is fine. Reviewed By: mravishankar Differential Revision: https://reviews.llvm.org/D95236
2021-01-22[mlir] Add coro intrinsics operations to LLVM dialectEugene Zhulenev3-0/+134
This PR only has coro intrinsics needed for the Async to LLVM lowering. Will add other intrinsics as needed in the followup PRs. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D95143
2021-01-22[mlir][StandardOps] Fix typos in the td file.Hanhan Wang1-5/+5
- Fix arguments name for subview and subtensor. - Fix a typo in a comment of subtensor's method. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D95211
2021-01-22[MLIR] Add support for extracting an integer sample point (if one exists) ↵Arjun P8-125/+240
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-21[mlir][StandardToSPIRV] Add support for lowering uitofp to SPIR-VHanhan Wang3-11/+130
- Extend spirv::ConstantOp::getZero/One to handle float, vector of int, and vector of float. - Refactor ZeroExtendI1Pattern to use getZero/One methods. - Add one more test for lowering std.zexti which extends vector<4xi1> to vector<4xi64>. Reviewed By: antiagainst Differential Revision: https://reviews.llvm.org/D95120
2021-01-21[mlir][Linalg] Introduce linalg.pad_tensor op.Hanhan Wang4-0/+341
`linalg.pad_tensor` is an operation that pads the `source` tensor with given `low` and `high` padding config. Example 1: ```mlir %pad_value = ... : f32 %1 = linalg.pad_tensor %0 low[1, 2] high[2, 3] { ^bb0(%arg0 : index, %arg1 : index): linalg.yield %pad_value : f32 } : tensor<?x?xf32> to tensor<?x?xf32> ``` Example 2: ```mlir %pad_value = ... : f32 %1 = linalg.pad_tensor %arg0 low[2, %arg1, 3, 3] high[3, 3, %arg1, 2] { ^bb0(%arg2: index, %arg3: index, %arg4: index, %arg5: index): linalg.yield %pad_value : f32 } : tensor<1x2x2x?xf32> to tensor<6x?x?x?xf32> ``` Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D93704
2021-01-21[mlir] Enable passing crash reproducer stream factory methodJacques Pienaar3-31/+111
Add factory to create streams for logging the reproducer. Allows for more general logging (beyond file) and logging the configuration/module separately (logged in order, configuration before module). Also enable querying filename of ToolOutputFile. Differential Revision: https://reviews.llvm.org/D94868
2021-01-21[mlir] Support FuncOpSignatureConversion for more FunctionLike ops.mikeurbach4-25/+85
This extracts the implementation of getType, setType, and getBody from FunctionSupport.h into the mlir::impl namespace and defines them generically in FunctionSupport.cpp. This allows them to be used elsewhere for any FunctionLike ops that use FunctionType for their type signature. Using the new helpers, FuncOpSignatureConversion is generalized to work with all such FunctionLike ops. Convenience helpers are added to configure the pattern for a given concrete FunctionLike op type. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D95021
2021-01-21Add Python bindings for the builtin dialectMehdi Amini7-1/+192
This includes some minor customization for FuncOp and ModuleOp. Differential Revision: https://reviews.llvm.org/D95022
2021-01-21Revert [mlir] Link mlir_runner_utils statically into ↵Christian Sigg18-36/+16
cuda/rocm-runtime-wrappers (cf50f4f76456) There are cmake failures that I do not know how to fix. Differential Revision: https://reviews.llvm.org/D95162
2021-01-21Remove deprecated methods from OpState.Christian Sigg2-104/+0
Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D95123
2021-01-21[mlir]][SPIRV] Define OrderedOp and UnorderedOp and add lowerings from Standard.MaheshRavishankar6-9/+92
Define OrderedOp and UnorderedOp instructions in SPIR-V and convert cmpf operations with `ord` and `uno` tag to these instructions respectively. Differential Revision: https://reviews.llvm.org/D95098
2021-01-21[mlir][SPIRV] Rename OpSpecConstantOperation -> OpSpecConstantOpMaheshRavishankar5-21/+21
The SPIR-V spec uses OpSpecConstantOp. Using an inconsistent name makes the dialect generation scripts fail. Update to use the right operation name, and fix the auto generation scripts as well. Differential Revision: https://reviews.llvm.org/D95097
2021-01-21Add log1p lowering from standard to ROCDL intrinsicsFrederik Gossen2-0/+17
Differential Revision: https://reviews.llvm.org/D95129
2021-01-21Add log1p lowering from standard to NVVM intrinsicsFrederik Gossen2-0/+17
Differential Revision: https://reviews.llvm.org/D95130
2021-01-21[mlir] Remove complex ops from Standard dialect.Alexander Belyaev6-412/+0
`complex` dialect should be used instead. https://llvm.discourse.group/t/rfc-split-the-complex-dialect-from-std/2496/2 Differential Revision: https://reviews.llvm.org/D95077
2021-01-20[mlir][OpFormatGen] Fix incorrect kind used for RegionsDirectiveRiver Riddle1-1/+1
I attempted to write a test case for this, but the situations in which the kind is used for RegionDirective and ResultsDirective have zero overlap; meaning that there isn't a situation in which sharing the kind creates a conflict. Differential Revision: https://reviews.llvm.org/D94988
2021-01-21[mlir] Make MLIRContext::getOrLoadDialect(StringRef, TypeID, ...) publicmfehr1-3/+5
Having this function in a public scope is helpful to register dialects that are defined at runtime, and thus that need a runtime-defined TypeID. Also, a similar function in DialectRegistry, insert(TypeID, StringRef, ...), has a public scope. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D95091
2021-01-20[mlir] Add a new builtin `unrealized_conversion_cast` operationRiver Riddle7-0/+144
An `unrealized_conversion_cast` operation represents an unrealized conversion from one set of types to another, that is used to enable the inter-mixing of different type systems. This operation should not be attributed any special representational or execution semantics, and is generally only intended to be used to satisfy the temporary intermixing of type systems during the conversion of one type system to another. This operation was discussed in the following RFC(and ODM): https://llvm.discourse.group/t/open-meeting-1-14-dialect-conversion-and-type-conversion-the-question-of-cast-operations/ Differential Revision: https://reviews.llvm.org/D94832
2021-01-20[mlir] Add an interface for Cast-Like operationsRiver Riddle38-207/+387
A cast-like operation is one that converts from a set of input types to a set of output types. The arity of the inputs may be from 0-N, whereas the arity of the outputs may be anything from 1-N. Cast-like operations are removable in cases where they produce a "no-op", i.e when the input types and output types match 1-1. Differential Revision: https://reviews.llvm.org/D94831
2021-01-21Revert "[mlir][Affine] Add support for multi-store producer fusion"Diego Caballero9-900/+404
This reverts commit 7dd198852b4db52ae22242dfeda4eccda83aa8b2. ASAN issue.
generated by cgit v1.1 at 2024-11-14 00:54:48 +0000