[mlir] Tidy uses of llvm::raw_stream_ostream (NFC)

As specified in the docs,
1) raw_string_ostream is always unbuffered and
2) the underlying buffer may be used directly

( 65b13610a5226b84889b923ba

[mlir] Tidy uses of llvm::raw_stream_ostream (NFC)

As specified in the docs,
1) raw_string_ostream is always unbuffered and
2) the underlying buffer may be used directly

( 65b13610a5226b84889b923bae884ba395ad084d for further reference )

* Don't call raw_string_ostream::flush(), which is essentially a no-op.
* Avoid unneeded calls to raw_string_ostream::str(), to avoid excess indirection.

show more ...

Switch member calls to `isa/dyn_cast/cast/...` to free function calls. (#89356)

This change cleans up call sites. Next step is to mark the member
functions deprecated.

See https://mlir.llvm.org/

Switch member calls to `isa/dyn_cast/cast/...` to free function calls. (#89356)

This change cleans up call sites. Next step is to mark the member
functions deprecated.

See https://mlir.llvm.org/deprecation and
https://discourse.llvm.org/t/preferred-casting-style-going-forward.

show more ...

[mlir][sparse] Clean up parser (#72571)

Remove unused functions in parser.

[mlir][sparse] Parser cleanup (#69792)

Removed TODOs, FIXMEs and long notes that are more suited for design
doc.

[mlir][sparse] Add more error messages and avoid crashing in new parser (#67034)

Updates:
1. Added more invalid encodings to test the robustness of the new syntax
2. Changed the asserts that cause

[mlir][sparse] Add more error messages and avoid crashing in new parser (#67034)

Updates:
1. Added more invalid encodings to test the robustness of the new syntax
2. Changed the asserts that caused crashing into returning booleans
3. Modified some error messages to make them clearer and handled
failures in parsing quotes as keyword for level formats and properties.

show more ...

[mlir][sparse] Adding `{Var,DimLvlExpr,DimSpec,LvlSpec,DimLvlMap}::str` methods

These methods are needed for use with `Diagnostic::operator<<` etc.

The definitions follow the pattern of `Diagnostic

[mlir][sparse] Adding `{Var,DimLvlExpr,DimSpec,LvlSpec,DimLvlMap}::str` methods

These methods are needed for use with `Diagnostic::operator<<` etc.

The definitions follow the pattern of `Diagnostic::str` by simply wrapping the underlying `print(raw_ostream)` method. Although there is some overhead for constructing the `std::string`, this seems like the overall most-efficient option: since this overhead only occurs on the error path (under the current intended usage). An alternative approach would be to have one method construct a `Twine` directly, and then have the print method pass the twine to the stream; however, that would mean introducing the overhead of twine construction on the common/happy path of simply printing things out.

Reviewed By: aartbik

Differential Revision: https://reviews.llvm.org/D157643

show more ...

[mlir][sparse] Adding getters/setters to `DimLvlMap`

Depends On D156768

Reviewed By: aartbik

Differential Revision: https://reviews.llvm.org/D156770

[mlir][sparse] Adding `Ranks::operator==` and `VarSet::getRank` etc

Depends On D156001

Reviewed By: aartbik

Differential Revision: https://reviews.llvm.org/D156010

[mlir][sparse] Marking off todos and updating commentary

Depends On D155999

Reviewed By: Peiming

Differential Revision: https://reviews.llvm.org/D156001

[mlir][sparse] Fixes bug in VarSet ctor

Previously, the commented out code in the `DimLvlMap` ctor would result in `VarSet::add` raising an OOB error; which should be impossible because the ctor ass

[mlir][sparse] Fixes bug in VarSet ctor

Previously, the commented out code in the `DimLvlMap` ctor would result in `VarSet::add` raising an OOB error; which should be impossible because the ctor asserted `DimLvlMap::isWF` which ensures that all variables occuring in the map are within bounds for the ranks.

The root cause of that bug was the `VarSet` ctor using `SmallBitVector::reserve` which does not actually change the size of the bitvectors (hence the subsequent OOB). This is corrected by using any of `SmallBitVector::resize`, the move-ctor, or the copy-ctor. Since the default-initialized bitvectors being modified/overwritten have size zero, there shouldn't be any significant performance difference between these three implementations.

Reviewed By: Peiming

Differential Revision: https://reviews.llvm.org/D155999

show more ...

[mlir][sparse] Improve `DimLvlMapParser`'s handling of variable bindings

This commit comprises a number of related changes:

(1) Reintroduces the semantic distinction between `parseVarUsage` vs `par

[mlir][sparse] Improve `DimLvlMapParser`'s handling of variable bindings

This commit comprises a number of related changes:

(1) Reintroduces the semantic distinction between `parseVarUsage` vs `parseVarBinding`, adds documentation explaining the distinction, and adds commentary to the one place that violates the desired/intended semantics.

(2) Improves documentation/commentary about the forward-declaration of level-vars, and about the meaning of the `bool` parameter to `parseLvlSpec`.

(2) Removes the `VarEnv::addVars` method, and instead has `DimLvlMapParser` handle the conversion issues directly. In particular, the parser now stores and maintains the `{dims,lvls}AndSymbols` arrays, thereby avoiding the O(n^2) behavior of scanning through the entire `VarEnv` for each `parse{Dim,Lvl}Spec` call. Unfortunately there still remains another source of O(n^2) behavior, namely: the `AsmParser::parseAffineExpr` method will copy the `DimLvlMapParser::{dims,lvls}AndSymbols` arrays into `AffineParser::dimsAndSymbols` on each `parse{Dim,Lvl}Spec` call; but fixing that would require extensive changes to `AffineParser` itself.

Depends On D155532

Reviewed By: Peiming

Differential Revision: https://reviews.llvm.org/D155533

show more ...

[mlir][sparse] Renaming `CreationPolicy` to `Policy`

This change is mostly for brevity's sake; but it also paves the way for the `Policy` enum to be reuseable for other situations that require the s

[mlir][sparse] Renaming `CreationPolicy` to `Policy`

This change is mostly for brevity's sake; but it also paves the way for the `Policy` enum to be reuseable for other situations that require the same three-way semantics.

Reviewed By: Peiming

Differential Revision: https://reviews.llvm.org/D155532

show more ...

[mlir][sparse] Cleaning up OOB implementation details for `VarSet`

Reviewed By: aartbik

Differential Revision: https://reviews.llvm.org/D154674

[mlir][sparse] add affine parsing to new surface syntax for STEA

(1) uses the previously introduce API to reuse AffineExpr parser without codedup
(2) solves the look-ahead problem when parsing level

[mlir][sparse] add affine parsing to new surface syntax for STEA

(1) uses the previously introduce API to reuse AffineExpr parser without codedup
(2) solves the look-ahead problem when parsing level spec

Reviewed By: Peiming

Differential Revision: https://reviews.llvm.org/D154254

show more ...

[mlir][sparse] Start migration to new surface syntax for STEA

We are in the progress of migrating to a much improved surface syntax for the Sparse Tensor Encoding Attribute (STEA).

You can see a pr

[mlir][sparse] Start migration to new surface syntax for STEA

We are in the progress of migrating to a much improved surface syntax for the Sparse Tensor Encoding Attribute (STEA).

You can see a preview of this in the StableHLO RFC at

https://github.com/openxla/stablehlo/blob/main/rfcs/20230210-sparsity.md

//**This design is courtesy Wren Romano.**//

This initial revision
(1) Introduces the first version of a new parser written by Wren Romano
(2) Introduces a simple "migration plan" using NEW_SYNTAX on the STEA, which will allow us to test the new parser with new examples, as well as migrate existing examples over without the need to rewrite them all

This first "drop" merely provides the entry points to parse the new syntax. The parser is still under active development. For example, we need to address the "lookahead" issue when parsing the lvl spec (viz. do we see l0 = d0 or a direct d0). Another larger task is to actually implement "affine" parsing (since the MLIR affine parser is not accessible in other parts of the tree).

EXAMPLE:

Currently, CSR looks like

#CSR = #sparse_tensor.encoding<{
lvlTypes = ["dense","compressed"],
dimToLvl = affine_map<(i,j) -> (i,j)>
}>

but you can "force" the new parser with

#CSR = #sparse_tensor.encoding<{
NEW_SYNTAX =
(d0, d1) -> (l0 = d0 : dense, l1 = d1 : compressed)
}>

Reviewed By: Peiming

Differential Revision: https://reviews.llvm.org/D153997

show more ...