[clang] [llvm] [AArch64] Implement GCS ACLE intrinsics (PR #96903)

[Sam Elliott via cfe-commits]

================
@@ -855,6 +863,25 @@ __rndrrs(uint64_t *__p) {
 }
 #endif
 
+/* 11.2 Guarded Control Stack intrinsics */
+#if defined(__ARM_64BIT_STATE) && __ARM_64BIT_STATE
+static __inline__ void * __attribute__((__always_inline__, __nodebug__))
+__gcspr() {
+  return (void *)__builtin_arm_rsr64("gcspr_el0");
+}
+
+static __inline__ uint64_t __attribute__((__always_inline__, __nodebug__, target("gcs")))
+__gcspopm() {
+  return __builtin_arm_gcspopm(0);
+}
+
+static __inline__ const void * __attribute__((__always_inline__, __nodebug__, target("gcs")))
+__gcsss(const void *__stack) {
+  __builtin_arm_gcsss1(__stack);
+  return __builtin_arm_gcsss2(0);
+}
----------------
lenary wrote:

My concerns are:
- builtins eventually become a defacto compiler interface, with users using them directly outside of compiler-only headers (and potentially expecting them to be compatible between gcc and clang). Maybe this is fine, as we can reserve the right to break them (but doing so is still not easy)? The other obvious option is to match the builtin to the ACLE intrinsic, and write C++, as you say, which is not as easy but also not necessarily any better as an implementation.
- What happens if the compiler ends up separating these two operations? I guess maybe we can leave this until it is a reported problem. Even if we had one operation until isel, we might still have to make sure that reasonable optimisations were prevented post-isel. I realise that the `sideEffects = 1` on the instructions should prevent a lot of these, but I'm not clear on things that should be side-effect safe but might interact with GCS such as Machine Outliner.



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