maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/mlir/test/Dialect/GPU/ops.mlir

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

170 lines
6.3 KiB
MLIR
Raw Normal View History

Add a flag on the context to protect against creation of operations in unregistered dialects Differential Revision: https://reviews.llvm.org/D76903
2020-03-30 06:35:38 +08:00
// RUN: mlir-opt -allow-unregistered-dialect %s | FileCheck %s
Start GPU Dialect Define a new dialect related to GPU kernels. Currently, it only contains a single operation for launching a kernel on a three-dimensional grid of thread blocks, following a model similar to that of CUDA. In particular, the body of the kernel contains operations executed by each thread and uses region arguments to accept thread and block identifiers (similar to how the loop body region accepts the induction value). -- PiperOrigin-RevId: 245713728
2019-04-29 18:00:25 +08:00
Use named modules for gpu.launch_func 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
2019-10-08 19:29:58 +08:00
module attributes {gpu.container_module} {
// CHECK-LABEL:func @no_args(%{{.*}}: index)
func @no_args(%sz : index) {
// CHECK: gpu.launch blocks(%{{.*}}, %{{.*}}, %{{.*}}) in (%{{.*}} = %{{.*}}, %{{.*}} = %{{.*}}, %{{.*}} = %{{.*}}) threads(%{{.*}}, %{{.*}}, %{{.*}}) in (%{{.*}} = %{{.*}}, %{{.*}} = %{{.*}}, %{{.*}} = %{{.*}})
gpu.launch blocks(%bx, %by, %bz) in (%grid_x = %sz, %grid_y = %sz, %grid_z = %sz)
threads(%tx, %ty, %tz) in (%block_x = %sz, %block_y = %sz, %block_z = %sz) {
Add 'gpu.terminator' operation. Summary: The 'gpu.terminator' operation is used as the terminator for the regions of gpu.launch. This is to disambugaute them from the return operation on 'gpu.func' functions. This is a breaking change and users of the gpu dialect will need to adapt their code when producting 'gpu.launch' operations. Reviewers: nicolasvasilache Subscribers: mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, csigg, arpith-jacob, mgester, lucyrfox, liufengdb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73620
2020-01-29 20:59:36 +08:00
// CHECK: gpu.terminator
gpu.terminator
Use named modules for gpu.launch_func 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
2019-10-08 19:29:58 +08:00
}
return
GPU dialect: introduce custom syntax for gpu.launch This syntax removes boilerplate and verbose list of region arguments in the header of the entry block. It groups operands into segments related to GPU blocks, GPU threads as well as the operands that are forwarded to the kernel. The two former segments are also used to give names to the region arguments that are used for GPU blocks and threads inside the kernel body region. -- PiperOrigin-RevId: 246792329
2019-05-06 17:30:50 +08:00
}
Start GPU Dialect Define a new dialect related to GPU kernels. Currently, it only contains a single operation for launching a kernel on a three-dimensional grid of thread blocks, following a model similar to that of CUDA. In particular, the body of the kernel contains operations executed by each thread and uses region arguments to accept thread and block identifiers (similar to how the loop body region accepts the induction value). -- PiperOrigin-RevId: 245713728
2019-04-29 18:00:25 +08:00
Use named modules for gpu.launch_func 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
2019-10-08 19:29:58 +08:00
// CHECK-LABEL:func @args(%{{.*}}: index, %{{.*}}: index, %{{.*}}: f32, %{{.*}}: memref<?xf32, 1>) {
func @args(%blk : index, %thrd : index, %float : f32, %data : memref<?xf32,1>) {
[MLIR] Make gpu.launch implicitly capture uses of values defined above. Summary: In the original design, gpu.launch required explicit capture of uses and passing them as operands to the gpu.launch operation. This was motivated by infrastructure restrictions rather than design. This change lifts the requirement and removes the concept of kernel arguments from gpu.launch. Instead, the kernel outlining transformation now does the explicit capturing. This is a breaking change for users of gpu.launch. Differential Revision: https://reviews.llvm.org/D73769
2020-01-31 17:29:29 +08:00
// CHECK: gpu.launch blocks(%{{.*}}, %{{.*}}, %{{.*}}) in (%{{.*}} = %{{.*}}, %{{.*}} = %{{.*}}, %{{.*}} = %{{.*}}) threads(%{{.*}}, %{{.*}}, %{{.*}}) in (%{{.*}} = %{{.*}}, %{{.*}} = %{{.*}}, %{{.*}} = %{{.*}})
Use named modules for gpu.launch_func 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
2019-10-08 19:29:58 +08:00
gpu.launch blocks(%bx, %by, %bz) in (%grid_x = %blk, %grid_y = %blk, %grid_z = %blk)
[MLIR] Make gpu.launch implicitly capture uses of values defined above. Summary: In the original design, gpu.launch required explicit capture of uses and passing them as operands to the gpu.launch operation. This was motivated by infrastructure restrictions rather than design. This change lifts the requirement and removes the concept of kernel arguments from gpu.launch. Instead, the kernel outlining transformation now does the explicit capturing. This is a breaking change for users of gpu.launch. Differential Revision: https://reviews.llvm.org/D73769
2020-01-31 17:29:29 +08:00
threads(%tx, %ty, %tz) in (%block_x = %thrd, %block_y = %thrd, %block_z = %thrd) {
"use"(%float) : (f32) -> ()
"use"(%data) : (memref<?xf32,1>) -> ()
Add 'gpu.terminator' operation. Summary: The 'gpu.terminator' operation is used as the terminator for the regions of gpu.launch. This is to disambugaute them from the return operation on 'gpu.func' functions. This is a breaking change and users of the gpu dialect will need to adapt their code when producting 'gpu.launch' operations. Reviewers: nicolasvasilache Subscribers: mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, csigg, arpith-jacob, mgester, lucyrfox, liufengdb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73620
2020-01-29 20:59:36 +08:00
// CHECK: gpu.terminator
gpu.terminator
Use named modules for gpu.launch_func 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
2019-10-08 19:29:58 +08:00
}
return
GPU dialect: introduce custom syntax for gpu.launch This syntax removes boilerplate and verbose list of region arguments in the header of the entry block. It groups operands into segments related to GPU blocks, GPU threads as well as the operands that are forwarded to the kernel. The two former segments are also used to give names to the region arguments that are used for GPU blocks and threads inside the kernel body region. -- PiperOrigin-RevId: 246792329
2019-05-06 17:30:50 +08:00
}
Add the "gpu.launch_func" op to the GPU dialect. The idea is to lower `gpu.launch` operations into `gpu.launch_func` operations by outlining the kernel body into a function, which is closer to the NVVM model. -- PiperOrigin-RevId: 246806890
2019-05-06 20:01:12 +08:00
Create a gpu.module operation for the GPU Dialect. 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. Reverts "Revert "[mlir] Create a gpu.module operation for the GPU Dialect."" This reverts commit ac446302ca4145cdc89f377c0c364c29ee303be5 after fixing internal Google issues. This additionally updates ROCDL lowering to use the new gpu.module. Reviewers: herhut, mravishankar, antiagainst, nicolasvasilache Subscribers: jholewinski, mgorny, mehdi_amini, jpienaar, burmako, shauheen, csigg, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, llvm-commits, mravishankar, rriddle, antiagainst, bkramer Tags: #llvm Differential Revision: https://reviews.llvm.org/D72921
2020-01-17 22:18:23 +08:00
gpu.module @kernels {
[MLIR] Use `kernel` as a short hand for `gpu.kernel` attribute. Summary: Use the shortcu `kernel` for the `gpu.kernel` attribute of `gpu.func`. The parser supports this and test cases are easier to read. Differential Revision: https://reviews.llvm.org/D78542
2020-04-21 15:11:10 +08:00
gpu.func @kernel_1(%arg0 : f32, %arg1 : memref<?xf32, 1>) kernel {
Use named modules for gpu.launch_func 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
2019-10-08 19:29:58 +08:00
%tIdX = "gpu.thread_id"() {dimension = "x"} : () -> (index)
%tIdY = "gpu.thread_id"() {dimension = "y"} : () -> (index)
%tIdZ = "gpu.thread_id"() {dimension = "z"} : () -> (index)
Add operations to produce block/index ids and dimensions to the gpu dialect. -- PiperOrigin-RevId: 246976227
2019-05-07 16:27:54 +08:00
Use named modules for gpu.launch_func 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
2019-10-08 19:29:58 +08:00
%bDimX = "gpu.block_dim"() {dimension = "x"} : () -> (index)
%bDimY = "gpu.block_dim"() {dimension = "y"} : () -> (index)
%bDimZ = "gpu.block_dim"() {dimension = "z"} : () -> (index)
Add operations to produce block/index ids and dimensions to the gpu dialect. -- PiperOrigin-RevId: 246976227
2019-05-07 16:27:54 +08:00
Use named modules for gpu.launch_func 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
2019-10-08 19:29:58 +08:00
%bIdX = "gpu.block_id"() {dimension = "x"} : () -> (index)
%bIdY = "gpu.block_id"() {dimension = "y"} : () -> (index)
%bIdZ = "gpu.block_id"() {dimension = "z"} : () -> (index)
Add operations to produce block/index ids and dimensions to the gpu dialect. -- PiperOrigin-RevId: 246976227
2019-05-07 16:27:54 +08:00
Use named modules for gpu.launch_func 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
2019-10-08 19:29:58 +08:00
%gDimX = "gpu.grid_dim"() {dimension = "x"} : () -> (index)
%gDimY = "gpu.grid_dim"() {dimension = "y"} : () -> (index)
%gDimZ = "gpu.grid_dim"() {dimension = "z"} : () -> (index)
Add operations to produce block/index ids and dimensions to the gpu dialect. -- PiperOrigin-RevId: 246976227
2019-05-07 16:27:54 +08:00
[mlir][gpu] Add subgroup Id/Size/Num to GPU dialect Add SubgroupId, SubgroupSize and NumSubgroups to GPU dialect ops and add the lowering of those ops to SPIRV. Differential Revision: https://reviews.llvm.org/D81042
2020-06-05 01:45:53 +08:00
%sgId = gpu.subgroup_id : index
%numSg = gpu.num_subgroups : index
%SgSi = gpu.subgroup_size : index
Use named modules for gpu.launch_func 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
2019-10-08 19:29:58 +08:00
%one = constant 1.0 : f32
Support custom accumulator provided as region to gpu.all_reduce. 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
2019-10-17 01:43:12 +08:00
%sum = "gpu.all_reduce"(%one) ({}) {op = "add"} : (f32) -> (f32)
Add AllReduceOp to GPU dialect with lowering to NVVM. The reduction operation is currently fixed to "add", and the scope is fixed to "workgroup". The implementation is currently limited to sizes that are multiple 32 (warp size) and no larger than 1024. PiperOrigin-RevId: 271290265
2019-09-26 15:17:13 +08:00
Add gpu.shuffle op. 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
2019-12-20 18:52:21 +08:00
%width = constant 7 : i32
%offset = constant 3 : i32
// CHECK: gpu.shuffle %{{.*}}, %{{.*}}, %{{.*}} xor : f32
%shfl, %pred = gpu.shuffle %arg0, %offset, %width xor : f32
Add gpu.barrier op to synchronize invocations of a local workgroup. Adding gen table for rewrite patterns from GPU to NVVM dialect. Copy missing op documentation from GPUOps.td to GPU.md. PiperOrigin-RevId: 275419588
2019-10-18 15:30:14 +08:00
"gpu.barrier"() : () -> ()
Use named modules for gpu.launch_func 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
2019-10-08 19:29:58 +08:00
"some_op"(%bIdX, %tIdX) : (index, index) -> ()
%42 = load %arg1[%bIdX] : memref<?xf32, 1>
Plug gpu.func into the GPU lowering pipelines 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
2019-12-17 04:12:20 +08:00
gpu.return
Use named modules for gpu.launch_func 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
2019-10-08 19:29:58 +08:00
}
[MLIR] Use `kernel` as a short hand for `gpu.kernel` attribute. Summary: Use the shortcu `kernel` for the `gpu.kernel` attribute of `gpu.func`. The parser supports this and test cases are easier to read. Differential Revision: https://reviews.llvm.org/D78542
2020-04-21 15:11:10 +08:00
gpu.func @kernel_2(%arg0: f32, %arg1: memref<?xf32, 1>) kernel {
Plug gpu.func into the GPU lowering pipelines 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
2019-12-17 04:12:20 +08:00
gpu.return
}
Use named modules for gpu.launch_func 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
2019-10-08 19:29:58 +08:00
}
Add the "gpu.launch_func" op to the GPU dialect. The idea is to lower `gpu.launch` operations into `gpu.launch_func` operations by outlining the kernel body into a function, which is closer to the NVVM model. -- PiperOrigin-RevId: 246806890
2019-05-06 20:01:12 +08:00
Use named modules for gpu.launch_func 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
2019-10-08 19:29:58 +08:00
func @foo() {
%0 = "op"() : () -> (f32)
%1 = "op"() : () -> (memref<?xf32, 1>)
// CHECK: %{{.*}} = constant 8
%cst = constant 8 : index
Verification for gpu.launch_func should rely on function type and not on the actual body of a kernel function. This enables using gpu.launch_func with external kernel declarations. PiperOrigin-RevId: 253639770
2019-06-18 03:47:09 +08:00
[MLIR] Use nested symbol to identify kernel in `LaunchFuncOp`. Summary: Use a nested symbol to identify the kernel to be invoked by a `LaunchFuncOp` in the GPU dialect. This replaces the two attributes that were used to identify the kernel module and the kernel within seperately. Differential Revision: https://reviews.llvm.org/D78551
2020-04-21 18:16:41 +08:00
// CHECK: "gpu.launch_func"(%{{.*}}, %{{.*}}, %{{.*}}, %{{.*}}, %{{.*}}, %{{.*}}, %{{.*}}, %{{.*}}) {kernel = @kernels::@kernel_1} : (index, index, index, index, index, index, f32, memref<?xf32, 1>) -> ()
Use named modules for gpu.launch_func 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
2019-10-08 19:29:58 +08:00
"gpu.launch_func"(%cst, %cst, %cst, %cst, %cst, %cst, %0, %1)
[MLIR] Use nested symbol to identify kernel in `LaunchFuncOp`. Summary: Use a nested symbol to identify the kernel to be invoked by a `LaunchFuncOp` in the GPU dialect. This replaces the two attributes that were used to identify the kernel module and the kernel within seperately. Differential Revision: https://reviews.llvm.org/D78551
2020-04-21 18:16:41 +08:00
{ kernel = @kernels::@kernel_1}
Use named modules for gpu.launch_func 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
2019-10-08 19:29:58 +08:00
: (index, index, index, index, index, index, f32, memref<?xf32, 1>) -> ()
Add the "gpu.launch_func" op to the GPU dialect. The idea is to lower `gpu.launch` operations into `gpu.launch_func` operations by outlining the kernel body into a function, which is closer to the NVVM model. -- PiperOrigin-RevId: 246806890
2019-05-06 20:01:12 +08:00
[MLIR] Use nested symbol to identify kernel in `LaunchFuncOp`. Summary: Use a nested symbol to identify the kernel to be invoked by a `LaunchFuncOp` in the GPU dialect. This replaces the two attributes that were used to identify the kernel module and the kernel within seperately. Differential Revision: https://reviews.llvm.org/D78551
2020-04-21 18:16:41 +08:00
// CHECK: "gpu.launch_func"(%{{.*}}, %{{.*}}, %{{.*}}, %{{.*}}, %{{.*}}, %{{.*}}, %{{.*}}, %{{.*}}) {kernel = @kernels::@kernel_2} : (index, index, index, index, index, index, f32, memref<?xf32, 1>) -> ()
Use named modules for gpu.launch_func 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
2019-10-08 19:29:58 +08:00
"gpu.launch_func"(%cst, %cst, %cst, %cst, %cst, %cst, %0, %1)
[MLIR] Use nested symbol to identify kernel in `LaunchFuncOp`. Summary: Use a nested symbol to identify the kernel to be invoked by a `LaunchFuncOp` in the GPU dialect. This replaces the two attributes that were used to identify the kernel module and the kernel within seperately. Differential Revision: https://reviews.llvm.org/D78551
2020-04-21 18:16:41 +08:00
{ kernel = @kernels::@kernel_2}
Use named modules for gpu.launch_func 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
2019-10-08 19:29:58 +08:00
: (index, index, index, index, index, index, f32, memref<?xf32, 1>) -> ()
Verification for gpu.launch_func should rely on function type and not on the actual body of a kernel function. This enables using gpu.launch_func with external kernel declarations. PiperOrigin-RevId: 253639770
2019-06-18 03:47:09 +08:00
Use named modules for gpu.launch_func 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
2019-10-08 19:29:58 +08:00
return
}
Verification for gpu.launch_func should rely on function type and not on the actual body of a kernel function. This enables using gpu.launch_func with external kernel declarations. PiperOrigin-RevId: 253639770
2019-06-18 03:47:09 +08:00
[MLIR] Ensure `gpu.func` must be inside a `gpu.module`. Ensure that `gpu.func` is only used within the dedicated `gpu.module`. Implement the constraint to the GPU dialect and adopt test cases. Differential Revision: https://reviews.llvm.org/D78541
2020-04-21 18:05:17 +08:00
gpu.module @gpu_funcs {
Add 'gpu.terminator' operation. Summary: The 'gpu.terminator' operation is used as the terminator for the regions of gpu.launch. This is to disambugaute them from the return operation on 'gpu.func' functions. This is a breaking change and users of the gpu dialect will need to adapt their code when producting 'gpu.launch' operations. Reviewers: nicolasvasilache Subscribers: mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, csigg, arpith-jacob, mgester, lucyrfox, liufengdb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73620
2020-01-29 20:59:36 +08:00
// CHECK-LABEL: gpu.func @kernel_1({{.*}}: f32)
Introduce gpu.func 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
2019-11-25 23:59:52 +08:00
// CHECK: workgroup
// CHECK: private
// CHECK: attributes
Add 'gpu.terminator' operation. Summary: The 'gpu.terminator' operation is used as the terminator for the regions of gpu.launch. This is to disambugaute them from the return operation on 'gpu.func' functions. This is a breaking change and users of the gpu dialect will need to adapt their code when producting 'gpu.launch' operations. Reviewers: nicolasvasilache Subscribers: mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, csigg, arpith-jacob, mgester, lucyrfox, liufengdb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73620
2020-01-29 20:59:36 +08:00
gpu.func @kernel_1(%arg0: f32)
Introduce gpu.func 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
2019-11-25 23:59:52 +08:00
workgroup(%arg1: memref<42xf32, 3>)
private(%arg2: memref<2xf32, 5>, %arg3: memref<1xf32, 5>)
kernel
attributes {foo="bar"} {
"use"(%arg1) : (memref<42xf32, 3>) -> ()
"use"(%arg2) : (memref<2xf32, 5>) -> ()
"use"(%arg3) : (memref<1xf32, 5>) -> ()
gpu.return
}
// CHECK-LABEL: gpu.func @no_attribution
// CHECK: {
gpu.func @no_attribution(%arg0: f32) {
gpu.return
}
// CHECK-LABEL: @no_attribution_attrs
// CHECK: attributes
// CHECK: {
gpu.func @no_attribution_attrs(%arg0: f32) attributes {foo="bar"} {
gpu.return
}
// CHECK-LABEL: @workgroup_only
// CHECK: workgroup({{.*}}: {{.*}})
// CHECK: {
gpu.func @workgroup_only() workgroup(%arg0: memref<42xf32, 3>) {
gpu.return
}
// CHECK-LABEL: @private_only
// CHECK: private({{.*}}: {{.*}})
// CHECK: {
gpu.func @private_only() private(%arg0: memref<2xf32, 5>) {
gpu.return
}
// CHECK-LABEL: @empty_attribution
// CHECK: {
gpu.func @empty_attribution(%arg0: f32) workgroup() private() {
gpu.return
}
}
[mlir][gpu] Fix logic error in D79508 computing number of private attributions. Fix logic error in D79508. The old logic would make the first check in `GPUFuncOp::verifyBody` always pass.
2020-06-01 23:48:23 +08:00
gpu.module @explicit_attributions {
// CHECK-LABEL: gpu.func @kernel_1({{.*}}: f32, {{.*}}: memref<?xf32>) workgroup({{.*}}: memref<5xf32, 3>) private({{.*}}: memref<5xf32, 5>)
"gpu.func"() ( {
^bb0(%arg0: f32, %arg1: memref<?xf32>, %arg2: memref<5xf32, 3>, %arg3: memref<5xf32, 5>):
"gpu.return"() : () -> ()
} ) {gpu.kernel, sym_name = "kernel_1", type = (f32, memref<?xf32>) -> (), workgroup_attributions = 1: i64} : () -> ()
}
Add GPU async op interface and token type. See https://llvm.discourse.group/t/rfc-new-dialect-for-modelling-asynchronous-execution-at-a-higher-level/1345 Reviewed By: herhut Differential Revision: https://reviews.llvm.org/D88954
2020-10-08 19:43:18 +08:00
func @async_token(%arg0 : !gpu.async.token) -> !gpu.async.token {
// CHECK-LABEL: func @async_token({{.*}}: !gpu.async.token)
// CHECK: return {{.*}} : !gpu.async.token
return %arg0 : !gpu.async.token
}
[mlir][gpu] Add `gpu.wait` op. This combines two separate ops (D88972: `gpu.create_token`, D89043: `gpu.host_wait`) into one. I do after all like the idea of combining the two ops, because it matches exactly the pattern we are going to have in the other gpu ops that will implement the AsyncOpInterface (launch_func, copies, alloc): If the op is async, we return a !gpu.async.token. Otherwise, we synchronize with the host and don't return a token. The use cases for `gpu.wait async` and `gpu.wait` are further apart than those of e.g. `gpu.h2d async` and `gpu.h2d`, but I like the consistent meaning of the `async` keyword in GPU ops. Reviewed By: herhut Differential Revision: https://reviews.llvm.org/D89160
2020-10-13 23:21:59 +08:00
func @async_wait() {
// CHECK-LABEL: func @async_wait
// CHECK: %[[t0:.*]] = gpu.wait async
%0 = gpu.wait async
// CHECK: %[[t1:.*]] = gpu.wait async [%[[t0]]]
%1 = gpu.wait async [%0]
// CHECK: %{{.*}} = gpu.wait async [%[[t0]], %[[t1]]]
%2 = gpu.wait async [%0, %1]
// CHECK: gpu.wait [%[[t0]], %[[t1]]]
// CHECK-NOT: async
gpu.wait [%0, %1]
// CHECK: gpu.wait
// CHECK-NOT: async
gpu.wait // Valid, but a no-op.
return
}
Add the "gpu.launch_func" op to the GPU dialect. The idea is to lower `gpu.launch` operations into `gpu.launch_func` operations by outlining the kernel body into a function, which is closer to the NVVM model. -- PiperOrigin-RevId: 246806890
2019-05-06 20:01:12 +08:00
}