[PATCH] D13512: [GlobalsAA] Loosen an overly conservative bailout

[Chandler Carruth via llvm-commits]

chandlerc added a comment.

My brain hurts from thinking about this. ;] Sorry for delays though. I *think* I've got my head wrapped around it.


================
Comment at: lib/Analysis/GlobalsModRef.cpp:682
@@ -674,3 +681,3 @@
 
-      // Otherwise, a load could come from anywhere, so bail.
-      return false;
+      auto *Ptr = GetUnderlyingObject(LI->getPointerOperand(), DL);
+      if (Ptr) {
----------------
However we end up with this, please minimize the number of calls to GetUnderlyingObject. That is actually the expensive part, and its redundant with the above code.

================
Comment at: lib/Analysis/GlobalsModRef.cpp:684-687
@@ +683,6 @@
+      if (Ptr) {
+        // If the object this is loaded from is itself captured, then this
+        // pointer must have been captured too.
+        Inputs.push_back(Ptr);
+        continue;
+      } else {
----------------
So, pushing this onto the worklist isn't quite what we want. And whatever we want, we shouldn't have the one-off check above, because whatever we want should work for the immediate pointer operand as well as N-deep pointer operands.

The loop we want for loads is substantially simpler than the one we are currently inside of, because we don't need to handle overridable global variables, the original global variable, whether things are sized, etc etc.

Once we are looking through a load, we can simply check for globals, calls, invokes, and arguments; and recurse through phis, selects, and subsequent loads. However, this also means we can't re-use the visited set. I think we should have a dedicated helper for recursing on load pointer operands, and pass the depth parameter into it. This will remove the need for some of the shuffling here.


Also, as a minor point, the issue is not capture, but escape. Even if the escape does not outlive a particular function, it can break this. However, as is mentioned above, we are relying on it being unreasonable for a transformation to introduce an escape of a global variable. This includes a direct escape (which the existing code relies upon) and an indirect escape (which your new logic relies upon).


Repository:
  rL LLVM

http://reviews.llvm.org/D13512