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

Qiu Chaofan via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun May 30 19:10:58 PDT 2021


qiucf added a comment.

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

> In D98240#2782010 <https://reviews.llvm.org/D98240#2782010>, @hgreving wrote:
>
>>> 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 thanks 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...
>
> I guess it depends on whether the backend can legalize/convert back to a vector load. In general, relying on the middle-end to no scalarize those loads for correctness seems a bit fragile. I'm not sure if it makes sense to add a TTI hook that's not used by any in tree targets.
>
> @qiucf would you be able to look into extending the code to check for the cost?

I'll look into it, thanks. Sorry for the late notice.


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