This is an archive of the discontinued LLVM Phabricator instance.

[SCEV] Common code for computing trip count in a fixed type [NFC-ish]
ClosedPublic

Authored by reames on Apr 18 2023, 2:14 PM.

Details

Summary

This is a follow on to D147117 and D147355. In both cases, we were adding special cases to compute zext(BTC+1) instead of zext(BTC)+1 when the BTC+1 computation was known not to overflow.

Diff Detail

Event Timeline

reames created this revision.Apr 18 2023, 2:14 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 18 2023, 2:14 PM
reames requested review of this revision.Apr 18 2023, 2:14 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 18 2023, 2:14 PM
craig.topper added inline comments.Apr 18 2023, 4:09 PM
llvm/lib/Analysis/ScalarEvolution.cpp
8073

"need to need to"

llvm/lib/Transforms/Scalar/LoopFlatten.cpp
318–320

counts -> count's ?

319

"avoid by widening"

llvm/lib/Transforms/Scalar/LoopIdiomRecognize.cpp
994

Isn't clang-format for line wrap 4 spaces of indention?

caojoshua added inline comments.Apr 18 2023, 8:36 PM
llvm/lib/Analysis/ScalarEvolution.cpp
8049

Does this break existing calls to getTripCountFromExitCount()? Now all trip counts will be ZeroExtended.

Although this is not breaking any current tests, I do have https://reviews.llvm.org/D141823 open which depends on removing the zext when possible when computing trip multiples.

8066

no need for if here

return L && isLoopEntryGuardedByCond...

Also, not sure if its better, but I think computing applyLoopGuards(ExitCount, L) and then checking the RangeRef of the resulting SCEV will supersede isLoopEntryGuardedByCond and probably cover more other cases.

8076

unnecessary brackets

I believe this should be !CanAddOneWithoutOverflow(). If its true, then there is no reason to zext.

llvm/lib/Transforms/Scalar/LoopIdiomRecognize.cpp
994

I think 2 spaces is correct. If I run

clang-format -style=llvm -dump-config > .clang-format

I see IndentWidth: 2 and UseTab: Never

craig.topper added inline comments.Apr 18 2023, 9:11 PM
llvm/lib/Transforms/Scalar/LoopIdiomRecognize.cpp
994

The value I'm thinking of might be ContinuationIndentWidth = 4;

caojoshua added inline comments.Apr 18 2023, 9:24 PM
llvm/lib/Transforms/Scalar/LoopIdiomRecognize.cpp
994

OK yeah I think you're right. Should be 4 spaces.

reames added inline comments.Apr 20 2023, 1:07 PM
llvm/lib/Analysis/ScalarEvolution.cpp
8049

It does not. We know this because returning the wider type was the interface of this function before your recent change.

As for your second point, relying on a narrower type being returned (instead of doing the inference) is highly suspicious. You can rebase here and propose a follow on if needed.

llvm/lib/Transforms/Scalar/LoopFlatten.cpp
319

In the original text. I didn't want to reword as I wasn't 100% sure I understood the intent.

reames updated this revision to Diff 515449.Apr 20 2023, 1:10 PM

Address style comments

caojoshua accepted this revision.Apr 20 2023, 8:56 PM
caojoshua added inline comments.
llvm/lib/Analysis/ScalarEvolution.cpp
8049

As for your second point, relying on a narrower type being returned (instead of doing the inference) is highly suspicious.

I think its fair to simplify a SCEV as much as possible so that inference does not have to do as much work. The change does not rely on a narrower type, but it does rely on the +1 getting folded into the zext. It is explained in https://reviews.llvm.org/D147117.

This revision is now accepted and ready to land.Apr 20 2023, 8:56 PM
This revision was landed with ongoing or failed builds.Apr 25 2023, 12:05 PM
This revision was automatically updated to reflect the committed changes.
reames added inline comments.Apr 25 2023, 12:17 PM
llvm/lib/Analysis/ScalarEvolution.cpp
8049

I finally figured out the confusion here. My landed patch was adjusted to use the other routine, and should address your concern here.