[PATCH] D11410: [GMR] Teach GlobalsModRef to distinguish an important and safe case of no-alias with non-addr-taken globals: they cannot alias a captured pointer.

Chandler Carruth chandlerc at gmail.com
Wed Jul 22 05:27:50 PDT 2015

chandlerc created this revision.
chandlerc added reviewers: hfinkel, mzolotukhin, pete.
chandlerc added a subscriber: llvm-commits.

If the non-global underlying object would have been a capture were it to
alias the global, we can firmly conclude no-alias. It isn't reasonable
for a transformation to introduce a capture in a way observable by an
alias analysis. Consider, even if it were to temporarily capture one
globals address into another global and then restore the other global
afterward, there would be no way for the load in the alias query to
observe that capture event correctly. If it observes it then the
temporary capturing would have changed the meaning of the program,
making it an invalid transformation. Even instrumentation passes or
a pass which is synthesizing stores to global variables to expose race
conditions in programs could not trigger this unless it queried the
alias analysis infrastructure mid-transform, in which case it seems
reasonable to return results from before the transform started.

See the comments in the change for a more detailed outlining of the
theory here.

This should address the primary performance regression found when the
non-conservatively-correct path of the alias query was disabled.

I haven't yet written a specific test case, but wanted to share the idea
of the technique with others to see if this is sufficiently promising to
be the preferred path forward.



Index: lib/Analysis/IPA/GlobalsModRef.cpp
--- lib/Analysis/IPA/GlobalsModRef.cpp
+++ lib/Analysis/IPA/GlobalsModRef.cpp
@@ -580,6 +580,60 @@
       if ((GV1 || GV2) && GV1 != GV2)
         return NoAlias;
+    // There are particular cases where we can conclude no-alias between
+    // a non-addr-taken global and some other underlying object. Specifically,
+    // a non-addr-taken global is known to not be captured by any function. It
+    // is also incorrect for a transformation to introduce a capture of
+    // a global in a way that is observable when it was not there previously.
+    // One function being transformed to introduce a capture which could
+    // possibly be observed (via loading from a global for example) within
+    // another function is never safe. If the observation is made through
+    // non-atomic operations on different threads, it is a data-race and UB. If
+    // the observation is well defined, by being observed the transformation
+    // would have changed program behavior by introducing the capture, making
+    // it an invalid transform.
+    //
+    // This property does require that transformation which *temporarily*
+    // capture a global that was not previously captured, prior to restoring
+    // it, cannot rely on the results of GMR::alias. This seems a reasonable
+    // restriction, although currently there is no way to enforce it. There is
+    // also no realistic optimization pass that would make this mistake. The
+    // closest example is a transformation pass which does reg2mem of SSA
+    // values but stores them into global variables temporarily before
+    // restoring the global variable's value. This could be useful to expose
+    // "benign" races for example. However, it seems reasonable to require that
+    // a pass which introduces captures of global variables in this way to
+    // either not trust AA results while the capture is active, or to be forced
+    // to operate as a module pass that cannot co-exist with an alias analysis
+    // such as GMR.
+    if ((GV1 || GV2) && GV1 != GV2) {
+      const GlobalValue *GV;
+      const Value *UV;
+      if (GV1) {
+        GV = GV1;
+        UV = UV2;
+      } else {
+        GV = GV2;
+        UV = UV1;
+      }
+      // In order to know that the underlying object cannot alias the
+      // non-addr-taken global, we must know that it would have to be an
+      // escape. Thus if the underlying object is a function argument, a load
+      // from a global, or the return of a function, it cannot alias.
+      if (isa<Argument>(UV) || isa<CallInst>(UV) || isa<InvokeInst>(UV)) {
+        // Arguments to functions or returns from functions are inherently
+        // capturing, so we can immediately classify those as not aliasing any
+        // non-addr-taken globals.
+        return NoAlias;
+      } else if (auto *LI = dyn_cast<LoadInst>(UV)) {
+        // A pointer loaded from a global would have been captured, and we know
+        // that GV is non-addr-taken, so no alias.
+        if (isa<GlobalValue>(LI->getPointerOperand()))
+          return NoAlias;
+      }
+    }
     // Otherwise if they are both derived from the same addr-taken global, we
     // can't know the two accesses don't overlap.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D11410.30342.patch
Type: text/x-patch
Size: 3344 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150722/e2ce5ad6/attachment.bin>

More information about the llvm-commits mailing list