[PATCH] asan: do not instrument direct inbounds accesses to stack variables

[Chandler Carruth]

This looks very good to me as well. I think you can submit now. The remaining issues are I think quite minor.

However, I would love to find some form of naming that doesn't so easily confuse the GEP "inbounds" keyword with this check. Sadly, I can't come up with any good ideas. Maybe just talk about "safe" in the APIs and explain what the object size check is computing, etc.? Anyways, a minor point.

If this causes a compile-time regression, it should be easy to track down. You might do a quick sanity check for some big inputs Dmitry, since it seems like you have them.

Danny, I'm pretty sure that the object size code is newer and should at least in theory be more powerful than just getting the base address. I could be wrong though. Still, easy to switch to that in a follow-up if needed.


================
Comment at: lib/Transforms/Instrumentation/AddressSanitizer.cpp:397-398
@@ -388,3 +396,4 @@
   Value *isInterestingMemoryAccess(Instruction *I, bool *IsWrite,
-                                   unsigned *Alignment) const;
-  void instrumentMop(Instruction *I, bool UseCalls);
+                                   uint64_t *TypeSize, unsigned *Alignment)
+                                   const;
+  void instrumentMop(ObjectSizeOffsetVisitor &ObjSizeVis, Instruction *I,
----------------
Surely clang-format puts this 'const' somewhere else...

http://reviews.llvm.org/D7583

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/