[llvm] [SLP][NFC] Refactor vectorizeStores::RangeSizes (PR #177241)

[Ryan Buchner via llvm-commits]

bababuck wrote:

> I rather doubt it can be marked as NFC. It changes the processing, so we need to find a case, which is affected by this change

The intention is that no change in processing occurs (though my logic could be flawed). I'll look into some of the compile time tests to see if any of the changes aren't just from random jitter.

In `vectorizeStores::tryToVectorize()`, there is a main `while` loop, and within that loop, we iterate over `CandidateVFs`.
Candidate VF's contains different values each iteration:
0th iteration: `CandidateVFs = {MaxVF <= MaxRegVF, MaxVF / 2, ..., MinVF}`
1st iteration: `CandidateVFs = {Limit (optional such that MaxRegVF * 2 < Limit < MaxRegVF * 4), MaxRegVF * 2}`
2nd iteration: `CandidateVFs = {Limit (optional such that MaxRegVF * 4 < Limit < MaxRegVF * 8), MaxRegVF * 4}`
3rd iteration: `CandidateVFs = {Limit (optional such that MaxRegVF * 8 < Limit < MaxRegVF * 16), MaxRegVF * 8}`

Previously, when updating `RangeSizes`, we update `second` if `VF >= MaxRegVF`, otherwise we update `first`.
When looking up values in `RangeSizes`, we reference `first` if `VF >= MaxRegVF`, otherwise we reference `second`.

After iterating though all `CandidateVFs` (end of the `while` loop), we update `RangeSizes.first` with the values from `RangeSizes.second`.

The behavior is that the VFs from a given iteration don't see the effects of prior VFs from the same iteration, but see the values from all prior iterations, with the exception of the `0th` iteration where if the first element is `MaxRegVF` then it will affect the other VFs in the `0th` iteration.

With this change, we always update `RangeSizes.second` and always look up from `RangeSizes.first`. We update `RangeSizes.first` with values from `RangeSizes.second` after iterating through all `CandidateVFs` or mid-iteration if `VF == MaxRegVF`.

https://github.com/llvm/llvm-project/pull/177241