| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir][arith] Add support for sitofp, uitofp to ArithToAPFloat (#169284) Add support for arith.sitofp and arith.uitofp. | 8 个月前 | |
[mlir] Rename mlir-cpu-runner to mlir-runner (#123776) With the removal of mlir-vulkan-runner (as part of #73457) in e7e3c45bc70904e24e2b3221ac8521e67eb84668, mlir-cpu-runner is now the only runner for all CPU and GPU targets, and the "cpu" name has been misleading for some time already. This commit renames it to mlir-runner. | 1 年前 | |
| 8 个月前 | ||
[mlir] Rename mlir-cpu-runner to mlir-runner (#123776) With the removal of mlir-vulkan-runner (as part of #73457) in e7e3c45bc70904e24e2b3221ac8521e67eb84668, mlir-cpu-runner is now the only runner for all CPU and GPU targets, and the "cpu" name has been misleading for some time already. This commit renames it to mlir-runner. | 1 年前 | |
[mlir] Rename mlir-cpu-runner to mlir-runner (#123776) With the removal of mlir-vulkan-runner (as part of #73457) in e7e3c45bc70904e24e2b3221ac8521e67eb84668, mlir-cpu-runner is now the only runner for all CPU and GPU targets, and the "cpu" name has been misleading for some time already. This commit renames it to mlir-runner. | 1 年前 | |
[mlir][linalg] Fix Linalg runtime verification test (#167814) This integration test has been broken for a while. This commit partially fixes it. - Use CHECK + CHECK-NEXT to ensure that the correct error lines are matched together. - Move all CHECK-NOT to the end. Having a CHECK with the same string does not make sense after a CHECK-NOT. - Add a missing CHECK: ERROR for one of the test cases. - Deactivate reverse_from_3, which is broken, and put a TODO. | 8 个月前 | |
[mlir] Rename mlir-cpu-runner to mlir-runner (#123776) With the removal of mlir-vulkan-runner (as part of #73457) in e7e3c45bc70904e24e2b3221ac8521e67eb84668, mlir-cpu-runner is now the only runner for all CPU and GPU targets, and the "cpu" name has been misleading for some time already. This commit renames it to mlir-runner. | 1 年前 | |
[mlir][memref] Fix runtime verification for memref.subview for empty memref subviews (#166581) This PR applies the same fix from #166569 to memref.subview. That PR fixed the issue for tensor.extract_slice, and this one addresses the identical problem for memref.subview. The runtime verification for memref.subview incorrectly rejects valid empty subviews (size=0) starting at the memref boundary. **Example that demonstrates the issue:** mlir func.func @subview_with_empty_slice(%memref: memref<10x4x1xf32, strided<[?, ?, ?], offset: ?>>, %dim_0: index, %dim_1: index, %dim_2: index, %offset: index) { // When called with: offset=10, dim_0=0, dim_1=4, dim_2=1 // Runtime verification fails: "offset 0 is out-of-bounds" %subview = memref.subview %memref[%offset, 0, 0] [%dim_0, %dim_1, %dim_2] [1, 1, 1] : memref<10x4x1xf32, strided<[?, ?, ?], offset: ?>> to memref<?x?x?xf32, strided<[?, ?, ?], offset: ?>> return } When %offset=10 and %dim_0=0, we're creating an empty subview (zero elements along dimension 0) starting at the boundary. The current verification enforces offset < dim_size, which evaluates to 10 < 10 and fails. I feel this should be valid since no memory is accessed. **The fix:** Same as #166569 - make the offset check conditional on subview size: - Empty subview (size == 0): allow 0 <= offset <= dim_size - Non-empty subview (size > 0): require 0 <= offset < dim_size Please see #166569 for motivation and rationale. --- Co-authored-by: Hanumanth Hanumantharayappa <hhanuman@ah-hhanuman-l.dhcp.mathworks.com> | 8 个月前 | |
[mlir:PDL] Fix a syntax ambiguity in pdl.attribute pdl.attribute currently has a syntax ambiguity that leads to the incorrect parsing of pdl.attribute operations with locations that don't also have a constant value. For example: pdl.attribute loc("foo") The above IR is treated as being a pdl.attribute with a constant value containing the location, loc("foo"), which is incorrect. This commit changes the syntax to use = <constant-value> to clearly distinguish when the constant value is present, as opposed to just trying to parse an attribute. Differential Revision: https://reviews.llvm.org/D124582 | 4 年前 | |
[mlir][SparseTensor] Re-enable tests on AArch64 (#143387) These tests were disabled in https://reviews.llvm.org/D136273, due to: * https://github.com/llvm/llvm-project/issues/58465 That issue has now been resolved, so we should be able to re-enable these tests. | 1 年前 | |
[mlir] Rename mlir-cpu-runner to mlir-runner (#123776) With the removal of mlir-vulkan-runner (as part of #73457) in e7e3c45bc70904e24e2b3221ac8521e67eb84668, mlir-cpu-runner is now the only runner for all CPU and GPU targets, and the "cpu" name has been misleading for some time already. This commit renames it to mlir-runner. | 1 年前 | |
[mlir][tensor] Fix runtime verification for tensor.extract_slice for empty tensor slices (#166569) I hit another runtime verification issue (similar to https://github.com/llvm/llvm-project/pull/164878) while working with TFLite models. The verifier is incorrectly rejecting tensor.extract_slice operations when extracting an empty slice (size=0) that starts exactly at the tensor boundary. The current runtime verification unconditionally enforces offset < dim_size. This makes sense for non-empty slices, but it's too strict for empty slices, causing false positives that lead to spurious runtime assertions. **Simple example that demonstrates the issue:** mlir func.func @extract_empty_slice(%tensor: tensor<?xf32>, %offset: index, %size: index) { // When called with: tensor size=10, offset=10, size=0 // Runtime verification fails: "offset 0 is out-of-bounds" %slice = tensor.extract_slice %tensor[%offset] [%size] [1] : tensor<?xf32> to tensor<?xf32> return } For the above example, the check evaluates 10 < 10 which is false, so verification fails. However, I believe this operation should be valid - we're extracting zero elements, so there's no actual out-of-bounds access. **Real-world repro from the TensorFlow Lite models:** This issue manifests while lowering TFLite models and a lot of our system tests are failing due to this. Here's a simplified version showing the problematic pattern: In this code, %extracted_slice_0 becomes an empty tensor when SSA value %15 reaches 10 (on the final loop iteration), making %16 = 0. The operation extracts zero elements along dimension 0, which is semantically valid but fails runtime verification. mlir func.func @simplified_repro_from_tensorflowlite_model(%arg0: tensor<10x4x1xf32>) -> tensor<10x4x1xf32> { %c0 = arith.constant 0 : index %c1 = arith.constant 1 : index %c2 = arith.constant 2 : index %c10 = arith.constant 10 : index %c-1 = arith.constant -1 : index %0 = "tosa.const"() <{values = dense<0> : tensor<i32>}> : () -> tensor<i32> %1 = "tosa.const"() <{values = dense<1> : tensor<i32>}> : () -> tensor<i32> %2 = "tosa.const"() <{values = dense<10> : tensor<i32>}> : () -> tensor<i32> %3 = "tosa.const"() <{values = dense<-1> : tensor<2xi32>}> : () -> tensor<2xi32> %4 = "tosa.const"() <{values = dense<0> : tensor<2xi32>}> : () -> tensor<2xi32> %5 = "tosa.const"() <{values = dense<0.000000e+00> : tensor<1x4x1xf32>}> : () -> tensor<1x4x1xf32> %c4_1 = tosa.const_shape {values = dense<1> : tensor<1xindex>} : () -> !tosa.shape<1> %6:2 = scf.while (%arg1 = %0, %arg2 = %arg0) : (tensor<i32>, tensor<10x4x1xf32>) -> (tensor<i32>, tensor<10x4x1xf32>) { %7 = tosa.greater %2, %arg1 : (tensor<i32>, tensor<i32>) -> tensor<i1> %extracted = tensor.extract %7[] : tensor<i1> scf.condition(%extracted) %arg1, %arg2 : tensor<i32>, tensor<10x4x1xf32> } do { ^bb0(%arg1: tensor<i32>, %arg2: tensor<10x4x1xf32>): %7 = tosa.add %arg1, %1 : (tensor<i32>, tensor<i32>) -> tensor<i32> // First slice %8 = tosa.reshape %arg1, %c4_1 : (tensor<i32>, !tosa.shape<1>) -> tensor<1xi32> %9 = tosa.concat %8, %3 {axis = 0 : i32} : (tensor<1xi32>, tensor<2xi32>) -> tensor<3xi32> %extracted_0 = tensor.extract %9[%c0] : tensor<3xi32> %10 = index.casts %extracted_0 : i32 to index %11 = arith.cmpi eq, %10, %c-1 : index %12 = arith.select %11, %c10, %10 : index %extracted_slice = tensor.extract_slice %arg2[0, 0, 0] [%12, 4, 1] [1, 1, 1] : tensor<10x4x1xf32> to tensor<?x4x1xf32> // Second slice - this is where the failure occurs %13 = tosa.reshape %7, %c4_1 : (tensor<i32>, !tosa.shape<1>) -> tensor<1xi32> %14 = tosa.concat %13, %4 {axis = 0 : i32} : (tensor<1xi32>, tensor<2xi32>) -> tensor<3xi32> %extracted_1 = tensor.extract %14[%c0] : tensor<3xi32> %15 = index.castu %extracted_1 : i32 to index %16 = arith.subi %c10, %15 : index // size = 10 - offset %extracted_2 = tensor.extract %14[%c1] : tensor<3xi32> %17 = index.castu %extracted_2 : i32 to index %extracted_3 = tensor.extract %14[%c2] : tensor<3xi32> %18 = index.castu %extracted_3 : i32 to index // On the last loop iteration: %15=10, %16=0 // %extracted_slice_0 becomes an empty tensor // Runtime verification fails: "offset 0 is out-of-bounds" %extracted_slice_0 = tensor.extract_slice %arg2[%15, %17, %18] [%16, 4, 1] [1, 1, 1] : tensor<10x4x1xf32> to tensor<?x4x1xf32> %19 = tosa.concat %extracted_slice, %5, %extracted_slice_0 {axis = 0 : i32} : (tensor<?x4x1xf32>, tensor<1x4x1xf32>, tensor<?x4x1xf32>) -> tensor<10x4x1xf32> scf.yield %7, %19 : tensor<i32>, tensor<10x4x1xf32> } return %6#1 : tensor<10x4x1xf32> } **The fix:** Make the offset check conditional on slice size: - Empty slice (size == 0): allow 0 <= offset <= dim_size - Non-empty slice (size > 0): require 0 <= offset < dim_size **Question for reviewers:** Should we also relax the static verifier to allow this edge case? Currently, the static verifier rejects the following IR: mlir %tensor = arith.constant dense<1.0> : tensor<10xf32> %slice = tensor.extract_slice %tensor[10] [0] [1] : tensor<10xf32> to tensor<0xf32> Since we're allowing it at runtime for dynamic shapes, it seems inconsistent to reject it statically. However, I wanted to get feedback before making that change - this PR focuses only on the runtime verification fix for dynamic shapes. P.S. We have a similar issue with memref.subview. I will send a separate patch for the issue. Co-authored-by: Hanumanth Hanumantharayappa <hhanuman@ah-hhanuman-l.dhcp.mathworks.com> | 8 个月前 | |
[mlir][bufferization][NFC] Rename to_memref to to_buffer (#137180) As part of the work on transitioning bufferization dialect, ops, and associated logic to operate on newly added type interfaces (see 00eaff3e9c897c263a879416d0f151d7ca7eeaff), rename the bufferization.to_memref to highlight the generic nature of the op. Bufferization process produces buffers while memref is a builtin type rather than a generic term. Preserve the current API (to_buffer still produces a memref), however, as the new type interfaces are not used yet. | 1 年前 | |
[MLIR][Linalg] Remove elemwise_unary and elemwise_binary (#147082) RFC: https://discourse.llvm.org/t/rfc-deprecate-linalg-elemwise-unary-and-elemwise-binary/87144 Remove the two operations and fix the tests by: * Cleaning simple operation tests of the old ops * Changing linalg.elemwise_{u|bi}nary with linalg.{exp|add} on transform tests * Changing some of the tests with linalg.elementwise instead, to broaden test coverage * Surgically removing the elemwise_* part in the Python tests * Update MLIR transform examples (text and tests) with linalg.elementwise instead Nothing else changed. | 1 年前 | |
[MLIR][Vector] Fix test following vector.splat removal (#162892) This is a fix for the failing integration test (see https://lab.llvm.org/buildbot/#/builders/177/builds/22398) reported in https://github.com/llvm/llvm-project/pull/162167. | 9 个月前 | |
[mlir][gpu]Add GPUToXeVM lowering pipeline pass. (#161216) It's the default GPU to XeVM lowering pipeline. It starts by lowering GPU code to the specified compilation target (default is fatbin), then lowers the host code. If XeGPU ops are used, it expects the MLIR code to have XeGPU ops already embedded in gpu code. | 9 个月前 | |
[MLIR][GPU] Generalize gpu.printf op lowering to LLVM call pattern. (#164297) Existing pattern for lowering gpu.printf op to LLVM call uses fixed function name and calling convention. Those two should be exposed as pass option to allow supporting Intel Compute Runtime for GPU. Also adds gpu.printf op pattern to GPU to LLVMSPV pass. It may appear out of place, but integration test is added to XeVM integration test as that is the current best folder for testing with Intel Compute Runtime. Test should be moved in the future if a better test folder is added. | 9 个月前 |