[all-commits] [llvm/llvm-project] 4452cc: [VectorCombine] Don't vectorize scalar load under ...

[Fangrui Song via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 4452cc4086aca1a424b2cd40da9fa120add522e7
      https://github.com/llvm/llvm-project/commit/4452cc4086aca1a424b2cd40da9fa120add522e7
  Author: Fangrui Song <i at maskray.me>
  Date:   2020-09-15 (Tue, 15 Sep 2020)

  Changed paths:
    M llvm/lib/Transforms/Vectorize/VectorCombine.cpp
    M llvm/test/Transforms/VectorCombine/X86/load.ll

  Log Message:
  -----------
  [VectorCombine] Don't vectorize scalar load under asan/hwasan/memtag/tsan

Similar to the tsan suppression in
`Utils/VNCoercion.cpp:getLoadLoadClobberFullWidthSize` (rL175034; load widening used by GVN),
the D81766 optimization should be suppressed under tsan due to potential
spurious data race reports:

  struct A {
    int i;
    const short s; // the load cannot be vectorized because
    int modify;    // it overlaps with bytes being concurrently modified
    long pad1, pad2;
  };
  // __tsan_read16 does not know that some bytes are undef and accessing is safe

Similarly, under asan, users can mark memory regions with
`__asan_poison_memory_region`. A widened load can lead to a spurious
use-after-poison error. hwasan/memtag should be similarly suppressed.

`mustSuppressSpeculation` suppresses asan/hwasan/tsan but not memtag, so
we need to exclude memtag in `vectorizeLoadInsert`.

Note, memtag suppression can be relaxed if the load is aligned to the
its granule (usually 16), but that is out of scope of this patch.

Reviewed By: spatel, vitalybuka

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