r286389 updates UP.Count unconditionally when considering complete unroll of loop with compile-time known TripCount.
This can overwrite UP.Count retrieved by getUnrollingPreferences().
Details
- Reviewers
• zinob mzolotukhin evstupac
Diff Detail
- Repository
- rL LLVM
Event Timeline
I agree that r286389 have changed behavior.
However to prevent this in future would you mind to add a test case?
This issue was found in our in-house branch with custom TTI::getUnrollingPreferences()... not easy to produce a test case.
lib/Transforms/Scalar/LoopUnrollPass.cpp | ||
---|---|---|
785 | Will it work if we put UP.Count change under FullUnrollTripCount condition? |
lib/Transforms/Scalar/LoopUnrollPass.cpp | ||
---|---|---|
761 | I think you need to set UP.Count in this situation, too. |
lib/Transforms/Scalar/LoopUnrollPass.cpp | ||
---|---|---|
761 | Sorry, never mind. |
This issue was found in our in-house branch with custom TTI::getUnrollingPreferences()... not easy to produce a test case.
It looks like no one from trunk targets has UP.Count set in Unroll Preferences. So to add a test we'll need to add an option setting UP.Count default.
LGTM if all tests are passed.
Will it work if we put UP.Count change under FullUnrollTripCount condition?
If we leave the change as is it could happen that for full unroll UP.Count is less than MaxTripCount. Which is not ok.
Also could you please add context to the patch:
svn diff --diff-cmd=diff -x -U999999