[clang] [llvm] [SystemZ] Properly support 16 byte atomic int/fp types and ops. (PR #73134)

[Jonas Paulsson via cfe-commits]

================
@@ -0,0 +1,71 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 -triple s390x-linux-gnu -O1 -emit-llvm %s -o - | FileCheck %s
+//
+// Test __atomic_is_lock_free() for __int128 with default alignment (8
+// bytes), atomic alignment (16 bytes) and with a null pointer. Also test
+// __atomic_always_lock_free() and __c11_atomic_is_lock_free().
+
+#include <stdatomic.h>
+#include <stdint.h>
+
+__int128 Ptr_Al8   __attribute__((aligned(8)));
+__int128 Ptr_Al16 __attribute__((aligned(16)));
+
+// CHECK-LABEL: @fun_PtrAl8_is_lock_free(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:    [[CALL:%.*]] = tail call zeroext i1 @__atomic_is_lock_free(i64 noundef 16, ptr noundef nonnull @Ptr_Al8) #[[ATTR2:[0-9]+]]
+// CHECK-NEXT:    ret i1 [[CALL]]
+//
+_Bool fun_PtrAl8_is_lock_free() {
+  return __atomic_is_lock_free(16, &Ptr_Al8);
+}
+
+// CHECK-LABEL: @fun_PtrAl8_always_lock_free(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:    ret i1 false
+//
+_Bool fun_PtrAl8_always_lock_free() {
+  return __atomic_always_lock_free(16, &Ptr_Al8);
+}
+
+// CHECK-LABEL: @fun_PtrAl16_is_lock_free(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:    [[CALL:%.*]] = tail call zeroext i1 @__atomic_is_lock_free(i64 noundef 16, ptr noundef nonnull @Ptr_Al16) #[[ATTR2]]
+// CHECK-NEXT:    ret i1 [[CALL]]
+//
+_Bool fun_PtrAl16_is_lock_free() {
+  return __atomic_is_lock_free(16, &Ptr_Al16);
+}
+
+// CHECK-LABEL: @fun_PtrAl16_always_lock_free(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:    ret i1 false
+//
+_Bool fun_PtrAl16_always_lock_free() {
+  return __atomic_always_lock_free(16, &Ptr_Al16);
+}
+
+// CHECK-LABEL: @fun_noptr_is_lock_free(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:    ret i1 true
+//
+_Bool fun_noptr_is_lock_free() {
+  return __atomic_is_lock_free(16, 0);
----------------
JonPsson1 wrote:

Hmm, it seems that GCC is returning true for all of these in this test case, probably because the way it is written: the Ptr_Al8 is placed after the 16-byte aligned Ptr_Al16, so Ptr_Al8 also gets the greater (over)alignment.

Maybe I should try these in two separate files instead.

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