Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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 |
llvm/lib/Transforms/Scalar/LoopIdiomRecognize.cpp | ||
---|---|---|
994 | The value I'm thinking of might be ContinuationIndentWidth = 4; |
llvm/lib/Transforms/Scalar/LoopIdiomRecognize.cpp | ||
---|---|---|
994 | OK yeah I think you're right. Should be 4 spaces. |
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. |
llvm/lib/Analysis/ScalarEvolution.cpp | ||
---|---|---|
8049 |
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. |
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. |
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.