summaryrefslogtreecommitdiffstats
path: root/mlir/lib/Conversion/GPUToSPIRV
Commit message (Collapse)AuthorAgeFilesLines
* Revert "[mlir] Create a gpu.module operation for the GPU Dialect."Benjamin Kramer2020-01-164-50/+49
| | | | | | | This reverts commit 4624a1e8ac8a3f69cc887403b976f538f587744a. Causing problems downstream. (cherry picked from commit 0133cc60e4e230ee2c176c23eff5aa2f4ee17a75)
* [mlir][spirv] Properly support SPIR-V conversion targetLei Zhang2020-01-141-6/+6
| | | | | | | | | | | | | | | | This commit defines a new SPIR-V dialect attribute for specifying a SPIR-V target environment. It is a dictionary attribute containing the SPIR-V version, supported extension list, and allowed capability list. A SPIRVConversionTarget subclass is created to take in the target environment and sets proper dynmaically legal ops by querying the op availability interface of SPIR-V ops to make sure they are available in the specified target environment. All existing conversions targeting SPIR-V is changed to use this SPIRVConversionTarget. It probes whether the input IR has a `spv.target_env` attribute, otherwise, it uses the default target environment: SPIR-V 1.0 with Shader capability and no extra extensions. Differential Revision: https://reviews.llvm.org/D72256
* [mlir] Create a gpu.module operation for the GPU Dialect.Tres Popp2020-01-144-49/+50
| | | | | | | | | | | | | | | | | 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-2/+2
| | | | | | | | | | properly value-typed. Summary: These were temporary methods used to simplify the transition. Reviewed By: antiagainst Differential Revision: https://reviews.llvm.org/D72548
* Refactor the way that pass options are specified.River Riddle2019-12-231-16/+10
| | | | | | | | | This change refactors pass options to be more similar to how statistics are modeled. More specifically, the options are specified directly on the pass instead of in a separate options class. (Note that the behavior and specification for pass pipelines remains the same.) This brings about several benefits: * The specification of options is much simpler * The round-trip format of a pass can be generated automatically * This gives a somewhat deeper integration with "configuring" a pass, which we could potentially expose to users in the future. PiperOrigin-RevId: 286953824
* NFC: Replace ValuePtr with Value and remove it now that Value is value-typed.River Riddle2019-12-231-15/+15
| | | | | | ValuePtr was a temporary typedef during the transition to a value-typed Value. PiperOrigin-RevId: 286945714
* 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-15/+15
| | | | | | | | | | 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
* NFC: Cleanup non-conforming usages of namespaces.River Riddle2019-12-181-6/+5
| | | | | | | * Fixes use of anonymous namespace for static methods. * Uses explicit qualifiers(mlir::) instead of wrapping the definition with the namespace. PiperOrigin-RevId: 286222654
* Add atomic operations to SPIR-V dialect.Mahesh Ravishankar2019-12-161-2/+3
| | | | | | | Some changes to the dialect generation script to allow specification of different base class to derive from in ODS. PiperOrigin-RevId: 285859230
* Plug gpu.func into the GPU lowering pipelinesAlex Zinenko2019-12-161-10/+82
| | | | | | | | | | | | | | 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
* Expose a convenience function to add interface attributes to a function.Mahesh Ravishankar2019-12-111-1/+1
| | | | PiperOrigin-RevId: 285036647
* Add lowering for module with gpu.kernel_module attribute.Mahesh Ravishankar2019-12-092-27/+94
| | | | | | | | | | | The existing GPU to SPIR-V lowering created a spv.module for every function with gpu.kernel attribute. A better approach is to lower the module that the function lives in (which has the attribute gpu.kernel_module) to a spv.module operation. This better captures the host-device separation modeled by GPU dialect and simplifies the lowering as well. PiperOrigin-RevId: 284574688
* Allow specification of the workgroup size for GPUToSPIRV lowering.Mahesh Ravishankar2019-12-053-11/+48
| | | | | | | | | | SPIR-V/Vulkan spec requires the workgroups size to be specified with the spv.ExecutionMode operation. This was hard-wired to be set to a particular value. It is now changed to be configurable by clients of the pass or of the patterns that implement the lowering from GPU to SPIRV. PiperOrigin-RevId: 284017482
* NFC: Actually expose the implementation of createGPUToSPIRVLoweringPass.Mahesh Ravishankar2019-11-251-2/+3
| | | | | | | | A mismatch in the function declaration and function definition, prevented the implementation of the createGPUToSPIRVLoweringPass from being exposed. PiperOrigin-RevId: 282419815
* Introduce attributes that specify the final ABI for a spirv::ModuleOp.Mahesh Ravishankar2019-11-252-32/+18
| | | | | | | | | | | | | | | | | | | | | | | | To simplify the lowering into SPIR-V, while still respecting the ABI requirements of SPIR-V/Vulkan, split the process into two 1) While lowering a function to SPIR-V (when the function is an entry point function), allow specifying attributes on arguments and function itself that describe the ABI of the function. 2) Add a pass that materializes the ABI described in the function. Two attributes are needed. 1) Attribute on arguments of the entry point function that describe the descriptor_set, binding, storage class, etc, of the spv.globalVariable this argument will be replaced by 2) Attribute on function that specifies workgroup size, etc. (for now only workgroup size). Add the pass -spirv-lower-abi-attrs to materialize the ABI described by the attributes. This change makes the SPIRVBasicTypeConverter class unnecessary and is removed, further simplifying the SPIR-V lowering path. PiperOrigin-RevId: 282387587
* NFC: Refactor Dialect Conversion targeting SPIR-V.Mahesh Ravishankar2019-11-143-117/+155
| | | | | | | | | | | | Refactoring the conversion from StandardOps/GPU dialect to SPIR-V dialect: 1) Move the SPIRVTypeConversion and SPIRVOpLowering class into SPIR-V dialect. 2) Add header files that expose functions to add patterns for the dialects to SPIR-V lowering, as well as a pass that does the dialect to SPIR-V lowering. 3) Make SPIRVOpLowering derive from OpLowering class. PiperOrigin-RevId: 280486871
* NFC: Refactor block signature conversion to not erase the original arguments.River Riddle2019-11-131-2/+2
| | | | | | This refactors the implementation of block signature(type) conversion to not insert fake cast operations to perform the type conversion, but to instead create a new block containing the proper signature. This has the benefit of enabling the use of pre-computed analyses that rely on mapping values. It also leads to a much cleaner implementation overall. The major user facing change is that applySignatureConversion will now replace the entry block of the region, meaning that blocks generally shouldn't be cached over calls to applySignatureConversion. PiperOrigin-RevId: 280226936
* Make legality check in GPU->SPIR-V lowering of FuncOp kernel specific.Mahesh Ravishankar2019-11-121-2/+7
| | | | | | | | | | Existing check that sets FuncOp to be dynamically legal was just checking that the types of the argument are SPIR-V compatible. Since the current conversion from GPU to SPIR-V does not handle lowering non-kernel functions, change the legality check to verify that the FuncOp has the gpu.kernel attribute and has void(void) return type. PiperOrigin-RevId: 280032782
* Add Conversion to lower loop::ForOp to spirv::LoopOp.Mahesh Ravishankar2019-11-121-1/+83
| | | | | | | | | loop::ForOp can be lowered to the structured control flow represented by spirv::LoopOp by making the continue block of the spirv::LoopOp the loop latch and the merge block the exit block. The resulting spirv::LoopOp has a single back edge from the continue to header block, and a single exit from header to merge. PiperOrigin-RevId: 280015614
* Unify GPU op definition names with other dialects.Christian Sigg2019-10-211-5/+6
| | | | | | Rename GPU op names from gpu_Foo to GPU_FooOp. PiperOrigin-RevId: 275882232
* Makes spv.module generated by GPU->SPIRV conversion spec compliantMahesh Ravishankar2019-10-161-1/+6
| | | | | | | | | | | | | | | | Makes the spv.module generated by the GPU to SPIR-V conversion SPIR-V spec compliant (validated using spirv-val from Vulkan tools). 1) Separate out the VulkanLayoutUtils from DecorateSPIRVCompositeTypeLayoutPass to make it reusable within the Type converter in SPIR-V lowering infrastructure. This is used to compute the layout of the !spv.struct used in global variable type description. 2) Set the capabilities of the spv.module to Shader (needed for use of Logical Memory Model, and the extensions to SPV_KHR_storage_buffer_storage_class for use of Storage Buffer) PiperOrigin-RevId: 275081486
* Make SPIR-V lowering infrastructure follow Vulkan SPIR-V validation.Mahesh Ravishankar2019-10-091-6/+21
| | | | | | | | | | | | | | | | | | | | | | The lowering infrastructure needs to be enhanced to lower into a spv.Module that is consistent with the SPIR-V spec. The following changes are needed 1) The Vulkan/SPIR-V validation rules dictates entry functions to have signature of void(void). This requires changes to the function signature conversion infrastructure within the dialect conversion framework. When an argument is dropped from the original function signature, a function can be specified that when invoked will return the value to use as a replacement for the argument from the original function. 2) Some changes to the type converter to make the converted type consistent with the Vulkan/SPIR-V validation rules, a) Add support for converting dynamically shaped tensors to spv.rtarray type. b) Make the global variable of type !spv.ptr<!spv.struct<...>> 3) Generate the entry point operation for the kernel functions and automatically compute all the interface variables needed PiperOrigin-RevId: 273784229
* Use named modules for gpu.launch_funcAlex Zinenko2019-10-081-2/+2
| | | | | | | | | | | | | | | | | | 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
* Update SPIR-V symbols and use GLSL450 instead of VulkanKHRLei Zhang2019-09-131-1/+1
| | | | | | | | | | | | | | SPIR-V recently publishes v1.5, which brings a bunch of symbols into core. So the suffix "KHR"/"EXT"/etc. is removed from the symbols. We use a script to pull information from the spec directly. Also changed conversion and tests to use GLSL450 instead of VulkanKHR memory model. GLSL450 is still the main memory model supported by Vulkan shaders and it does not require extra capability to enable. PiperOrigin-RevId: 268992661
* NFC: Finish replacing FunctionPassBase/ModulePassBase with OpPassBase.River Riddle2019-09-131-1/+1
| | | | | | These directives were temporary during the generalization of FunctionPass/ModulePass to OpPass. PiperOrigin-RevId: 268970259
* Add folding rule and dialect materialization hook for spv.constantLei Zhang2019-09-031-1/+1
| | | | | | | | | This will allow us to use MLIR's folding infrastructure to deduplicate SPIR-V constants. This CL also changed isValidSPIRVType in SPIRVDialect to a static method. PiperOrigin-RevId: 266984403
* Enhance GPU To SPIR-V conversion to support builtins and load/store ops.Mahesh Ravishankar2019-08-271-2/+47
| | | | | | | | | | | | | | | | | To support a conversion of a simple load-compute-store kernel from GPU dialect to SPIR-V dialect, the conversion of operations like "gpu.block_dim", "gpu.thread_id" which allow threads to get the launch conversion is needed. In SPIR-V these are specified as global variables with builin attributes. This CL adds support to specify builtin variables in SPIR-V conversion framework. This is used to convert the relevant operations from GPU dialect to SPIR-V dialect. Also add support for conversion of load/store operation in Standard dialect to SPIR-V dialect. To simplify the conversion add a method to build a spv.AccessChain operation that automatically determines the return type based on the base pointer type and the indices provided. PiperOrigin-RevId: 265718525
* Simplify the classes that support SPIR-V conversion.Mahesh Ravishankar2019-08-151-9/+12
| | | | | | | | | | | | | | | | | | | | Modify the Type converters to have a SPIRVBasicTypeConverter which only handles conversion from standard types to SPIRV types. Rename SPIRVEntryFnConverter to SPIRVTypeConverter. This contains the SPIRVBasicTypeConverter within it. Remove SPIRVFnLowering class and have separate utility methods to lower a function as entry function or a non-entry function. The current setup could end with diamond inheritence that is not very friendly to use. For example, you could define the following Op conversion methods that lower from a dialect "Foo" which resuls in diamond inheritance. template<typename OpTy> class FooDialect : public SPIRVOpLowering<OpTy> {...}; class FooFnLowering : public FooDialect, SPIRVFnLowering {...}; PiperOrigin-RevId: 263597101
* NFC: Update usages of OwningRewritePatternList to pass by & instead of &&.River Riddle2019-08-091-1/+1
| | | | | | This will allow for reusing the same pattern list, which may be costly to continually reconstruct, on multiple invocations. PiperOrigin-RevId: 262664599
* NFC: Implement OwningRewritePatternList as a class instead of a using directive.River Riddle2019-08-051-2/+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
* Initial implementation to translate kernel fn in GPU Dialect to SPIR-V DialectMahesh Ravishankar2019-07-302-0/+138
This CL adds an initial implementation for translation of kernel function in GPU Dialect (used with a gpu.launch_kernel) op to a spv.Module. The original function is translated into an entry function. Most of the heavy lifting is done by adding TypeConversion and other utility functions/classes that provide most of the functionality to translate from Standard Dialect to SPIR-V Dialect. These are intended to be reusable in implementation of different dialect conversion pipelines. Note : Some of the files for have been renamed to be consistent with the norm used by the other Conversion frameworks. PiperOrigin-RevId: 260759165
OpenPOWER on IntegriCloud