Support more AtomicRWOps

[tomsmeding]

The current list of operations for atomicrmw (AtomicRWOp) was up to date for LLVM 8, but since then more operations have been added. By now (LLVM 19), 6 more have arrived (documentation). This PR adds them, and predicates their pretty-printing on the minimum LLVM version that has them.

Caveats:

1. Because data constructors are declared at compile time and we only know the target LLVM version at runtime, all we can do is error if an operation is used that the target LLVM version does not support. This is unfortunate, but I don't see a better option here.
2. I deduced minimum LLVM versions simply by looking at the LLVM LangRef documentation for atomicrmw for a whole bunch of LLVM versions. I did not actually test that the documentation corresponds with reality.

(Context: as an experiment, I'm trying to convert the Accelerate LLVM backend to use llvm-pretty instead of the llvm-hs bindings with the aim of reducing maintenance overhead for the Accelerate maintainers. No guarantees that we'll actually be merging this migration.)

[RyanGlScott]

Thanks for the patch!

1. Because data constructors are declared at compile time and we only know the target LLVM version at runtime, all we can do is `error` if an operation is used that the target LLVM version does not support. This is unfortunate, but I don't see a better option here.

That sounds quite reasonable to me, actually. In fact, we really ought to be doing this more often in the Text.LLVM.PP code than we current are. Of course, it would be a big task to identify all of the places where we're emitting LLVM IR that won't work on certain old LLVM versions, but I like the idea of using onlyOnLLVM to identify these places going forward.

2. I deduced minimum LLVM versions simply by looking at the LLVM LangRef documentation for `atomicrmw` for a whole bunch of LLVM versions. I did not actually test that the documentation corresponds with reality.

That is exactly how I do things, so you're in good company :)

(Context: as an experiment, I'm trying to convert the Accelerate LLVM backend to use llvm-pretty instead of the llvm-hs bindings with the aim of reducing maintenance overhead for the Accelerate maintainers. No guarantees that we'll actually be merging this migration.)

That sounds like a cool project! And it's nice to hear that other people are getting use of llvm-pretty. Please don't hesitate to file issues if there are other things that accelerate-llvm needs that llvm-pretty doesn't currently provide.

[tomsmeding]

That sounds quite reasonable to me, actually. In fact, we really ought to be doing this more often in the Text.LLVM.PP code than we current are. Of course, it would be a big task to identify all of the places where we're emitting LLVM IR that won't work on certain old LLVM versions, but I like the idea of using onlyOnLLVM to identify these places going forward.

That makes sense. Given that Accelerate's users will typically not be using very old versions of LLVM, I don't think we'll be running into undocumented support limits, so from our side this will probably mostly stay as-is. But let's try to do it right for new constructors, at least. :)

That sounds like a cool project! And it's nice to hear that other people are getting use of llvm-pretty. Please don't hesitate to file issues if there are other things that accelerate-llvm needs that llvm-pretty doesn't currently provide.

Thanks so much! Whether we need much more depends on whether we're also going to convert the CUDA backend (I'm not even sure whether that's feasible in the first place -- I'm not a CUDA API expert). If so, from memory, we may want these things at some point: half floats, some additional function attributes, and volatile loads and stores, as well as inline assembly. The current code also adds function attributes to call instructions (which llvm-pretty does not support), but I'm not sure whether those are actually needed -- contrary to what LLVM's documentation suggests, one can put function attributes on declare statements, and that ought to be enough, in theory.

I propose moving this disclaimer to the module Haddocks and generalizing it a bit. We don't rule out all possible invalid combinations just yet when pretty-printing, but we could at least encourage users to check that what they are attempting to pretty-print is in fact valid on their chosen version of LLVM.

I did so; I'm not sure about the wording. Feel free to edit or suggest changes.

I also reworded the support bounds comments to use the phrasing "Introduced in", to be consistent with the other places in the module where similar support bounds are indicated. I kind of like the plain "LLVM >= 9" phrasing more, because my brain reads that as "oops I should check whether that's old enough for me" whereas it reads "Introduced in ..." as a skippable historical remark. But that's my problem, not anyone else's. :)

[RyanGlScott]

Some minor Haddock suggestions, but otherwise this looks good to me.

[tomsmeding]

Sounds good, applied. :)

[RyanGlScott]

Thanks!