[PATCH] D98240: [VectorCombine] Simplify to scalar store if only one element updated

Hendrik Greving via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed May 26 07:01:56 PDT 2021


hgreving added a comment.

In D98240#2781262 <https://reviews.llvm.org/D98240#2781262>, @fhahn wrote:

> In D98240#2781048 <https://reviews.llvm.org/D98240#2781048>, @hgreving wrote:
>
>> For targets not supporting scalar load from vector memory (like ours), this breaks it:
>>
>>   %43 = load <8 x i32>, <8 x i32> addrspace(201)* %1, align 32, !tbaa !28
>>   %44 = extractelement <8 x i32> %43, i32 0
>>
>> Now:
>>
>>   %43 = getelementptr inbounds <8 x i32>, <8 x i32> addrspace(201)* %1, i32 0, i32 0
>>   %44 = load i32, i32 addrspace(201)* %43, align 32
>>
>> Are targets expected to provide patterns?
>
> Interesting! I guess the code assumes that a scalar load is always possible & at least as cheap as the vector version. But I think it would make sense to ask the cost-model if that's the case. Not sure if it would be possible to test this with an in-tree target?

Hi tanks for getting back to me. I'm not sure if it's a cost model question, a straight-up disable switch for not morphing vector derefs into scalar might be better? Is there anything else in this pass that might do that? Unfortunately yes, I think there's no proper upstream target with this constraint. Though I am guessing I am not the only downstream target with a vector memory like that. The problem with trying to make this work is that I am worried about what happens to the pointer. Will I always be able to rely on that it will be aligned, probably not...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98240



More information about the llvm-commits mailing list