[all-commits] [llvm/llvm-project] 933fef: [mlir][sparse] Adjusting DimLevelType numeric valu...

[wren romano via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 933fefb6a834836a4a9b044f6351f53daed7a2a0
      https://github.com/llvm/llvm-project/commit/933fefb6a834836a4a9b044f6351f53daed7a2a0
  Author: wren romano <2998727+wrengr at users.noreply.github.com>
  Date:   2022-10-05 (Wed, 05 Oct 2022)

  Changed paths:
    M mlir/include/mlir-c/Dialect/SparseTensor.h
    M mlir/include/mlir/Dialect/SparseTensor/IR/SparseTensorAttrDefs.td
    M mlir/include/mlir/ExecutionEngine/SparseTensor/Enums.h
    M mlir/include/mlir/ExecutionEngine/SparseTensor/Storage.h
    M mlir/lib/ExecutionEngine/SparseTensorUtils.cpp
    M mlir/test/CAPI/sparse_tensor.c
    M mlir/test/Dialect/SparseTensor/conversion_sparse2dense.mlir
    M mlir/test/Dialect/SparseTensor/sparse_concat.mlir
    M mlir/test/Dialect/SparseTensor/sparse_fill_zero.mlir

  Log Message:
  -----------
  [mlir][sparse] Adjusting DimLevelType numeric values for faster predicates

This differential adjusts the numeric values for DimLevelType values: using the low-order two bits for recording the "No" and "Nu" properties, and the high-order bits for the formats per se.  (The choice of encoding may seem a bit peculiar, since the bits are mapped to negative properties rather than positive properties.  But this was done in order to preserve the collation order of DimLevelType values.  If we don't care about collation order, then we may prefer to flip the semantics of the property bits, so that they're less surprising to readers.)

Using distinguished bits for the properties and formats enables faster implementation for the predicates detecting those properties/formats, which matters because this is in the runtime library itself (rather than on the codegen side of things).  This differential pushes through the changes to the enum values, and optimizes the basic predicates.  However it does not optimize all the places where we check compound predicates (e.g., "is compressed or singleton"), to help reduce rebasing conflict with D134933.  Those optimizations will be done after this differential and D134933 are landed.

Reviewed By: aartbik

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