diff options
author | Fangrui Song <i@maskray.me> | 2020-09-14 15:11:55 -0700 |
---|---|---|
committer | Fangrui Song <i@maskray.me> | 2020-09-15 09:47:21 -0700 |
commit | 4452cc4086aca1a424b2cd40da9fa120add522e7 (patch) | |
tree | bf6013c95dd4a6a85c70a96cec209c603f5e5e0c /llvm/lib/Support/MemoryBuffer.cpp | |
parent | 127faae7529aee7e8508abebbc19212ce30bbf27 (diff) | |
download | llvm-4452cc4086aca1a424b2cd40da9fa120add522e7.zip llvm-4452cc4086aca1a424b2cd40da9fa120add522e7.tar.gz llvm-4452cc4086aca1a424b2cd40da9fa120add522e7.tar.bz2 |
[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
Diffstat (limited to 'llvm/lib/Support/MemoryBuffer.cpp')
0 files changed, 0 insertions, 0 deletions