[llvm] [SystemZ] Test improvements for atomic load/store instructions (NFC). (PR #75630)

[Jonas Paulsson via llvm-commits]

JonPsson1 wrote:

Ahh.. maybe not. Maybe then AtomicExpand should not even emit libcalls, but rather assert and abort?

It seems that AtomicExpand decides to handle the unaligned cases with libcall:
```
// Determine if a particular atomic operation has a supported size,
// and is of appropriate alignment, to be passed through for target
// lowering. (Versus turning into a __atomic libcall)
template <typename Inst>
static bool atomicSizeSupported(const TargetLowering *TLI, Inst *I) {
  unsigned Size = getAtomicOpSize(I);
  Align Alignment = I->getAlign();
  return Alignment >= Size &&
         Size <= TLI->getMaxAtomicSizeInBitsSupported() / 8;
}
```
SelectionDAGBuilder however rejects this:
```
void SelectionDAGBuilder::visitAtomicLoad(const LoadInst &I) {
  SDLoc dl = getCurSDLoc();
  AtomicOrdering Order = I.getOrdering();
...
  if (!TLI.supportsUnalignedAtomics() &&
      I.getAlign().value() < MemVT.getSizeInBits() / 8)
    report_fatal_error("Cannot generate unaligned atomic load");
...
```
So with the notion of supporting unaligned atomics, it's a little unclear to me as indeed the spec says " the load has undefined behavior if the alignment is not set to a value which is at least the size in bytes of the pointee."

If there is library support for the unaligned cases, I guess the libcalls should be allowed. If not, the libcalls should not get emitted by AtomicExpand.


https://github.com/llvm/llvm-project/pull/75630