This is an archive of the discontinued LLVM Phabricator instance.

[SCEV] Drop cached ranges of AddRecs after flag update
ClosedPublic

Authored by mkazantsev on Oct 20 2020, 10:39 PM.

Details

Summary

Our range computation methods benefit from no-wrap flags. But if the ranges
were first computed before the flags were set, the cached range will be too
pessimistic.

We need to drop cached ranges whenever we sharpen AddRec's no wrap flags.

Diff Detail

Event Timeline

mkazantsev created this revision.Oct 20 2020, 10:39 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 20 2020, 10:39 PM
fhahn added inline comments.Oct 21 2020, 6:13 AM
llvm/include/llvm/Analysis/ScalarEvolution.h
1524

Is there a reason we don't do that for all SCEV expressions with wrapping flags? Might be good to document that this also invalidates cached info for AddRec, if it updates the flags and this should be use d from inside SE instead of AddRec->setNoWrapFlags. Not sure if there's a nice way to enforce users in SE to use SE::setNoWrapFlags.

nikic added inline comments.Oct 21 2020, 11:32 AM
llvm/lib/Analysis/ScalarEvolution.cpp
5522

Could it happen that other ranges have been computed in the meantime, based on the now outdated addrec range?

mkazantsev added inline comments.Oct 23 2020, 4:01 AM
llvm/lib/Analysis/ScalarEvolution.cpp
5522

Unfortunately yes. But tracking them would be expensive.

mkazantsev added inline comments.Oct 23 2020, 4:05 AM
llvm/include/llvm/Analysis/ScalarEvolution.h
1524

Sure, it can be done for adds/muls too. Can do as follow-up.

fhahn added inline comments.Nov 2 2020, 1:47 PM
llvm/lib/Analysis/ScalarEvolution.cpp
5522

Agreed, I do not think tracking this would be feasible unfortunately, but missing updates should be fine, as this should only refine the flags.

Can we assert here that Flags is a refinement of the existing flags on the AddREc?

mkazantsev updated this revision to Diff 303751.Nov 8 2020, 9:54 PM

Added elaborate comment, added assert that we don't pessimize the flags.

For some reason, it's no longer helpimg srem.ll. There has been a lot of related patches merged, one of them broke it?

fhahn accepted this revision.Nov 9 2020, 12:37 PM

Added elaborate comment, added assert that we don't pessimize the flags.

For some reason, it's no longer helpimg srem.ll. There has been a lot of related patches merged, one of them broke it?

I'm not sure, but I think @nikic had some patches that delay the flag computation in some cases, so maybe this caused the changes there?

Patch LGTM, thanks!

This revision is now accepted and ready to land.Nov 9 2020, 12:37 PM

I tried reverting that patch, but it didn't help. We can figure it out later I think.

llvm/test/Analysis/ScalarEvolution/srem.ll
32

Not sure w

mkazantsev added inline comments.Nov 9 2020, 8:55 PM
llvm/lib/Analysis/ScalarEvolution.cpp
5520

I realized it's not the right way to check it since the assert may never fail.

mkazantsev added inline comments.Nov 9 2020, 9:00 PM
llvm/lib/Analysis/ScalarEvolution.cpp
5520

Actually, setNoWrapFlags does not drop previous flags, so this assert is just pointless. I'll remove it.

Problem with srem solved after rebase. Weird...

This revision was automatically updated to reflect the committed changes.
fhahn added inline comments.Nov 10 2020, 2:11 AM
llvm/lib/Analysis/ScalarEvolution.cpp
5520

Ah right it already encodes this safety check. I guess it's not worth worrying about it here then, thanks!