They correspond to BUFFER_LOAD/STORE_FORMAT_XYZW and will be used by Mesa
to implement the GL_ARB_shader_image_load_store extension.
The intention is that for llvm.amdgcn.buffer.load.format, LLVM will decide
whether one of the _X/_XY/_XYZ opcodes can be used (similar to image sampling
and loads). However, this is not currently implemented.
For llvm.amdgcn.buffer.store, LLVM cannot decide to use one of the "smaller"
opcodes and therefore the intrinsic is overloaded. Currently, only the v4f32
is actually implemented since GLSL also only has a vec4 variant of the store
instructions, although it's conceivable that Mesa will want to be smarter
about this in the future.
BUFFER_LOAD_FORMAT_XYZW is already exposed via llvm.SI.vs.load.input, which
has a legacy name, pretends not to access memory, and does not capture the
full flexibility of the instruction.
The situation with the intrinsic attributes for buffer.store.format is
unfortunate. Specifying only IntrReadWriteArgMem will eventually be correct,
but right now LLVM doesn't understand buffer resources as pointers, so might
possibly miscompile something in an optimization pass. On the other hand,
not specifying any attributes at all (which is conservative and correct)
clashes in TableGen pattern generation with the fact that BUFFER_STORE_*
instruction have hasSideEffects = 0 (quite reasonably), and I'm hesitant to
change that since those instructions are already used by compute.