[PATCH] D153519: [LegalizeTypes] Widen insert_subvector ops for fixed insert into scalable

Craig Topper via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jun 22 10:26:05 PDT 2023

craig.topper added a comment.

In D153519#4441792 <https://reviews.llvm.org/D153519#4441792>, @luke wrote:

> In D153519#4441716 <https://reviews.llvm.org/D153519#4441716>, @craig.topper wrote:
>> In D153519#4441673 <https://reviews.llvm.org/D153519#4441673>, @luke wrote:
>>> In D153519#4441316 <https://reviews.llvm.org/D153519#4441316>, @craig.topper wrote:
>>>> Is it possible for the widened type to exceed the minimum vscale?
>>> Yes, but I think that would still fall under the "If this condition cannot be determined statically but is
>>> false at runtime, then the result vector is undefined." part of insert_subvector's definition. Since we currently already lower an insert_subvector of e.g. v8i32 into nxv4i32
>> What if vscale min is 3(not possible for RISC-V but this is generic code), and the types are nxv1i64 and v3i64. The operation is defined for those types, but when v3i64 gets widened to v4i64 it becomes undefined.
> Right, I see now. Could we then lower it as a series of insert_vector_elt?

Yeah I think the ultimate fallback can be a series of insert_vector_elts. For the original failing case, it looks like we have the vscale_range attribute so we could use the minimum vscale to guarantee safety?

  rG LLVM Github Monorepo



More information about the llvm-commits mailing list