ekalda commented on PR #15918:
URL: https://github.com/apache/tvm/pull/15918#issuecomment-1764716961
> * So, I had to look into adding zextend, sextend, truncate plus the
vectorpermute, vectorshuffle instead.
> The good point is that these are lowered to exactly what is needed (even
single insn, optim) for the target arch (x86 here).
Yes, all of these intrinsics are architecture independent in LLVM, so this
is a great addition from the point of other backends as well.
Regarding to using `AllocateConst`, I agree that it is designed (and named)
with the intent of holding larger chunks of runtime data, but it is still
essentially a TIR container for constants that you can query in the LLVM
codegen.
> * There are already the `{Float,Int,String}Imm` so why not `ArrayIntImm`.
`{Float,Int,String}Imm` are not duplicating functionality :)
> * See the simple usage from python: `tir.vectorpermute("int32x8",
whatever_vector, [0, 1, 4, 5, 2, 3, 6, 7])`
```
idx_vec = T.allocate_const([0, 1, 4, 5, 2, 3, 6, 7], "int32")
tir.vectorpermute("int32x8", whatever_vector, idx_vec)
```
is not more complex in my opinion :) I appreciate the convenience of
printing the index array inplace in TIR though.
In general, I won't argue against this change if there is a wider consensus
that this is a necessary addition. However, I think we have to think carefully
about adding another mechanism into TIR for representing data arrays that is
opaque to the memory planning. From what I can see, there are no restrictions
to the size of the data it can hold, so it's rather susceptible to misuse.
> I also follow your RFC related to scalable vectors, I am interested in
similar ideas for the riscv64 "v" extension.
That's cool! Yes, I hope we can come up with a design that is going to work
for all the scalable vector architectures out there. Feel free to chip in with
your thoughts there!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
