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

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

170 lines
12 KiB
MLIR
Raw Normal View History

Lower vector transfer ops to loop.for operations. This allows mixing linalg operations with vector transfer operations (with additional modifications to affine ops) and is a step towards solving tensorflow/mlir#189. PiperOrigin-RevId: 275543361
2019-10-19 05:09:42 +08:00
// RUN: mlir-opt %s -convert-linalg-to-llvm | FileCheck %s
Unify Linalg types by using strided memrefs This CL finishes the implementation of the Linalg + Affine type unification of the [strided memref RFC](https://groups.google.com/a/tensorflow.org/forum/#!topic/mlir/MaL8m2nXuio). As a consequence, the !linalg.view type, linalg::DimOp, linalg::LoadOp and linalg::StoreOp can now disappear and Linalg can use standard types everywhere. PiperOrigin-RevId: 272187165
2019-10-01 20:22:54 +08:00
Add a primitive linalg-lower-to-llvm-dialect pass This CL builds upon ftynse@'s Linalg dialect conversion (in examples/Linalg/Linalg1) and updates it to support buffers and the fully composed form of view and slice operations. A new BufferSizeOp is introduced for the purpose of extracting the size information from a buffer. This will be useful in a followup CL for an end-to-end LLVM execution path where mlir-cpu-runner will allocate a buffer. -- PiperOrigin-RevId: 246358593
2019-05-03 02:36:52 +08:00
func @range(%arg0: index) {
%c0 = constant 0 : index
%c1 = constant 1 : index
%R = linalg.range %c0:%arg0:%c1 : !linalg.range
return
}
[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
// CHECK-LABEL: func @range(%{{.*}}: i64) {
// CHECK: llvm.mlir.constant(0 : index) : i64
// CHECK-NEXT: llvm.mlir.constant(1 : index) : i64
[mlir] switch the modeling of LLVM types to use the new mechanism A new first-party modeling for LLVM IR types in the LLVM dialect has been developed in parallel to the existing modeling based on wrapping LLVM `Type *` instances. It resolves the long-standing problem of modeling identified structure types, including recursive structures, and enables future removal of LLVMContext and related locking mechanisms from LLVMDialect. This commit only switches the modeling by (a) renaming LLVMTypeNew to LLVMType, (b) removing the old implementaiton of LLVMType, and (c) updating the tests. It is intentionally minimal. Separate commits will remove the infrastructure built for the transition and update API uses where appropriate. Depends On D85020 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D85021
2020-08-04 17:37:50 +08:00
// CHECK-NEXT: llvm.mlir.undef : !llvm.struct<(i64, i64, i64)>
// CHECK-NEXT: llvm.insertvalue %{{.*}}, %{{.*}}[0] : !llvm.struct<(i64, i64, i64)>
// CHECK-NEXT: llvm.insertvalue %{{.*}}, %{{.*}}[1] : !llvm.struct<(i64, i64, i64)>
// CHECK-NEXT: llvm.insertvalue %{{.*}}, %{{.*}}[2] : !llvm.struct<(i64, i64, i64)>
Add a primitive linalg-lower-to-llvm-dialect pass This CL builds upon ftynse@'s Linalg dialect conversion (in examples/Linalg/Linalg1) and updates it to support buffers and the fully composed form of view and slice operations. A new BufferSizeOp is introduced for the purpose of extracting the size information from a buffer. This will be useful in a followup CL for an end-to-end LLVM execution path where mlir-cpu-runner will allocate a buffer. -- PiperOrigin-RevId: 246358593
2019-05-03 02:36:52 +08:00
Update Linalg to use std.view Now that a view op has graduated to the std dialect, we can update Linalg to use it and remove ops that have become obsolete. As a byproduct, the linalg buffer and associated ops can also disappear. PiperOrigin-RevId: 279073591
2019-11-07 22:32:39 +08:00
func @slice(%arg0: memref<?xf32, offset: ?, strides: [1]>, %arg1: !linalg.range) {
%1 = linalg.slice %arg0[%arg1] : memref<?xf32, offset: ?, strides: [1]>, !linalg.range, memref<?xf32, offset: ?, strides: [1]>
Add a primitive linalg-lower-to-llvm-dialect pass This CL builds upon ftynse@'s Linalg dialect conversion (in examples/Linalg/Linalg1) and updates it to support buffers and the fully composed form of view and slice operations. A new BufferSizeOp is introduced for the purpose of extracting the size information from a buffer. This will be useful in a followup CL for an end-to-end LLVM execution path where mlir-cpu-runner will allocate a buffer. -- PiperOrigin-RevId: 246358593
2019-05-03 02:36:52 +08:00
return
}
Refactor linalg lowering to LLVM The linalg.view type used to be lowered to a struct containing a data pointer, offset, sizes/strides information. This was problematic when passing to external functions due to ABI, struct padding and alignment issues. The linalg.view type is now lowered to LLVMIR as a *pointer* to a struct containing the data pointer, offset and sizes/strides. This simplifies the interfacing with external library functions and makes it trivial to add new functions without creating a shim that would go from a value type struct to a pointer type. The consequences are that: 1. lowering explicitly uses llvm.alloca in lieu of llvm.undef and performs the proper llvm.load/llvm.store where relevant. 2. the shim creation function `getLLVMLibraryCallDefinition` disappears. 3. views are passed by pointer, scalars are passed by value. In the future, other structs will be passed by pointer (on a per-need basis). PiperOrigin-RevId: 264183671
2019-08-20 01:21:15 +08:00
// CHECK-LABEL: func @slice
Simplify Linalg ABI integration with external function calls. View descriptors are converted to *pointer to* LLVM struct to avoid ABI issues related to C struct packing. This creates unnecessary complexity and hampers unification with memrefs. Instead, this CL makes view descriptors convert to LLVM struct (as it was originally) and promotes all structs to pointers right before calling an external function. PiperOrigin-RevId: 267602693
2019-09-06 23:30:54 +08:00
// insert data ptr for slice op
[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
// CHECK: llvm.extractvalue %{{.*}}[4, 0] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<1 x i64>, array<1 x i64>)>
// CHECK-NEXT: llvm.extractvalue %{{.*}}[2] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<1 x i64>, array<1 x i64>)>
[mlir] switch the modeling of LLVM types to use the new mechanism A new first-party modeling for LLVM IR types in the LLVM dialect has been developed in parallel to the existing modeling based on wrapping LLVM `Type *` instances. It resolves the long-standing problem of modeling identified structure types, including recursive structures, and enables future removal of LLVMContext and related locking mechanisms from LLVMDialect. This commit only switches the modeling by (a) renaming LLVMTypeNew to LLVMType, (b) removing the old implementaiton of LLVMType, and (c) updating the tests. It is intentionally minimal. Separate commits will remove the infrastructure built for the transition and update API uses where appropriate. Depends On D85020 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D85021
2020-08-04 17:37:50 +08:00
// CHECK-NEXT: llvm.extractvalue %{{.*}}[0] : !llvm.struct<(i64, i64, i64)>
[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
// CHECK-NEXT: llvm.mul %{{.*}}, %{{.*}} : i64
// CHECK-NEXT: llvm.add %{{.*}}, %{{.*}} : i64
Avoid overflow when lowering linalg.slice linalg.subview used to lower to a slice with a bounded range resulting in correct bounded accesses. However linalg.slice could still index out of bounds. This CL moves the bounding to linalg.slice. LLVM select and cmp ops gain a more idiomatic builder. PiperOrigin-RevId: 264897125
2019-08-23 03:46:30 +08:00
// insert offset
[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
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[1] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<1 x i64>, array<1 x i64>)>
// CHECK-NEXT: llvm.insertvalue %{{.*}}, %{{.*}}[2] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<1 x i64>, array<1 x i64>)>
Unify Linalg types by using strided memrefs This CL finishes the implementation of the Linalg + Affine type unification of the [strided memref RFC](https://groups.google.com/a/tensorflow.org/forum/#!topic/mlir/MaL8m2nXuio). As a consequence, the !linalg.view type, linalg::DimOp, linalg::LoadOp and linalg::StoreOp can now disappear and Linalg can use standard types everywhere. PiperOrigin-RevId: 272187165
2019-10-01 20:22:54 +08:00
// CHECK-NEXT: llvm.mlir.constant(0 : index)
[mlir] switch the modeling of LLVM types to use the new mechanism A new first-party modeling for LLVM IR types in the LLVM dialect has been developed in parallel to the existing modeling based on wrapping LLVM `Type *` instances. It resolves the long-standing problem of modeling identified structure types, including recursive structures, and enables future removal of LLVMContext and related locking mechanisms from LLVMDialect. This commit only switches the modeling by (a) renaming LLVMTypeNew to LLVMType, (b) removing the old implementaiton of LLVMType, and (c) updating the tests. It is intentionally minimal. Separate commits will remove the infrastructure built for the transition and update API uses where appropriate. Depends On D85020 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D85021
2020-08-04 17:37:50 +08:00
// CHECK-NEXT: llvm.extractvalue %{{.*}}[0] : !llvm.struct<(i64, i64, i64)>
// CHECK-NEXT: llvm.extractvalue %{{.*}}[1] : !llvm.struct<(i64, i64, i64)>
// CHECK-NEXT: llvm.extractvalue %{{.*}}[2] : !llvm.struct<(i64, i64, i64)>
Avoid overflow when lowering linalg.slice linalg.subview used to lower to a slice with a bounded range resulting in correct bounded accesses. However linalg.slice could still index out of bounds. This CL moves the bounding to linalg.slice. LLVM select and cmp ops gain a more idiomatic builder. PiperOrigin-RevId: 264897125
2019-08-23 03:46:30 +08:00
// get size[0] from parent view
[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
// CHECK-NEXT: llvm.extractvalue %{{.*}}[3, 0] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<1 x i64>, array<1 x i64>)>
[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
// CHECK-NEXT: llvm.icmp "slt" %{{.*}}, %{{.*}} : i64
// CHECK-NEXT: llvm.select %{{.*}}, %{{.*}}, %{{.*}} : i1, i64
Avoid overflow when lowering linalg.slice linalg.subview used to lower to a slice with a bounded range resulting in correct bounded accesses. However linalg.slice could still index out of bounds. This CL moves the bounding to linalg.slice. LLVM select and cmp ops gain a more idiomatic builder. PiperOrigin-RevId: 264897125
2019-08-23 03:46:30 +08:00
// compute size[0] bounded by parent view's size[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
// CHECK-NEXT: llvm.sub %{{.*}}, %{{.*}} : i64
Avoid overflow when lowering linalg.slice linalg.subview used to lower to a slice with a bounded range resulting in correct bounded accesses. However linalg.slice could still index out of bounds. This CL moves the bounding to linalg.slice. LLVM select and cmp ops gain a more idiomatic builder. PiperOrigin-RevId: 264897125
2019-08-23 03:46:30 +08:00
// bound below by 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
// CHECK-NEXT: llvm.icmp "slt" %{{.*}}, %{{.*}} : i64
// CHECK-NEXT: llvm.select %{{.*}}, %{{.*}}, %{{.*}} : i1, i64
Avoid overflow when lowering linalg.slice linalg.subview used to lower to a slice with a bounded range resulting in correct bounded accesses. However linalg.slice could still index out of bounds. This CL moves the bounding to linalg.slice. LLVM select and cmp ops gain a more idiomatic builder. PiperOrigin-RevId: 264897125
2019-08-23 03:46:30 +08:00
// compute stride[0] using bounded size
[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
// CHECK-NEXT: llvm.mul %{{.*}}, %{{.*}} : i64
Avoid overflow when lowering linalg.slice linalg.subview used to lower to a slice with a bounded range resulting in correct bounded accesses. However linalg.slice could still index out of bounds. This CL moves the bounding to linalg.slice. LLVM select and cmp ops gain a more idiomatic builder. PiperOrigin-RevId: 264897125
2019-08-23 03:46:30 +08:00
// insert size and stride
[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
// CHECK-NEXT: llvm.insertvalue %{{.*}}, %{{.*}}[3, 0] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<1 x i64>, array<1 x i64>)>
// CHECK-NEXT: llvm.insertvalue %{{.*}}, %{{.*}}[4, 0] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<1 x i64>, array<1 x i64>)>
Add a primitive linalg-lower-to-llvm-dialect pass This CL builds upon ftynse@'s Linalg dialect conversion (in examples/Linalg/Linalg1) and updates it to support buffers and the fully composed form of view and slice operations. A new BufferSizeOp is introduced for the purpose of extracting the size information from a buffer. This will be useful in a followup CL for an end-to-end LLVM execution path where mlir-cpu-runner will allocate a buffer. -- PiperOrigin-RevId: 246358593
2019-05-03 02:36:52 +08:00
Deprecate linalg.subview in favor of std.subview This CL uses the now standard std.subview in linalg. Two shortcuts are currently taken to allow this port: 1. the type resulting from a view is currently degraded to fully dynamic to pass the SubViewOp verifier. 2. indexing into SubViewOp may access out of bounds since lowering to LLVM does not currently enforce it by construction. These will be fixed in subsequent commits after discussions. PiperOrigin-RevId: 280250129
2019-11-14 04:09:40 +08:00
func @slice_with_range_and_index(%arg0: memref<?x?xf64, offset: ?, strides: [?, 1]>) {
Fix indexing issue in lowering of linalg.slice This CL fixes the stepping through operands when emitting the view sizes of linalg.slice to LLVMIR. This is now consistent with the strides emission. A relevant test is added. Fix suggested by Alex Zinenko, thanks! PiperOrigin-RevId: 263150922
2019-08-14 00:20:06 +08:00
%c0 = constant 0 : index
%c1 = constant 1 : index
%R = linalg.range %c0:%c1:%c1 : !linalg.range
[mlir] Change dialect namespace loop->scf All ops of the SCF dialect now use the `scf.` prefix instead of `loop.`. This is a part of dialect renaming. Differential Revision: https://reviews.llvm.org/D79844
2020-05-13 18:12:30 +08:00
scf.for %i0 = %c0 to %c1 step %c1 {
Add syntactic sugar for strided memref parsing. This CL implements the last remaining bit of the [strided memref proposal](https://groups.google.com/a/tensorflow.org/forum/#!topic/mlir/MaL8m2nXuio). The syntax is a bit more explicit than what was originally proposed and resembles: `memref<?x?xf32, offset: 0 strides: [?, 1]>` Nonnegative strides and offsets are currently supported. Future extensions will include negative strides. This also gives a concrete example of syntactic sugar for the ([RFC] Proposed Changes to MemRef and Tensor MLIR Types)[https://groups.google.com/a/tensorflow.org/forum/#!topic/mlir/-wKHANzDNTg]. The underlying implementation still uses AffineMap layout. PiperOrigin-RevId: 272717437
2019-10-04 03:33:47 +08:00
%1 = linalg.slice %arg0[%i0, %R] : memref<?x?xf64, offset: ?, strides: [?, 1]>, index, !linalg.range, memref<?xf64, offset: ?, strides: [1]>
Fix indexing issue in lowering of linalg.slice This CL fixes the stepping through operands when emitting the view sizes of linalg.slice to LLVMIR. This is now consistent with the strides emission. A relevant test is added. Fix suggested by Alex Zinenko, thanks! PiperOrigin-RevId: 263150922
2019-08-14 00:20:06 +08:00
}
return
}
Deprecate linalg.subview in favor of std.subview This CL uses the now standard std.subview in linalg. Two shortcuts are currently taken to allow this port: 1. the type resulting from a view is currently degraded to fully dynamic to pass the SubViewOp verifier. 2. indexing into SubViewOp may access out of bounds since lowering to LLVM does not currently enforce it by construction. These will be fixed in subsequent commits after discussions. PiperOrigin-RevId: 280250129
2019-11-14 04:09:40 +08:00
// CHECK-LABEL: func @slice_with_range_and_index
Simplify Linalg ABI integration with external function calls. View descriptors are converted to *pointer to* LLVM struct to avoid ABI issues related to C struct packing. This creates unnecessary complexity and hampers unification with memrefs. Instead, this CL makes view descriptors convert to LLVM struct (as it was originally) and promotes all structs to pointers right before calling an external function. PiperOrigin-RevId: 267602693
2019-09-06 23:30:54 +08:00
// loop-body.
[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
// CHECK: llvm.mlir.undef : !llvm.struct<(ptr<f64>, ptr<f64>, i64, array<1 x i64>, array<1 x i64>)>
// CHECK: llvm.extractvalue %{{.*}}[4, 0] : !llvm.struct<(ptr<f64>, ptr<f64>, i64, array<2 x i64>, array<2 x i64>)>
// CHECK: llvm.extractvalue %{{.*}}[4, 1] : !llvm.struct<(ptr<f64>, ptr<f64>, i64, array<2 x i64>, array<2 x i64>)>
// CHECK: llvm.extractvalue %{{.*}}[2] : !llvm.struct<(ptr<f64>, ptr<f64>, i64, array<2 x i64>, array<2 x i64>)>
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[0] : !llvm.struct<(ptr<f64>, ptr<f64>, i64, array<1 x i64>, array<1 x i64>)>
// CHECK: llvm.insertvalue %{{.*}}[2] : !llvm.struct<(ptr<f64>, ptr<f64>, i64, array<1 x i64>, array<1 x i64>)>
[mlir] switch the modeling of LLVM types to use the new mechanism A new first-party modeling for LLVM IR types in the LLVM dialect has been developed in parallel to the existing modeling based on wrapping LLVM `Type *` instances. It resolves the long-standing problem of modeling identified structure types, including recursive structures, and enables future removal of LLVMContext and related locking mechanisms from LLVMDialect. This commit only switches the modeling by (a) renaming LLVMTypeNew to LLVMType, (b) removing the old implementaiton of LLVMType, and (c) updating the tests. It is intentionally minimal. Separate commits will remove the infrastructure built for the transition and update API uses where appropriate. Depends On D85020 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D85021
2020-08-04 17:37:50 +08:00
// CHECK: llvm.extractvalue %{{.*}}[0] : !llvm.struct<(i64, i64, i64)>
// CHECK: llvm.extractvalue %{{.*}}[1] : !llvm.struct<(i64, i64, i64)>
[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
// CHECK: llvm.insertvalue %{{.*}}[3, 0] : !llvm.struct<(ptr<f64>, ptr<f64>, i64, array<1 x i64>, array<1 x i64>)>
// CHECK: llvm.insertvalue %{{.*}}[4, 0] : !llvm.struct<(ptr<f64>, ptr<f64>, i64, array<1 x i64>, array<1 x i64>)>
Add lowering of linalg.copy to an external C++ library and a test. This CL extends support for lowering of linalg to external C++ libraries with CopyOp. Currently this can only work when the permutation maps in the copies are identity. Future support for permutations will be added later. PiperOrigin-RevId: 265093025
2019-08-24 02:08:59 +08:00
[mlir][Linalg] Add folders and canonicalizers for linalg.reshape/linalg.tensor_reshape operations. Differential Revision: https://reviews.llvm.org/D79765
2020-05-13 13:50:44 +08:00
func @reshape_static_expand(%arg0: memref<3x4x5xf32>) -> memref<1x3x4x1x5xf32> {
// Reshapes that expand a contiguous tensor with some 1's.
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
%0 = linalg.reshape %arg0 [affine_map<(i, j, k, l, m) -> (i, j)>,
affine_map<(i, j, k, l, m) -> (k)>,
affine_map<(i, j, k, l, m) -> (l, m)>] :
[mlir][Linalg] Lower linalg.reshape to LLVM for the static case Summary: This diff adds lowering of the linalg.reshape op to LLVM. A new descriptor is created with fields initialized as follows: 1. allocatedPTr, alignedPtr and offset are copied from the source descriptor 2. sizes are copied from the static destination shape 3. strides are copied from the static strides collected with `getStridesAndOffset` Only the static case in which the target view conforms to strided memref semantics is supported. Other cases are left for future work and will be added on a per-need basis. Reviewers: ftynse, mravishankar Subscribers: mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72316
2020-01-06 08:37:56 +08:00
memref<3x4x5xf32> into memref<1x3x4x1x5xf32>
[mlir][Linalg] Add folders and canonicalizers for linalg.reshape/linalg.tensor_reshape operations. Differential Revision: https://reviews.llvm.org/D79765
2020-05-13 13:50:44 +08:00
return %0 : memref<1x3x4x1x5xf32>
}
// CHECK-LABEL: func @reshape_static_expand
[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
// CHECK: llvm.mlir.undef : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<5 x i64>, array<5 x i64>)>
// CHECK: llvm.extractvalue %{{.*}}[0] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<3 x i64>, array<3 x i64>)>
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[0] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<5 x i64>, array<5 x i64>)>
// CHECK: llvm.extractvalue %{{.*}}[1] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<3 x i64>, array<3 x i64>)>
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[1] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<5 x i64>, array<5 x i64>)>
// CHECK: llvm.extractvalue %{{.*}}[2] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<3 x i64>, array<3 x i64>)>
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[2] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<5 x i64>, array<5 x i64>)>
[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
// CHECK: llvm.mlir.constant(1 : index) : i64
[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
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[3, 0] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<5 x i64>, array<5 x i64>)>
[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
// CHECK: llvm.mlir.constant(3 : index) : i64
[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
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[3, 1] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<5 x i64>, array<5 x i64>)>
[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
// CHECK: llvm.mlir.constant(4 : index) : i64
[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
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[3, 2] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<5 x i64>, array<5 x i64>)>
[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
// CHECK: llvm.mlir.constant(1 : index) : i64
[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
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[3, 3] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<5 x i64>, array<5 x i64>)>
[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
// CHECK: llvm.mlir.constant(5 : index) : i64
[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
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[3, 4] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<5 x i64>, array<5 x i64>)>
[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
// CHECK: llvm.mlir.constant(60 : index) : i64
[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
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[4, 0] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<5 x i64>, array<5 x i64>)>
[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
// CHECK: llvm.mlir.constant(20 : index) : i64
[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
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[4, 1] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<5 x i64>, array<5 x i64>)>
[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
// CHECK: llvm.mlir.constant(5 : index) : i64
[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
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[4, 2] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<5 x i64>, array<5 x i64>)>
[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
// CHECK: llvm.mlir.constant(5 : index) : i64
[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
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[4, 3] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<5 x i64>, array<5 x i64>)>
[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
// CHECK: llvm.mlir.constant(1 : index) : i64
[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
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[4, 4] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<5 x i64>, array<5 x i64>)>
[mlir][Linalg] Add folders and canonicalizers for linalg.reshape/linalg.tensor_reshape operations. Differential Revision: https://reviews.llvm.org/D79765
2020-05-13 13:50:44 +08:00
func @reshape_static_collapse(%arg0: memref<1x3x4x1x5xf32>) -> memref<3x4x5xf32> {
%0 = linalg.reshape %arg0 [affine_map<(i, j, k, l, m) -> (i, j)>,
affine_map<(i, j, k, l, m) -> (k)>,
affine_map<(i, j, k, l, m) -> (l, m)>] :
[mlir][Linalg] Lower linalg.reshape to LLVM for the static case Summary: This diff adds lowering of the linalg.reshape op to LLVM. A new descriptor is created with fields initialized as follows: 1. allocatedPTr, alignedPtr and offset are copied from the source descriptor 2. sizes are copied from the static destination shape 3. strides are copied from the static strides collected with `getStridesAndOffset` Only the static case in which the target view conforms to strided memref semantics is supported. Other cases are left for future work and will be added on a per-need basis. Reviewers: ftynse, mravishankar Subscribers: mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72316
2020-01-06 08:37:56 +08:00
memref<1x3x4x1x5xf32> into memref<3x4x5xf32>
[mlir][Linalg] Add folders and canonicalizers for linalg.reshape/linalg.tensor_reshape operations. Differential Revision: https://reviews.llvm.org/D79765
2020-05-13 13:50:44 +08:00
return %0 : memref<3x4x5xf32>
[mlir][Linalg] Lower linalg.reshape to LLVM for the static case Summary: This diff adds lowering of the linalg.reshape op to LLVM. A new descriptor is created with fields initialized as follows: 1. allocatedPTr, alignedPtr and offset are copied from the source descriptor 2. sizes are copied from the static destination shape 3. strides are copied from the static strides collected with `getStridesAndOffset` Only the static case in which the target view conforms to strided memref semantics is supported. Other cases are left for future work and will be added on a per-need basis. Reviewers: ftynse, mravishankar Subscribers: mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72316
2020-01-06 08:37:56 +08:00
}
[mlir][Linalg] Add folders and canonicalizers for linalg.reshape/linalg.tensor_reshape operations. Differential Revision: https://reviews.llvm.org/D79765
2020-05-13 13:50:44 +08:00
// CHECK-LABEL: func @reshape_static_collapse
[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
// CHECK: llvm.mlir.undef : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<3 x i64>, array<3 x i64>)>
// CHECK: llvm.extractvalue %{{.*}}[0] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<5 x i64>, array<5 x i64>)>
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[0] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<3 x i64>, array<3 x i64>)>
// CHECK: llvm.extractvalue %{{.*}}[1] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<5 x i64>, array<5 x i64>)>
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[1] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<3 x i64>, array<3 x i64>)>
// CHECK: llvm.extractvalue %{{.*}}[2] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<5 x i64>, array<5 x i64>)>
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[2] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<3 x i64>, array<3 x i64>)>
[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
// CHECK: llvm.mlir.constant(3 : index) : i64
[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
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[3, 0] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<3 x i64>, array<3 x i64>)>
[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
// CHECK: llvm.mlir.constant(4 : index) : i64
[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
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[3, 1] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<3 x i64>, array<3 x i64>)>
[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
// CHECK: llvm.mlir.constant(5 : index) : i64
[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
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[3, 2] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<3 x i64>, array<3 x i64>)>
[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
// CHECK: llvm.mlir.constant(20 : index) : i64
[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
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[4, 0] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<3 x i64>, array<3 x i64>)>
[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
// CHECK: llvm.mlir.constant(5 : index) : i64
[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
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[4, 1] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<3 x i64>, array<3 x i64>)>
[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
// CHECK: llvm.mlir.constant(1 : index) : i64
[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
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[4, 2] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<3 x i64>, array<3 x i64>)>
[mlir][Linalg] Allow reshapes to collapse to a zero-rank tensor. This is only valid if the source tensors (result tensor) is static shaped with all unit-extents when the reshape is collapsing (expanding) dimensions. Differential Revision: https://reviews.llvm.org/D79764
2020-05-13 13:50:35 +08:00
[mlir][Linalg] Add folders and canonicalizers for linalg.reshape/linalg.tensor_reshape operations. Differential Revision: https://reviews.llvm.org/D79765
2020-05-13 13:50:44 +08:00
func @reshape_fold_zero_dim(%arg0 : memref<1x1xf32>) -> memref<f32> {
[mlir][Linalg] Allow reshapes to collapse to a zero-rank tensor. This is only valid if the source tensors (result tensor) is static shaped with all unit-extents when the reshape is collapsing (expanding) dimensions. Differential Revision: https://reviews.llvm.org/D79764
2020-05-13 13:50:35 +08:00
%0 = linalg.reshape %arg0 [] : memref<1x1xf32> into memref<f32>
[mlir][Linalg] Add folders and canonicalizers for linalg.reshape/linalg.tensor_reshape operations. Differential Revision: https://reviews.llvm.org/D79765
2020-05-13 13:50:44 +08:00
return %0 : memref<f32>
[mlir][Linalg] Allow reshapes to collapse to a zero-rank tensor. This is only valid if the source tensors (result tensor) is static shaped with all unit-extents when the reshape is collapsing (expanding) dimensions. Differential Revision: https://reviews.llvm.org/D79764
2020-05-13 13:50:35 +08:00
}
[mlir][Linalg] Add folders and canonicalizers for linalg.reshape/linalg.tensor_reshape operations. Differential Revision: https://reviews.llvm.org/D79765
2020-05-13 13:50:44 +08:00
// CHECK-LABEL: func @reshape_fold_zero_dim
[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
// CHECK: llvm.mlir.undef : !llvm.struct<(ptr<f32>, ptr<f32>, i64)>
// CHECK: llvm.extractvalue %{{.*}}[0] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<2 x i64>, array<2 x i64>)>
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[0] : !llvm.struct<(ptr<f32>, ptr<f32>, i64)>
// CHECK: llvm.extractvalue %{{.*}}[1] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<2 x i64>, array<2 x i64>)>
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[1] : !llvm.struct<(ptr<f32>, ptr<f32>, i64)>
// CHECK: llvm.extractvalue %{{.*}}[2] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<2 x i64>, array<2 x i64>)>
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[2] : !llvm.struct<(ptr<f32>, ptr<f32>, i64)>
[mlir][Linalg] Add folders and canonicalizers for linalg.reshape/linalg.tensor_reshape operations. Differential Revision: https://reviews.llvm.org/D79765
2020-05-13 13:50:44 +08:00
func @reshape_expand_zero_dim(%arg0 : memref<f32>) -> memref<1x1xf32> {
%0 = linalg.reshape %arg0 [] : memref<f32> into memref<1x1xf32>
return %0 : memref<1x1xf32>
}
// CHECK-LABEL: func @reshape_expand_zero_dim
[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
// CHECK: llvm.mlir.undef : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<2 x i64>, array<2 x i64>)>
// CHECK: llvm.extractvalue %{{.*}}[0] : !llvm.struct<(ptr<f32>, ptr<f32>, i64)>
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[0] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<2 x i64>, array<2 x i64>)>
// CHECK: llvm.extractvalue %{{.*}}[1] : !llvm.struct<(ptr<f32>, ptr<f32>, i64)>
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[1] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<2 x i64>, array<2 x i64>)>
// CHECK: llvm.extractvalue %{{.*}}[2] : !llvm.struct<(ptr<f32>, ptr<f32>, i64)>
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[2] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<2 x i64>, array<2 x i64>)>
[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
// CHECK: llvm.mlir.constant(1 : index) : i64
[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
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[3, 0] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<2 x i64>, array<2 x i64>)>
[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
// CHECK: llvm.mlir.constant(1 : index) : i64
[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
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[3, 1] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<2 x i64>, array<2 x i64>)>
[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
// CHECK: llvm.mlir.constant(1 : index) : i64
[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
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[4, 0] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<2 x i64>, array<2 x i64>)>
[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
// CHECK: llvm.mlir.constant(1 : index) : i64
[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
// CHECK: llvm.insertvalue %{{.*}}, %{{.*}}[4, 1] : !llvm.struct<(ptr<f32>, ptr<f32>, i64, array<2 x i64>, array<2 x i64>)>