This is an archive of the discontinued LLVM Phabricator instance.

[SCEV] Apply guards to max with non-unitary steps.
ClosedPublic

Authored by fhahn on May 11 2021, 11:42 AM.

Details

Summary

We already apply loop-guards when computing the maximum with unitary
steps. This extends the code to also do so when dealing with non-unitary
steps.

This allows us to infer a tighter maximum in some cases.

Diff Detail

Event Timeline

fhahn created this revision.May 11 2021, 11:42 AM
fhahn requested review of this revision.May 11 2021, 11:42 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 11 2021, 11:42 AM
nikic added inline comments.May 11 2021, 12:13 PM
llvm/lib/Analysis/ScalarEvolution.cpp
9269

Is there any particular reason to believe that this assertion can't be hit? The unit step case takes the minimum and has a test for this (@guard_pessimizes_analysis). Or is the assert here so we can find a test case?

On a related note, I wonder if we shouldn't be limiting the guard insertion to comparisons against constants. That case should be non-pessimizing, and at least none of the existing tests benefit from non-constant guards.

fhahn updated this revision to Diff 344924.May 12 2021, 1:04 PM

Add test where applying guards pessimizes range (96c1fa2a041d), replace assert with conditional assignment.

fhahn added inline comments.May 12 2021, 1:07 PM
llvm/lib/Analysis/ScalarEvolution.cpp
9269

Is there any particular reason to believe that this assertion can't be hit? The unit step case takes the minimum and has a test for this (@guard_pessimizes_analysis). Or is the assert here so we can find a test case?

I was overly optimistic. But I added a variant of @guard_pessimizes_analysis that would trigger the assert. Replaced that with a conditional assignment.

On a related note, I wonder if we shouldn't be limiting the guard insertion to comparisons against constants. That case should be non-pessimizing, and at least none of the existing tests benefit from non-constant guards.

I think in theory rewriting with non-constants could also help in some cases, but probably not in practice at the moment. I'm planning to look into that separately, possible to also help with pessimizing results after applying guards.

nikic accepted this revision.May 12 2021, 1:31 PM

LGTM

llvm/lib/Analysis/ScalarEvolution.cpp
9269

On a related note, I wonder if we shouldn't be limiting the guard insertion to comparisons against constants. That case should be non-pessimizing, and at least none of the existing tests benefit from non-constant guards.

I think in theory rewriting with non-constants could also help in some cases, but probably not in practice at the moment. I'm planning to look into that separately, possible to also help with pessimizing results after applying guards.

To avoid pessimization, we could do something like this: For LHS ule RHS rewrite to umin(LHS, getUnsignedRangeMax(RHS)) rather than umin(LHS, RHS). Though I suspect that for practical purposes, just limiting to constants would be fine.

9272

Max = getConstant(APIntOps::umin(MaxInt, BaseMaxInt)) maybe?

This revision is now accepted and ready to land.May 12 2021, 1:31 PM
This revision was automatically updated to reflect the committed changes.