[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