[PATCH] D83595: [Draft][MSAN] Optimize away poisoning allocas that are always written before load

Evgenii Stepanov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jul 30 14:45:39 PDT 2020


eugenis added a comment.

In D83595#2185554 <https://reviews.llvm.org/D83595#2185554>, @guiand wrote:

> This actually has very significant effects on some, but not all, benchmarks.
>
> Running `grep` I observed ~8% decrease in binary with this patch. But `clang` sees little effect: <1%.
>
> On a few different benchmarks from a benchmark suite, this also decreased runtime overhead by a significant amount: 8% for sha512 <https://github.com/rv8-io/rv8-bench/blob/master/src/sha512.c>, and 13% for qsort <https://github.com/rv8-io/rv8-bench/blob/master/src/qsort.c>.

This sounds worthwhile.



================
Comment at: llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp:3948
+
+    // Traverse to the Node's successors if we haven't yet
+    for (auto Node = succ_begin(BB); Node != succ_end(BB); Node++) {
----------------
I don't think this is entirely correct. Consider this:
```
entry { alloca 32; store 0..16 } -> A, B
A { store 16..32 } -> B
B { load }
```
traversing entry->A->B will mark B as done even though there is a path where control flow arrives at B with alloca not entirely initialized.

What happens to the benchmarks if this algorithm is limited to a single basic block?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83595/new/

https://reviews.llvm.org/D83595



More information about the llvm-commits mailing list