summaryrefslogtreecommitdiffstats
path: root/mlir/test/Conversion/GPUToCUDA
Commit message (Collapse)AuthorAgeFilesLines
* Revert "[mlir] Create a gpu.module operation for the GPU Dialect."Benjamin Kramer2020-01-162-4/+4
| | | | | | | This reverts commit 4624a1e8ac8a3f69cc887403b976f538f587744a. Causing problems downstream. (cherry picked from commit 0133cc60e4e230ee2c176c23eff5aa2f4ee17a75)
* [mlir] Create a gpu.module operation for the GPU Dialect.Tres Popp2020-01-142-4/+4
| | | | | | | | | | | | | | | | | 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
* Plug gpu.func into the GPU lowering pipelinesAlex Zinenko2019-12-161-2/+3
| | | | | | | | | | | | | | 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
* Introduce Linkage attribute to the LLVM dialectAlex Zinenko2019-12-021-2/+2
| | | | | | | | | | | LLVM IR supports linkage on global objects such as global variables and functions. Introduce the Linkage attribute into the LLVM dialect, backed by an integer storage. Use this attribute on LLVM::GlobalOp and make it mandatory. Implement parsing/printing of the attribute and conversion to LLVM IR. See tensorflow/mlir#277. PiperOrigin-RevId: 283309328
* Use LLVM_Type instead of AnyType in the definition of LLVM_CallOpAlex Zinenko2019-10-211-2/+2
| | | | | | | | | | The type constraint had to be relaxed due to the order of lowering passes in the examples, that since has been fixed. The relaxed version was still used by the CUDA lowering for launch sizes of `index` type. This is not necessary since the GPU dialect does not restrict the type of the launch size operands. Use an LLVM type instead and restore the check in the LLVM_CallOp definition. PiperOrigin-RevId: 275920109
* Use llvm.func to define functions with wrapped LLVM IR function typeAlex Zinenko2019-10-102-7/+8
| | | | | | | | | | | | | | 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
* GPUToCUDA: attach CUBIN to the nested module rather than to the functionAlex Zinenko2019-10-082-5/+4
| | | | | | | | | | | Originally, we were attaching attributes containing CUBIN blobs to the kernel function called by `gpu.launch_func`. This kernel is now contained in a nested module that is used as a compilation unit. Attach compiled CUBIN blobs to the module rather than to the function since we were compiling the module. This also avoids duplication of the attribute on multiple kernels within the same module. PiperOrigin-RevId: 273497303
* GPUToCUDA: emit addressof directly instead of wrapping it into a getter functionAlex Zinenko2019-10-081-12/+8
| | | | | | | | | | | | | Originally, the CUBIN getter function was introduced as a mechanism to circumvent the absence of globals in the LLVM dialect. It would allocate memory and populate it with the CUBIN data. LLVM dialect now supports globals and they are already used to store CUBIN data, making the getter function a trivial address computation of a global. Emit the address computation directly at the place of `gpu.launch_func` instead of putting it in a function and calling it. This simplifies the conversion flow and prepares it for using the DialectConversion infrastructure. PiperOrigin-RevId: 273496221
* Fuse GenerateCubinAccessors pass into LaunchFunctToCudaAlex Zinenko2019-10-082-24/+10
| | | | | | | | | | | Now that the accessor function is a trivial getter of the global variable, it makes less sense to have the getter generation as a separate pass. Move the getter generation into the lowering of `gpu.launch_func` to CUDA calls. This change is mostly code motion, but the process can be simplified further by generating the addressof inplace instead of using a call. This is will be done in a follow-up. PiperOrigin-RevId: 273492517
* Use named modules for gpu.launch_funcAlex Zinenko2019-10-082-26/+33
| | | | | | | | | | | | | | | | | | 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
* Outline GPU kernel function into a nested module.Christian Sigg2019-09-232-10/+33
| | | | | | | | Roll forward of commit 5684a12. When outlining GPU kernels, put the kernel function inside a nested module. Then use a nested pipeline to generate the cubins, independently per kernel. In a final pass, move the cubins back to the parent module. PiperOrigin-RevId: 270639748
* Automated rollback of commit 5684a12434f923d03b6870f2aa16226bfb0b38b6George Karpenkov2019-09-192-33/+10
| | | | PiperOrigin-RevId: 270126672
* Outline GPU kernel function into a nested module.MLIR Team2019-09-192-10/+33
| | | | | | When outlining GPU kernels, put the kernel function inside a nested module. Then use a nested pipeline to generate the cubins, independently per kernel. In a final pass, move the cubins back to the parent module. PiperOrigin-RevId: 269987720
* LLVM dialect: prefix auxiliary operations with "mlir."Alex Zinenko2019-09-032-4/+4
| | | | | | | | | | Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
* ConvertLaunchFuncToCudaCalls: use LLVM dialect globalsAlex Zinenko2019-08-201-8/+10
| | | | | | | | | | | | This conversion has been using a stack-allocated array of i8 to store the null-terminated kernel name in order to pass it to the CUDA wrappers expecting a C string because the LLVM dialect was missing support for globals. Now that the suport is introduced, use a global instead. Refactor global string construction from GenerateCubinAccessors into a common utility function living in the LLVM namespace. PiperOrigin-RevId: 264382489
* GenerateCubinAccessors: use LLVM dialect constantsAlex Zinenko2019-08-131-26/+9
| | | | | | | | | | | | The GenerateCubinAccessors was generating functions that fill dynamically-allocated memory with the binary constant of a CUBIN attached as a stirng attribute to the GPU kernel. This approach was taken to circumvent the missing support for global constants in the LLVM dialect (and MLIR in general). Global constants were recently added to the LLVM dialect. Change the GenerateCubinAccessors pass to emit a global constant array of characters and a function that returns a pointer to the first character in the array. PiperOrigin-RevId: 263092052
* Add an mlir-cuda-runner tool.Stephan Herhut2019-07-041-3/+3
| | | | | | | | This tool allows to execute MLIR IR snippets written in the GPU dialect on a CUDA capable GPU. For this to work, a working CUDA install is required and the build has to be configured with MLIR_CUDA_RUNNER_ENABLED set to 1. PiperOrigin-RevId: 256551415
* Add a pass that inserts getters for all cubins found via nvvm.cubinStephan Herhut2019-06-261-0/+31
| | | | | | | | | annotations. Getters are required as there are currently no global constants in MLIR and this is an easy way to unblock CUDA execution while waiting for those. PiperOrigin-RevId: 255169002
* Make GPU to CUDA transformations independent of CUDA runtime.Stephan Herhut2019-06-263-0/+35
The actual transformation from PTX source to a CUDA binary is now factored out, enabling compiling and testing the transformations independently of a CUDA runtime. MLIR has still to be built with NVPTX target support for the conversions to be built and tested. PiperOrigin-RevId: 255167139
OpenPOWER on IntegriCloud