This untangles some of the logic in widenIntOrFpInduction, which was quite necessary IMHO as the different cases was extremely difficult to follow and read. So I've removed/replaced this with more straigth-line code, which I would like to do first before making some other functional changes. Most of the times I directly commit NFC patches, but here I would like to get feedback as this is a little bit of a rewrite.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
1813 | Instead of implicitly setting Step in the lambdas, would it be possible to have the closures return the step/IV they create and take it as argument if required? | |
1827–1828 | Comment seems out of place now. | |
1851–1852 | The comment seems a bit out of place now, should it be around line 1910? | |
1852–1854 | it might be good to make the VF, Part and Step explicit parameters here (and potentially other places) to make things a bit more explicit at the call sites. |
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
1817–1826 | Seems like it may be good to pass in ID.getStep() as an explicit parameter, as it forms the basis of the step being created. | |
1824 | ||
1832–1833 | +1 about the first part of the original comment "If we haven't yet vectorized the induction variable..." seeming out of place here now. // The scalar value to broadcast. This will be derived from the canonical // induction variable. | |
1851–1852 | +1 | |
1864 | Is CreateScalarIVCode() really needed, instead of invoking Value *ScalarIV = CreateScalarIV(Step); CreateSplatIV(ScalarIV, Step); directly, as done below before calling buildScalarSteps()? | |
1887 | Can continue early-exiting by doing next if (!NeedsScalarIV) { createVectorIntOrFpInductionPHI(ID, Step, EntryVal); return; } cleaning up the checks for NeedsScalarIV below. |
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
1864 | Ha, that's funny: no, we don't need it. Probably I stared too long at this code to notice this duplication and it is indeed the same as: Value *ScalarIV = CreateScalarIV(Step); CreateSplatIV(ScalarIV, Step); which was actually also my intention. You're exactly right about:
I wanted to have a one-liner: CreateSplatIV(CreateScalarIV(Step), Step); but that's indeed not possible because Step may change. | |
1887 | Ah, many thanks. That cleans up things even more and this function is becoming a real beauty with just straight-line code. |
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
1822 | There's one more ID.getStep() >> Step | |
1882–1883 | Not sure where this first "If an induction ... doesn't need to be widened" sentence belongs now, but it doesn't fit here. |
- replaced ID.getStep() -> Step
- removed the sentence on line 1899 - 1900, and
- moved the comments on lines 1900 - 1904 to 1889.
This looks good to me, thanks. The title should be more descriptive, e.g., "[LV] Refactor widenIntOrFpInduction, NFC".
Please wait a day or so to see if @fhahn or @samparker have further comments.
Will do, and many thanks for all your reviews!
And just fyi, I've uploaded work-in-progress patch D76838 that builds on top of this refactoring.
Instead of implicitly setting Step in the lambdas, would it be possible to have the closures return the step/IV they create and take it as argument if required?