[llvm] [NVPTX] Load/Store/Fence syncscope support (PR #106101)

[via llvm-commits]

================
@@ -117,12 +117,22 @@ enum Ordering : OrderingUnderlyingType {
   // Consume = 3,   // Unimplemented in LLVM; NVPTX would map to "Acquire"
   Acquire = (OrderingUnderlyingType)AtomicOrdering::Acquire,
   Release = (OrderingUnderlyingType)AtomicOrdering::Release,
-  // AcquireRelease = 6, // TODO
+  AcquireRelease = (OrderingUnderlyingType)AtomicOrdering::AcquireRelease,
   SequentiallyConsistent =
       (OrderingUnderlyingType)AtomicOrdering::SequentiallyConsistent,
   Volatile = SequentiallyConsistent + 1,
   RelaxedMMIO = Volatile + 1,
-  LAST = RelaxedMMIO
+  LASTORDERING = RelaxedMMIO
+};
+
+using ScopeUnderlyingType = unsigned int;
+enum Scope : ScopeUnderlyingType {
+  Thread = 0,
+  System = 1,
+  Block = 2,
+  Cluster = 3,
+  Device = 4,
+  LASTSCOPE = Device
----------------
gonzalobg wrote:

I think that in retrospect, it does.

Currently, this extends the LLVM SyncScope::IDs, which reserve 0 and 1 for system and thread scopes, in a similar way to how NVPTX Ordering extends LLVM AtomicOrdering. 

The value of doing that is that you can just cast the LLVM value to our value, when processing the DAG, and that the `i32 3` in the DAG have the same meaning in LLVM enum as in NVPTX enum. For atomic ordering, this is quite useful.

For SyncScope, this is only useful for system scope. For the other SyncScopes, their value in the DAG is dynamic and depends on which order `syncscope`s where used in the LLVM module.. so to make sense of them one needs to do a translation to NVPTX::Scope via the dynamic map anyways. That is, extending the LLVM enum order is much less useful for SyncScope, than for AtomicOrdering.

I think that it is worth trying out whether ordering these from narrower to wider scope (thread =0 , system=last) allows us to save some code here and there (e.g. `if scope > thread: ...`). That's a non functional change, and it may or may not help (we may still need full `switch` statements here and there, cause some of the scopes are sm-arch dependent...). I think its worth giving that a try. Should I try to do it here, or in a follow up?

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