[PATCH] D39082: [IRCE] Smarter detection of empty ranges using SCEV

Max Kazantsev via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Oct 19 21:21:13 PDT 2017


mkazantsev added inline comments.


================
Comment at: lib/Transforms/Scalar/InductiveRangeCheckElimination.cpp:185
+      else
+        return SE.isKnownPredicate(ICmpInst::ICMP_UGE, Begin, End);
+    }
----------------
anna wrote:
> SCEV's isKnownPredicate is actually really good in most cases to identify the empty range (BEGIN >= END). 
> However, there's a stronger version of isKnownPredicate in `DependenceInfo::isKnownPredicate`. 
> 
> Specifically, it first checks SCEV's version of isKnownPredicate and if it fails, it does a further analysis using the Delta between Begin and End and checking the Delta based on the predicate passed in. 
> 
> I'm wondering if SCEV's form maybe weaker and hence we may fire the assert added about empty ranges at line 1756?
Assert on 1756 should never fire. If you look into `IntersectRange`, we check range on `isEmpty()` and return `None` if it is true. We make check before return and check in assert with the same `isEmpty()`, so we just cannot end up with one returning true and another returning false.

Thanks for pointing me out of `DependenceInfo::isKnownPredicate`, I will see if I can use it here.


================
Comment at: test/Transforms/IRCE/empty_ranges.ll:9
+; The intersection with safe iteration space is the empty range [60, 10).
+; It is better to eliminate one range check than attempt to eliminate both given
+; that we will never go to the main loop in the latter case and basically
----------------
anna wrote:
> So, in this case, from now on, only the first range check is removed, i.e. we will not remove range checks where the safe iteration space intersected with the "true" iteration space is empty. By true iteration space, I mean, the set where the guard is always true.
That was the intension. Checks in pre- and postloop are not eliminated, and if the safe iteration space is empty, we will never get to the mainloop (where something was removed). Removing at least something from the main loop which remains reachable may be good by itself. For example, if there was a load between range checks 1 and 2, we can now correctly hoist it out of the main loop because it becomes guaranteed to execute now.


https://reviews.llvm.org/D39082





More information about the llvm-commits mailing list