[PATCH] D84371: [DFSan] Add efficient fast16labels instrumentation mode.

Matt Morehouse via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jul 23 16:17:27 PDT 2020


morehouse added a subscriber: Dor1s.
morehouse added a comment.

In D84371#2168367 <https://reviews.llvm.org/D84371#2168367>, @kcc wrote:

> In what cases do we still call __dfsan_union?


We still call `__dfsan_union_load` when we load sizes greater than 2 bytes but not divisible by 4.  I actually am not sure what instruction sequence would hit this case, but it was already in DFSan so I left it there.

`__dfsan_union_load` then calls `__dfsan_union`.



================
Comment at: compiler-rt/lib/dfsan/dfsan.cpp:173
+// Configures the DFSan runtime to use fast16labels mode.
+extern "C" SANITIZER_INTERFACE_ATTRIBUTE void dfsan_use_fast16labels() {
+  use_fast16labels = true;
----------------
kcc wrote:
> I wonder if we can get away w/o these flags.
> Just assume that fast16mode works only when the fast16mode instrumentation is enabled. 
> (remember, fast16mode is currently experimental, we are free to change its behavior) 
SGTM.  I only know of @Dor1s using it at the moment.


================
Comment at: llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp:1079
+                           cast<Constant>(DFSanUseFast16LabelsFn.getCallee()),
+                           "__dfsan_fast16labels_preinit");
+    UseFast16LabelsInit->setSection(".preinit_array");
----------------
vitalybuka wrote:
> what we are going to do in __dfsan_fast16labels_preinit?
This global is simply a pointer to `dfsan_use_fast16labels()` so that it runs during preinit.  `dfsan_use_fast16labels` just enables fast16labels mode in the runtime.


================
Comment at: llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp:1339
+        IRB.CreateAlignedLoad(IRB.getInt64Ty(), WideAddr, ShadowAlign);
+    for (uint64_t Ofs = 64 / DFS.ShadowWidthBits; Ofs != Size;
+         Ofs += 64 / DFS.ShadowWidthBits) {
----------------
vitalybuka wrote:
> have you considered a loop?
> 
I think we should avoid loop overhead at least for the common case here  (loading 8-16 bytes of shadow).

I think it's also possible to hit this case with vector instructions, but vanilla DFSan currently doesn't use a loop in that case either.  If we want to use a loop for vector loads, I think we should do it in a different patch.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84371





More information about the llvm-commits mailing list