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

2023-12-04 Thread Ulrich Weigand via cfe-commits 

https://github.com/uweigand approved this pull request.

This version LGTM now.

https://github.com/llvm/llvm-project/pull/73134
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2023-11-28 Thread Jonas Paulsson via cfe-commits 

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

>From bf9b6b735c131833ec9457f23b72322fd50ef821 Mon Sep 17 00:00:00 2001
From: Jonas Paulsson 
Date: Fri, 3 Feb 2023 14:32:58 +0100
Subject: [PATCH 1/5] [SystemZ] Improve support for 16 byte atomic int/fp types
 and operations.

- Clang FE now has MaxAtomicPromoteWidth and MaxAtomicInlineWidth with a value
  of 128. It now produces IR instead of calls to __atomic instrinsics for 16
  bytes as well. FP loads are first loaded as i128 and then casted to fp128.
- Atomic __int128 (and long double) variables are aligned to 16 bytes
  (like gcc 14).
- AtomicExpand pass now expands also 16 byte operations.

- tests for __atomic builtins for all integer widths, with test for i128 in
  both align=8 and align=16 cases.
- Resulting behavior of __atomic_is_lock_free / __atomic_always_lock_free /
  __c11_atomic_is_lock_free is tested in gnu-atomic_is_lock_free.c
- shouldExpandAtomicRMWInIR() was already returning true for any FP type. Now
  that the backend is acepting 16 byte atomics, 16 byte FP atomicrmw:s now also
  get expanded by AtomicExpand. The default (and used)
  shouldCastAtomicRMWIInIR() says that if the type is FP, it is casted to
  integer (see atomicrmw-xchg-07.ll).
- TODO: AtomicExpand pass handles with this patch expansion of i128 atomicrmw:s.
  As a next step smaller integer types should also be possible to handle this
  way instead of in backend.

Original patch rebased.
Remove the regalloc handling for CDSG loops.
Tests improved.
---
 clang/lib/Basic/Targets/SystemZ.h |   2 +-
 clang/test/CodeGen/SystemZ/atomic-alignment.c |  35 ++
 .../SystemZ/gnu-atomic-builtins-i128-16Al.c   | 257 +
 .../SystemZ/gnu-atomic-builtins-i128-8Al.c| 301 +++
 .../CodeGen/SystemZ/gnu-atomic-builtins-i16.c | 219 
 .../CodeGen/SystemZ/gnu-atomic-builtins-i32.c | 219 
 .../CodeGen/SystemZ/gnu-atomic-builtins-i64.c | 219 
 .../CodeGen/SystemZ/gnu-atomic-builtins-i8.c  | 219 
 .../gnu-atomic_is_lock_free-i128-16Al.c   |  54 ++
 .../gnu-atomic_is_lock_free-i128-8Al.c|  28 +
 .../Target/SystemZ/SystemZISelLowering.cpp|   6 +-
 .../CodeGen/SystemZ/atomicrmw-ops-i128.ll | 496 --
 .../test/CodeGen/SystemZ/atomicrmw-xchg-07.ll |  37 +-
 13 files changed, 2030 insertions(+), 62 deletions(-)
 create mode 100644 clang/test/CodeGen/SystemZ/atomic-alignment.c
 create mode 100644 clang/test/CodeGen/SystemZ/gnu-atomic-builtins-i128-16Al.c
 create mode 100644 clang/test/CodeGen/SystemZ/gnu-atomic-builtins-i128-8Al.c
 create mode 100644 clang/test/CodeGen/SystemZ/gnu-atomic-builtins-i16.c
 create mode 100644 clang/test/CodeGen/SystemZ/gnu-atomic-builtins-i32.c
 create mode 100644 clang/test/CodeGen/SystemZ/gnu-atomic-builtins-i64.c
 create mode 100644 clang/test/CodeGen/SystemZ/gnu-atomic-builtins-i8.c
 create mode 100644 
clang/test/CodeGen/SystemZ/gnu-atomic_is_lock_free-i128-16Al.c
 create mode 100644 
clang/test/CodeGen/SystemZ/gnu-atomic_is_lock_free-i128-8Al.c

diff --git a/clang/lib/Basic/Targets/SystemZ.h 
b/clang/lib/Basic/Targets/SystemZ.h
index 9ba255745cf2cc5..e4ec338880f2109 100644
--- a/clang/lib/Basic/Targets/SystemZ.h
+++ b/clang/lib/Basic/Targets/SystemZ.h
@@ -60,7 +60,7 @@ class LLVM_LIBRARY_VISIBILITY SystemZTargetInfo : public 
TargetInfo {
   resetDataLayout("E-m:e-i1:8:16-i8:8:16-i64:64-f128:64"
   "-v128:64-a:8:16-n32:64");
 }
-MaxAtomicPromoteWidth = MaxAtomicInlineWidth = 64;
+MaxAtomicPromoteWidth = MaxAtomicInlineWidth = 128;
 HasStrictFP = true;
   }
 
diff --git a/clang/test/CodeGen/SystemZ/atomic-alignment.c 
b/clang/test/CodeGen/SystemZ/atomic-alignment.c
new file mode 100644
index 000..da478842ca31b2b
--- /dev/null
+++ b/clang/test/CodeGen/SystemZ/atomic-alignment.c
@@ -0,0 +1,35 @@
+// RUN: %clang_cc1 -triple s390x-linux-gnu -O3 -emit-llvm %s -o - | FileCheck 
%s
+//
+// Test alignment of 128 bit Atomic int/fp types, as well as loading
+// from memory with a simple addition. The fp128 is loaded as i128 and
+// then casted.
+
+// CHECK: @Atomic_int128 = {{.*}} i128 0, align 16
+// CHECK: @Atomic_fp128 = {{.*}} fp128 0xL, 
align 16
+
+// CHECK-LABEL:  @f1
+// CHECK:  %atomic-load = load atomic i128, ptr @Atomic_int128 seq_cst, 
align 16
+// CHECK-NEXT: %add = add nsw i128 %atomic-load, 1
+// CHECK-NEXT: store i128 %add, ptr %agg.result, align 8
+// CHECK-NEXT: ret void
+
+// CHECK-LABEL:  @f2
+// CHECK:  %atomic-load = load atomic i128, ptr @Atomic_fp128 seq_cst, 
align 16
+// CHECK-NEXT: %0 = bitcast i128 %atomic-load to fp128
+// CHECK-NEXT: %add = fadd fp128 %0, 0xL3FFF
+// CHECK-NEXT: store fp128 %add, ptr %agg.result, align 8
+// CHECK-NEXT: ret void
+
+
+#include 
+
+_Atomic __int128Atomic_int128;
+_Atomic long double Atomic_fp128;
+
+__int128 f1() {
+  return Atomic_int128 + 1;
+}
+
+long double

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

2023-11-25 Thread Jonas Paulsson via cfe-commits 

JonPsson1 wrote:

Sorry for the confusion of the files: the tests for __atomic_is_lock_free() and 
friends are now in back a single file atomic_is_lock_free-i128.c. The C library 
call is also included as it also changes behavior with this patch.
Current test output in CHECKs, with previous problems remaining.
I see that these can be called for `long double / Atomic` as well, and clang is 
now changing output with the patch. GCC however seems to return 'true' for any 
such calls, regardless of alignment / type, so I suspect this is not really 
expected to work. IIUC, the builtins are only intended for use with integral 
types. The library call may not be limited to ints. Waiting with these until 
later.

https://github.com/llvm/llvm-project/pull/73134
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2023-11-24 Thread Jonas Paulsson via cfe-commits 

JonPsson1 wrote:

Not sure about GCC here, as far as I can see, it is returning true for both of 
the 8-byte aligned cases in gnu-atomic_is_lock_free-i128-8Al.c, also now that 
the alignment is actually 8...

GCC is returning true for all in gnu-atomic_is_lock_free-i128-16Al.c, except 
for except for emitting a call to __c11_atomic_is_lock_free.

https://github.com/llvm/llvm-project/pull/73134
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2023-11-24 Thread Jonas Paulsson via cfe-commits 


@@ -0,0 +1,42 @@
+// RUN: %clang_cc1 -triple s390x-linux-gnu -O1 -emit-llvm %s -o - | FileCheck 
%s
+//
+// Test __atomic_is_lock_free() and __atomic_always_lock_free() for __int128
+// with 16 byte alignment.
+
+#include 
+#include 
+
+__int128 Int128_Al16 __attribute__((aligned(16)));
+
+// CHECK-LABEL: @fun0
+// CHECK:   tail call zeroext i1 @__atomic_is_lock_free
+_Bool fun0() {
+  return __atomic_is_lock_free(16, _Al16);
+}
+
+// CHECK-LABEL: @fun1
+// CHECK:   ret i1 false
+_Bool fun1() {
+  return __atomic_always_lock_free(16, _Al16);
+}
+
+// Also test these with a 16 byte size and null-pointer.
+// CHECK-LABEL: @fun2
+// CHECK:   ret i1 true
+_Bool fun2() {
+  return __atomic_is_lock_free(16, 0);

JonPsson1 wrote:

> But this seems actually incorrect - when using default assumptions, the 
> operation should not be lock-free ...

https://github.com/llvm/llvm-project/pull/73134
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2023-11-24 Thread Jonas Paulsson via cfe-commits 


@@ -0,0 +1,42 @@
+// RUN: %clang_cc1 -triple s390x-linux-gnu -O1 -emit-llvm %s -o - | FileCheck 
%s
+//
+// Test __atomic_is_lock_free() and __atomic_always_lock_free() for __int128
+// with 16 byte alignment.
+
+#include 
+#include 
+

JonPsson1 wrote:

The first two functions here should return true..?

https://github.com/llvm/llvm-project/pull/73134
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2023-11-24 Thread Jonas Paulsson via cfe-commits 

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

>From bf9b6b735c131833ec9457f23b72322fd50ef821 Mon Sep 17 00:00:00 2001
From: Jonas Paulsson 
Date: Fri, 3 Feb 2023 14:32:58 +0100
Subject: [PATCH 1/2] [SystemZ] Improve support for 16 byte atomic int/fp types
 and operations.

- Clang FE now has MaxAtomicPromoteWidth and MaxAtomicInlineWidth with a value
  of 128. It now produces IR instead of calls to __atomic instrinsics for 16
  bytes as well. FP loads are first loaded as i128 and then casted to fp128.
- Atomic __int128 (and long double) variables are aligned to 16 bytes
  (like gcc 14).
- AtomicExpand pass now expands also 16 byte operations.

- tests for __atomic builtins for all integer widths, with test for i128 in
  both align=8 and align=16 cases.
- Resulting behavior of __atomic_is_lock_free / __atomic_always_lock_free /
  __c11_atomic_is_lock_free is tested in gnu-atomic_is_lock_free.c
- shouldExpandAtomicRMWInIR() was already returning true for any FP type. Now
  that the backend is acepting 16 byte atomics, 16 byte FP atomicrmw:s now also
  get expanded by AtomicExpand. The default (and used)
  shouldCastAtomicRMWIInIR() says that if the type is FP, it is casted to
  integer (see atomicrmw-xchg-07.ll).
- TODO: AtomicExpand pass handles with this patch expansion of i128 atomicrmw:s.
  As a next step smaller integer types should also be possible to handle this
  way instead of in backend.

Original patch rebased.
Remove the regalloc handling for CDSG loops.
Tests improved.
---
 clang/lib/Basic/Targets/SystemZ.h |   2 +-
 clang/test/CodeGen/SystemZ/atomic-alignment.c |  35 ++
 .../SystemZ/gnu-atomic-builtins-i128-16Al.c   | 257 +
 .../SystemZ/gnu-atomic-builtins-i128-8Al.c| 301 +++
 .../CodeGen/SystemZ/gnu-atomic-builtins-i16.c | 219 
 .../CodeGen/SystemZ/gnu-atomic-builtins-i32.c | 219 
 .../CodeGen/SystemZ/gnu-atomic-builtins-i64.c | 219 
 .../CodeGen/SystemZ/gnu-atomic-builtins-i8.c  | 219 
 .../gnu-atomic_is_lock_free-i128-16Al.c   |  54 ++
 .../gnu-atomic_is_lock_free-i128-8Al.c|  28 +
 .../Target/SystemZ/SystemZISelLowering.cpp|   6 +-
 .../CodeGen/SystemZ/atomicrmw-ops-i128.ll | 496 --
 .../test/CodeGen/SystemZ/atomicrmw-xchg-07.ll |  37 +-
 13 files changed, 2030 insertions(+), 62 deletions(-)
 create mode 100644 clang/test/CodeGen/SystemZ/atomic-alignment.c
 create mode 100644 clang/test/CodeGen/SystemZ/gnu-atomic-builtins-i128-16Al.c
 create mode 100644 clang/test/CodeGen/SystemZ/gnu-atomic-builtins-i128-8Al.c
 create mode 100644 clang/test/CodeGen/SystemZ/gnu-atomic-builtins-i16.c
 create mode 100644 clang/test/CodeGen/SystemZ/gnu-atomic-builtins-i32.c
 create mode 100644 clang/test/CodeGen/SystemZ/gnu-atomic-builtins-i64.c
 create mode 100644 clang/test/CodeGen/SystemZ/gnu-atomic-builtins-i8.c
 create mode 100644 
clang/test/CodeGen/SystemZ/gnu-atomic_is_lock_free-i128-16Al.c
 create mode 100644 
clang/test/CodeGen/SystemZ/gnu-atomic_is_lock_free-i128-8Al.c

diff --git a/clang/lib/Basic/Targets/SystemZ.h 
b/clang/lib/Basic/Targets/SystemZ.h
index 9ba255745cf2cc52..e4ec338880f21095 100644
--- a/clang/lib/Basic/Targets/SystemZ.h
+++ b/clang/lib/Basic/Targets/SystemZ.h
@@ -60,7 +60,7 @@ class LLVM_LIBRARY_VISIBILITY SystemZTargetInfo : public 
TargetInfo {
   resetDataLayout("E-m:e-i1:8:16-i8:8:16-i64:64-f128:64"
   "-v128:64-a:8:16-n32:64");
 }
-MaxAtomicPromoteWidth = MaxAtomicInlineWidth = 64;
+MaxAtomicPromoteWidth = MaxAtomicInlineWidth = 128;
 HasStrictFP = true;
   }
 
diff --git a/clang/test/CodeGen/SystemZ/atomic-alignment.c 
b/clang/test/CodeGen/SystemZ/atomic-alignment.c
new file mode 100644
index ..da478842ca31b2b0
--- /dev/null
+++ b/clang/test/CodeGen/SystemZ/atomic-alignment.c
@@ -0,0 +1,35 @@
+// RUN: %clang_cc1 -triple s390x-linux-gnu -O3 -emit-llvm %s -o - | FileCheck 
%s
+//
+// Test alignment of 128 bit Atomic int/fp types, as well as loading
+// from memory with a simple addition. The fp128 is loaded as i128 and
+// then casted.
+
+// CHECK: @Atomic_int128 = {{.*}} i128 0, align 16
+// CHECK: @Atomic_fp128 = {{.*}} fp128 0xL, 
align 16
+
+// CHECK-LABEL:  @f1
+// CHECK:  %atomic-load = load atomic i128, ptr @Atomic_int128 seq_cst, 
align 16
+// CHECK-NEXT: %add = add nsw i128 %atomic-load, 1
+// CHECK-NEXT: store i128 %add, ptr %agg.result, align 8
+// CHECK-NEXT: ret void
+
+// CHECK-LABEL:  @f2
+// CHECK:  %atomic-load = load atomic i128, ptr @Atomic_fp128 seq_cst, 
align 16
+// CHECK-NEXT: %0 = bitcast i128 %atomic-load to fp128
+// CHECK-NEXT: %add = fadd fp128 %0, 0xL3FFF
+// CHECK-NEXT: store fp128 %add, ptr %agg.result, align 8
+// CHECK-NEXT: ret void
+
+
+#include 
+
+_Atomic __int128Atomic_int128;
+_Atomic long double Atomic_fp128;
+
+__int128 f1() {
+  return Atomic_int128 + 1;
+}
+
+long

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

2023-11-24 Thread Ulrich Weigand 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 
+#include 
+
+__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, _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, _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]]

uweigand wrote:

Here I would have expected `true`, assuming the compiler correctly figures out 
the object is 16-byte aligned.

https://github.com/llvm/llvm-project/pull/73134
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2023-11-24 Thread Ulrich Weigand via cfe-commits 

https://github.com/uweigand commented:

Not sure about the is_lock_free results, see inline comments.

What does recent GCC return for those?

https://github.com/llvm/llvm-project/pull/73134
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2023-11-22 Thread Jonas Paulsson via cfe-commits 

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

- Clang FE now has MaxAtomicPromoteWidth and MaxAtomicInlineWidth with a value 
of 128. It now produces IR instead of calls to __atomic instrinsics for 16 
bytes as well. FP loads are first loaded as i128 and then casted to fp128.
- Atomic __int128 (and long double) variables are aligned to 16 bytes (like gcc 
14).
- AtomicExpand pass now expands also 16 byte operations.

- tests for __atomic builtins for all integer widths, with test for i128 in 
both align=8 and align=16 cases.
- Resulting behavior of __atomic_is_lock_free / __atomic_always_lock_free / 
__c11_atomic_is_lock_free is tested in gnu-atomic_is_lock_free.c
- shouldExpandAtomicRMWInIR() was already returning true for any FP type. Now 
that the backend is acepting 16 byte atomics, 16 byte FP atomicrmw:s now also 
get expanded by AtomicExpand. The default (and used) shouldCastAtomicRMWIInIR() 
says that if the type is FP, it is casted to integer (see atomicrmw-xchg-07.ll).
- TODO: AtomicExpand pass handles with this patch expansion of i128 
atomicrmw:s. As a next step smaller integer types should also be possible to 
handle this way instead of in backend.

Original patch rebased.
Remove the regalloc handling for CDSG loops.
Tests improved.

>From e392e34f1c6762cce079e26c90e9d27a868bc5f2 Mon Sep 17 00:00:00 2001
From: Jonas Paulsson 
Date: Fri, 3 Feb 2023 14:32:58 +0100
Subject: [PATCH] [SystemZ] Improve support for 16 byte atomic int/fp types and
 operations.

- Clang FE now has MaxAtomicPromoteWidth and MaxAtomicInlineWidth with a value
  of 128. It now produces IR instead of calls to __atomic instrinsics for 16
  bytes as well. FP loads are first loaded as i128 and then casted to fp128.
- Atomic __int128 (and long double) variables are aligned to 16 bytes
  (like gcc 14).
- AtomicExpand pass now expands also 16 byte operations.

- tests for __atomic builtins for all integer widths, with test for i128 in
  both align=8 and align=16 cases.
- Resulting behavior of __atomic_is_lock_free / __atomic_always_lock_free /
  __c11_atomic_is_lock_free is tested in gnu-atomic_is_lock_free.c
- shouldExpandAtomicRMWInIR() was already returning true for any FP type. Now
  that the backend is acepting 16 byte atomics, 16 byte FP atomicrmw:s now also
  get expanded by AtomicExpand. The default (and used)
  shouldCastAtomicRMWIInIR() says that if the type is FP, it is casted to
  integer (see atomicrmw-xchg-07.ll).
- TODO: AtomicExpand pass handles with this patch expansion of i128 atomicrmw:s.
  As a next step smaller integer types should also be possible to handle this
  way instead of in backend.

Original patch rebased.
Remove the regalloc handling for CDSG loops.
Tests improved.
---
 clang/lib/Basic/Targets/SystemZ.h |   2 +-
 clang/test/CodeGen/SystemZ/atomic-alignment.c |  35 ++
 .../SystemZ/gnu-atomic-builtins-i128-16Al.c   | 257 +
 .../SystemZ/gnu-atomic-builtins-i128-8Al.c| 301 +++
 .../CodeGen/SystemZ/gnu-atomic-builtins-i16.c | 219 
 .../CodeGen/SystemZ/gnu-atomic-builtins-i32.c | 219 
 .../CodeGen/SystemZ/gnu-atomic-builtins-i64.c | 219 
 .../CodeGen/SystemZ/gnu-atomic-builtins-i8.c  | 219 
 .../CodeGen/SystemZ/gnu-atomic_is_lock_free.c |  71 +++
 .../Target/SystemZ/SystemZISelLowering.cpp|   6 +-
 .../CodeGen/SystemZ/atomicrmw-ops-i128.ll | 496 --
 .../test/CodeGen/SystemZ/atomicrmw-xchg-07.ll |  37 +-
 12 files changed, 2019 insertions(+), 62 deletions(-)
 create mode 100644 clang/test/CodeGen/SystemZ/atomic-alignment.c
 create mode 100644 clang/test/CodeGen/SystemZ/gnu-atomic-builtins-i128-16Al.c
 create mode 100644 clang/test/CodeGen/SystemZ/gnu-atomic-builtins-i128-8Al.c
 create mode 100644 clang/test/CodeGen/SystemZ/gnu-atomic-builtins-i16.c
 create mode 100644 clang/test/CodeGen/SystemZ/gnu-atomic-builtins-i32.c
 create mode 100644 clang/test/CodeGen/SystemZ/gnu-atomic-builtins-i64.c
 create mode 100644 clang/test/CodeGen/SystemZ/gnu-atomic-builtins-i8.c
 create mode 100644 clang/test/CodeGen/SystemZ/gnu-atomic_is_lock_free.c

diff --git a/clang/lib/Basic/Targets/SystemZ.h 
b/clang/lib/Basic/Targets/SystemZ.h
index 9ba255745cf2cc52..e4ec338880f21095 100644
--- a/clang/lib/Basic/Targets/SystemZ.h
+++ b/clang/lib/Basic/Targets/SystemZ.h
@@ -60,7 +60,7 @@ class LLVM_LIBRARY_VISIBILITY SystemZTargetInfo : public 
TargetInfo {
   resetDataLayout("E-m:e-i1:8:16-i8:8:16-i64:64-f128:64"
   "-v128:64-a:8:16-n32:64");
 }
-MaxAtomicPromoteWidth = MaxAtomicInlineWidth = 64;
+MaxAtomicPromoteWidth = MaxAtomicInlineWidth = 128;
 HasStrictFP = true;
   }
 
diff --git a/clang/test/CodeGen/SystemZ/atomic-alignment.c 
b/clang/test/CodeGen/SystemZ/atomic-alignment.c
new file mode 100644
index ..da478842ca31b2b0
--- /dev/null
+++ b/clang/test/CodeGen/SystemZ/atomic-alignment.c
@@ -0,0 +1,35 @@
+// RUN: %clang_cc1 -triple