[all-commits] [llvm/llvm-project] 5bcb4c: [MSAN] Support load and stores of scalable vector ...

[Philip Reames via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 5bcb4c4da99c443fb880d408e5ff4e9b305bbb77
      https://github.com/llvm/llvm-project/commit/5bcb4c4da99c443fb880d408e5ff4e9b305bbb77
  Author: Philip Reames <preames at rivosinc.com>
  Date:   2023-03-23 (Thu, 23 Mar 2023)

  Changed paths:
    M llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp
    M llvm/test/Instrumentation/MemorySanitizer/vector-load-store.ll

  Log Message:
  -----------
  [MSAN] Support load and stores of scalable vector types

This adds support for scalable vector types - at least far enough to get basic load and store cases working. It turns out that load/store without origin tracking already worked; I apparently got that working with one of the pre patches to use TypeSize utilities and didn't notice. The code changes here are required to enable origin tracking.

For origin tracking, a 4 byte value - the origin - is broadcast into a shadow region whose size exactly matches the type being accessed. This origin is only written if the shadow value is non-zero. The details of how shadow is computed from the original value being stored aren't relevant for this patch.

The code changes involve two related primitives.

First, we need to be able to perform that broadcast into a scalable sized memory region. This requires the use of a loop, and appropriate bound. The fixed size case optimizes with larger stores and alignment; I did not bother with that for the scalable case for now. We can optimize this codepath later if desired.

Second, we need a way to test if the shadow is zero. The mechanism for this in the code is to convert the shadow value into a scalar, and then zero check that. There's an assumption that this scalar is zero exactly when all elements of the shadow value are zero. As a result, we use an OR reduction on the scalable vector. This is analogous to how e.g. an array is handled. I landed a bunch of cleanup changes to remove other direct uses of the scalar conversion to convince myself there were no other undocumented invariants.

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