5a9af39aab
Because the sparse vectorizer relies on the code coming out of the sparsifier, the "patterns" are not always made very general. However, a recent change in the generated code revealed an obvious situation where the subscript analysis could be made a bit more robust. Fixes: https://github.com/llvm/llvm-project/issues/79897
32 lines
920 B
MLIR
32 lines
920 B
MLIR
// RUN: mlir-opt %s -sparsifier="vl=8" | FileCheck %s
|
|
|
|
#Dense = #sparse_tensor.encoding<{
|
|
map = (d0, d1) -> (d0 : dense, d1 : dense)
|
|
}>
|
|
|
|
#matvec = {
|
|
indexing_maps = [
|
|
affine_map<(i,j) -> (i,j)>, // A
|
|
affine_map<(i,j) -> (j)>, // b
|
|
affine_map<(i,j) -> (i)> // x (out)
|
|
],
|
|
iterator_types = ["parallel", "reduction"],
|
|
doc = "X(i) += A(i,j) * B(j)"
|
|
}
|
|
|
|
// CHECK-LABEL: llvm.func @kernel_matvec
|
|
// CHECK: llvm.intr.vector.reduce.fadd
|
|
func.func @kernel_matvec(%arga: tensor<?x?xf32, #Dense>,
|
|
%argb: tensor<?xf32>,
|
|
%argx: tensor<?xf32>) -> tensor<?xf32> {
|
|
%x = linalg.generic #matvec
|
|
ins(%arga, %argb: tensor<?x?xf32, #Dense>, tensor<?xf32>)
|
|
outs(%argx: tensor<?xf32>) {
|
|
^bb(%a: f32, %b: f32, %x: f32):
|
|
%0 = arith.mulf %a, %b : f32
|
|
%1 = arith.addf %x, %0 : f32
|
|
linalg.yield %1 : f32
|
|
} -> tensor<?xf32>
|
|
return %x : tensor<?xf32>
|
|
}
|