[PATCH] D111460: [X86][LoopVectorize] Fix `LoopVectorizationCostModel::getMemInstScalarizationCost()`

Roman Lebedev via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Oct 11 07:08:28 PDT 2021


lebedev.ri added a comment.

In D111460#3054336 <https://reviews.llvm.org/D111460#3054336>, @dmgreen wrote:

>> I see. While it does really look that way, i maintain that this is not intentional and just a bug/leftover from the D27919 <https://reviews.llvm.org/D27919> rework.
>> To know for sure we'd have to ask the patch's author (@delena), but there is no recent activity on that account, so don't really expect to get an answer.
>
> It sure has changed over time, but the use of getAddressComputationCost before and after that patch looks the same to me. Only the call inside "Legal->memoryInstructionMustBeScalarized(I, VF)" was passing a SCEV through to getAddressComputationCost.
>
>>> There is no scev for vectors, and so no LSR for vector addresses and pulling address values out of vectors can be very slow. Perhaps that can be improved over time.
>>
>> Sure. But i'm not really following. Where do we pull address values out of vectors?
>> This approach (as opposed to D111220 <https://reviews.llvm.org/D111220>) specifically does not result in any vector GEP's.
>
> Something like this code is what I was looking at: https://godbolt.org/z/sj57EaGzc. Hopefully that does enough extra work to overcome the additional cost with this patch, but uses a pragma in that example (I believe it produces the same code, without legal gather/scatters). It does the address computation for the store in vectors, and then transfers those over to scalars.

Aha, that is a great point! Posted D111546 <https://reviews.llvm.org/D111546>.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111460/new/

https://reviews.llvm.org/D111460



More information about the llvm-commits mailing list