History log of /llvm-project/mlir/lib/Dialect/SparseTensor/Transforms/SparseIterationToScf.cpp (Results 1 – 12 of 12)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init, llvmorg-19.1.7
# 2b5b3cf6 27-Dec-2024 Matthias Springer <me@m-sp.org>

[mlir][sparse_tensor] Migrate `SparseIterationToScf.cpp` to dialect conversion (#121054)

Use the regular dialect conversion driver instead of the 1:N dialect
conversion driver. The 1:N dialect conv

[mlir][sparse_tensor] Migrate `SparseIterationToScf.cpp` to dialect conversion (#121054)

Use the regular dialect conversion driver instead of the 1:N dialect
conversion driver. The 1:N dialect conversion driver will be removed
soon.

show more ...


Revision tags: llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3
# f18c3e4e 23-Oct-2024 Matthias Springer <me@m-sp.org>

[mlir][Transforms] Dialect Conversion: Simplify materialization fn result type (#113031)

This commit simplifies the result type of materialization functions.

Previously: `std::optional<Value>`
N

[mlir][Transforms] Dialect Conversion: Simplify materialization fn result type (#113031)

This commit simplifies the result type of materialization functions.

Previously: `std::optional<Value>`
Now: `Value`

The previous implementation allowed 3 possible return values:
- Non-null value: The materialization function produced a valid
materialization.
- `std::nullopt`: The materialization function failed, but another
materialization can be attempted.
- `Value()`: The materialization failed and so should the dialect
conversion. (Previously: Dialect conversion can roll back.)

This commit removes the last variant. It is not particularly useful
because the dialect conversion will fail anyway if all other
materialization functions produced `std::nullopt`.

Furthermore, in contrast to type conversions, at least one
materialization callback is expected to succeed. In case of a failing
type conversion, the current dialect conversion can roll back and try a
different pattern. This also used to be the case for materializations,
but that functionality was removed with #107109: failed materializations
can no longer trigger a rollback. (They can just make the entire dialect
conversion fail without rollback.) With this in mind, it is even less
useful to have an additional error state for materialization functions.

This commit is in preparation of merging the 1:1 and 1:N type
converters. Target materializations will have to return multiple values
instead of a single one. With this commit, we can keep the API simple:
`SmallVector<Value>` instead of `std::optional<SmallVector<Value>>`.

Note for LLVM integration: All 1:1 materializations should return
`Value` instead of `std::optional<Value>`. Instead of `std::nullopt`
return `Value()`.

show more ...


Revision tags: llvmorg-19.1.2
# 206fad0e 05-Oct-2024 Matthias Springer <me@m-sp.org>

[mlir][NFC] Mark type converter in `populate...` functions as `const` (#111250)

This commit marks the type converter in `populate...` functions as
`const`. This is useful for debugging.

Patterns

[mlir][NFC] Mark type converter in `populate...` functions as `const` (#111250)

This commit marks the type converter in `populate...` functions as
`const`. This is useful for debugging.

Patterns already take a `const` type converter. However, some
`populate...` functions do not only add new patterns, but also add
additional type conversion rules. That makes it difficult to find the
place where a type conversion was added in the code base. With this
change, all `populate...` functions that only populate pattern now have
a `const` type converter. Programmers can then conclude from the
function signature that these functions do not register any new type
conversion rules.

Also some minor cleanups around the 1:N dialect conversion
infrastructure, which did not always pass the type converter as a
`const` object internally.

show more ...


Revision tags: llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4
# b48ef8d8 23-Aug-2024 Peiming Liu <peiming@google.com>

[mlir][sparse] unify block arguments order between iterate/coiterate operations. (#105567)


# 71867042 23-Aug-2024 Peiming Liu <peiming@google.com>

[mlir][sparse] refactoring sparse_tensor.iterate lowering pattern implementation. (#105566)


# f607102a 23-Aug-2024 Peiming Liu <peiming@google.com>

[mlir][sparse] partially support lowering sparse coiteration loops to scf.while/for. (#105565)


Revision tags: llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2
# 951a3630 31-Jul-2024 Peiming Liu <peiming@google.com>

[mlir][sparse] implement `sparse_tensor.extract_value` operation. (#101220)


Revision tags: llvmorg-19.1.0-rc1, llvmorg-20-init
# a02010b3 17-Jun-2024 Peiming Liu <peiming@google.com>

[mlir][sparse] support sparsifying sparse kernels to sparse-iterator-based loop (#95858)


# d6cc35f7 17-Jun-2024 Peiming Liu <peiming@google.com>

Reapply "[mlir][sparse] implement lowering rules for IterateOp." (#95836)


# 996905d8 17-Jun-2024 Peiming Liu <peiming@google.com>

Revert "[mlir][sparse] implement lowering rules for IterateOp." (#95826)

Reverts llvm/llvm-project#95286


# 3a2e4428 17-Jun-2024 Peiming Liu <peiming@google.com>

[mlir][sparse] implement lowering rules for IterateOp. (#95286)


Revision tags: llvmorg-18.1.8
# c42bbda4 12-Jun-2024 Peiming Liu <peiming@google.com>

[mlir][sparse] implement lowering rules for ExtractIterSpaceOp. (#89143)

**DO NOT MERGE** until https://github.com/llvm/llvm-project/pull/89003