[all-commits] [llvm/llvm-project] 0f8bab: [mlir] Revamp implementation of sub-byte load/stor...

[MaheshRavishankar via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 0f8bab8d590ed0cb5402f72009b32cbad115f013
      https://github.com/llvm/llvm-project/commit/0f8bab8d590ed0cb5402f72009b32cbad115f013
  Author: Mahesh Ravishankar <ravishankarm at google.com>
  Date:   2023-08-17 (Thu, 17 Aug 2023)

  Changed paths:
    M mlir/include/mlir/Dialect/MemRef/Utils/MemRefUtils.h
    M mlir/lib/Dialect/MemRef/Transforms/EmulateNarrowType.cpp
    M mlir/lib/Dialect/MemRef/Transforms/ExpandStridedMetadata.cpp
    M mlir/lib/Dialect/MemRef/Utils/MemRefUtils.cpp
    M mlir/lib/Dialect/Vector/Transforms/VectorEmulateNarrowType.cpp
    R mlir/test/Dialect/MemRef/emulate-narrow-type-diff-load-compute.mlir
    R mlir/test/Dialect/MemRef/emulate-narrow-type-same-load-compute.mlir
    A mlir/test/Dialect/MemRef/emulate-narrow-type.mlir
    M mlir/test/Dialect/Vector/vector-emulate-narrow-type.mlir
    M mlir/test/lib/Dialect/MemRef/TestEmulateNarrowType.cpp

  Log Message:
  -----------
  [mlir] Revamp implementation of sub-byte load/store emulation.

When handling sub-byte emulation, the sizes of the converted `memref`s
also need to be updated (this was not done in the current
implementation). This adds the additional complexity of having to
linearize the `memref`s as well. Consider a `memref<3x3xi4>` where the
`i4` elements are packed. This has a overall size of 5 bytes (rounded
up to number of bytes). This can only be represented by a
`memref<5xi8>`. A `memref<3x2xi8>` would imply an implicit padding of
4 bits at the end of each row. So incorporate linearization into the
sub-byte load-store emulation.

This patch also updates some of the utility functions to make better
use of statically available information using `OpFoldResult` and
`makeComposedFoldedAffineApplyOps`.

Reviewed By: hanchung, yzhang93

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