10 Commits

Author SHA1 Message Date
Fangrui Song
6a684dbc44 [Support] Remove llvm::is_trivially_{copy/move}_constructible
This restores D132311, which was reverted in
29c841ce93e087fa4e0c5f3abae94edd460bc24a (Sep 2022) due to certain files
not buildable with GCC 7.3.0. The previous attempt was reverted by
6cd9608fb37ca2418fb44b57ec955bb5efe10689 (Dec 2020).

This time, GCC 7.3.0 has existing build errors for a long time due to
structured bindings for many files, e.g.

```
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:9098:13: error: cannot decompose class type ‘std::pair<llvm::Value*, const llvm::SCEV*>’: both it and it
s base class ‘std::pair<llvm::Value*, const llvm::SCEV*>’ have non-static data members
   for (auto [_, Stride] : Legal->getLAI()->getSymbolicStrides()) {
             ^~~~~~~~~~~
```

... and also some `error: duplicate initialization of` instances due to llvm/Transforms/IPO/Attributor.h.

---

GCC 7.5.0 has a bug that, without this change, certain `SmallVector` with a `std::pair` element type like `SmallVector<std::pair<Instruction * const, Info>, 0> X;` lead to spurious

```
/tmp/opt/gcc-7.5.0/include/c++/7.5.0/type_traits:878:48: error: constructor required before non-static data member for ‘...’ has been parsed
```

Switching to std::is_trivially_{copy/move}_constructible fixes the error.
2023-07-25 17:21:16 -07:00
wren romano
889f4bf264 [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
2023-07-20 15:56:03 -07:00
wren romano
ad7a6b672c [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
2023-07-19 12:13:02 -07:00
Amir Bishara
1ad009ad3c [mlir][cmake] Comment out redundant static assert regarding VarInfo struct
Reviewed By: aartbik

Differential Revision: https://reviews.llvm.org/D154940
2023-07-18 00:14:24 -07:00
wren romano
47cf7a4ba5 [llvm] Allow SMLoc to be used in constexpr context
Since `StringRef::empty` can be used in constexpr context, it seems reasonable that `SMLoc::isValid` should be too.  The default-ctor and `operator==` are made constexpr for consistency.

In particular, the `constexpr` keyword is needed for silencing warnings on Windows (whereas Linux allows constexpr usage without the keyword).

Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D154741
2023-07-17 11:45:22 -07:00
Peiming Liu
269c82d389 [mlir][sparse] introduce new 2:4 block sparsity level type.
Reviewed By: aartbik

Differential Revision: https://reviews.llvm.org/D155128
2023-07-12 23:33:53 +00:00
wren romano
dcadb68a5c [mlir][sparse] Cleaning up OOB implementation details for VarSet
Reviewed By: aartbik

Differential Revision: https://reviews.llvm.org/D154674
2023-07-07 14:35:56 -07:00
wren romano
68785c1c44 [mlir][sparse] Correcting RTTI implementation for the Var class
Reviewed By: aartbik

Differential Revision: https://reviews.llvm.org/D154662
2023-07-06 18:57:02 -07:00
Aart Bik
b939c015a4 [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
2023-06-30 14:48:23 -07:00
Aart Bik
6b88c852b6 [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
2023-06-29 11:32:07 -07:00