maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/mlir/test/Target/LLVMIR/rocdl.mlir

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

180 lines
11 KiB
MLIR
Raw Normal View History

[mlir] Use the interface-based translation for LLVM "intrinsic" dialects Port the translation of five dialects that define LLVM IR intrinsics (LLVMAVX512, LLVMArmNeon, LLVMArmSVE, NVVM, ROCDL) to the new dialect interface-based mechanism. This allows us to remove individual translations that were created for each of these dialects and just use one common MLIR-to-LLVM-IR translation that potentially supports all dialects instead, based on what is registered and including any combination of translatable dialects. This removal was one of the main goals of the refactoring. To support the addition of GPU-related metadata, the translation interface is extended with the `amendOperation` function that allows the interface implementation to post-process any translated operation with dialect attributes from the dialect for which the interface is implemented regardless of the operation's dialect. This is currently applied to "kernel" functions, but can be used to construct other metadata in dialect-specific ways without necessarily affecting operations. Depends On D96591, D96504 Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96592
2021-02-12 19:53:27 +08:00
// RUN: mlir-translate -mlir-to-llvmir %s | FileCheck %s
[ROCm] Adding ROCDL Dialect. This commit introduces the ROCDL Dialect (i.e. the ROCDL ops + the code to lower those ROCDL ops to LLWM intrinsics/functions). Think of ROCDL Dialect as analogous to the NVVM Dialect, but for AMD GPUs. This patch contains just the essentials needed to get a simple example up and running. We expect to make further additions to the ROCDL Dialect. This is the first of 3 commits, the follow-up will be: * add a pass that lowers GPU Dialect to ROCDL Dialect * add a "mlir-rocm-runner" utility Closes tensorflow/mlir#146 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/146 from deven-amd:deven-rocdl-dialect e78e8005c75a78912631116c78dc844fcc4b0de9 PiperOrigin-RevId: 271511259
2019-09-27 14:49:51 +08:00
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
llvm.func @rocdl_special_regs() -> i32 {
[ROCm] Adding ROCDL Dialect. This commit introduces the ROCDL Dialect (i.e. the ROCDL ops + the code to lower those ROCDL ops to LLWM intrinsics/functions). Think of ROCDL Dialect as analogous to the NVVM Dialect, but for AMD GPUs. This patch contains just the essentials needed to get a simple example up and running. We expect to make further additions to the ROCDL Dialect. This is the first of 3 commits, the follow-up will be: * add a pass that lowers GPU Dialect to ROCDL Dialect * add a "mlir-rocm-runner" utility Closes tensorflow/mlir#146 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/146 from deven-amd:deven-rocdl-dialect e78e8005c75a78912631116c78dc844fcc4b0de9 PiperOrigin-RevId: 271511259
2019-09-27 14:49:51 +08:00
// CHECK-LABEL: rocdl_special_regs
// CHECK: call i32 @llvm.amdgcn.workitem.id.x()
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
%1 = rocdl.workitem.id.x : i32
[ROCm] Adding ROCDL Dialect. This commit introduces the ROCDL Dialect (i.e. the ROCDL ops + the code to lower those ROCDL ops to LLWM intrinsics/functions). Think of ROCDL Dialect as analogous to the NVVM Dialect, but for AMD GPUs. This patch contains just the essentials needed to get a simple example up and running. We expect to make further additions to the ROCDL Dialect. This is the first of 3 commits, the follow-up will be: * add a pass that lowers GPU Dialect to ROCDL Dialect * add a "mlir-rocm-runner" utility Closes tensorflow/mlir#146 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/146 from deven-amd:deven-rocdl-dialect e78e8005c75a78912631116c78dc844fcc4b0de9 PiperOrigin-RevId: 271511259
2019-09-27 14:49:51 +08:00
// CHECK: call i32 @llvm.amdgcn.workitem.id.y()
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
%2 = rocdl.workitem.id.y : i32
[ROCm] Adding ROCDL Dialect. This commit introduces the ROCDL Dialect (i.e. the ROCDL ops + the code to lower those ROCDL ops to LLWM intrinsics/functions). Think of ROCDL Dialect as analogous to the NVVM Dialect, but for AMD GPUs. This patch contains just the essentials needed to get a simple example up and running. We expect to make further additions to the ROCDL Dialect. This is the first of 3 commits, the follow-up will be: * add a pass that lowers GPU Dialect to ROCDL Dialect * add a "mlir-rocm-runner" utility Closes tensorflow/mlir#146 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/146 from deven-amd:deven-rocdl-dialect e78e8005c75a78912631116c78dc844fcc4b0de9 PiperOrigin-RevId: 271511259
2019-09-27 14:49:51 +08:00
// CHECK: call i32 @llvm.amdgcn.workitem.id.z()
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
%3 = rocdl.workitem.id.z : i32
[ROCm] Adding ROCDL Dialect. This commit introduces the ROCDL Dialect (i.e. the ROCDL ops + the code to lower those ROCDL ops to LLWM intrinsics/functions). Think of ROCDL Dialect as analogous to the NVVM Dialect, but for AMD GPUs. This patch contains just the essentials needed to get a simple example up and running. We expect to make further additions to the ROCDL Dialect. This is the first of 3 commits, the follow-up will be: * add a pass that lowers GPU Dialect to ROCDL Dialect * add a "mlir-rocm-runner" utility Closes tensorflow/mlir#146 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/146 from deven-amd:deven-rocdl-dialect e78e8005c75a78912631116c78dc844fcc4b0de9 PiperOrigin-RevId: 271511259
2019-09-27 14:49:51 +08:00
// CHECK: call i32 @llvm.amdgcn.workgroup.id.x()
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
%4 = rocdl.workgroup.id.x : i32
[ROCm] Adding ROCDL Dialect. This commit introduces the ROCDL Dialect (i.e. the ROCDL ops + the code to lower those ROCDL ops to LLWM intrinsics/functions). Think of ROCDL Dialect as analogous to the NVVM Dialect, but for AMD GPUs. This patch contains just the essentials needed to get a simple example up and running. We expect to make further additions to the ROCDL Dialect. This is the first of 3 commits, the follow-up will be: * add a pass that lowers GPU Dialect to ROCDL Dialect * add a "mlir-rocm-runner" utility Closes tensorflow/mlir#146 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/146 from deven-amd:deven-rocdl-dialect e78e8005c75a78912631116c78dc844fcc4b0de9 PiperOrigin-RevId: 271511259
2019-09-27 14:49:51 +08:00
// CHECK: call i32 @llvm.amdgcn.workgroup.id.y()
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
%5 = rocdl.workgroup.id.y : i32
[ROCm] Adding ROCDL Dialect. This commit introduces the ROCDL Dialect (i.e. the ROCDL ops + the code to lower those ROCDL ops to LLWM intrinsics/functions). Think of ROCDL Dialect as analogous to the NVVM Dialect, but for AMD GPUs. This patch contains just the essentials needed to get a simple example up and running. We expect to make further additions to the ROCDL Dialect. This is the first of 3 commits, the follow-up will be: * add a pass that lowers GPU Dialect to ROCDL Dialect * add a "mlir-rocm-runner" utility Closes tensorflow/mlir#146 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/146 from deven-amd:deven-rocdl-dialect e78e8005c75a78912631116c78dc844fcc4b0de9 PiperOrigin-RevId: 271511259
2019-09-27 14:49:51 +08:00
// CHECK: call i32 @llvm.amdgcn.workgroup.id.z()
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
%6 = rocdl.workgroup.id.z : i32
[ROCm] Fix the return type for the device function calls from i32 to i64. This is matching what the runtime library is expecting. Closes tensorflow/mlir#171 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/171 from deven-amd:deven-rocdl-device-func-i64 80762629a8c34e844ebdc542b34dd783990db9db PiperOrigin-RevId: 273640767
2019-10-09 08:19:03 +08:00
// CHECK: call i64 @__ockl_get_local_size(i32 0)
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
%7 = rocdl.workgroup.dim.x : i64
[ROCm] Fix the return type for the device function calls from i32 to i64. This is matching what the runtime library is expecting. Closes tensorflow/mlir#171 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/171 from deven-amd:deven-rocdl-device-func-i64 80762629a8c34e844ebdc542b34dd783990db9db PiperOrigin-RevId: 273640767
2019-10-09 08:19:03 +08:00
// CHECK: call i64 @__ockl_get_local_size(i32 1)
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
%8 = rocdl.workgroup.dim.y : i64
[ROCm] Fix the return type for the device function calls from i32 to i64. This is matching what the runtime library is expecting. Closes tensorflow/mlir#171 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/171 from deven-amd:deven-rocdl-device-func-i64 80762629a8c34e844ebdc542b34dd783990db9db PiperOrigin-RevId: 273640767
2019-10-09 08:19:03 +08:00
// CHECK: call i64 @__ockl_get_local_size(i32 2)
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
%9 = rocdl.workgroup.dim.z : i64
[ROCm] Fix the return type for the device function calls from i32 to i64. This is matching what the runtime library is expecting. Closes tensorflow/mlir#171 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/171 from deven-amd:deven-rocdl-device-func-i64 80762629a8c34e844ebdc542b34dd783990db9db PiperOrigin-RevId: 273640767
2019-10-09 08:19:03 +08:00
// CHECK: call i64 @__ockl_get_global_size(i32 0)
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
%10 = rocdl.grid.dim.x : i64
[ROCm] Fix the return type for the device function calls from i32 to i64. This is matching what the runtime library is expecting. Closes tensorflow/mlir#171 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/171 from deven-amd:deven-rocdl-device-func-i64 80762629a8c34e844ebdc542b34dd783990db9db PiperOrigin-RevId: 273640767
2019-10-09 08:19:03 +08:00
// CHECK: call i64 @__ockl_get_global_size(i32 1)
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
%11 = rocdl.grid.dim.y : i64
[ROCm] Fix the return type for the device function calls from i32 to i64. This is matching what the runtime library is expecting. Closes tensorflow/mlir#171 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/171 from deven-amd:deven-rocdl-device-func-i64 80762629a8c34e844ebdc542b34dd783990db9db PiperOrigin-RevId: 273640767
2019-10-09 08:19:03 +08:00
// CHECK: call i64 @__ockl_get_global_size(i32 2)
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
%12 = rocdl.grid.dim.z : i64
llvm.return %1 : i32
[ROCm] Adding ROCDL Dialect. This commit introduces the ROCDL Dialect (i.e. the ROCDL ops + the code to lower those ROCDL ops to LLWM intrinsics/functions). Think of ROCDL Dialect as analogous to the NVVM Dialect, but for AMD GPUs. This patch contains just the essentials needed to get a simple example up and running. We expect to make further additions to the ROCDL Dialect. This is the first of 3 commits, the follow-up will be: * add a pass that lowers GPU Dialect to ROCDL Dialect * add a "mlir-rocm-runner" utility Closes tensorflow/mlir#146 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/146 from deven-amd:deven-rocdl-dialect e78e8005c75a78912631116c78dc844fcc4b0de9 PiperOrigin-RevId: 271511259
2019-09-27 14:49:51 +08:00
}
[mlir] Use target-specific GPU kernel attributes in lowering pipelines Until now, the GPU translation to NVVM or ROCDL intrinsics relied on the presence of the generic `gpu.kernel` attribute to attach additional LLVM IR metadata to the relevant functions. This would be problematic if each dialect were to handle the conversion of its own options, which is the intended direction for the translation infrastructure. Introduce `nvvm.kernel` and `rocdl.kernel` in addition to `gpu.kernel` and base translation on these new attributes instead. Reviewed By: herhut Differential Revision: https://reviews.llvm.org/D96591
2021-02-12 19:53:12 +08:00
llvm.func @kernel_func() attributes {rocdl.kernel} {
[ROCm] Adding ROCDL Dialect. This commit introduces the ROCDL Dialect (i.e. the ROCDL ops + the code to lower those ROCDL ops to LLWM intrinsics/functions). Think of ROCDL Dialect as analogous to the NVVM Dialect, but for AMD GPUs. This patch contains just the essentials needed to get a simple example up and running. We expect to make further additions to the ROCDL Dialect. This is the first of 3 commits, the follow-up will be: * add a pass that lowers GPU Dialect to ROCDL Dialect * add a "mlir-rocm-runner" utility Closes tensorflow/mlir#146 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/146 from deven-amd:deven-rocdl-dialect e78e8005c75a78912631116c78dc844fcc4b0de9 PiperOrigin-RevId: 271511259
2019-09-27 14:49:51 +08:00
// CHECK-LABEL: amdgpu_kernel void @kernel_func
llvm.return
}
[mlir][rocdl] add rocdl.barier op. - Add rocdl.barrier op. - Lower gpu.barier to rocdl.barrier in -convert-gpu-to-rocdl. Differential Revision: https://reviews.llvm.org/D79126
2020-05-04 16:32:16 +08:00
llvm.func @rocdl.barrier() {
// CHECK: fence syncscope("workgroup") release
// CHECK-NEXT: call void @llvm.amdgcn.s.barrier()
// CHECK-NEXT: fence syncscope("workgroup") acquire
rocdl.barrier
llvm.return
}
[mlir][rocdl] Add xdlops intrinsics to rocdl dialect Summary: This adds xdlops (mfma) to the rocdl dialect and also tests the translation to llvm ir. Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits Tags: #llvm #mlir Differential Revision: https://reviews.llvm.org/D79642
2020-05-09 02:20:47 +08:00
[mlir] replace LLVM dialect float types with built-ins Continue the convergence between LLVM dialect and built-in types by replacing the bfloat, half, float and double LLVM dialect types with their built-in counterparts. At the API level, this is a direct replacement. At the syntax level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively, to be compatible with the built-in type syntax. The old keywords can still be parsed but produce a deprecation warning and will be eventually removed. Depends On D94178 Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
llvm.func @rocdl.xdlops(%arg0 : f32, %arg1 : f32,
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
%arg2 : vector<32 x f32>, %arg3: i32,
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
%arg4 : vector<16 x f32>, %arg5 : vector<4xf32>,
%arg6 : vector<4xf16>, %arg7 : vector<32 x i32>,
%arg8 : vector<16 x i32>, %arg9 : vector<4xi32>,
%arg10 : vector<2xi16>) -> vector<32 x f32> {
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
%csti32 = llvm.mlir.constant(42 : i32) : i32
[mlir][rocdl] Add xdlops intrinsics to rocdl dialect Summary: This adds xdlops (mfma) to the rocdl dialect and also tests the translation to llvm ir. Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits Tags: #llvm #mlir Differential Revision: https://reviews.llvm.org/D79642
2020-05-09 02:20:47 +08:00
// CHECK-LABEL: rocdl.xdlops
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
// CHECK: call <32 x float> @llvm.amdgcn.mfma.f32.32x32x1f32(float %{{.*}}, float %{{.*}}, <32 x float> %{{.*}}, i32 {{.*}}, i32 {{.*}}, i32 {{.*}})
%r0 = rocdl.mfma.f32.32x32x1f32 %arg0, %arg1, %arg2, %csti32, %csti32, %csti32 :
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
(f32, f32, vector<32 x f32>,
i32, i32, i32) -> vector<32 x f32>
[mlir][rocdl] Add xdlops intrinsics to rocdl dialect Summary: This adds xdlops (mfma) to the rocdl dialect and also tests the translation to llvm ir. Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits Tags: #llvm #mlir Differential Revision: https://reviews.llvm.org/D79642
2020-05-09 02:20:47 +08:00
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
// CHECK: call <16 x float> @llvm.amdgcn.mfma.f32.16x16x1f32(float %{{.*}}, float %{{.*}}, <16 x float> %{{.*}}, i32 {{.*}}, i32 {{.*}}, i32 {{.*}})
%r1 = rocdl.mfma.f32.16x16x1f32 %arg0, %arg1, %arg4, %csti32, %csti32, %csti32 :
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
(f32, f32, vector<16 x f32>,
i32, i32, i32) -> vector<16 x f32>
[mlir][rocdl] Add xdlops intrinsics to rocdl dialect Summary: This adds xdlops (mfma) to the rocdl dialect and also tests the translation to llvm ir. Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits Tags: #llvm #mlir Differential Revision: https://reviews.llvm.org/D79642
2020-05-09 02:20:47 +08:00
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
// CHECK: call <4 x float> @llvm.amdgcn.mfma.f32.16x16x4f32(float %{{.*}}, float %{{.*}}, <4 x float> %{{.*}}, i32 {{.*}}, i32 {{.*}}, i32 {{.*}})
%r2 = rocdl.mfma.f32.16x16x4f32 %arg0, %arg1, %arg5, %csti32, %csti32, %csti32 :
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
(f32, f32, vector<4xf32>,
i32, i32, i32) -> vector<4xf32>
[mlir][rocdl] Add xdlops intrinsics to rocdl dialect Summary: This adds xdlops (mfma) to the rocdl dialect and also tests the translation to llvm ir. Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits Tags: #llvm #mlir Differential Revision: https://reviews.llvm.org/D79642
2020-05-09 02:20:47 +08:00
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
// CHECK: call <4 x float> @llvm.amdgcn.mfma.f32.4x4x1f32(float %{{.*}}, float %{{.*}}, <4 x float> %{{.*}}, i32 {{.*}}, i32 {{.*}}, i32 {{.*}})
%r3 = rocdl.mfma.f32.4x4x1f32 %arg0, %arg1, %arg5, %csti32, %csti32, %csti32 :
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
(f32, f32, vector<4xf32>,
i32, i32, i32) -> vector<4xf32>
[mlir][rocdl] Add xdlops intrinsics to rocdl dialect Summary: This adds xdlops (mfma) to the rocdl dialect and also tests the translation to llvm ir. Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits Tags: #llvm #mlir Differential Revision: https://reviews.llvm.org/D79642
2020-05-09 02:20:47 +08:00
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
// CHECK: call <16 x float> @llvm.amdgcn.mfma.f32.32x32x2f32(float %{{.*}}, float %{{.*}}, <16 x float> %{{.*}}, i32 {{.*}}, i32 {{.*}}, i32 {{.*}})
%r4= rocdl.mfma.f32.32x32x2f32 %arg0, %arg1, %arg4, %csti32, %csti32, %csti32 :
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
(f32, f32, vector<16 x f32>,
i32, i32, i32) -> vector<16 x f32>
[mlir][rocdl] Add xdlops intrinsics to rocdl dialect Summary: This adds xdlops (mfma) to the rocdl dialect and also tests the translation to llvm ir. Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits Tags: #llvm #mlir Differential Revision: https://reviews.llvm.org/D79642
2020-05-09 02:20:47 +08:00
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
// CHECK: call <32 x float> @llvm.amdgcn.mfma.f32.32x32x4f16(<4 x half> %{{.*}}, <4 x half> %{{.*}}, <32 x float> %{{.*}}, i32 {{.*}}, i32 {{.*}}, i32 {{.*}})
%r5 = rocdl.mfma.f32.32x32x4f16 %arg6, %arg6, %arg2, %csti32, %csti32, %csti32 :
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
(vector<4xf16>, vector<4xf16>, vector<32 x f32>,
i32, i32, i32) -> vector<32 x f32>
[mlir][rocdl] Add xdlops intrinsics to rocdl dialect Summary: This adds xdlops (mfma) to the rocdl dialect and also tests the translation to llvm ir. Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits Tags: #llvm #mlir Differential Revision: https://reviews.llvm.org/D79642
2020-05-09 02:20:47 +08:00
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
// CHECK: call <16 x float> @llvm.amdgcn.mfma.f32.16x16x4f16(<4 x half> %{{.*}}, <4 x half> %{{.*}}, <16 x float> %{{.*}}, i32 {{.*}}, i32 {{.*}}, i32 {{.*}})
%r6 = rocdl.mfma.f32.16x16x4f16 %arg6, %arg6, %arg4, %csti32, %csti32, %csti32 :
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
(vector<4xf16>, vector<4xf16>, vector<16 x f32>,
i32, i32, i32) -> vector<16 x f32>
[mlir][rocdl] Add xdlops intrinsics to rocdl dialect Summary: This adds xdlops (mfma) to the rocdl dialect and also tests the translation to llvm ir. Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits Tags: #llvm #mlir Differential Revision: https://reviews.llvm.org/D79642
2020-05-09 02:20:47 +08:00
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
// CHECK: call <4 x float> @llvm.amdgcn.mfma.f32.4x4x4f16(<4 x half> %{{.*}}, <4 x half> %{{.*}}, <4 x float> %{{.*}}, i32 {{.*}}, i32 {{.*}}, i32 {{.*}})
%r7 = rocdl.mfma.f32.4x4x4f16 %arg6, %arg6, %arg5, %csti32, %csti32, %csti32 :
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
(vector<4xf16>, vector<4xf16>, vector<4xf32>,
i32, i32, i32) -> vector<4xf32>
[mlir][rocdl] Add xdlops intrinsics to rocdl dialect Summary: This adds xdlops (mfma) to the rocdl dialect and also tests the translation to llvm ir. Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits Tags: #llvm #mlir Differential Revision: https://reviews.llvm.org/D79642
2020-05-09 02:20:47 +08:00
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
// CHECK: call <16 x float> @llvm.amdgcn.mfma.f32.32x32x8f16(<4 x half> %{{.*}}, <4 x half> %{{.*}}, <16 x float> %{{.*}}, i32 {{.*}}, i32 {{.*}}, i32 {{.*}})
%r8 = rocdl.mfma.f32.32x32x8f16 %arg6, %arg6, %arg4, %csti32, %csti32, %csti32 :
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
(vector<4xf16>, vector<4xf16>, vector<16 x f32>,
i32, i32, i32) -> vector<16 x f32>
[mlir][rocdl] Add xdlops intrinsics to rocdl dialect Summary: This adds xdlops (mfma) to the rocdl dialect and also tests the translation to llvm ir. Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits Tags: #llvm #mlir Differential Revision: https://reviews.llvm.org/D79642
2020-05-09 02:20:47 +08:00
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
// CHECK: call <4 x float> @llvm.amdgcn.mfma.f32.16x16x16f16(<4 x half> %{{.*}}, <4 x half> %{{.*}}, <4 x float> %{{.*}}, i32 {{.*}}, i32 {{.*}}, i32 {{.*}})
%r9 = rocdl.mfma.f32.16x16x16f16 %arg6, %arg6, %arg5, %csti32, %csti32, %csti32 :
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
(vector<4xf16>, vector<4xf16>, vector<4xf32>,
i32, i32, i32) -> vector<4xf32>
[mlir][rocdl] Add xdlops intrinsics to rocdl dialect Summary: This adds xdlops (mfma) to the rocdl dialect and also tests the translation to llvm ir. Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits Tags: #llvm #mlir Differential Revision: https://reviews.llvm.org/D79642
2020-05-09 02:20:47 +08:00
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
// CHECK: call <32 x i32> @llvm.amdgcn.mfma.i32.32x32x4i8(i32 %{{.*}}, i32 %{{.*}}, <32 x i32> %{{.*}}, i32 {{.*}}, i32 {{.*}}, i32 {{.*}})
%r10 = rocdl.mfma.i32.32x32x4i8 %arg3, %arg3, %arg7, %csti32, %csti32, %csti32 :
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
(i32, i32, vector<32 x i32>,
i32, i32, i32) -> vector<32 x i32>
[mlir][rocdl] Add xdlops intrinsics to rocdl dialect Summary: This adds xdlops (mfma) to the rocdl dialect and also tests the translation to llvm ir. Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits Tags: #llvm #mlir Differential Revision: https://reviews.llvm.org/D79642
2020-05-09 02:20:47 +08:00
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
// CHECK: call <16 x i32> @llvm.amdgcn.mfma.i32.16x16x4i8(i32 %{{.*}}, i32 %{{.*}}, <16 x i32> %{{.*}}, i32 {{.*}}, i32 {{.*}}, i32 {{.*}})
%r11 = rocdl.mfma.i32.16x16x4i8 %arg3, %arg3, %arg8, %csti32, %csti32, %csti32 :
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
(i32, i32, vector<16 x i32>,
i32, i32, i32) -> vector<16 x i32>
[mlir][rocdl] Add xdlops intrinsics to rocdl dialect Summary: This adds xdlops (mfma) to the rocdl dialect and also tests the translation to llvm ir. Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits Tags: #llvm #mlir Differential Revision: https://reviews.llvm.org/D79642
2020-05-09 02:20:47 +08:00
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
// CHECK: call <4 x i32> @llvm.amdgcn.mfma.i32.4x4x4i8(i32 %{{.*}}, i32 %{{.*}}, <4 x i32> %{{.*}}, i32 {{.*}}, i32 {{.*}}, i32 {{.*}})
%r12 = rocdl.mfma.i32.4x4x4i8 %arg3, %arg3, %arg9, %csti32, %csti32, %csti32 :
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
(i32, i32, vector<4xi32>,
i32, i32, i32) -> vector<4xi32>
[mlir][rocdl] Add xdlops intrinsics to rocdl dialect Summary: This adds xdlops (mfma) to the rocdl dialect and also tests the translation to llvm ir. Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits Tags: #llvm #mlir Differential Revision: https://reviews.llvm.org/D79642
2020-05-09 02:20:47 +08:00
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
// CHECK: call <16 x i32> @llvm.amdgcn.mfma.i32.32x32x8i8(i32 %{{.*}}, i32 %{{.*}}, <16 x i32> %{{.*}}, i32 {{.*}}, i32 {{.*}}, i32 {{.*}})
%r13 = rocdl.mfma.i32.32x32x8i8 %arg3, %arg3, %arg8, %csti32, %csti32, %csti32 :
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
(i32, i32, vector<16 x i32>,
i32, i32, i32) -> vector<16 x i32>
[mlir][rocdl] Add xdlops intrinsics to rocdl dialect Summary: This adds xdlops (mfma) to the rocdl dialect and also tests the translation to llvm ir. Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits Tags: #llvm #mlir Differential Revision: https://reviews.llvm.org/D79642
2020-05-09 02:20:47 +08:00
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
// CHECK: call <4 x i32> @llvm.amdgcn.mfma.i32.16x16x16i8(i32 %{{.*}}, i32 %{{.*}}, <4 x i32> %{{.*}}, i32 {{.*}}, i32 {{.*}}, i32 {{.*}})
%r14 = rocdl.mfma.i32.16x16x16i8 %arg3, %arg3, %arg9, %csti32, %csti32, %csti32 :
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
(i32, i32, vector<4xi32>,
i32, i32, i32) -> vector<4xi32>
[mlir][rocdl] Add xdlops intrinsics to rocdl dialect Summary: This adds xdlops (mfma) to the rocdl dialect and also tests the translation to llvm ir. Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits Tags: #llvm #mlir Differential Revision: https://reviews.llvm.org/D79642
2020-05-09 02:20:47 +08:00
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
// CHECK: call <32 x float> @llvm.amdgcn.mfma.f32.32x32x2bf16(<2 x i16> %{{.*}}, <2 x i16> %{{.*}}, <32 x float> %{{.*}}, i32 {{.*}}, i32 {{.*}}, i32 {{.*}})
%r15 = rocdl.mfma.f32.32x32x2bf16 %arg10, %arg10, %arg2, %csti32, %csti32, %csti32 :
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
(vector<2xi16>, vector<2xi16>, vector<32 x f32>,
i32, i32, i32) -> vector<32 x f32>
[mlir][rocdl] Add xdlops intrinsics to rocdl dialect Summary: This adds xdlops (mfma) to the rocdl dialect and also tests the translation to llvm ir. Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits Tags: #llvm #mlir Differential Revision: https://reviews.llvm.org/D79642
2020-05-09 02:20:47 +08:00
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
// CHECK: call <16 x float> @llvm.amdgcn.mfma.f32.16x16x2bf16(<2 x i16> %{{.*}}, <2 x i16> %{{.*}}, <16 x float> %{{.*}}, i32 {{.*}}, i32 {{.*}}, i32 {{.*}})
%r16 = rocdl.mfma.f32.16x16x2bf16 %arg10, %arg10, %arg4, %csti32, %csti32, %csti32 :
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
(vector<2xi16>, vector<2xi16>, vector<16 x f32>,
i32, i32, i32) -> vector<16 x f32>
[mlir][rocdl] Add xdlops intrinsics to rocdl dialect Summary: This adds xdlops (mfma) to the rocdl dialect and also tests the translation to llvm ir. Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits Tags: #llvm #mlir Differential Revision: https://reviews.llvm.org/D79642
2020-05-09 02:20:47 +08:00
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
// CHECK: call <4 x float> @llvm.amdgcn.mfma.f32.4x4x2bf16(<2 x i16> %{{.*}}, <2 x i16> %{{.*}}, <4 x float> %{{.*}}, i32 {{.*}}, i32 {{.*}}, i32 {{.*}})
%r17 = rocdl.mfma.f32.4x4x2bf16 %arg10, %arg10, %arg5, %csti32, %csti32, %csti32 :
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
(vector<2xi16>, vector<2xi16>, vector<4xf32>,
i32, i32, i32) -> vector<4xf32>
[mlir][rocdl] Add xdlops intrinsics to rocdl dialect Summary: This adds xdlops (mfma) to the rocdl dialect and also tests the translation to llvm ir. Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits Tags: #llvm #mlir Differential Revision: https://reviews.llvm.org/D79642
2020-05-09 02:20:47 +08:00
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
// CHECK: call <16 x float> @llvm.amdgcn.mfma.f32.32x32x4bf16(<2 x i16> %{{.*}}, <2 x i16> %{{.*}}, <16 x float> %{{.*}}, i32 {{.*}}, i32 {{.*}}, i32 {{.*}})
%r18 = rocdl.mfma.f32.32x32x4bf16 %arg10, %arg10, %arg4, %csti32, %csti32, %csti32 :
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
(vector<2xi16>, vector<2xi16>, vector<16 x f32>,
i32, i32, i32) -> vector<16 x f32>
[mlir][rocdl] Add xdlops intrinsics to rocdl dialect Summary: This adds xdlops (mfma) to the rocdl dialect and also tests the translation to llvm ir. Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits Tags: #llvm #mlir Differential Revision: https://reviews.llvm.org/D79642
2020-05-09 02:20:47 +08:00
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
// CHECK: call <4 x float> @llvm.amdgcn.mfma.f32.16x16x8bf16(<2 x i16> %{{.*}}, <2 x i16> %{{.*}}, <4 x float> %{{.*}}, i32 {{.*}}, i32 {{.*}}, i32 {{.*}})
%r19 = rocdl.mfma.f32.16x16x8bf16 %arg10, %arg10, %arg5, %csti32, %csti32, %csti32 :
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
(vector<2xi16>, vector<2xi16>, vector<4xf32>,
i32, i32, i32) -> vector<4xf32>
[mlir][rocdl] Add xdlops intrinsics to rocdl dialect Summary: This adds xdlops (mfma) to the rocdl dialect and also tests the translation to llvm ir. Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits Tags: #llvm #mlir Differential Revision: https://reviews.llvm.org/D79642
2020-05-09 02:20:47 +08:00
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
llvm.return %r0 : vector<32 x f32>
[mlir][rocdl] Add xdlops intrinsics to rocdl dialect Summary: This adds xdlops (mfma) to the rocdl dialect and also tests the translation to llvm ir. Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits Tags: #llvm #mlir Differential Revision: https://reviews.llvm.org/D79642
2020-05-09 02:20:47 +08:00
}
[mlir][rocdl] Exposing buffer load/store intrinsic Summary: * Updated ROCDLOps tablegen * Added parsing and printing function for new intrinsic * Added unit tests Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, jurahul, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80233
2020-05-20 03:59:58 +08:00
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
llvm.func @rocdl.mubuf(%rsrc : vector<4xi32>, %vindex : i32,
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
%offset : i32, %vdata1 : vector<1xf32>,
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
%vdata2 : vector<2xf32>, %vdata4 : vector<4xf32>) {
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
%glc = llvm.mlir.constant(false) : i1
%slc = llvm.mlir.constant(true) : i1
[mlir][rocdl] Exposing buffer load/store intrinsic Summary: * Updated ROCDLOps tablegen * Added parsing and printing function for new intrinsic * Added unit tests Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, jurahul, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80233
2020-05-20 03:59:58 +08:00
// CHECK-LABEL: rocdl.mubuf
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
// CHECK: call <1 x float> @llvm.amdgcn.buffer.load.v1f32(<4 x i32> %{{.*}}, i32 %{{.*}}, i32 %{{.*}}, i1 {{.*}}, i1 {{.*}})
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
%r1 = rocdl.buffer.load %rsrc, %vindex, %offset, %glc, %slc : vector<1xf32>
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
// CHECK: call <2 x float> @llvm.amdgcn.buffer.load.v2f32(<4 x i32> %{{.*}}, i32 %{{.*}}, i32 %{{.*}}, i1 {{.*}}, i1 {{.*}})
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
%r2 = rocdl.buffer.load %rsrc, %vindex, %offset, %glc, %slc : vector<2xf32>
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
// CHECK: call <4 x float> @llvm.amdgcn.buffer.load.v4f32(<4 x i32> %{{.*}}, i32 %{{.*}}, i32 %{{.*}}, i1 {{.*}}, i1 {{.*}})
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
%r4 = rocdl.buffer.load %rsrc, %vindex, %offset, %glc, %slc : vector<4xf32>
[mlir][rocdl] Exposing buffer load/store intrinsic Summary: * Updated ROCDLOps tablegen * Added parsing and printing function for new intrinsic * Added unit tests Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, jurahul, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80233
2020-05-20 03:59:58 +08:00
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
// CHECK: call void @llvm.amdgcn.buffer.store.v1f32(<1 x float> %{{.*}}, <4 x i32> %{{.*}}, i32 %{{.*}}, i32 %{{.*}}, i1 {{.*}}, i1 {{.*}})
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
rocdl.buffer.store %vdata1, %rsrc, %vindex, %offset, %glc, %slc : vector<1xf32>
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
// CHECK: call void @llvm.amdgcn.buffer.store.v2f32(<2 x float> %{{.*}}, <4 x i32> %{{.*}}, i32 %{{.*}}, i32 %{{.*}}, i1 {{.*}}, i1 {{.*}})
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
rocdl.buffer.store %vdata2, %rsrc, %vindex, %offset, %glc, %slc : vector<2xf32>
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
// CHECK: call void @llvm.amdgcn.buffer.store.v4f32(<4 x float> %{{.*}}, <4 x i32> %{{.*}}, i32 %{{.*}}, i32 %{{.*}}, i1 {{.*}}, i1 {{.*}})
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
rocdl.buffer.store %vdata4, %rsrc, %vindex, %offset, %glc, %slc : vector<4xf32>
[mlir][rocdl] Exposing buffer load/store intrinsic Summary: * Updated ROCDLOps tablegen * Added parsing and printing function for new intrinsic * Added unit tests Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, jurahul, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80233
2020-05-20 03:59:58 +08:00
llvm.return
}