summaryrefslogtreecommitdiffstats
path: root/mlir/lib/Conversion/GPUToCUDA
Commit message (Collapse)AuthorAgeFilesLines
* Revert "[mlir] Create a gpu.module operation for the GPU Dialect."Benjamin Kramer2020-01-162-15/+19
| | | | | | | 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-19/+15
| | | | | | | | | | | | | | | | | 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-1/+1
| | | | | | | | | | properly value-typed. Summary: These were temporary methods used to simplify the transition. Reviewed By: antiagainst Differential Revision: https://reviews.llvm.org/D72548
* NFC: Replace ValuePtr with Value and remove it now that Value is value-typed.River Riddle2019-12-231-25/+24
| | | | | | 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-23/+23
| | | | | | | | | | 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
* Introduce Linkage attribute to the LLVM dialectAlex Zinenko2019-12-021-2/+3
| | | | | | | | | | | 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
* Make type and rank explicit in mcuMemHostRegister function.Christian Sigg2019-11-191-8/+10
| | | | | | Fix registered size of indirect MemRefType kernel arguments. PiperOrigin-RevId: 281362940
* Adapt code to LLVM API updates.MLIR Team2019-11-141-1/+1
| | | | PiperOrigin-RevId: 280431812
* Fix minor spelling tweaks (NFC)Kazuaki Ishizaki2019-10-201-3/+3
| | | | | | Closes tensorflow/mlir#177 PiperOrigin-RevId: 275692653
* Use llvm.func to define functions with wrapped LLVM IR function typeAlex Zinenko2019-10-101-53/+63
| | | | | | | | | | | | | | 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-46/+38
| | | | | | | | | | | 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-65/+13
| | | | | | | | | | | | | 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-083-141/+58
| | | | | | | | | | | 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-31/+37
| | | | | | | | | | | | | | | | | | 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
* Promote MemRefDescriptor to a pointer to struct when passing function ↵Nicolas Vasilache2019-09-271-4/+37
| | | | | | | | | | | | | 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
* Add convenience methods to set an OpBuilder insertion point after an ↵Mehdi Amini2019-09-231-1/+1
| | | | | | Operation (NFC) PiperOrigin-RevId: 270727180
* Outline GPU kernel function into a nested module.Christian Sigg2019-09-232-39/+62
| | | | | | | | 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-62/+39
| | | | PiperOrigin-RevId: 270126672
* Outline GPU kernel function into a nested module.MLIR Team2019-09-192-39/+62
| | | | | | 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
* Unify error messages to start with lower-case.MLIR Team2019-09-182-3/+3
| | | | PiperOrigin-RevId: 269803466
* Error out when kernel function is not found while translating GPU calls.MLIR Team2019-09-161-0/+4
| | | | PiperOrigin-RevId: 269327909
* NFC: Finish replacing FunctionPassBase/ModulePassBase with OpPassBase.River Riddle2019-09-133-3/+3
| | | | | | These directives were temporary during the generalization of FunctionPass/ModulePass to OpPass. PiperOrigin-RevId: 268970259
* Refactor the 'walk' methods for operations.River Riddle2019-08-291-1/+1
| | | | | | | | | | | | This change refactors and cleans up the implementation of the operation walk methods. After this refactoring is that the explicit template parameter for the operation type is no longer needed for the explicit op walks. For example: op->walk<AffineForOp>([](AffineForOp op) { ... }); is now accomplished via: op->walk([](AffineForOp op) { ... }); PiperOrigin-RevId: 266209552
* ConvertLaunchFuncToCudaCalls: use LLVM dialect globalsAlex Zinenko2019-08-202-52/+29
| | | | | | | | | | | | 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
* NFC: Move LLVMIR, SDBM, and StandardOps to the Dialect/ directory.River Riddle2019-08-192-2/+2
| | | | PiperOrigin-RevId: 264193915
* Refactor linalg lowering to LLVMNicolas Vasilache2019-08-191-7/+8
| | | | | | | | | | | | | The linalg.view type used to be lowered to a struct containing a data pointer, offset, sizes/strides information. This was problematic when passing to external functions due to ABI, struct padding and alignment issues. The linalg.view type is now lowered to LLVMIR as a *pointer* to a struct containing the data pointer, offset and sizes/strides. This simplifies the interfacing with external library functions and makes it trivial to add new functions without creating a shim that would go from a value type struct to a pointer type. The consequences are that: 1. lowering explicitly uses llvm.alloca in lieu of llvm.undef and performs the proper llvm.load/llvm.store where relevant. 2. the shim creation function `getLLVMLibraryCallDefinition` disappears. 3. views are passed by pointer, scalars are passed by value. In the future, other structs will be passed by pointer (on a per-need basis). PiperOrigin-RevId: 264183671
* Change from llvm::make_unique to std::make_uniqueJacques Pienaar2019-08-173-4/+4
| | | | | | | | Switch to C++14 standard method as llvm::make_unique has been removed ( https://reviews.llvm.org/D66259). Also mark some targets as c++14 to ease next integrates. PiperOrigin-RevId: 263953918
* GenerateCubinAccessors: use LLVM dialect constantsAlex Zinenko2019-08-131-70/+48
| | | | | | | | | | | | 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
* Express ownership transfer in PassManager API through std::unique_ptr (NFC)Mehdi Amini2019-08-123-6/+7
| | | | | | | | | | | | | | Since raw pointers are always passed around for IR construct without implying any ownership transfer, it can be error prone to have implicit ownership transferred the same way. For example this code can seem harmless: Pass *pass = .... pm.addPass(pass); pm.addPass(pass); pm.run(module); PiperOrigin-RevId: 263053082
* Move GPU dialect to {lib,include/mlir}/DialectAlex Zinenko2019-07-253-3/+3
| | | | | | | 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
* Remove the 'region' field from OpBuilder.River Riddle2019-07-121-1/+1
| | | | | | This field wasn't updated as the insertion point changed, making it potentially dangerous given the multi-level of MLIR(e.g. 'createBlock' would always insert the new block in 'region'). This also allows for building an OpBuilder with just a context. PiperOrigin-RevId: 257829135
* Rename FunctionAttr to SymbolRefAttr.River Riddle2019-07-122-8/+8
| | | | | | This allows for the attribute to hold symbolic references to other operations than FuncOp. This also allows for removing the dependence on FuncOp from the base Builder. PiperOrigin-RevId: 257650017
* NFC: Replace Module::getNamedFunction with lookupSymbol<FuncOp>.River Riddle2019-07-122-12/+12
| | | | | | This allows for removing the last direct reference to FuncOp from ModuleOp. PiperOrigin-RevId: 257498296
* NFC: Rename Module to ModuleOp.River Riddle2019-07-102-2/+2
| | | | | | Module is a legacy name that only exists as a typedef of ModuleOp. PiperOrigin-RevId: 257427248
* Update ModuleOp::create(...) to take a Location instead of a context.River Riddle2019-07-101-1/+1
| | | | | | This allows for giving a Module a more interesting location than 'Unknown'. PiperOrigin-RevId: 257310117
* NFC: Rename Function to FuncOp.River Riddle2019-07-103-44/+42
| | | | PiperOrigin-RevId: 257293379
* NFC: Remove `Module::getFunctions` in favor of a general `getOps<T>`.River Riddle2019-07-083-3/+3
| | | | | | Modules can now contain more than just Functions, this just updates the iteration API to reflect that. The 'begin'/'end' methods have also been updated to iterate over opaque Operations. PiperOrigin-RevId: 257099084
* Add an mlir-cuda-runner tool.Stephan Herhut2019-07-042-10/+15
| | | | | | | | 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
* NFC: Refactor Module to be value typed.River Riddle2019-07-023-7/+8
| | | | | | As with Functions, Module will soon become an operation, which are value-typed. This eases the transition from Module to ModuleOp. A new class, OwningModuleRef is provided to allow for owning a reference to a Module, and will auto-delete the held module on destruction. PiperOrigin-RevId: 256196193
* NFC: Refactor Function to be value typed.River Riddle2019-07-013-69/+69
| | | | | | Move the data members out of Function and into a new impl storage class 'FunctionStorage'. This allows for Function to become value typed, which will greatly simplify the transition of Function to FuncOp(given that FuncOp is also value typed). PiperOrigin-RevId: 255983022
* Add a pass that inserts getters for all cubins found via nvvm.cubinStephan Herhut2019-06-262-0/+148
| | | | | | | | | 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-262-113/+69
| | | | | | | | | | | 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
* Add gpu::GPUDialect::isKernel helper.Stephan Herhut2019-06-251-8/+4
| | | | | | Also some mild cleanup of the kernel to cubin conversion pass. PiperOrigin-RevId: 254959303
* NVVM target: emit nvvm.annotations for kernel functionsAlex Zinenko2019-06-251-16/+0
| | | | | | | | | | PTX backend in LLVM expects additional module-level metadata `!nvvm.annotations` that lists functions that can be used as GPU kernels. Generate this metadata based on the `gpu.kernel` attribute attached to functions. This attribute is added automatically by the kernel outlining pass in the GPU dialect lowering flow. PiperOrigin-RevId: 254957345
* Add a pass that translates GPU.launch_func into a series of runtime calls.Stephan Herhut2019-06-192-0/+394
| | | | | | | | This does not map the calls to the CUDA libary directly but uses a slim wrapper ABI on top that has more convenient types for code generation and is stable. Such ABI is expected to be provided by the actual runner. PiperOrigin-RevId: 253983833
* Add a pass that translates a CUDA kernel function (tagged with nvvm.kernel) toStephan Herhut2019-06-192-0/+251
a CUBIN blob for execution on CUDA GPUs. This is a first in a series of patches to build a simple CUDA runner to allow experimenting with MLIR code on GPUs. PiperOrigin-RevId: 253758915
OpenPOWER on IntegriCloud