arsenm wrote:
> On the other hand, it's a lot easier to handle ugly types down in instruction
> selection, where you get to play much more fast and loose with types.
I think it's mostly easier to do this in the IR
>
> And there are buffer uses that don't fit into the fat pointer use use case
> where we'd still want them to work. For example, both `str
> uct.ptr.bufferload.v6f16` and `struct.ptr.buffer.load.v3f32` should be a
> `buffer_load_dwordx3`, but I'm pretty sure 6 x half isn't a register type.
Yes, we should just fix this one
>
> The load and store intrinsics are already overloaded to handle various {8,
> 16, ..., 128}-bit types, and it seems much cleaner to let it support any type
> of those lengths. It's just a load/store with somewhat weird indexing
> semantics, is all.
Splitting is pretty ugly too, especially for a truly arbitrary type in
legalization.
https://github.com/llvm/llvm-project/pull/95379
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
