[PATCH] D41689: [SCEVAA] Don't crash on pointers with no dominance relationship.

Daniel Berlin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 5 14:01:23 PST 2018


dberlin added a comment.

First, it's definitely the case that you can't compute the difference for all SCEVs.  It's equivalent to being able to symbolically executing the program with only static information :)

It is possible to compute the difference between the expressions in some cases,  using symbolic execution to come up with path sensitive symbolic answers.
Given alias() is giving all-paths answers, you'd need to meet those answers over all paths anyway.

It's possible that gives you a better answer than "no idea" (IE you discover that on any path, they cannot alias).

It's almost certainly not worth it.

Dominance checking is basically shortcutting this to try to difference them only when you can prove that all paths must lead to computing the result :)



================
Comment at: lib/Analysis/ScalarEvolutionAliasAnalysis.cpp:101
+  return !BottomA || !BottomB || DT.dominates(BottomA, BottomB) ||
+         DT.dominates(BottomB, BottomA);
+}
----------------
FWIW: This rediscovers the same info again and again .
But i'm not sure it's that slow.

IE you could cache scev->largest domtree dfs number interval, and only have to do this computation once per scev.
In fact, it also speeds up the other computation if you want

IE if the dom tree dfs in/out numbers for scev A are {50, 75}, when you call GetBottom on scev B, the second you see an operand with a set of dfs numbers that is either not between those or not encompassing those, there is no dominance relationship between the scevs and you can stop.

(Of course, then you can't cache the dfs number pair for that scev, but ...)

It's fine if you want to leave all this as a comment, i don't know if it's slow enough to be worth doing atm.


Repository:
  rL LLVM

https://reviews.llvm.org/D41689





More information about the llvm-commits mailing list