[PATCH] D111460: [X86][LoopVectorize] "Fix" `X86TTIImpl::getAddressComputationCost()`

Roman Lebedev via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Oct 19 01:44:47 PDT 2021


lebedev.ri added a comment.

@RKSimon / @craig.topper thoughts on the diff?

In D111460#3072267 <https://reviews.llvm.org/D111460#3072267>, @pengfei wrote:

>>> I think the high cost might have practical consideration, e.g., impact some benchmarks etc.
>>
>> Sure, any change might have practical considerations, in either direction.
>
> I agree, but we should evaluate it carefully to make sure we get good than bad, right?

Or that it is at least a step in the right direction.

>>> IIUC, you are saying we prefer naive interleaving to scalarized gather, right?
>>
>> Quote please? Define we prefer?
>
> X86TargetTransformInfo.cpp:3853, "interleaved load is better in general in reality"

I mean, sure, wide load + shuffles should be better than many narrow scalar loads + chain of insertelement's.
Emphasis on *should*, this is not an ultimate truth.

>>> Can we make sure we always generate the interleaving sequence, e.g., when not have a constant stride?
>>
>> Why? I don't think we should be doing anything like that. It is up to the vectorizer
>> to pick the best sequence, given the cost estimates provided by TTI for each one.
>
> Only when the estimate is precise enough. Underestimating the cost of scalarized gather sequence will fool vectorizer in practice.
> IA optimization manual says gather/scatter is prefered, emulated gather/scatter cost shouldn’t be lower than real gather/scatter.

Yeah no, if this is what you believe we won't make progress here.


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