================
@@ -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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
