This is an archive of the discontinued LLVM Phabricator instance.

[SCEV] Skip instrs with non-scevable types in forget[Loop,Value].
ClosedPublic

Authored by fhahn on Feb 27 2023, 12:49 AM.

Details

Summary

No SCEVs are formed for instructions with non-scevable types, so no
other SCEV expressions can depend on them. Skip those instructions and
their users when invalidating SCEV expressions.

To catch potential missed cases, the full def-use chains are traversed
after the cleanup to assert no entries in ValueExprMap remain.

Depends on D144847.

Diff Detail

Event Timeline

fhahn created this revision.Feb 27 2023, 12:49 AM
fhahn requested review of this revision.Feb 27 2023, 12:49 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 27 2023, 12:49 AM
nikic added inline comments.Feb 27 2023, 12:55 AM
llvm/lib/Analysis/ScalarEvolution.cpp
8411

Hm, isn't the verification supposed to omit this check?

mkazantsev added a comment.EditedFeb 27 2023, 3:42 AM
This comment has been deleted.
llvm/include/llvm/Analysis/ScalarEvolution.h
2049 ↗(On Diff #500689)

typo: Worlist -> Worklist

llvm/lib/Analysis/ScalarEvolution.cpp
8411

I guess we can skip it. We can't have them in ValueExprMap anyways.

Should this be under VerifySCEV ?

mkazantsev added inline comments.Feb 27 2023, 8:18 PM
llvm/lib/Analysis/ScalarEvolution.cpp
8411

Maybe even assert on that.

fhahn updated this revision to Diff 501606.Mar 1 2023, 11:36 AM

Adjust condition to skip instructions in verifyAllUsersClearedFromMap.

fhahn marked 3 inline comments as done.Mar 1 2023, 11:48 AM

Should this be under VerifySCEV ?

The main reason I didn't use VerifySCEV is that this would require a check of the VerifySCEV variable on each verifyAllUsersClearedFromMap, whereas with the current setup it is free for builds without assertions.

llvm/lib/Analysis/ScalarEvolution.cpp
8411

The issue is that non-SCEVable instructions can be operands for SCEVable instructions (e.g. a floating point instruction used by an fcmp). I think in all those cases, the SCEV-able instruction needs to be a SCEVUnknown and the SCEV def-use chain is broken and we should be able to stop invalidation for this instruction.

I updated the condition to more explicitly check for this.

fhahn updated this revision to Diff 501613.Mar 1 2023, 11:49 AM
fhahn marked an inline comment as done.

Also fix typo

fhahn marked an inline comment as done.Mar 1 2023, 11:49 AM
fhahn added inline comments.
llvm/include/llvm/Analysis/ScalarEvolution.h
2049 ↗(On Diff #500689)

Fixed, thanks!

mkazantsev accepted this revision.Mar 3 2023, 2:14 AM

LG, thanks!

This revision is now accepted and ready to land.Mar 3 2023, 2:14 AM
nikic added inline comments.Mar 6 2023, 2:05 PM
llvm/lib/Analysis/ScalarEvolution.cpp
8411

I think the general change here is right, but I'm not sure this verification is actually verifying anything useful. We aren't going to invalidate the same set of values (by design), so there doesn't really seem anything to verify.

My understanding of this change is that we only want to visit users for which the value may contribute towards the user's SCEV expression. Non-scevable types are one case that can never contribute. The other are instructions that always produce SCEVUnknown, e.g. it doesn't really make sense to follow the use chain across a load regardless of which types it works on (this is probably more common than non-scevable types).

The caveat here is that while they cannot contribute towards SCEVs, it's still theoretically possible to contribute towards cached analysis results, e.g. a SCEVUnknown could be caching no longer valid ValueTracking results.

fhahn marked 2 inline comments as done.Mar 7 2023, 1:42 AM
fhahn added inline comments.
llvm/lib/Analysis/ScalarEvolution.cpp
8411

The current verification here is not super useful for the change here itself, the main use case where it would become more useful should be D144849. I can also just remove it from the current patch.

nikic added inline comments.Mar 7 2023, 1:47 AM
llvm/lib/Analysis/ScalarEvolution.cpp
8411

In that case I'd drop it from this patch.

fhahn updated this revision to Diff 517911.Apr 28 2023, 7:10 AM
fhahn marked an inline comment as done.

Strip off verification. I'll update the description and I am planning on committing this soon.

This revision was landed with ongoing or failed builds.Apr 28 2023, 7:37 AM
This revision was automatically updated to reflect the committed changes.