summaryrefslogtreecommitdiffstats
path: root/mlir/lib/Dialect/GPU/IR
Commit message (Collapse)AuthorAgeFilesLines
* Revert "[mlir] Create a gpu.module operation for the GPU Dialect."Benjamin Kramer2020-01-161-45/+10
| | | | | | | This reverts commit 4624a1e8ac8a3f69cc887403b976f538f587744a. Causing problems downstream. (cherry picked from commit 0133cc60e4e230ee2c176c23eff5aa2f4ee17a75)
* Make helper functions static or move them into anonymous namespaces. NFC.Benjamin Kramer2020-01-141-5/+5
|
* [mlir] Create a gpu.module operation for the GPU Dialect.Tres Popp2020-01-141-10/+45
| | | | | | | | | | | | | | | | | Summary: This is based on the use of code constantly checking for an attribute on a model and instead represents the distinct operaion with a different op. Instead, this op can be used to provide better filtering. Reviewers: herhut, mravishankar, antiagainst, rriddle Reviewed By: herhut, antiagainst, rriddle Subscribers: liufengdb, aartbik, jholewinski, mgorny, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, nicolasvasilache, csigg, arpith-jacob, mgester, lucyrfox, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72336
* [mlir] NFC: Remove Value::operator* and Value::operator-> now that Value is ↵River Riddle2020-01-111-30/+20
| | | | | | | | | | properly value-typed. Summary: These were temporary methods used to simplify the transition. Reviewed By: antiagainst Differential Revision: https://reviews.llvm.org/D72548
* [mlir][GPU] introduce utilities for promotion to workgroup memoryAlex Zinenko2020-01-091-0/+18
| | | | | | | | | | | | | | | | | | | Introduce a set of function that promote a memref argument of a `gpu.func` to workgroup memory using memory attribution. The promotion boils down to additional loops performing the copy from the original argument to the attributed memory in the beginning of the function, and back at the end of the function using all available threads. The loop bounds are specified so as to adapt to any size of the workgroup. These utilities are intended to compose with other existing utilities (loop coalescing and tiling) in cases where the distribution of work across threads is uneven, e.g. copying a 2D memref with only the threads along the "x" dimension. Similarly, specialization of the kernel to specific launch sizes should be implemented as a separate pass combining constant propagation and canonicalization. Introduce a simple attribute-driven pass to test the promotion transformation since we don't have a heuristic at the moment. Differential revision: https://reviews.llvm.org/D71904
* NFC: Replace ValuePtr with Value and remove it now that Value is value-typed.River Riddle2019-12-231-16/+13
| | | | | | ValuePtr was a temporary typedef during the transition to a value-typed Value. PiperOrigin-RevId: 286945714
* Change the `notifyRootUpdated` API to be transaction based.River Riddle2019-12-231-13/+12
| | | | | | This means that in-place, or root, updates need to use explicit calls to `startRootUpdate`, `finalizeRootUpdate`, and `cancelRootUpdate`. The major benefit of this change is that it enables in-place updates in DialectConversion, which simplifies the FuncOp pattern for example. The major downside to this is that the cases that *may* modify an operation in-place will need an explicit cancel on the failure branches(assuming that they started an update before attempting the transformation). PiperOrigin-RevId: 286933674
* Adjust License.txt file to use the LLVM licenseMehdi Amini2019-12-232-26/+8
| | | | PiperOrigin-RevId: 286906740
* NFC: Introduce new ValuePtr/ValueRef typedefs to simplify the transition to ↵River Riddle2019-12-221-23/+24
| | | | | | | | | | 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
* Add gpu.shuffle op.Christian Sigg2019-12-201-0/+41
| | | | | | | | This will allow us to lower most of gpu.all_reduce (when all_reduce doesn't exist in the target dialect) within the GPU dialect, and only do target-specific lowering for the shuffle op. PiperOrigin-RevId: 286548256
* NFC: Remove unnecessary 'llvm::' prefix from uses of llvm symbols declared ↵River Riddle2019-12-181-1/+1
| | | | | | | | in `mlir` namespace. Aside from being cleaner, this also makes the codebase more consistent. PiperOrigin-RevId: 286206974
* Harden the requirements to memory attribution types in gpu.funcAlex Zinenko2019-12-181-0/+22
| | | | | | | | | | When memory attributions are present in `gpu.func`, require that they are of memref type and live in memoryspaces 3 and 5 for workgroup and private memory attributions, respectively. Adapt the conversion from the GPU dialect to the NVVM dialect to drop the private memory space from attributions as NVVM is able to model them as local `llvm.alloca`s in the default memory space. PiperOrigin-RevId: 286161763
* Plug gpu.func into the GPU lowering pipelinesAlex Zinenko2019-12-161-5/+17
| | | | | | | | | | | | | | This updates the lowering pipelines from the GPU dialect to lower-level dialects (NVVM, SPIRV) to use the recently introduced gpu.func operation instead of a standard function annotated with an attribute. In particular, the kernel outlining is updated to produce gpu.func instead of std.func and the individual conversions are updated to consume gpu.funcs and disallow standard funcs after legalization, if necessary. The attribute "gpu.kernel" is preserved in the generic syntax, but can also be used with the custom syntax on gpu.funcs. The special kind of function for GPU allows one to use additional features such as memory attribution. PiperOrigin-RevId: 285822272
* NFC: Cleanup the various Op::print methods.River Riddle2019-12-121-17/+8
| | | | | | This cleans up the implementation of the various operation print methods. This is done via a combination of code cleanup, adding new streaming methods to the printer(e.g. operand ranges), etc. PiperOrigin-RevId: 285285181
* Move gpu.launch_func to ODS. NFCAlex Zinenko2019-12-101-14/+14
| | | | | | | | | Move the definition of gpu.launch_func operation from hand-rolled C++ implementation to the ODS framework. Also move the documentation. This only performs the move and remains a non-functional change, a follow-up will clean up the custom functions that can be auto-generated using ODS. PiperOrigin-RevId: 284842252
* Update the builder API to take ValueRange instead of ArrayRef<Value *>River Riddle2019-12-071-10/+8
| | | | | | This allows for users to provide operand_range and result_range in builder.create<> calls, instead of requiring an explicit copy into a separate data structure like SmallVector/std::vector. PiperOrigin-RevId: 284360710
* Replace custom getBody method with an ODS-generated in gpu::LaunchOpAlex Zinenko2019-12-061-20/+18
| | | | PiperOrigin-RevId: 284262981
* Move GPU::LaunchOp to ODS. NFC.Alex Zinenko2019-12-061-29/+35
| | | | | | | | Move the definition of the GPU launch opreation from hand-rolled C++ code to ODS framework. This only does the moves, a follow-up is necessary to clean up users of custom functions that could be auto-generated by ODS. PiperOrigin-RevId: 284261856
* Move GPU::FuncOp definition to ODS - NFCAlex Zinenko2019-12-061-29/+30
| | | | | | | | Move the definition of the GPU function opreation from hand-rolled C++ code to ODS framework. This only does the moves, a follow-up is necessary to clean up users of custom functions that could be auto-generated by ODS. PiperOrigin-RevId: 284233245
* Split out FunctionLike printing/parsing into FunctionImplementation.{h,cpp}Alex Zinenko2019-11-281-0/+1
| | | | | | | | | | | Helper utilies for parsing and printing FunctionLike Ops are only relevant to the implementation of the Op, not its definition. They depend on OpImplementation.h and increase the inclusion footprint of FunctionSupport.h, and do so only to provide some utilities in the "impl" namespace. Move them to a separate files, similarly to OpDefinition/OpImplementation distinction, and make only Op implementations use them while keeping headers cleaner. NFC. PiperOrigin-RevId: 282964556
* Introduce gpu.funcAlex Zinenko2019-11-251-6/+195
| | | | | | | | | | | | | | | | | | Introduce a new function-like operation to the GPU dialect to provide a placeholder for the execution semantic description and to add support for GPU memory hierarchy. This aligns with the overall goal of the dialect to expose the common abstraction layer for GPU devices, in particular by providing an MLIR unit of semantics (i.e. an operation) for memory modeling. This proposal has been discussed in the mailing list: https://groups.google.com/a/tensorflow.org/d/msg/mlir/RfXNP7Hklsc/MBNN7KhjAgAJ As decided, the "convergence" aspect of the execution model will be factored out into a new discussion and therefore is not included in this commit. This commit only introduces the operation but does not hook it up with the remaining flow. The intention is to develop the new flow while keeping the old flow operational and do the switch in a simple, separately reversible commit. PiperOrigin-RevId: 282357599
* Add support for nested symbol references.River Riddle2019-11-111-1/+2
| | | | | | | | | | | | | | | | | | This change allows for adding additional nested references to a SymbolRefAttr to allow for further resolving a symbol if that symbol also defines a SymbolTable. If a referenced symbol also defines a symbol table, a nested reference can be used to refer to a symbol within that table. Nested references are printed after the main reference in the following form: symbol-ref-attribute ::= symbol-ref-id (`::` symbol-ref-id)* Example: module @reference { func @nested_reference() } my_reference_op @reference::@nested_reference Given that SymbolRefAttr is now more general, the existing functionality centered around a single reference is moved to a derived class FlatSymbolRefAttr. Followup commits will add support to lookups, rauw, etc. for scoped references. PiperOrigin-RevId: 279860501
* NFC: Rename parseOptionalAttributeDict -> parseOptionalAttrDict to match the ↵River Riddle2019-11-051-1/+1
| | | | | | name of the print method. PiperOrigin-RevId: 278696668
* Unify GPU op definition names with other dialects.Christian Sigg2019-10-211-3/+8
| | | | | | Rename GPU op names from gpu_Foo to GPU_FooOp. PiperOrigin-RevId: 275882232
* Use StrEnumAttr for gpu.allreduce op instead of StringAttr to better encode ↵Stephan Herhut2019-10-181-5/+0
| | | | | | constraints. PiperOrigin-RevId: 275448372
* Use a SmallVector instead of an ArrayRef to materialize a temporary local arrayMehdi Amini2019-10-171-1/+1
| | | | | | | | | | | | This pattern is error prone and unfortunately none of the sanitizer is catching it at the moment. Fixes tensorflow/mlir#192 Closes tensorflow/mlir#193 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/193 from joker-eph:fix_array_ref 8092252e64c426c6a8a790b7638f847bea4818b1 PiperOrigin-RevId: 275280201
* Support custom accumulator provided as region to gpu.all_reduce.Christian Sigg2019-10-161-0/+32
| | | | | | | | | | In addition to specifying the type of accumulation through the 'op' attribute, the accumulation can now also be specified as arbitrary code region. Adds a gpu.yield op to specify the result of the accumulation. Also support more types (integers) and accumulations (mul). PiperOrigin-RevId: 275065447
* Use llvm.func to define functions with wrapped LLVM IR function typeAlex Zinenko2019-10-101-10/+17
| | | | | | | | | | | | | | This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
* Use named modules for gpu.launch_funcAlex Zinenko2019-10-081-35/+105
| | | | | | | | | | | | | | | | | | The kernel function called by gpu.launch_func is now placed into an isolated nested module during the outlining stage to simplify separate compilation. Until recently, modules did not have names and could not be referenced. This limitation was circumvented by introducing a stub kernel at the same name at the same nesting level as the module containing the actual kernel. This relation is only effective in one direction: from actual kernel function to its launch_func "caller". Leverage the recently introduced symbol name attributes on modules to refer to a specific nested module from `gpu.launch_func`. This removes the implicit connection between the identically named stub and kernel functions. It also enables support for `gpu.launch_func`s to call different kernels located in the same module. PiperOrigin-RevId: 273491891
* Fix typos, NFC.Christian Sigg2019-10-041-6/+6
| | | | PiperOrigin-RevId: 272851237
* Promote MemRefDescriptor to a pointer to struct when passing function ↵Nicolas Vasilache2019-09-271-7/+11
| | | | | | | | | | | | | boundaries in LLVMLowering. The strided MemRef RFC discusses a normalized descriptor and interaction with library calls (https://groups.google.com/a/tensorflow.org/forum/#!topic/mlir/MaL8m2nXuio). Lowering of nested LLVM structs as value types does not play nicely with externally compiled C/C++ functions due to ABI issues. Solving the ABI problem generally is a very complex problem and most likely involves taking a dependence on clang that we do not want atm. A simple workaround is to pass pointers to memref descriptors at function boundaries, which this CL implement. PiperOrigin-RevId: 271591708
* NFC: Pass OpAsmPrinter by reference instead of by pointer.River Riddle2019-09-201-18/+18
| | | | | | MLIR follows the LLVM style of pass-by-reference. PiperOrigin-RevId: 270401378
* NFC: Pass OperationState by reference instead of by pointer.River Riddle2019-09-201-15/+15
| | | | | | MLIR follows the LLVM convention of passing by reference instead of by pointer. PiperOrigin-RevId: 270396945
* NFC: Pass OpAsmParser by reference instead of by pointer.River Riddle2019-09-201-27/+26
| | | | | | MLIR follows the LLVM style of pass-by-reference. PiperOrigin-RevId: 270315612
* Add support to OpAsmParser for parsing unknown keywords.River Riddle2019-09-171-1/+1
| | | | | | This is useful in several cases, for example a user may want to sugar the syntax of a string(as we do with custom operation syntax), or avoid many nested ifs for parsing a set of known keywords. PiperOrigin-RevId: 269695451
* Unify how errors are emitted in LaunchFuncOp verification.MLIR Team2019-09-161-3/+3
| | | | PiperOrigin-RevId: 269331869
* Add verification for dimension attribute on GPUDialect index operations.Stephan Herhut2019-08-281-0/+7
| | | | PiperOrigin-RevId: 266073204
* NFC: Move LLVMIR, SDBM, and StandardOps to the Dialect/ directory.River Riddle2019-08-191-1/+1
| | | | PiperOrigin-RevId: 264193915
* NFC: Implement OwningRewritePatternList as a class instead of a using directive.River Riddle2019-08-051-1/+1
| | | | | | This allows for proper forward declaration, as opposed to leaking the internal implementation via a using directive. This also allows for all pattern building to go through 'insert' methods on the OwningRewritePatternList, replacing uses of 'push_back' and 'RewriteListBuilder'. PiperOrigin-RevId: 261816316
* Move GPU dialect to {lib,include/mlir}/DialectAlex Zinenko2019-07-252-0/+475
Per tacit agreement, individual dialects should now live in lib/Dialect/Name with headers in include/mlir/Dialect/Name and tests in test/Dialect/Name. PiperOrigin-RevId: 259896851
OpenPOWER on IntegriCloud