[polly] [Polly] Guard ISL ast gen compute out (PR #201859)

[Shikhar Jain via llvm-commits]

================
@@ -717,34 +717,44 @@ bool Dependences::isParallel(__isl_keep isl_union_map *Schedule,
                              __isl_give isl_pw_aff **MinDistancePtr) const {
   isl_set *Deltas, *Distance;
   isl_map *ScheduleDeps;
-  unsigned Dimension;
+  int Dimension;
   bool IsParallel;
 
   Deps = isl_union_map_apply_range(Deps, isl_union_map_copy(Schedule));
   Deps = isl_union_map_apply_domain(Deps, isl_union_map_copy(Schedule));
+  isl_bool UnionMapIsEmpty = isl_union_map_is_empty(Deps);
 
-  if (isl_union_map_is_empty(Deps)) {
+  if (UnionMapIsEmpty != isl_bool_false) {
     isl_union_map_free(Deps);
-    return true;
+    return UnionMapIsEmpty == isl_bool_true;
   }
 
   ScheduleDeps = isl_map_from_union_map(Deps);
+  // In the event isl_map_dim() returns isl_size_error which is -1
+  // then Dimension being an unsigned variable would store a very large
+  // wrap-around value. This could result in compilation issues like indefinite
+  // hang. Thus changed Dimension into an signed integer storage
   Dimension = isl_map_dim(ScheduleDeps, isl_dim_out) - 1;
 
-  for (unsigned i = 0; i < Dimension; i++)
+  if (Dimension < 0) {
+    isl_map_free(ScheduleDeps);
+    return false;
----------------
ShikharJ-Corp wrote:

Good point on the conservatism, and agreed on the underlying fact: dependence analysis is a conservative may-analysis, so a false here is an overapproximation . it can report a dependence that never actually materializes at runtime. I'd treat that as imprecision within the false result itself,  a separate problem that lives inside the false bucket  -> rather than something that makes false and error() equivalent.

The reason I kept the third state is that these outcomes differ along two independent axes, not one:

- did the analysis actually conclude anything? true and false are both results of a successful, completed analysis: true = it proved no dependence (parallel), false = it proved a dependence exists (i.e. it affirmatively proved a potential race condition). error() is different in kind — the analysis never completed (operation quota exhausted / null input), so it makes no claim at all. That's "proved" vs. "unknown," which is orthogonal to "parallel" vs. "not parallel."

- Future-resolvability. Because true/false come from a successful analysis, a more precise algorithm (e.g. one that reasons about runtime behavior) can legitimately move a case between them — a conservatively-reported dependence that doesn't occur at runtime would resolve false → true, and a real one stays false. An error() case can never be resolved this way: no amount of added precision recovers an analysis that ran out of budget. It is a permanently distinct category.

Collapsing error() into false would re-introduce exactly the overloaded-false conflation 
where a mechanical failure ("couldn't compute, so couldn't rule out a race") was indistinguishable from a computed result ("proved a dependence exists"), and then went on to mutate the reduction-related NodeInfo state .

https://github.com/llvm/llvm-project/pull/201859