krzysz00 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.
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.
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.
And then, since we're there ... `load i256, ptr addrspace(1) %p` legalizes to
multiple instructions, and `{raw,struct}.ptr.buffer.load(ptr addrspace(8) %p,
i32 %offset, ...)` should too. It's just a load, after all.
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
