[PATCH] D102766: [SelectionDAG] Implement PromoteIntRes_INSERT_SUBVECTOR

Eli Friedman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jul 6 08:57:12 PDT 2021


efriedma added a comment.

In D102766#2859581 <https://reviews.llvm.org/D102766#2859581>, @bsmith wrote:

> In D102766#2858467 <https://reviews.llvm.org/D102766#2858467>, @efriedma wrote:
>
>> In D102766#2857778 <https://reviews.llvm.org/D102766#2857778>, @bsmith wrote:
>>
>>> In D102766#2853500 <https://reviews.llvm.org/D102766#2853500>, @efriedma wrote:
>>>
>>>> Sorry about the late reply here, but I'm not sure why PromoteIntRes_INSERT_SUBVECTOR needs to go through the stack.  Can't you just ANY_EXTEND the operand and the result?
>>>>
>>>> At that point, you might end up with a node that needs to be legalized by PromoteIntOp_INSERT_SUBVECTOR, but better to take legalization one step at a time.
>>>
>>> I'm not sure I fully understand how you are thinking this would look, bare in mind that we also need to handle inserting scalable into scalable here.
>>>
>>> If you had something like:
>>>
>>>   %ins = call <vscale x 4 x i16> @llvm.experimental.vector.insert.nxv4i16.nxv2i16(<vscale x 4 x i16> %vec, <vscale x 2 x i16> %subvec, i64 4)
>>>
>>> and you promoted all of the scalable types to their equivalent legal types you'd end up with:
>>>
>>>   %ins = call <vscale x 4 x i32> @llvm.experimental.vector.insert.nxv4i16.nxv2i16(<vscale x 4 x i32> %vec, <vscale x 2 x i64> %subvec, i64 4)
>>>
>>> This ends up no longer being a valid use of vector.insert since the element types differ.
>>
>> Right.  My suggestion is that you promote from:
>>
>>   %ins = call <vscale x 4 x i16> @llvm.experimental.vector.insert.nxv4i16.nxv2i16(<vscale x 4 x i16> %vec, <vscale x 2 x i16> %subvec, i64 1)
>>
>> to:
>>
>>   %ins = call <vscale x 4 x i32> @llvm.experimental.vector.insert.nxv4i32.nxv2i32(<vscale x 4 x i32> %vec, <vscale x 2 x i32> %subvec, i64 1)
>>
>> This isn't legal, but we need code to handle it anyway.
>
> Are you suggesting to still go through memory but to do it during operand legalization instead?

Yes, sort of...

In some cases, we might not end up going through memory; we currently have some custom lowering support for some special cases, and might add more cases in the future.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102766



More information about the llvm-commits mailing list