[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