[GlobalISel] Allow per-lane truncating/extending G_STORE/G_LOAD semantics

The semantics of vector G_STORE is currently not well defined. The docs
have diverged with the implementation on whether vector G_STORE/G_LOAD
instructions have per-lane truncating/extending behavior. The docs say
G_LOAD/G_STORE is not per-lane truncating/extending. This diverges from
the SelectionDAG semantics and also does not match our current
implementation in some cases. One case I am aware of is
llvm#121169.

We do require some implementation of these semantics for handling cases
like in the above PR, e.g. storing a <8 x s8> register into a <8 x s1>
bitfield. I would like to discuss which route we want to take.

1. Allow per-lane truncating/extending G_STORE/G_LOAD semantics like
   SelectionDAG. If we do not have a good reason to diverge from
   SelectionDAG here, this probably is the default option, as it would
   make it more straightforward to port patterns and lowering code from
   SDAG. However, I think we would need to tighten down the MemDesc
   legality rules, because they currently only check the size of the
   memory type.
   I have drafted the documentation changes for this route in this PR,
   but I am not familiar with scalable vectors in GISel, so I would
   appreciate some input on how they are supposed to behave with
   extending/truncating stores.
2. Add new opcodes.
3. Other ideas?

Author: tobias-stadler

llvm/docs/GlobalISel/GenericOpcode.rst

@@ -861,9 +861,16 @@ Generic load. Expects a MachineMemOperand in addition to explicit
 operands. If the result size is larger than the memory size, the
 high bits are undefined, sign-extended, or zero-extended respectively.
 
-Only G_LOAD is valid if the result is a vector type. If the result is larger
-than the memory size, the high elements are undefined (i.e. this is not a
-per-element, vector anyextload)
+If both the result value type (<ValElems x ValElemTy>) and the memory type
+(<MemElems x MemElemTy>) are vectors:
+* and ValElemTy is larger than ValElemTy: the high bits of each vector element
+  are extended according to the opcode (i.e. this acts as a per-lane
+  anyext/zext/sext load).
+* and ValElemTy is larger than MemElems: the high elements are undefined.
+
+Note that if either the result value type or memory type is scalar (e.g.
+loading <4 x s8> from s28), extension applies to the high bits of the entire
+value instead of per-lane.
 
 Unlike in SelectionDAG, atomic loads are expressed with the same
 opcodes as regular loads. G_LOAD, G_SEXTLOAD and G_ZEXTLOAD may all
@@ -889,11 +896,19 @@ Same as G_INDEXED_LOAD except that the load performed is zero-extending, as with
 G_STORE
 ^^^^^^^
 
-Generic store. Expects a MachineMemOperand in addition to explicit
-operands. If the stored value size is greater than the memory size,
-the high bits are implicitly truncated. If this is a vector store, the
-high elements are discarded (i.e. this does not function as a per-lane
-vector, truncating store)
+Generic store. Expects a MachineMemOperand in addition to explicit operands.
+If the stored value size is greater than the memory size, the high bits are
+implicitly truncated.
+
+If both the stored value type (<ValElems x ValElemTy>) and the memory type
+(<MemElems x MemElemTy>) are vectors:
+* and MemElemTy is smaller than ValElemTy: the high bits of each vector element
+  are truncated (i.e. this acts as a per-lane truncating store).
+* and MemElms is smaller than MemElems: the high elements are discarded.
+
+Note that if either the stored value type or memory type is scalar (e.g.
+storing <4 x s8> as s28), truncation applies to the high bits of the entire
+value instead of per-lane.
 
 G_INDEXED_STORE
 ^^^^^^^^^^^^^^^