[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
git-svn-id: https://llvm.org/svn/llvm-project/polly/trunk@342010 91177308-0d34-0410-b5e6-96231b3b80d8
diff --git a/lib/Analysis/ScopDetection.cpp b/lib/Analysis/ScopDetection.cpp
index 666ac34..480589e 100644
--- a/lib/Analysis/ScopDetection.cpp
+++ b/lib/Analysis/ScopDetection.cpp
@@ -717,7 +717,9 @@
// 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 @@
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:
