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?