[PATCH] D94088: [SCEV] Assumption context for GetMinTrailingZeros

Gil Rapaport via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jan 25 16:27:54 PST 2021


gilr added a comment.

In D94088#2519311 <https://reviews.llvm.org/D94088#2519311>, @lebedev.ri wrote:

> I would expect that the SCEV change could be testable with just the scev itselfs (`-analyze -scalar-evolution`), is it not?

Right, will add a unit test for this API.

In D94088#2519327 <https://reviews.llvm.org/D94088#2519327>, @fhahn wrote:

> I think the fix makes sense in isolation, but I am wondering if we could generalize this to automatically apply in more cases. Would it be possible to 'apply' the information from the loop guard directly to the SCEV expression? Like we do for some conditions already: https://github.com/llvm/llvm-project/blob/master/llvm/lib/Analysis/ScalarEvolution.cpp#L13241 ?

Will take a look at that. Thanks!



================
Comment at: llvm/lib/Analysis/ScalarEvolution.cpp:5611-5615
+  if (!CxtI) {
+    auto I = MinTrailingZerosCache.find(S);
+    if (I != MinTrailingZerosCache.end())
+      return I->second;
+  }
----------------
lebedev.ri wrote:
> Doesn't this defy the point of the cache?
> I think `MinTrailingZerosCache`'s key should be changed to be a `std::pair<SCEV*,CxtI*>`
> Doesn't this defy the point of the cache?

This API seems to be used extensively. Since (for now) only the unroller and vectorizer would be providing a non-null context I wasn't sure caching those calls was worth the added space/time of extending the key.

> I think MinTrailingZerosCache's key should be changed to be a std::pair<SCEV*,CxtI*>

Will do.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D94088/new/

https://reviews.llvm.org/D94088



More information about the llvm-commits mailing list