Add atomic arch instructions

[XAMPPRocky]

This PR adds nearly all of the SPIR-V atomic instructions, the only ones not implemented are the ones around atomic flags as we don't have a type for them at the moment.

Depends on #519

[khyperia]

I thought we had discussed this already in #442 and the plan was to expose these through the rust stdlib, instead of custom instructions?

[khyperia]

To be clear, if I recall correctly, the entire purpose of the arch module is intended to let us prototype high level abstractions over SPIR-V concepts without getting into compiler work. There is already a high level abstraction in place for atomics (sync::atomic), no prototyping is necessary, and so I don't want to waste work to add instructions to the arch module for sake of adding instructions to the arch module. I think our effort would be better directed towards things like fixing #442.

[XAMPPRocky]

I thought we had discussed this already in #442 and the plan was to expose these through the rust stdlib, instead of custom instructions?

Well there's no discussion in that thread, so if we did discuss it , it wasn't there and I don't remember it beyond "yes we should have them". I don't have a strong opinion on how we do it, but as I've read the spec more I'm not sure stdlib is complete abstraction for SPIR-V's atomics. For example there are way more memory semantics in SPIR-V than just Relaxed, Release, Acquire, AcqRel, and SeqCst. stdlib also doesn't have any concept of Scope, and there's no AtomicBool equivalent in SPIR-V. So to me it seems like we'd be better off providing our own abstraction.

[eddyb]

(Re-opened temporarily to force push a rebase - the presence of the atomics branch, with a massive merge anomaly, was getting in the way of using jj on this repo, so I felt I had to untangle it)

[XAMPPRocky]

@eddyb I can delete the branch if that helps.

[eddyb]

I can delete the branch if that helps.

@XAMPPRocky Only if you think it's been obsoleted by e.g.:

• Add low-level atomic instructions to spirv_std::arch #877

(even if you delete the branch now, I still thing my cleanup of it was worth it, because the PR doesn't look extremely broken - idk how much that persists after deleting the branch, but better safe than sorry)