[PATCH] D109362: [SystemZ][z/OS] Add GOFF Support to the DataLayout

[Anirudh Prasad via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
anirudhp marked an inline comment as done.
Closed by commit rGe09a1dc47515: [SystemZ][z/OS] Add GOFF Support to the 
DataLayout (authored by anirudhp).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109362/new/

https://reviews.llvm.org/D109362

Files:
  clang/lib/Basic/Targets/SystemZ.h
  clang/test/CodeGen/target-data.c
  llvm/docs/LangRef.rst
  llvm/include/llvm/IR/DataLayout.h
  llvm/lib/IR/DataLayout.cpp
  llvm/lib/Target/SystemZ/SystemZTargetMachine.cpp
  llvm/unittests/IR/ManglerTest.cpp

Index: llvm/unittests/IR/ManglerTest.cpp
===
--- llvm/unittests/IR/ManglerTest.cpp
+++ llvm/unittests/IR/ManglerTest.cpp
@@ -156,4 +156,22 @@
 "L..foo");
 }
 
+TEST(ManglerTest, GOFF) {
+  LLVMContext Ctx;
+  DataLayout DL("m:l"); // GOFF
+  Module Mod("test", Ctx);
+  Mod.setDataLayout(DL);
+  Mangler Mang;
+
+  EXPECT_EQ(mangleStr("foo", Mang, DL), "foo");
+  EXPECT_EQ(mangleStr("\01foo", Mang, DL), "foo");
+  EXPECT_EQ(mangleStr("?foo", Mang, DL), "?foo");
+  EXPECT_EQ(mangleFunc("foo", llvm::GlobalValue::ExternalLinkage,
+   llvm::CallingConv::C, Mod, Mang),
+"foo");
+  EXPECT_EQ(mangleFunc("foo", llvm::GlobalValue::PrivateLinkage,
+   llvm::CallingConv::C, Mod, Mang),
+"@foo");
+}
+
 } // end anonymous namespace
Index: llvm/lib/Target/SystemZ/SystemZTargetMachine.cpp
===
--- llvm/lib/Target/SystemZ/SystemZTargetMachine.cpp
+++ llvm/lib/Target/SystemZ/SystemZTargetMachine.cpp
@@ -84,8 +84,9 @@
   // 128-bit floats are aligned only to 64 bits.
   Ret += "-f128:64";
 
-  // When using the vector ABI, 128-bit vectors are also aligned to 64 bits.
-  if (VectorABI)
+  // When using the vector ABI on Linux, 128-bit vectors are also aligned to 64
+  // bits. On z/OS, vector types are always aligned to 64 bits.
+  if (VectorABI || TT.isOSzOS())
 Ret += "-v128:64";
 
   // We prefer 16 bits of aligned for all globals; see above.
Index: llvm/lib/IR/DataLayout.cpp
===
--- llvm/lib/IR/DataLayout.cpp
+++ llvm/lib/IR/DataLayout.cpp
@@ -151,6 +151,8 @@
 //===--===//
 
 const char *DataLayout::getManglingComponent(const Triple ) {
+  if (T.isOSBinFormatGOFF())
+return "-m:l";
   if (T.isOSBinFormatMachO())
 return "-m:o";
   if (T.isOSWindows() && T.isOSBinFormatCOFF())
@@ -500,6 +502,9 @@
   case 'e':
 ManglingMode = MM_ELF;
 break;
+  case 'l':
+ManglingMode = MM_GOFF;
+break;
   case 'o':
 ManglingMode = MM_MachO;
 break;
Index: llvm/include/llvm/IR/DataLayout.h
===
--- llvm/include/llvm/IR/DataLayout.h
+++ llvm/include/llvm/IR/DataLayout.h
@@ -135,6 +135,7 @@
 MM_MachO,
 MM_WinCOFF,
 MM_WinCOFFX86,
+MM_GOFF,
 MM_Mips,
 MM_XCOFF
   };
@@ -316,6 +317,7 @@
 switch (ManglingMode) {
 case MM_None:
 case MM_ELF:
+case MM_GOFF:
 case MM_Mips:
 case MM_WinCOFF:
 case MM_XCOFF:
@@ -334,6 +336,8 @@
 case MM_ELF:
 case MM_WinCOFF:
   return ".L";
+case MM_GOFF:
+  return "@";
 case MM_Mips:
   return "$";
 case MM_MachO:
Index: llvm/docs/LangRef.rst
===
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -2605,6 +2605,7 @@
 options are
 
 * ``e``: ELF mangling: Private symbols get a ``.L`` prefix.
+* ``l``: GOFF mangling: Private symbols get a ``@`` prefix.
 * ``m``: Mips mangling: Private symbols get a ``$`` prefix.
 * ``o``: Mach-O mangling: Private symbols get ``L`` prefix. Other
   symbols get a ``_`` prefix.
Index: clang/test/CodeGen/target-data.c
===
--- clang/test/CodeGen/target-data.c
+++ clang/test/CodeGen/target-data.c
@@ -219,40 +219,24 @@
 // RUN: FileCheck %s -check-prefix=HEXAGON
 // HEXAGON: target datalayout = "e-m:e-p:32:32:32-a:0-n16:32-i64:64:64-i32:32:32-i16:16:16-i1:8:8-f32:32:32-f64:64:64-v32:32:32-v64:64:64-v512:512:512-v1024:1024:1024-v2048:2048:2048"
 
-// RUN: %clang_cc1 -triple s390x-unknown -o - -emit-llvm %s | \
-// RUN: FileCheck %s -check-prefix=SYSTEMZ
 // RUN: %clang_cc1 -triple s390x-unknown -target-cpu z10 -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=SYSTEMZ
-// RUN: %clang_cc1 -triple s390x-unknown -target-cpu arch8 -o - -emit-llvm %s | \
-// RUN: FileCheck %s -check-prefix=SYSTEMZ
-// RUN: %clang_cc1 -triple s390x-unknown -target-cpu z196 -o - -emit-llvm %s | \
-// RUN: FileCheck %s -check-prefix=SYSTEMZ
-// 

[PATCH] D109362: [SystemZ][z/OS] Add GOFF Support to the DataLayout

[Anirudh Prasad via Phabricator via cfe-commits]

anirudhp marked 2 inline comments as done.
anirudhp added inline comments.



Comment at: clang/test/CodeGen/target-data.c:256
 
+// RUN: %clang_cc1 -triple s390x-none-zos -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=ZOS

MaskRay wrote:
> MaskRay wrote:
> > anirudhp wrote:
> > > MaskRay wrote:
> > > > If you add so many RUN lines at once, please use unittests instead. 
> > > > This would cost some test execution time
> > > We're essentially matching what was available for the systemz elf target 
> > > (above lines) for the z/OS target. Is there a real concern for the 
> > > execution time here for moving it to a separate unit test. If we did, it 
> > > would seem to "stand out" for just the z/OS target.
> > This is a real concern. Perhaps you can also move the SYstemZ ELF tests to 
> > a unit test.
> It also doesn't appear useful to enumerate every combination when the patch 
> doesn't touch these combination individually.
> 
> I.e. if you add z/OS condition to `arch8` code, then having a test is fine. 
> If you don't touch it, I don't think you should enumerate `{elf,goff} * 
> {z10,arch8,z196,arch9,...}`
After a bit of discussions with @uweigand , we've reduced the number of run 
lines for the SystemZ target(s) (both elf and goff). They should be greatly 
reduced now.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109362/new/

https://reviews.llvm.org/D109362

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109362: [SystemZ][z/OS] Add GOFF Support to the DataLayout

[Anirudh Prasad via Phabricator via cfe-commits]

anirudhp updated this revision to Diff 373999.
anirudhp added a comment.

- Reduced the number of test lines in target-data.c, since we don't have to 
check for every combination of arch,cpu for the SystemZ target (for both elf 
and z/OS)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109362/new/

https://reviews.llvm.org/D109362

Files:
  clang/lib/Basic/Targets/SystemZ.h
  clang/test/CodeGen/target-data.c
  llvm/docs/LangRef.rst
  llvm/include/llvm/IR/DataLayout.h
  llvm/lib/IR/DataLayout.cpp
  llvm/lib/Target/SystemZ/SystemZTargetMachine.cpp
  llvm/unittests/IR/ManglerTest.cpp

Index: llvm/unittests/IR/ManglerTest.cpp
===
--- llvm/unittests/IR/ManglerTest.cpp
+++ llvm/unittests/IR/ManglerTest.cpp
@@ -156,4 +156,22 @@
 "L..foo");
 }
 
+TEST(ManglerTest, GOFF) {
+  LLVMContext Ctx;
+  DataLayout DL("m:l"); // GOFF
+  Module Mod("test", Ctx);
+  Mod.setDataLayout(DL);
+  Mangler Mang;
+
+  EXPECT_EQ(mangleStr("foo", Mang, DL), "foo");
+  EXPECT_EQ(mangleStr("\01foo", Mang, DL), "foo");
+  EXPECT_EQ(mangleStr("?foo", Mang, DL), "?foo");
+  EXPECT_EQ(mangleFunc("foo", llvm::GlobalValue::ExternalLinkage,
+   llvm::CallingConv::C, Mod, Mang),
+"foo");
+  EXPECT_EQ(mangleFunc("foo", llvm::GlobalValue::PrivateLinkage,
+   llvm::CallingConv::C, Mod, Mang),
+"@foo");
+}
+
 } // end anonymous namespace
Index: llvm/lib/Target/SystemZ/SystemZTargetMachine.cpp
===
--- llvm/lib/Target/SystemZ/SystemZTargetMachine.cpp
+++ llvm/lib/Target/SystemZ/SystemZTargetMachine.cpp
@@ -84,8 +84,9 @@
   // 128-bit floats are aligned only to 64 bits.
   Ret += "-f128:64";
 
-  // When using the vector ABI, 128-bit vectors are also aligned to 64 bits.
-  if (VectorABI)
+  // When using the vector ABI on Linux, 128-bit vectors are also aligned to 64
+  // bits. On z/OS, vector types are always aligned to 64 bits.
+  if (VectorABI || TT.isOSzOS())
 Ret += "-v128:64";
 
   // We prefer 16 bits of aligned for all globals; see above.
Index: llvm/lib/IR/DataLayout.cpp
===
--- llvm/lib/IR/DataLayout.cpp
+++ llvm/lib/IR/DataLayout.cpp
@@ -151,6 +151,8 @@
 //===--===//
 
 const char *DataLayout::getManglingComponent(const Triple ) {
+  if (T.isOSBinFormatGOFF())
+return "-m:l";
   if (T.isOSBinFormatMachO())
 return "-m:o";
   if (T.isOSWindows() && T.isOSBinFormatCOFF())
@@ -500,6 +502,9 @@
   case 'e':
 ManglingMode = MM_ELF;
 break;
+  case 'l':
+ManglingMode = MM_GOFF;
+break;
   case 'o':
 ManglingMode = MM_MachO;
 break;
Index: llvm/include/llvm/IR/DataLayout.h
===
--- llvm/include/llvm/IR/DataLayout.h
+++ llvm/include/llvm/IR/DataLayout.h
@@ -135,6 +135,7 @@
 MM_MachO,
 MM_WinCOFF,
 MM_WinCOFFX86,
+MM_GOFF,
 MM_Mips,
 MM_XCOFF
   };
@@ -316,6 +317,7 @@
 switch (ManglingMode) {
 case MM_None:
 case MM_ELF:
+case MM_GOFF:
 case MM_Mips:
 case MM_WinCOFF:
 case MM_XCOFF:
@@ -334,6 +336,8 @@
 case MM_ELF:
 case MM_WinCOFF:
   return ".L";
+case MM_GOFF:
+  return "@";
 case MM_Mips:
   return "$";
 case MM_MachO:
Index: llvm/docs/LangRef.rst
===
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -2593,6 +2593,7 @@
 options are
 
 * ``e``: ELF mangling: Private symbols get a ``.L`` prefix.
+* ``l``: GOFF mangling: Private symbols get a ``@`` prefix.
 * ``m``: Mips mangling: Private symbols get a ``$`` prefix.
 * ``o``: Mach-O mangling: Private symbols get ``L`` prefix. Other
   symbols get a ``_`` prefix.
Index: clang/test/CodeGen/target-data.c
===
--- clang/test/CodeGen/target-data.c
+++ clang/test/CodeGen/target-data.c
@@ -219,40 +219,24 @@
 // RUN: FileCheck %s -check-prefix=HEXAGON
 // HEXAGON: target datalayout = "e-m:e-p:32:32:32-a:0-n16:32-i64:64:64-i32:32:32-i16:16:16-i1:8:8-f32:32:32-f64:64:64-v32:32:32-v64:64:64-v512:512:512-v1024:1024:1024-v2048:2048:2048"
 
-// RUN: %clang_cc1 -triple s390x-unknown -o - -emit-llvm %s | \
-// RUN: FileCheck %s -check-prefix=SYSTEMZ
 // RUN: %clang_cc1 -triple s390x-unknown -target-cpu z10 -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=SYSTEMZ
-// RUN: %clang_cc1 -triple s390x-unknown -target-cpu arch8 -o - -emit-llvm %s | \
-// RUN: FileCheck %s -check-prefix=SYSTEMZ
-// RUN: %clang_cc1 -triple s390x-unknown -target-cpu z196 -o - -emit-llvm %s | \
-// RUN: FileCheck %s -check-prefix=SYSTEMZ
-// RUN: %clang_cc1 -triple s390x-unknown 

[PATCH] D109362: [SystemZ][z/OS] Add GOFF Support to the DataLayout

[Anirudh Prasad via Phabricator via cfe-commits]

anirudhp added inline comments.



Comment at: clang/test/CodeGen/target-data.c:256
 
+// RUN: %clang_cc1 -triple s390x-none-zos -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=ZOS

MaskRay wrote:
> If you add so many RUN lines at once, please use unittests instead. This 
> would cost some test execution time
We're essentially matching what was available for the systemz elf target (above 
lines) for the z/OS target. Is there a real concern for the execution time here 
for moving it to a separate unit test. If we did, it would seem to "stand out" 
for just the z/OS target.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109362/new/

https://reviews.llvm.org/D109362

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109362: [SystemZ][z/OS] Add GOFF Support to the DataLayout

[Anirudh Prasad via Phabricator via cfe-commits]

anirudhp updated this revision to Diff 372737.
anirudhp added a comment.

- Update to the documentation as well in account for the update to the global 
prefix.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109362/new/

https://reviews.llvm.org/D109362

Files:
  clang/lib/Basic/Targets/SystemZ.h
  clang/test/CodeGen/target-data.c
  llvm/docs/LangRef.rst
  llvm/include/llvm/IR/DataLayout.h
  llvm/lib/IR/DataLayout.cpp
  llvm/lib/Target/SystemZ/SystemZTargetMachine.cpp
  llvm/unittests/IR/ManglerTest.cpp

Index: llvm/unittests/IR/ManglerTest.cpp
===
--- llvm/unittests/IR/ManglerTest.cpp
+++ llvm/unittests/IR/ManglerTest.cpp
@@ -156,4 +156,22 @@
 "L..foo");
 }
 
+TEST(ManglerTest, GOFF) {
+  LLVMContext Ctx;
+  DataLayout DL("m:l"); // GOFF
+  Module Mod("test", Ctx);
+  Mod.setDataLayout(DL);
+  Mangler Mang;
+
+  EXPECT_EQ(mangleStr("foo", Mang, DL), "foo");
+  EXPECT_EQ(mangleStr("\01foo", Mang, DL), "foo");
+  EXPECT_EQ(mangleStr("?foo", Mang, DL), "?foo");
+  EXPECT_EQ(mangleFunc("foo", llvm::GlobalValue::ExternalLinkage,
+   llvm::CallingConv::C, Mod, Mang),
+"foo");
+  EXPECT_EQ(mangleFunc("foo", llvm::GlobalValue::PrivateLinkage,
+   llvm::CallingConv::C, Mod, Mang),
+"@foo");
+}
+
 } // end anonymous namespace
Index: llvm/lib/Target/SystemZ/SystemZTargetMachine.cpp
===
--- llvm/lib/Target/SystemZ/SystemZTargetMachine.cpp
+++ llvm/lib/Target/SystemZ/SystemZTargetMachine.cpp
@@ -84,8 +84,9 @@
   // 128-bit floats are aligned only to 64 bits.
   Ret += "-f128:64";
 
-  // When using the vector ABI, 128-bit vectors are also aligned to 64 bits.
-  if (VectorABI)
+  // When using the vector ABI on Linux, 128-bit vectors are also aligned to 64
+  // bits. On z/OS, vector types are always aligned to 64 bits.
+  if (VectorABI || TT.isOSzOS())
 Ret += "-v128:64";
 
   // We prefer 16 bits of aligned for all globals; see above.
Index: llvm/lib/IR/DataLayout.cpp
===
--- llvm/lib/IR/DataLayout.cpp
+++ llvm/lib/IR/DataLayout.cpp
@@ -151,6 +151,8 @@
 //===--===//
 
 const char *DataLayout::getManglingComponent(const Triple ) {
+  if (T.isOSBinFormatGOFF())
+return "-m:l";
   if (T.isOSBinFormatMachO())
 return "-m:o";
   if (T.isOSWindows() && T.isOSBinFormatCOFF())
@@ -500,6 +502,9 @@
   case 'e':
 ManglingMode = MM_ELF;
 break;
+  case 'l':
+ManglingMode = MM_GOFF;
+break;
   case 'o':
 ManglingMode = MM_MachO;
 break;
Index: llvm/include/llvm/IR/DataLayout.h
===
--- llvm/include/llvm/IR/DataLayout.h
+++ llvm/include/llvm/IR/DataLayout.h
@@ -135,6 +135,7 @@
 MM_MachO,
 MM_WinCOFF,
 MM_WinCOFFX86,
+MM_GOFF,
 MM_Mips,
 MM_XCOFF
   };
@@ -316,6 +317,7 @@
 switch (ManglingMode) {
 case MM_None:
 case MM_ELF:
+case MM_GOFF:
 case MM_Mips:
 case MM_WinCOFF:
 case MM_XCOFF:
@@ -334,6 +336,8 @@
 case MM_ELF:
 case MM_WinCOFF:
   return ".L";
+case MM_GOFF:
+  return "@";
 case MM_Mips:
   return "$";
 case MM_MachO:
Index: llvm/docs/LangRef.rst
===
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -2593,6 +2593,7 @@
 options are
 
 * ``e``: ELF mangling: Private symbols get a ``.L`` prefix.
+* ``l``: GOFF mangling: Private symbols get a ``@`` prefix.
 * ``m``: Mips mangling: Private symbols get a ``$`` prefix.
 * ``o``: Mach-O mangling: Private symbols get ``L`` prefix. Other
   symbols get a ``_`` prefix.
Index: clang/test/CodeGen/target-data.c
===
--- clang/test/CodeGen/target-data.c
+++ clang/test/CodeGen/target-data.c
@@ -253,6 +253,38 @@
 // RUN: FileCheck %s -check-prefix=SYSTEMZ-VECTOR
 // SYSTEMZ-VECTOR: target datalayout = "E-m:e-i1:8:16-i8:8:16-i64:64-f128:64-v128:64-a:8:16-n32:64"
 
+// RUN: %clang_cc1 -triple s390x-none-zos -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=ZOS
+// RUN: %clang_cc1 -triple s390x-none-zos -target-cpu z10 -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=ZOS
+// RUN: %clang_cc1 -triple s390x-none-zos -target-cpu arch8 -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=ZOS
+// RUN: %clang_cc1 -triple s390x-none-zos -target-cpu z196 -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=ZOS
+// RUN: %clang_cc1 -triple s390x-none-zos -target-cpu arch9 -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=ZOS
+// RUN: %clang_cc1 -triple s390x-none-zos -target-cpu zEC12 -o - -emit-llvm %s | \
+// RUN: 

[PATCH] D109362: [SystemZ][z/OS] Add GOFF Support to the DataLayout

[Anirudh Prasad via Phabricator via cfe-commits]

anirudhp added a comment.

In D109362#3001294 , @uweigand wrote:

> In D109362#3000284 , @anirudhp 
> wrote:
>
>> In D109362#2999688 , @uweigand 
>> wrote:
>>
>>> Looking at the common code parts, it seems the behavior of MM_GOFF is 
>>> actually identical to MM_ELF.   Is this correct?   If so, do we really need 
>>> a different format type here?
>>
>> At a future point, we will be changing the local and global prefixes. At 
>> that point we would still need a separate `MM_GOFF` field. I feel it would 
>> be a bit better to enforce it from now itself.
>
> I see.  Is there a reason why we cannot use the "correct" prefixes to begin 
> with?

Nope. I'll update the patch.

In D109362#3001294 , @uweigand wrote:

> In D109362#3000284 , @anirudhp 
> wrote:
>
>> In D109362#2999688 , @uweigand 
>> wrote:
>>
>>> Looking at the common code parts, it seems the behavior of MM_GOFF is 
>>> actually identical to MM_ELF.   Is this correct?   If so, do we really need 
>>> a different format type here?
>>
>> At a future point, we will be changing the local and global prefixes. At 
>> that point we would still need a separate `MM_GOFF` field. I feel it would 
>> be a bit better to enforce it from now itself.
>
> I see.  Is there a reason why we cannot use the "correct" prefixes to begin 
> with?

Nope. I've added it. There should also be a change to the MCAsmInfo fields 
(`PrivateGlobalPrefix` and `PrivateLabelPrefix`). These will be added in when 
the MCAsmInfo interfaces for z/OS are put up.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109362/new/

https://reviews.llvm.org/D109362

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109362: [SystemZ][z/OS] Add GOFF Support to the DataLayout

[Anirudh Prasad via Phabricator via cfe-commits]

anirudhp updated this revision to Diff 372733.
anirudhp added a comment.

- Introduce separate label prefix for `MM_GOFF`


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109362/new/

https://reviews.llvm.org/D109362

Files:
  clang/lib/Basic/Targets/SystemZ.h
  clang/test/CodeGen/target-data.c
  llvm/docs/LangRef.rst
  llvm/include/llvm/IR/DataLayout.h
  llvm/lib/IR/DataLayout.cpp
  llvm/lib/Target/SystemZ/SystemZTargetMachine.cpp
  llvm/unittests/IR/ManglerTest.cpp

Index: llvm/unittests/IR/ManglerTest.cpp
===
--- llvm/unittests/IR/ManglerTest.cpp
+++ llvm/unittests/IR/ManglerTest.cpp
@@ -156,4 +156,22 @@
 "L..foo");
 }
 
+TEST(ManglerTest, GOFF) {
+  LLVMContext Ctx;
+  DataLayout DL("m:l"); // GOFF
+  Module Mod("test", Ctx);
+  Mod.setDataLayout(DL);
+  Mangler Mang;
+
+  EXPECT_EQ(mangleStr("foo", Mang, DL), "foo");
+  EXPECT_EQ(mangleStr("\01foo", Mang, DL), "foo");
+  EXPECT_EQ(mangleStr("?foo", Mang, DL), "?foo");
+  EXPECT_EQ(mangleFunc("foo", llvm::GlobalValue::ExternalLinkage,
+   llvm::CallingConv::C, Mod, Mang),
+"foo");
+  EXPECT_EQ(mangleFunc("foo", llvm::GlobalValue::PrivateLinkage,
+   llvm::CallingConv::C, Mod, Mang),
+"@foo");
+}
+
 } // end anonymous namespace
Index: llvm/lib/Target/SystemZ/SystemZTargetMachine.cpp
===
--- llvm/lib/Target/SystemZ/SystemZTargetMachine.cpp
+++ llvm/lib/Target/SystemZ/SystemZTargetMachine.cpp
@@ -84,8 +84,9 @@
   // 128-bit floats are aligned only to 64 bits.
   Ret += "-f128:64";
 
-  // When using the vector ABI, 128-bit vectors are also aligned to 64 bits.
-  if (VectorABI)
+  // When using the vector ABI on Linux, 128-bit vectors are also aligned to 64
+  // bits. On z/OS, vector types are always aligned to 64 bits.
+  if (VectorABI || TT.isOSzOS())
 Ret += "-v128:64";
 
   // We prefer 16 bits of aligned for all globals; see above.
Index: llvm/lib/IR/DataLayout.cpp
===
--- llvm/lib/IR/DataLayout.cpp
+++ llvm/lib/IR/DataLayout.cpp
@@ -151,6 +151,8 @@
 //===--===//
 
 const char *DataLayout::getManglingComponent(const Triple ) {
+  if (T.isOSBinFormatGOFF())
+return "-m:l";
   if (T.isOSBinFormatMachO())
 return "-m:o";
   if (T.isOSWindows() && T.isOSBinFormatCOFF())
@@ -500,6 +502,9 @@
   case 'e':
 ManglingMode = MM_ELF;
 break;
+  case 'l':
+ManglingMode = MM_GOFF;
+break;
   case 'o':
 ManglingMode = MM_MachO;
 break;
Index: llvm/include/llvm/IR/DataLayout.h
===
--- llvm/include/llvm/IR/DataLayout.h
+++ llvm/include/llvm/IR/DataLayout.h
@@ -135,6 +135,7 @@
 MM_MachO,
 MM_WinCOFF,
 MM_WinCOFFX86,
+MM_GOFF,
 MM_Mips,
 MM_XCOFF
   };
@@ -316,6 +317,7 @@
 switch (ManglingMode) {
 case MM_None:
 case MM_ELF:
+case MM_GOFF:
 case MM_Mips:
 case MM_WinCOFF:
 case MM_XCOFF:
@@ -334,6 +336,8 @@
 case MM_ELF:
 case MM_WinCOFF:
   return ".L";
+case MM_GOFF:
+  return "@";
 case MM_Mips:
   return "$";
 case MM_MachO:
Index: llvm/docs/LangRef.rst
===
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -2593,6 +2593,7 @@
 options are
 
 * ``e``: ELF mangling: Private symbols get a ``.L`` prefix.
+* ``l``: GOFF mangling: Private symbols get a ``.L`` prefix.
 * ``m``: Mips mangling: Private symbols get a ``$`` prefix.
 * ``o``: Mach-O mangling: Private symbols get ``L`` prefix. Other
   symbols get a ``_`` prefix.
Index: clang/test/CodeGen/target-data.c
===
--- clang/test/CodeGen/target-data.c
+++ clang/test/CodeGen/target-data.c
@@ -253,6 +253,38 @@
 // RUN: FileCheck %s -check-prefix=SYSTEMZ-VECTOR
 // SYSTEMZ-VECTOR: target datalayout = "E-m:e-i1:8:16-i8:8:16-i64:64-f128:64-v128:64-a:8:16-n32:64"
 
+// RUN: %clang_cc1 -triple s390x-none-zos -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=ZOS
+// RUN: %clang_cc1 -triple s390x-none-zos -target-cpu z10 -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=ZOS
+// RUN: %clang_cc1 -triple s390x-none-zos -target-cpu arch8 -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=ZOS
+// RUN: %clang_cc1 -triple s390x-none-zos -target-cpu z196 -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=ZOS
+// RUN: %clang_cc1 -triple s390x-none-zos -target-cpu arch9 -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=ZOS
+// RUN: %clang_cc1 -triple s390x-none-zos -target-cpu zEC12 -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=ZOS
+// 

[PATCH] D109362: [SystemZ][z/OS] Add GOFF Support to the DataLayout

[Anirudh Prasad via Phabricator via cfe-commits]

anirudhp added a comment.

In D109362#2999688 , @uweigand wrote:

> Looking at the common code parts, it seems the behavior of MM_GOFF is 
> actually identical to MM_ELF.   Is this correct?   If so, do we really need a 
> different format type here?

At a future point, we will be changing the local and global prefixes. At that 
point we would still need a separate `MM_GOFF` field. I feel it would be a bit 
better to enforce it from now itself.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109362/new/

https://reviews.llvm.org/D109362

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109362: [SystemZ][z/OS] Add GOFF Support to the DataLayout

[Anirudh Prasad via Phabricator via cfe-commits]

anirudhp added a comment.

Ping :)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109362/new/

https://reviews.llvm.org/D109362

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109362: [SystemZ][z/OS] Add GOFF Support to the DataLayout

[Anirudh Prasad via Phabricator via cfe-commits]

anirudhp updated this revision to Diff 371106.
anirudhp added a comment.

- Condensed the lit test a bit.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109362/new/

https://reviews.llvm.org/D109362

Files:
  clang/lib/Basic/Targets/SystemZ.h
  clang/test/CodeGen/target-data.c
  llvm/docs/LangRef.rst
  llvm/include/llvm/IR/DataLayout.h
  llvm/lib/IR/DataLayout.cpp
  llvm/lib/Target/SystemZ/SystemZTargetMachine.cpp
  llvm/unittests/IR/ManglerTest.cpp

Index: llvm/unittests/IR/ManglerTest.cpp
===
--- llvm/unittests/IR/ManglerTest.cpp
+++ llvm/unittests/IR/ManglerTest.cpp
@@ -156,4 +156,22 @@
 "L..foo");
 }
 
+TEST(ManglerTest, GOFF) {
+  LLVMContext Ctx;
+  DataLayout DL("m:l"); // GOFF
+  Module Mod("test", Ctx);
+  Mod.setDataLayout(DL);
+  Mangler Mang;
+
+  EXPECT_EQ(mangleStr("foo", Mang, DL), "foo");
+  EXPECT_EQ(mangleStr("\01foo", Mang, DL), "foo");
+  EXPECT_EQ(mangleStr("?foo", Mang, DL), "?foo");
+  EXPECT_EQ(mangleFunc("foo", llvm::GlobalValue::ExternalLinkage,
+   llvm::CallingConv::C, Mod, Mang),
+"foo");
+  EXPECT_EQ(mangleFunc("foo", llvm::GlobalValue::PrivateLinkage,
+   llvm::CallingConv::C, Mod, Mang),
+".Lfoo");
+}
+
 } // end anonymous namespace
Index: llvm/lib/Target/SystemZ/SystemZTargetMachine.cpp
===
--- llvm/lib/Target/SystemZ/SystemZTargetMachine.cpp
+++ llvm/lib/Target/SystemZ/SystemZTargetMachine.cpp
@@ -84,8 +84,9 @@
   // 128-bit floats are aligned only to 64 bits.
   Ret += "-f128:64";
 
-  // When using the vector ABI, 128-bit vectors are also aligned to 64 bits.
-  if (VectorABI)
+  // When using the vector ABI on Linux, 128-bit vectors are also aligned to 64
+  // bits. On z/OS, vector types are always aligned to 64 bits.
+  if (VectorABI || TT.isOSzOS())
 Ret += "-v128:64";
 
   // We prefer 16 bits of aligned for all globals; see above.
Index: llvm/lib/IR/DataLayout.cpp
===
--- llvm/lib/IR/DataLayout.cpp
+++ llvm/lib/IR/DataLayout.cpp
@@ -151,6 +151,8 @@
 //===--===//
 
 const char *DataLayout::getManglingComponent(const Triple ) {
+  if (T.isOSBinFormatGOFF())
+return "-m:l";
   if (T.isOSBinFormatMachO())
 return "-m:o";
   if (T.isOSWindows() && T.isOSBinFormatCOFF())
@@ -500,6 +502,9 @@
   case 'e':
 ManglingMode = MM_ELF;
 break;
+  case 'l':
+ManglingMode = MM_GOFF;
+break;
   case 'o':
 ManglingMode = MM_MachO;
 break;
Index: llvm/include/llvm/IR/DataLayout.h
===
--- llvm/include/llvm/IR/DataLayout.h
+++ llvm/include/llvm/IR/DataLayout.h
@@ -135,6 +135,7 @@
 MM_MachO,
 MM_WinCOFF,
 MM_WinCOFFX86,
+MM_GOFF,
 MM_Mips,
 MM_XCOFF
   };
@@ -316,6 +317,7 @@
 switch (ManglingMode) {
 case MM_None:
 case MM_ELF:
+case MM_GOFF:
 case MM_Mips:
 case MM_WinCOFF:
 case MM_XCOFF:
@@ -332,6 +334,7 @@
 case MM_None:
   return "";
 case MM_ELF:
+case MM_GOFF:
 case MM_WinCOFF:
   return ".L";
 case MM_Mips:
Index: llvm/docs/LangRef.rst
===
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -2593,6 +2593,7 @@
 options are
 
 * ``e``: ELF mangling: Private symbols get a ``.L`` prefix.
+* ``l``: GOFF mangling: Private symbols get a ``.L`` prefix.
 * ``m``: Mips mangling: Private symbols get a ``$`` prefix.
 * ``o``: Mach-O mangling: Private symbols get ``L`` prefix. Other
   symbols get a ``_`` prefix.
Index: clang/test/CodeGen/target-data.c
===
--- clang/test/CodeGen/target-data.c
+++ clang/test/CodeGen/target-data.c
@@ -253,6 +253,38 @@
 // RUN: FileCheck %s -check-prefix=SYSTEMZ-VECTOR
 // SYSTEMZ-VECTOR: target datalayout = "E-m:e-i1:8:16-i8:8:16-i64:64-f128:64-v128:64-a:8:16-n32:64"
 
+// RUN: %clang_cc1 -triple s390x-none-zos -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=ZOS
+// RUN: %clang_cc1 -triple s390x-none-zos -target-cpu z10 -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=ZOS
+// RUN: %clang_cc1 -triple s390x-none-zos -target-cpu arch8 -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=ZOS
+// RUN: %clang_cc1 -triple s390x-none-zos -target-cpu z196 -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=ZOS
+// RUN: %clang_cc1 -triple s390x-none-zos -target-cpu arch9 -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=ZOS
+// RUN: %clang_cc1 -triple s390x-none-zos -target-cpu zEC12 -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=ZOS
+// RUN: %clang_cc1 -triple s390x-none-zos 

[PATCH] D109362: [SystemZ][z/OS] Add GOFF Support to the DataLayout

[Anirudh Prasad via Phabricator via cfe-commits]

anirudhp created this revision.
Herald added subscribers: dexonsmith, jdoerfert, hiraditya.
anirudhp requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

- This patch adds in the GOFF mangling support to the LLVM data layout string. 
A corresponding additional line has been added into the data layout section in 
the language reference documentation.
- Furthermore, this patch also sets the right data layout string for the z/OS 
target in the SystemZ backend.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109362

Files:
  clang/lib/Basic/Targets/SystemZ.h
  clang/test/CodeGen/target-data.c
  llvm/docs/LangRef.rst
  llvm/include/llvm/IR/DataLayout.h
  llvm/lib/IR/DataLayout.cpp
  llvm/lib/Target/SystemZ/SystemZTargetMachine.cpp
  llvm/unittests/IR/ManglerTest.cpp

Index: llvm/unittests/IR/ManglerTest.cpp
===
--- llvm/unittests/IR/ManglerTest.cpp
+++ llvm/unittests/IR/ManglerTest.cpp
@@ -156,4 +156,22 @@
 "L..foo");
 }
 
+TEST(ManglerTest, GOFF) {
+  LLVMContext Ctx;
+  DataLayout DL("m:l"); // GOFF
+  Module Mod("test", Ctx);
+  Mod.setDataLayout(DL);
+  Mangler Mang;
+
+  EXPECT_EQ(mangleStr("foo", Mang, DL), "foo");
+  EXPECT_EQ(mangleStr("\01foo", Mang, DL), "foo");
+  EXPECT_EQ(mangleStr("?foo", Mang, DL), "?foo");
+  EXPECT_EQ(mangleFunc("foo", llvm::GlobalValue::ExternalLinkage,
+   llvm::CallingConv::C, Mod, Mang),
+"foo");
+  EXPECT_EQ(mangleFunc("foo", llvm::GlobalValue::PrivateLinkage,
+   llvm::CallingConv::C, Mod, Mang),
+".Lfoo");
+}
+
 } // end anonymous namespace
Index: llvm/lib/Target/SystemZ/SystemZTargetMachine.cpp
===
--- llvm/lib/Target/SystemZ/SystemZTargetMachine.cpp
+++ llvm/lib/Target/SystemZ/SystemZTargetMachine.cpp
@@ -84,8 +84,9 @@
   // 128-bit floats are aligned only to 64 bits.
   Ret += "-f128:64";
 
-  // When using the vector ABI, 128-bit vectors are also aligned to 64 bits.
-  if (VectorABI)
+  // When using the vector ABI on Linux, 128-bit vectors are also aligned to 64
+  // bits. On z/OS, vector types are always aligned to 64 bits.
+  if (VectorABI || TT.isOSzOS())
 Ret += "-v128:64";
 
   // We prefer 16 bits of aligned for all globals; see above.
Index: llvm/lib/IR/DataLayout.cpp
===
--- llvm/lib/IR/DataLayout.cpp
+++ llvm/lib/IR/DataLayout.cpp
@@ -151,6 +151,8 @@
 //===--===//
 
 const char *DataLayout::getManglingComponent(const Triple ) {
+  if (T.isOSBinFormatGOFF())
+return "-m:l";
   if (T.isOSBinFormatMachO())
 return "-m:o";
   if (T.isOSWindows() && T.isOSBinFormatCOFF())
@@ -500,6 +502,9 @@
   case 'e':
 ManglingMode = MM_ELF;
 break;
+  case 'l':
+ManglingMode = MM_GOFF;
+break;
   case 'o':
 ManglingMode = MM_MachO;
 break;
Index: llvm/include/llvm/IR/DataLayout.h
===
--- llvm/include/llvm/IR/DataLayout.h
+++ llvm/include/llvm/IR/DataLayout.h
@@ -135,6 +135,7 @@
 MM_MachO,
 MM_WinCOFF,
 MM_WinCOFFX86,
+MM_GOFF,
 MM_Mips,
 MM_XCOFF
   };
@@ -316,6 +317,7 @@
 switch (ManglingMode) {
 case MM_None:
 case MM_ELF:
+case MM_GOFF:
 case MM_Mips:
 case MM_WinCOFF:
 case MM_XCOFF:
@@ -332,6 +334,7 @@
 case MM_None:
   return "";
 case MM_ELF:
+case MM_GOFF:
 case MM_WinCOFF:
   return ".L";
 case MM_Mips:
Index: llvm/docs/LangRef.rst
===
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -2593,6 +2593,7 @@
 options are
 
 * ``e``: ELF mangling: Private symbols get a ``.L`` prefix.
+* ``l``: GOFF mangling: Private symbols get a ``.L`` prefix.
 * ``m``: Mips mangling: Private symbols get a ``$`` prefix.
 * ``o``: Mach-O mangling: Private symbols get ``L`` prefix. Other
   symbols get a ``_`` prefix.
Index: clang/test/CodeGen/target-data.c
===
--- clang/test/CodeGen/target-data.c
+++ clang/test/CodeGen/target-data.c
@@ -253,6 +253,40 @@
 // RUN: FileCheck %s -check-prefix=SYSTEMZ-VECTOR
 // SYSTEMZ-VECTOR: target datalayout = "E-m:e-i1:8:16-i8:8:16-i64:64-f128:64-v128:64-a:8:16-n32:64"
 
+// RUN: %clang_cc1 -triple s390x-none-zos -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=ZOS
+// RUN: %clang_cc1 -triple s390x-none-zos -target-cpu z10 -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=ZOS
+// RUN: %clang_cc1 -triple s390x-none-zos -target-cpu arch8 -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=ZOS
+// RUN: %clang_cc1 -triple s390x-none-zos 

[PATCH] D105142: RFC: Implementing new mechanism for hard register operands to inline asm as a constraint.

[Anirudh Prasad via Phabricator via cfe-commits]

anirudhp added a comment.

In D105142#2862592 , @jyknight wrote:

> This code doesn't handle multiple alternatives in a constraint.
>
> E.g. `"={eax}{ebx}"` or `"={eax}{ebx},m"`.
>
> See the GCC docs for the C-level syntax
> https://gcc.gnu.org/onlinedocs/gcc/Multi-Alternative.html#Multi-Alternative
> and LLVM IR docs for the IR syntax:
> https://llvm.org/docs/LangRef.html#constraint-codes
>
> LLVM doesn't handle alternatives very well in the backend, but Clang at least 
> should parse and properly generate LLVM asm strings for these cases I think.

You're right, when it came to the {...} constraint, initially I purposely 
errored out when there were multiple constraints after {.*}. To me, it didn't 
make sense to issue another constraint when you're already being specific 
enough by asking the backend to use a specific register. For example, the 
AMDGPU target, currently errors out when you have something like "{reg-name}a". 
Ideally if its an option, I'd like to make it even more strict to ensure that 
there is no other constraint applied with {.*}. Ie. if a user specifies a hard 
register constraint, only emit that, otherwise diagnose as an error, because a 
hard register constraint is quite specific to begin with. Maybe this could be 
documented as a special feature (a standalone constraint, can't be used as a 
multi-alternative constraint) since this is something new? (From the backend's 
perspective, is it a valid scenario to try to allocate two registers for an 
operand? will the last one occurring be the one allocated? what happens if the 
user wanted the "first" register?)

If not, I have no issue with changing it to emit multiple constraints in the 
IR, but I'd like to get your thoughts on the above first.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105142/new/

https://reviews.llvm.org/D105142

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D105142: RFC: Implementing new mechanism for hard register operands to inline asm as a constraint.

[Anirudh Prasad via Phabricator via cfe-commits]

anirudhp added a comment.

@MaskRay Could you please look at the latest changeset, I have added your 
example as a separate test case for the x86 target.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105142/new/

https://reviews.llvm.org/D105142

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D105142: RFC: Implementing new mechanism for hard register operands to inline asm as a constraint.

[Anirudh Prasad via Phabricator via cfe-commits]

anirudhp updated this revision to Diff 356968.
anirudhp added a comment.

- Something went wrong with the previous time updating the diff. I'm not too 
sure, but I'm just doing it again, and this time the it looks a lot better.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105142/new/

https://reviews.llvm.org/D105142

Files:
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/CodeGen/CGStmt.cpp
  clang/test/CodeGen/SystemZ/systemz-inline-asm-02.c
  clang/test/CodeGen/SystemZ/systemz-inline-asm.c
  clang/test/CodeGen/aarch64-inline-asm.c
  clang/test/CodeGen/asm-goto.c
  clang/test/CodeGen/ms-intrinsics.c
  clang/test/CodeGen/x86-asm-register-constraint-mix.c
  clang/test/CodeGen/z-hard-register-inline-asm.c
  clang/test/Sema/z-hard-register-inline-asm.c

Index: clang/test/Sema/z-hard-register-inline-asm.c
===
--- /dev/null
+++ clang/test/Sema/z-hard-register-inline-asm.c
@@ -0,0 +1,49 @@
+// RUN: %clang_cc1 %s -triple s390x-ibm-linux -fsyntax-only -verify
+// RUN: %clang_cc1 %s -triple s390x-ibm-zos -fsyntax-only -verify
+
+void f1() {
+  int a, b;
+  __asm("lhi %0,5\n"
+: "={r2}"(a)
+:);
+
+  __asm("lgr %0,%1\n"
+: "={r2}"(a)
+: "{r1}"(b));
+
+  __asm("lgr %0,%1\n"
+: "={r2}"(a)
+: "{%r1}"(b));
+
+  __asm("lgr %0,%1\n"
+: "=&{r1}"(a)
+: "{r2}"(b));
+
+  __asm("lhi %0,5\n"
+: "={r2"(a) // expected-error {{invalid output constraint '={r2' in asm}}
+:);
+
+  __asm("lhi %0,5\n"
+: "={r17}"(a) // expected-error {{invalid output constraint '={r17}' in asm}}
+:);
+
+  __asm("lhi %0,5\n"
+: "={}"(a) // expected-error {{invalid output constraint '={}' in asm}}
+:);
+
+  __asm("lhi %0,5\n"
+: "=&{r2"(a) // expected-error {{invalid output constraint '=&{r2' in asm}}
+:);
+
+  __asm("lgr %0,%1\n"
+: "=r"(a)
+: "{r1"(b)); // expected-error {{invalid input constraint '{r1' in asm}}
+
+  __asm("lgr %0,%1\n"
+: "=r"(a)
+: "{}"(b)); // expected-error {{invalid input constraint '{}' in asm}}
+
+  __asm("lgr %0,%1\n"
+: "={r1}"(a)
+: "{r17}"(b)); // expected-error {{invalid input constraint '{r17}' in asm}}
+}
Index: clang/test/CodeGen/z-hard-register-inline-asm.c
===
--- /dev/null
+++ clang/test/CodeGen/z-hard-register-inline-asm.c
@@ -0,0 +1,48 @@
+// RUN: %clang_cc1 -triple s390x-ibm-linux -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple s390x-ibm-zos -emit-llvm -o - %s | FileCheck %s
+
+void f1() {
+  int a, b;
+  register int c asm("r1");
+  register int d asm("r2");
+
+  // CHECK-COUNT-2: call i32 asm "lhi $0,5\0A", "={r1}"
+  __asm("lhi %0,5\n"
+: "={r1}"(a)
+:
+:);
+  __asm("lhi %0,5\n"
+: "=r"(c)
+:
+:);
+
+  // CHECK-COUNT-2: call i32 asm "lgr $0,$1\0A", "={r1},{r2}"
+  __asm("lgr %0,%1\n"
+: "={r1}"(a)
+: "{r2}"(b)
+:);
+  __asm("lgr %0,%1\n"
+: "=r"(c)
+: "r"(d)
+:);
+
+  // CHECK-COUNT-2: call i32 asm "lgr $0,$1\0A", "={r1},{r2}"
+  __asm("lgr %0,%1\n"
+: "={%r1}"(a)
+: "{%r2}"(b)
+:);
+  __asm("lgr %0,%1\n"
+: "={r1}"(a)
+: "{%r2}"(b)
+:);
+
+  // CHECK-COUNT-2: call i32 asm "lgr $0,$1\0A", "=&{r1},{r2}"
+  __asm("lgr %0,%1\n"
+: "=&{r1}"(a)
+: "{%r2}"(b)
+:);
+  __asm("lgr %0,%1\n"
+: "="(c)
+: "r"(d)
+:);
+}
Index: clang/test/CodeGen/x86-asm-register-constraint-mix.c
===
--- /dev/null
+++ clang/test/CodeGen/x86-asm-register-constraint-mix.c
@@ -0,0 +1,63 @@
+// REQUIRES: x86-registered-target
+// RUN: %clang_cc1 -triple x86_64-pc-linux-gnu -O2 -emit-llvm %s -o - | FileCheck %s
+
+unsigned long foo(unsigned long addr, unsigned long a0,
+  unsigned long a1, unsigned long a2,
+  unsigned long a3, unsigned long a4,
+  unsigned long a5) {
+  register unsigned long result asm("rax");
+  register unsigned long addr1 asm("rax") = addr;
+  register unsigned long b0 asm("rdi") = a0;
+  register unsigned long b1 asm("rsi") = a1;
+  register unsigned long b2 asm("rdx") = a2;
+  register unsigned long b3 asm("rcx") = a3;
+  register unsigned long b4 asm("r8") = a4;
+  register unsigned long b5 asm("r9") = a5;
+
+  // CHECK: tail call i64 asm "call *$1", "={rax},{rax},{rdi},{rsi},{rdx},{rcx},{r8},{r9},{rax},~{dirflag},~{fpsr},~{flags}"(i64 %addr, i64 %a0, i64 %a1, i64 %a2, i64 %a3, i64 %a4, i64 %a5, i64 undef)
+  asm("call *%1" 
+  : "+r" (result) 
+  : "r"(addr1), "r"(b0), "r"(b1), "r"(b2), "r"(b3), "r"(b4), "r"(b5));
+  return result;
+}
+
+unsigned long foo1(unsigned long addr, unsigned long a0,
+  

[PATCH] D105142: RFC: Implementing new mechanism for hard register operands to inline asm as a constraint.

[Anirudh Prasad via Phabricator via cfe-commits]

anirudhp updated this revision to Diff 356961.
anirudhp added a comment.

- Disable constraint simplification when you already have a constraint of the 
form {...}. Constraint simplification is usually done character by character, 
with different targets having different implementations.
- Furthermore, a constraint of the form {...} already maps to the LLVM inline 
assembly IR that tells the backend to allocate a suitable physical register.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105142/new/

https://reviews.llvm.org/D105142

Files:
  clang/lib/CodeGen/CGStmt.cpp
  clang/test/CodeGen/x86-asm-register-constraint-mix.c


Index: clang/test/CodeGen/x86-asm-register-constraint-mix.c
===
--- /dev/null
+++ clang/test/CodeGen/x86-asm-register-constraint-mix.c
@@ -0,0 +1,63 @@
+// REQUIRES: x86-registered-target
+// RUN: %clang_cc1 -triple x86_64-pc-linux-gnu -O2 -emit-llvm %s -o - | 
FileCheck %s
+
+unsigned long foo(unsigned long addr, unsigned long a0,
+  unsigned long a1, unsigned long a2,
+  unsigned long a3, unsigned long a4,
+  unsigned long a5) {
+  register unsigned long result asm("rax");
+  register unsigned long addr1 asm("rax") = addr;
+  register unsigned long b0 asm("rdi") = a0;
+  register unsigned long b1 asm("rsi") = a1;
+  register unsigned long b2 asm("rdx") = a2;
+  register unsigned long b3 asm("rcx") = a3;
+  register unsigned long b4 asm("r8") = a4;
+  register unsigned long b5 asm("r9") = a5;
+
+  // CHECK: tail call i64 asm "call *$1", 
"={rax},{rax},{rdi},{rsi},{rdx},{rcx},{r8},{r9},{rax},~{dirflag},~{fpsr},~{flags}"(i64
 %addr, i64 %a0, i64 %a1, i64 %a2, i64 %a3, i64 %a4, i64 %a5, i64 undef)
+  asm("call *%1" 
+  : "+r" (result) 
+  : "r"(addr1), "r"(b0), "r"(b1), "r"(b2), "r"(b3), "r"(b4), "r"(b5));
+  return result;
+}
+
+unsigned long foo1(unsigned long addr, unsigned long a0,
+  unsigned long a1, unsigned long a2,
+  unsigned long a3, unsigned long a4,
+  unsigned long a5) {
+  unsigned long result;
+  unsigned long addr1 = addr;
+  unsigned long b0 = a0;
+  unsigned long b1 = a1;
+  unsigned long b2 = a2;
+  unsigned long b3 = a3;
+  unsigned long b4 = a4;
+  unsigned long b5 = a5;
+
+  // CHECK: tail call i64 asm "call *$1", 
"={rax},{rax},{rdi},{rsi},{rdx},{rcx},{r8},{r9},{rax},~{dirflag},~{fpsr},~{flags}"(i64
 %addr, i64 %a0, i64 %a1, i64 %a2, i64 %a3, i64 %a4, i64 %a5, i64 undef)
+  asm("call *%1" 
+  : "+{rax}" (result) 
+  : "{rax}"(addr1), "{rdi}"(b0), "{rsi}"(b1), "{rdx}"(b2), "{rcx}"(b3), 
"{r8}"(b4), "{r9}"(b5));
+  return result;
+}
+
+unsigned long foo2(unsigned long addr, unsigned long a0,
+  unsigned long a1, unsigned long a2,
+  unsigned long a3, unsigned long a4,
+  unsigned long a5) {
+  register unsigned long result asm("rax");
+  unsigned long addr1 = addr;
+  unsigned long b0 = a0;
+  register unsigned long b1 asm ("rsi") = a1;
+  unsigned long b2 = a2;
+  unsigned long b3 = a3;
+  register unsigned long b4 asm ("r8") = a4;
+  unsigned long b5 = a5;
+
+  // CHECK: tail call i64 asm "call *$1", 
"={rax},{rax},{rdi},{rsi},{rdx},{rcx},{r8},{r9},{rax},~{dirflag},~{fpsr},~{flags}"(i64
 %addr, i64 %a0, i64 %a1, i64 %a2, i64 %a3, i64 %a4, i64 %a5, i64 undef)
+  asm("call *%1" 
+  : "+r" (result) 
+  : "{rax}"(addr1), "{rdi}"(b0), "r"(b1), "{rdx}"(b2), "{rcx}"(b3), 
"r"(b4), "{r9}"(b5));
+  return result;
+}
+
Index: clang/lib/CodeGen/CGStmt.cpp
===
--- clang/lib/CodeGen/CGStmt.cpp
+++ clang/lib/CodeGen/CGStmt.cpp
@@ -1966,6 +1966,13 @@
 static std::string
 SimplifyConstraint(const char *Constraint, const TargetInfo ,
  SmallVectorImpl *OutCons=nullptr) 
{
+  // If we have only the {...} constraint, do not do any simplifications. This 
already
+  // maps to the lower level LLVM inline assembly IR that tells the backend to 
allocate
+  // a specific register. Any validations would have already been done in the 
Sema stage
+  // or will be done in the AddVariableConstraints function.
+  if (Constraint[0] == '{' || (Constraint[0] == '&' && Constraint[1] == '{'))
+return std::string(Constraint);
+
   std::string Result;
 
   while (*Constraint) {


Index: clang/test/CodeGen/x86-asm-register-constraint-mix.c
===
--- /dev/null
+++ clang/test/CodeGen/x86-asm-register-constraint-mix.c
@@ -0,0 +1,63 @@
+// REQUIRES: x86-registered-target
+// RUN: %clang_cc1 -triple x86_64-pc-linux-gnu -O2 -emit-llvm %s -o - | FileCheck %s
+
+unsigned long foo(unsigned long addr, unsigned long a0,
+  unsigned long a1, unsigned long a2,
+  unsigned long a3, unsigned long a4,
+  unsigned long a5) {
+  register unsigned long 

[PATCH] D105142: RFC: Implementing new mechanism for hard register operands to inline asm as a constraint.

[Anirudh Prasad via Phabricator via cfe-commits]

anirudhp added a comment.

In D105142#2860885 , @MaskRay wrote:

> This is great.
>
>   unsigned long foo(unsigned long addr, unsigned long a0,
> unsigned long a1, unsigned long a2,
> unsigned long a3, unsigned long a4,
> unsigned long a5) {
> unsigned long result asm("rax");
> unsigned long b2 asm("rdx") = a2;
> unsigned long b3 asm("rcx") = a3;
> unsigned long b4 asm("r8") = a4;
> unsigned long b5 asm("r9") = a5;
> asm("call *%1" : "=r" (result) : "{rax}"(addr), "{rdi}"(a0), "{rsi}"(a1), 
> "r"(b2), "r"(b3), "r"(b4), "r"(b5));
> return result;
>   }
>
> this compiles to`%0 = tail call i64 asm "call *$1", 
> "=r,{r{ax}x},{r{dx}i},{rsi},r,r,r,r,~{dirflag},~{fpsr},~{flags}"(i64 %addr, 
> i64 %a0, i64 %a1, i64 %a2, i64 %a3, i64 %a4, i64 %a5) #1, !srcloc !3`
> (note `{r{ax}x},{r{dx}i}`) which will cause a backend failure `error: 
> couldn't allocate input reg for constraint '{r{dx}'`.
> Can you investigate it?

Definitely!

I'm assuming this is the X86 target from the usage of the registers in the 
example. So the issue here seems to be that before a constraint is emitted into 
the IR, the `SimplifyConstraint` (in CGStmt.cpp) 
/`TargetInfo::ConvertConstraint` (Target overridden) function(s) is/are called 
to "convert" the constraint into a simpler form if it exists. So, in this 
particular case, {rax}, gets "simplified" to {r{ax}} because:

  { -> no simplification rule exists -> simply emit it
  r -> no simplification rule exists -> simply emit it
  a -> simplified to {ax}-> {ax} is emitted
  x -> no simplification rule exists -> simply emit it
  } -> no simplification rule exists -> simply emit it

Thanks for bringing up this point because I missed it.

Looking into it in more detail, I think we can just forego the 
"simplification"/"conversion" of the constraint while emitting, if we have the 
[&]{.*} form, since this already maps to the lower level LLVM inline assembly 
IR which is responsible for telling the backend to allocate a specific 
register. All validation is already performed in the Sema stage, and/or in the 
AddVariableConstraints function. So what can be done imo, is to simply early 
return in the `SimplifyConstraint` function in CGStmt.cpp, when you have the 
constraint of the form [&]{.*}. What do you think?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105142/new/

https://reviews.llvm.org/D105142

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D105142: RFC: Implementing new mechanism for hard register operands to inline asm as a constraint.

[Anirudh Prasad via Phabricator via cfe-commits]

anirudhp added a comment.

In D105142#2849835 , @theraven wrote:

> The code looks fine but it would be good to see some docs along with it.  
> We're currently missing docs on inline assembly entirely and the GCC ones are 
> somewhat... opaque when it comes to describing how constraints work.

Thank you for your feedback! By docs do you mind updating/adding some 
information to the existing LLVM docs(like the langref 
https://llvm.org/docs/LangRef.html for example), or more comments to the code?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105142/new/

https://reviews.llvm.org/D105142

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D105142: RFC: Implementing new mechanism for hard register operands to inline asm as a constraint.

[Anirudh Prasad via Phabricator via cfe-commits]

anirudhp updated this revision to Diff 355332.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105142/new/

https://reviews.llvm.org/D105142

Files:
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/CodeGen/CGStmt.cpp
  clang/test/CodeGen/SystemZ/systemz-inline-asm-02.c
  clang/test/CodeGen/SystemZ/systemz-inline-asm.c
  clang/test/CodeGen/aarch64-inline-asm.c
  clang/test/CodeGen/asm-goto.c
  clang/test/CodeGen/ms-intrinsics.c
  clang/test/CodeGen/z-hard-register-inline-asm.c
  clang/test/Sema/z-hard-register-inline-asm.c

Index: clang/test/Sema/z-hard-register-inline-asm.c
===
--- /dev/null
+++ clang/test/Sema/z-hard-register-inline-asm.c
@@ -0,0 +1,49 @@
+// RUN: %clang_cc1 %s -triple s390x-ibm-linux -fsyntax-only -verify
+// RUN: %clang_cc1 %s -triple s390x-ibm-zos -fsyntax-only -verify
+
+void f1() {
+  int a, b;
+  __asm("lhi %0,5\n"
+: "={r2}"(a)
+:);
+
+  __asm("lgr %0,%1\n"
+: "={r2}"(a)
+: "{r1}"(b));
+
+  __asm("lgr %0,%1\n"
+: "={r2}"(a)
+: "{%r1}"(b));
+
+  __asm("lgr %0,%1\n"
+: "=&{r1}"(a)
+: "{r2}"(b));
+
+  __asm("lhi %0,5\n"
+: "={r2"(a) // expected-error {{invalid output constraint '={r2' in asm}}
+:);
+
+  __asm("lhi %0,5\n"
+: "={r17}"(a) // expected-error {{invalid output constraint '={r17}' in asm}}
+:);
+
+  __asm("lhi %0,5\n"
+: "={}"(a) // expected-error {{invalid output constraint '={}' in asm}}
+:);
+
+  __asm("lhi %0,5\n"
+: "=&{r2"(a) // expected-error {{invalid output constraint '=&{r2' in asm}}
+:);
+
+  __asm("lgr %0,%1\n"
+: "=r"(a)
+: "{r1"(b)); // expected-error {{invalid input constraint '{r1' in asm}}
+
+  __asm("lgr %0,%1\n"
+: "=r"(a)
+: "{}"(b)); // expected-error {{invalid input constraint '{}' in asm}}
+
+  __asm("lgr %0,%1\n"
+: "={r1}"(a)
+: "{r17}"(b)); // expected-error {{invalid input constraint '{r17}' in asm}}
+}
Index: clang/test/CodeGen/z-hard-register-inline-asm.c
===
--- /dev/null
+++ clang/test/CodeGen/z-hard-register-inline-asm.c
@@ -0,0 +1,48 @@
+// RUN: %clang_cc1 -triple s390x-ibm-linux -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple s390x-ibm-zos -emit-llvm -o - %s | FileCheck %s
+
+void f1() {
+  int a, b;
+  register int c asm("r1");
+  register int d asm("r2");
+
+  // CHECK-COUNT-2: call i32 asm "lhi $0,5\0A", "={r1}"
+  __asm("lhi %0,5\n"
+: "={r1}"(a)
+:
+:);
+  __asm("lhi %0,5\n"
+: "=r"(c)
+:
+:);
+
+  // CHECK-COUNT-2: call i32 asm "lgr $0,$1\0A", "={r1},{r2}"
+  __asm("lgr %0,%1\n"
+: "={r1}"(a)
+: "{r2}"(b)
+:);
+  __asm("lgr %0,%1\n"
+: "=r"(c)
+: "r"(d)
+:);
+
+  // CHECK-COUNT-2: call i32 asm "lgr $0,$1\0A", "={r1},{r2}"
+  __asm("lgr %0,%1\n"
+: "={%r1}"(a)
+: "{%r2}"(b)
+:);
+  __asm("lgr %0,%1\n"
+: "={r1}"(a)
+: "{%r2}"(b)
+:);
+
+  // CHECK-COUNT-2: call i32 asm "lgr $0,$1\0A", "=&{r1},{r2}"
+  __asm("lgr %0,%1\n"
+: "=&{r1}"(a)
+: "{%r2}"(b)
+:);
+  __asm("lgr %0,%1\n"
+: "="(c)
+: "r"(d)
+:);
+}
Index: clang/test/CodeGen/ms-intrinsics.c
===
--- clang/test/CodeGen/ms-intrinsics.c
+++ clang/test/CodeGen/ms-intrinsics.c
@@ -36,12 +36,12 @@
   return __movsb(Dest, Src, Count);
 }
 // CHECK-I386-LABEL: define{{.*}} void @test__movsb
-// CHECK-I386:   call { i8*, i8*, i32 } asm sideeffect "rep movsb", "={di},={si},={cx},0,1,2,~{memory},~{dirflag},~{fpsr},~{flags}"(i8* %Dest, i8* %Src, i32 %Count)
+// CHECK-I386:   call { i8*, i8*, i32 } asm sideeffect "rep movsb", "={di},={si},={cx},{di},{si},{cx},~{memory},~{dirflag},~{fpsr},~{flags}"(i8* %Dest, i8* %Src, i32 %Count)
 // CHECK-I386:   ret void
 // CHECK-I386: }
 
 // CHECK-X64-LABEL: define{{.*}} void @test__movsb
-// CHECK-X64:   call { i8*, i8*, i64 } asm sideeffect "rep movsb", "={di},={si},={cx},0,1,2,~{memory},~{dirflag},~{fpsr},~{flags}"(i8* %Dest, i8* %Src, i64 %Count)
+// CHECK-X64:   call { i8*, i8*, i64 } asm sideeffect "rep movsb", "={di},={si},={cx},{di},{si},{cx},~{memory},~{dirflag},~{fpsr},~{flags}"(i8* %Dest, i8* %Src, i64 %Count)
 // CHECK-X64:   ret void
 // CHECK-X64: }
 
@@ -49,12 +49,12 @@
   return __stosw(Dest, Data, Count);
 }
 // CHECK-I386-LABEL: define{{.*}} void @test__stosw
-// CHECK-I386:   call { i16*, i32 } asm sideeffect "rep stosw", "={di},={cx},{ax},0,1,~{memory},~{dirflag},~{fpsr},~{flags}"(i16 %Data, i16* %Dest, i32 %Count)
+// CHECK-I386:   call { i16*, i32 } asm sideeffect "rep stosw", "={di},={cx},{ax},{di},{cx},~{memory},~{dirflag},~{fpsr},~{flags}"(i16 %Data, i16* %Dest, i32 %Count)
 // 

[PATCH] D105142: RFC: Implementing new mechanism for hard register operands to inline asm as a constraint.

[Anirudh Prasad via Phabricator via cfe-commits]

anirudhp created this revision.
Herald added subscribers: pengfei, jfb, tpr.
anirudhp requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

- Relevant RFCs posted here

https://lists.llvm.org/pipermail/llvm-dev/2021-June/151370.html
https://gcc.gnu.org/pipermail/gcc/2021-June/236269.html

- This is put up as an RFC patch to get feedback about the introduction of a 
new inline asm constraint which supports hard register operands
- This is mostly a clang change, since the LLVM IR for the inline assembly 
already supports the {...} syntax which the backend recognizes. This change 
merely completes the loop in terms of introducing a user facing constraint 
which maps to it.

The following design decisions were taken for this patch:

For the Sema side:

- We validate the "{" constraint using a two-phase validation approach. 
Firstly, we check if there is a target dependent implementation to handle the 
{} constraint. If it fails, then we move on to a target agnostic check 
where we parse and validate the {} constraint.
- Why do we do this? Well, there are some targets which already process the 
{...} as a user facing constraint. For example the AMDGPU target. It supports 
syntax of the form {register-name} as well as {register-name[...]}. Moving this 
implementation to the target agnostic side seems to set a precedent, that we 
can keep extending the target agnostic implementation based on new cases for 
certain targets, which would be better served of moving it to the respective 
target.
- In terms of the target agnostic validation, we simply check for the following 
syntax {.*}. The parsed out content within the two curly braces is checked to 
see whether its a "valid GCC register".

For the Clang CodeGen side:

- Most of the work is done in the `AddVariableConstraints` function in 
CGStmt.cpp, which is responsible for emitting the LLVM IR corresponding to the 
usage of an actual register that the backend can use. Coincidentally, the LLVM 
IR is also {...}. As mentioned above, this is essentially mapping the LLVM 
Inline Assembly IR back to a user facing inline asm constraint.
- Within this function we add in logic to check if the constraint is of the 
form [&]{...} in addition to the "register asm" construct.
- A scenario where it was applicable to apply both the "register asm" construct 
and the "hard register inline asm constraint" was diagnosed as an unsupported 
error because there's no way the compiler will know which register the user 
meant. The safest option here is to error out explicitly, and put onus back on 
the user.
- To achieve this, and refactor it in a nice way, most of the logic pertaining 
to the "register asm" construct has been moved into a separate function called 
`ShouldApplyRegisterVariableConstraint` which deduces whether to apply the 
"register asm" construct or not.
- Furthermore, the GCCReg field is set with the "Register" only if the register 
is validated to be a "valid GCC Register" type. To me it doesn't make a lot of 
sense to set GCC Reg to something that might not necessarily be a "valid GCC 
register" as defined by respective targets. Would we have a case where we could 
have a {.*} constraint where the contents inside the curly brace is not a valid 
register? Yes. For example, The x86 target supports the "@cca" constraint, 
which is validated on the Sema side as a valid constraint, and before 
processing is converted to "{@cca}" (via the `convertAsmConstraint` function. 
"@cca" is not a valid "GCC register name". So in these case, we'll simply emit 
the constraint without setting GCCReg (with the assumption that the respective 
backends deal with it appropriately)

Tests:

- Various tests were updated to account for the new behaviour.
- I added a few SystemZ tests because we work on the Z backend, but I have no 
issues adding testing for multiple targets.
- There were a few mentions of "waiting" for the GCC implementation of the same 
to land before the Clang side lands. As mentioned above, the intent to 
implement it on the GCC side has already been put forward via the RFC. I have 
no issues "parking" this implementation until its ready to be merged in. 
However, it might be good to hash out any open questions/concerns in the 
interim.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D105142

Files:
  clang/lib/CodeGen/CGStmt.cpp
  clang/test/CodeGen/SystemZ/systemz-inline-asm-02.c
  clang/test/CodeGen/SystemZ/systemz-inline-asm.c
  clang/test/CodeGen/aarch64-inline-asm.c
  clang/test/CodeGen/asm-goto.c
  clang/test/CodeGen/ms-intrinsics.c
  clang/test/CodeGen/z-hard-register-inline-asm.c

Index: clang/test/CodeGen/z-hard-register-inline-asm.c
===
--- /dev/null
+++ clang/test/CodeGen/z-hard-register-inline-asm.c
@@ -0,0 +1,48 @@
+// RUN: %clang_cc1 -triple s390x-ibm-linux -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 

[PATCH] D101462: [MC] Untangle MCContext and MCObjectFileInfo

[Anirudh Prasad via Phabricator via cfe-commits]

anirudhp added a comment.

Hi @flip1995
My apologies, but you might have to rebase this on the latest main. I 
introduced a `MCSubtargetInfo` field in https://reviews.llvm.org/D100975. Some 
of the existing changes to the file may not be needed anymore.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101462/new/

https://reviews.llvm.org/D101462

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D99072: [NFC] Formatting changes

[Anirudh Prasad via Phabricator via cfe-commits]

anirudhp accepted this revision.
anirudhp added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D99072/new/

https://reviews.llvm.org/D99072

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D97785: [SystemZ][z/OS] Distinguish between text and binary files on z/OS

[Anirudh Prasad via Phabricator via cfe-commits]

anirudhp added a comment.

LGTM.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D97785/new/

https://reviews.llvm.org/D97785

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D82862: [ThinLTO] Always parse module level inline asm with At dialect

[Anirudh Prasad via Phabricator via cfe-commits]

anirudhp added a comment.

In D82862#2513044 , @rnk wrote:

> In D82862#2512908 , @uweigand wrote:
>
>> So why do you want GNU inline asm for clang-cl anyway?   I thought the whole 
>> point of clang-cl was to be compatible with the Microsoft Visual Studio 
>> compiler, which I understand only supports the MS asm syntax?
>
> We have users, in this case, I think it's V8, who would prefer to use 
> gcc-style module level assembly if it is available. Their motivation is 
> somewhat arbitrary, but generally, clang-cl supports a variety of extensions, 
> some inherited from GCC, in all modes. Part of the point of switching 
> compilers from MSVC to clang is to get access to those extensions.

I might be mistaken here  but couldn't this be done by introducing an option 
and tying it to setting the AssemblerDialect field in the target's respective 
`MCAsmInfo` instance and then querying that? Wouldn't this remove the 
dependency on setting the dialect on the parser. Module level assembly are only 
going to be treated as GNU statements (from Uli's comment above), and if its 
just the case of using a different variant (within the gnu dialect), then this 
can be set in the respective (Target)MCAsmInfo instances appropriately?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82862/new/

https://reviews.llvm.org/D82862

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D85324: [z/OS] Add z/OS Target and define macros

[Anirudh Prasad via Phabricator via cfe-commits]

anirudhp added inline comments.



Comment at: clang/lib/Basic/Targets/OSTargets.h:745
+if (this->PointerWidth == 64) {
+  Builder.defineMacro("__64BIT__");
+}

abhina.sreeskantharajan wrote:
> anirudhp wrote:
> > What about the `__LP64__` and the `_LP64` macros?
> These two are already added in the common code, so it would be redundant to 
> add them again.
Alright Thanks! 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85324/new/

https://reviews.llvm.org/D85324

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D85324: [z/OS] Add z/OS Target and define macros

[Anirudh Prasad via Phabricator via cfe-commits]

anirudhp added inline comments.



Comment at: clang/lib/Basic/Targets/OSTargets.h:745
+if (this->PointerWidth == 64) {
+  Builder.defineMacro("__64BIT__");
+}

What about the `__LP64__` and the `_LP64` macros?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85324/new/

https://reviews.llvm.org/D85324

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits