[ScopDetection] Use addUnknown for calls in the AliasSetTracker.

The general-purpose add() now sometimes adds unexpected loop-variant
pointers to the AliasSetTracker, so certain loops would be rejected with
-polly-allow-modref-calls.  Use addUnknown() instead, which has the old
behavior.

I'm not completely convinced the resulting behavior is actually
correct: ScopDetection::isValidAccess seems to mostly ignore
"unknown" instructions in the AliasSetTracker.  But it's not any worse
than what was happening before.

Committing without pre-commit review to unbreak the buildbots; the
following tests were failing:

test/ScopInfo/mod_ref_access_pointee_arguments.ll
test/ScopInfo/mod_ref_read_pointee_arguments.ll
test/ScopInfo/multidim_2d_with_modref_call_2.ll

1 files changed, 6 insertions, 2 deletions

diff --git a/polly/lib/Analysis/ScopDetection.cpp b/polly/lib/Analysis/ScopDetection.cpp
index 666ac34ea57..480589e1f22 100644
--- a/polly/lib/Analysis/ScopDetection.cpp
+++ b/polly/lib/Analysis/ScopDetection.cpp
@@ -717,7 +717,9 @@ bool ScopDetection::isValidCallInst(CallInst &CI,
       // Implicitly disable delinearization since we have an unknown
       // accesses with an unknown access function.
       Context.HasUnknownAccess = true;
-      Context.AST.add(&CI);
+      // Explicitly use addUnknown so we don't put a loop-variant
+      // pointer into the alias set.
+      Context.AST.addUnknown(&CI);
       return true;
     case FMRB_OnlyReadsArgumentPointees:
     case FMRB_OnlyAccessesArgumentPointees:
@@ -740,7 +742,9 @@ bool ScopDetection::isValidCallInst(CallInst &CI,
         Context.HasUnknownAccess = true;
       }
 
-      Context.AST.add(&CI);
+      // Explicitly use addUnknown so we don't put a loop-variant
+      // pointer into the alias set.
+      Context.AST.addUnknown(&CI);
       return true;
     case FMRB_DoesNotReadMemory:
     case FMRB_OnlyAccessesInaccessibleMem: