[PATCH] D12838: [GlobalsAA] Teach GlobalsAA about memory intrinsics

[hfinkel@anl.gov via llvm-commits]

hfinkel added a comment.

Actually, I wonder if the right solution here is somewhat more general. As I recall, generally speaking, GMR cannot use 'nocapture' attributes on functions parameters because:

1. It cannot use nocapture on the parent function's arguments because nocapture is a statement only about appearances to the caller, not a guarantee about what happens inside the function itself.
2. It cannot use nocapture on attributes on the call instructions because it is possible that the function is directly or indirectly recursive, and so (1) applies.

And, so, we can honor nocapture for any function calls which we can prove are not directly or indirectly recursive with the current function. This seems like something we could do given that we have a callgraph, and perhaps can assert more generally for all intrinsics?


================
Comment at: lib/Analysis/GlobalsModRef.cpp:776-782
@@ +775,9 @@
+  default:
+    return MRI_ModRef;
+  case Intrinsic::memset:
+    return (Operands[0] ? MRI_Mod : MRI_NoModRef);
+  case Intrinsic::memcpy:
+  case Intrinsic::memmove:
+    return static_cast<ModRefInfo>((Operands[0] ? MRI_Mod : MRI_NoModRef) |
+                                   (Operands[1] ? MRI_Ref : MRI_NoModRef));
+  }
----------------
aadg wrote:
> Shouldn't we also handle the isVolatile argument ? As anything could happen when this is a volatile operation, I think we should always return MRI_ModRef when it is set.
I agree with James's response (from the list, which is seems did not make it into Phabricator); volatility and aliasing are orthogonal concepts, and while we do imply aliasing affects to volatile operations (and atomics) in various places (for reasons that I'm sure seemed convenient at the time), it is really not a good thing, and I see no reason to do so here.



Repository:
  rL LLVM

http://reviews.llvm.org/D12838