[all-commits] [llvm/llvm-project] 2c3132: [MLIR] VectorEmulateNarrowType to support loading ...

[lialan via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 2c313259c65317f097d57ab4c6684b25db98f2e4
      https://github.com/llvm/llvm-project/commit/2c313259c65317f097d57ab4c6684b25db98f2e4
  Author: lialan <xunli at amd.com>
  Date:   2024-10-29 (Tue, 29 Oct 2024)

  Changed paths:
    M mlir/include/mlir/Dialect/MemRef/Utils/MemRefUtils.h
    M mlir/lib/Dialect/MemRef/Utils/MemRefUtils.cpp
    M mlir/lib/Dialect/Vector/Transforms/VectorEmulateNarrowType.cpp
    A mlir/test/Dialect/Vector/vector-emulate-narrow-type-unaligned.mlir

  Log Message:
  -----------
  [MLIR] VectorEmulateNarrowType to support loading of unaligned vectors (#113411)

Previously, the pass only supported emulation of loading vector sizes
that are multiples of the emulated data type. This patch expands its
support for emulating sizes that are not multiples of byte sizes. In
such cases, the element values are packed back-to-back to preserve
memory space.

To give a concrete example: if an input has type `memref<3x3xi2>`, it is
actually occupying 3 bytes in memory, with the first 18 bits storing the
values and the last 6 bits as padding. The slice of `vector<3xi2>` at
index `[2, 0]` is stored in memory from bit 12 to bit 18. To properly
load the elements from bit 12 to bit 18 from memory, first load byte 2
and byte 3, and convert it to a vector of `i2` type; then extract bits 4
to 10 (element index 2-5) to form a `vector<3xi2>`.

A limitation of this patch is that the linearized index of the unaligned
vector has to be known at compile time. Extra code needs to be emitted
to handle it if the condition does not hold.

The following ops are updated:
* `vector::LoadOp`
* `vector::TransferReadOp`
* `vector::MaskedLoadOp`



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications