[PATCH] D38656: [CGExprScalar] In EmitCompare trunc the result if it has different type as E->getType()

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

I assume this also fixes https://bugs.llvm.org/show_bug.cgi?id=31161?


https://reviews.llvm.org/D38656



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

[PATCH] D38656: [CGExprScalar] In EmitCompare trunc the result if it has different type as E->getType()

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

In https://reviews.llvm.org/D38656#892072, @Carrot wrote:

> I worked on a similar bug as 31161, and then found this one, it should be 
> same as in comment7.
>  What is the current status of the work on that bug?


No one has had time to finalize a fix to it. Please go ahead with this patch. 
If this patch indeed fixes the bug, please close it.


https://reviews.llvm.org/D38656



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

[PATCH] D38820: [CGExprScalar] Add missing types in function GetIntrinsic

[Nemanja Ivanovic via Phabricator via cfe-commits]

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

LGTM.


https://reviews.llvm.org/D38820



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

[PATCH] D52074: [PowerPC] [Clang] Add vector int128 pack/unpack builtins

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

LGTM.


Repository:
  rC Clang

https://reviews.llvm.org/D52074



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

[PATCH] D49424: [PowerPC] Handle __builtin_xxpermdi the same way as GCC does

[Nemanja Ivanovic via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC337449: [PowerPC] Handle __builtin_xxpermdi the same way as 
GCC does (authored by nemanjai, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D49424?vs=155869&id=156251#toc

Repository:
  rC Clang

https://reviews.llvm.org/D49424

Files:
  lib/CodeGen/CGBuiltin.cpp
  test/CodeGen/builtins-ppc-vsx.c


Index: test/CodeGen/builtins-ppc-vsx.c
===
--- test/CodeGen/builtins-ppc-vsx.c
+++ test/CodeGen/builtins-ppc-vsx.c
@@ -1694,43 +1694,43 @@
 
 res_vd = vec_xxpermdi(vd, vd, 0);
 // CHECK: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
-// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
+// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
 
 res_vf = vec_xxpermdi(vf, vf, 1);
 // CHECK: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
-// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
+// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
 
 res_vsll = vec_xxpermdi(vsll, vsll, 2);
 // CHECK: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
-// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
+// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
 
 res_vull = vec_xxpermdi(vull, vull, 3);
 // CHECK: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
-// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
+// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
 
 res_vsi = vec_xxpermdi(vsi, vsi, 0);
 // CHECK: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
-// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
+// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
 
 res_vui = vec_xxpermdi(vui, vui, 1);
 // CHECK: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
-// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
+// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
 
 res_vss = vec_xxpermdi(vss, vss, 2);
 // CHECK: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
-// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
+// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
 
 res_vus = vec_xxpermdi(vus, vus, 3);
 // CHECK: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
-// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
+// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
 
 res_vsc = vec_xxpermdi(vsc, vsc, 0);
 // CHECK: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
-// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
+// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
 
 res_vuc = vec_xxpermdi(vuc, vuc, 1);
 // CHECK: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
-// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
+// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
 
 res_vd = vec_xxsldwi(vd, vd, 0);
 // CHECK: shufflevector <4 x i32> %{{[0-9]+}}, <4 x i32> %{{[0-9]+}}, <4 x 
i32> 
@@ -1786,7 +1786,7 @@
 
 // CHECK-LE:  bitcast <4 x i32> %{{[0-9]+}} to <2 x i64>
 // CHECK-LE-NEXT:  bitcast <4 x i32> %{{[0-9]+}} to <2 x i64>
-// CHECK-LE-NEXT:  shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, 
<2 x i32> 
+// CHECK-LE-NEXT:  shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, 
<2 x i32> 
 // CHECK-LE-NEXT:  bitcast <2 x i64> %{{[0-9]+}} to <4 x i32>
 }
 
Index: lib/CodeGen/CGBuiltin.cpp
===
--- lib/CodeGen/CGBuiltin.cpp
+++ lib/CodeGen/CGBuiltin.cpp
@@ -10831,19 +10831,11 @@
 Ops[0] = Builder.CreateBitCast(Ops[0], llvm::VectorType::get(Int64Ty, 2));
 Ops[1] = Builder.CreateBitCast(Ops[1], llvm::VectorType::get(Int64Ty, 2));
 
-// Element zero comes from the first input vector and element one comes 
from
-// the second. The element indices within each vector are numbered in big
-// endian order so the shuffle mask must be adjusted for this on little
-// endian platforms (i.e. index is complemented and source vector 
reversed).
-unsigned ElemIdx0;
-unsigned ElemIdx1;
-if (getTarget().isLittleEndian()) {
-  ElemIdx0 = (~Index & 1) + 2;
-  ElemIdx1 = (~Index & 2) >> 1;
-} else { // BigEndian
-  ElemIdx0 = (Index & 2) >> 1;
-  ElemIdx1 = 2

[PATCH] D33820: [PowerPC] Pass CPU to assembler with -no-integrated-as

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai created this revision.

This just adds the CPU to a list of commands passed to GAS when not using the 
integrated assembler.


Repository:
  rL LLVM

https://reviews.llvm.org/D33820

Files:
  lib/Driver/ToolChains/Arch/PPC.cpp
  lib/Driver/ToolChains/Arch/PPC.h
  lib/Driver/ToolChains/Gnu.cpp


Index: lib/Driver/ToolChains/Gnu.cpp
===
--- lib/Driver/ToolChains/Gnu.cpp
+++ lib/Driver/ToolChains/Gnu.cpp
@@ -11,6 +11,7 @@
 #include "Linux.h"
 #include "Arch/ARM.h"
 #include "Arch/Mips.h"
+#include "Arch/PPC.h"
 #include "Arch/Sparc.h"
 #include "Arch/SystemZ.h"
 #include "CommonArgs.h"
@@ -674,22 +675,28 @@
 else
   CmdArgs.push_back("--64");
 break;
-  case llvm::Triple::ppc:
+  case llvm::Triple::ppc: {
 CmdArgs.push_back("-a32");
 CmdArgs.push_back("-mppc");
-CmdArgs.push_back("-many");
+std::string CPU = getCPUName(Args, getToolChain().getTriple());
+CmdArgs.push_back(ppc::getPPCAsmModeForCPU(CPU));
 break;
-  case llvm::Triple::ppc64:
+  }
+  case llvm::Triple::ppc64: {
 CmdArgs.push_back("-a64");
 CmdArgs.push_back("-mppc64");
-CmdArgs.push_back("-many");
+std::string CPU = getCPUName(Args, getToolChain().getTriple());
+CmdArgs.push_back(ppc::getPPCAsmModeForCPU(CPU));
 break;
-  case llvm::Triple::ppc64le:
+  }
+  case llvm::Triple::ppc64le: {
 CmdArgs.push_back("-a64");
 CmdArgs.push_back("-mppc64");
-CmdArgs.push_back("-many");
 CmdArgs.push_back("-mlittle-endian");
+std::string CPU = getCPUName(Args, getToolChain().getTriple());
+CmdArgs.push_back(ppc::getPPCAsmModeForCPU(CPU));
 break;
+  }
   case llvm::Triple::sparc:
   case llvm::Triple::sparcel: {
 CmdArgs.push_back("-32");
Index: lib/Driver/ToolChains/Arch/PPC.h
===
--- lib/Driver/ToolChains/Arch/PPC.h
+++ lib/Driver/ToolChains/Arch/PPC.h
@@ -32,6 +32,7 @@
 FloatABI getPPCFloatABI(const Driver &D, const llvm::opt::ArgList &Args);
 
 std::string getPPCTargetCPU(const llvm::opt::ArgList &Args);
+const char *getPPCAsmModeForCPU(StringRef Name);
 
 void getPPCTargetFeatures(const Driver &D, const llvm::Triple &Triple,
   const llvm::opt::ArgList &Args,
Index: lib/Driver/ToolChains/Arch/PPC.cpp
===
--- lib/Driver/ToolChains/Arch/PPC.cpp
+++ lib/Driver/ToolChains/Arch/PPC.cpp
@@ -86,6 +86,18 @@
   return "";
 }
 
+const char *ppc::getPPCAsmModeForCPU(StringRef Name) {
+  return llvm::StringSwitch(Name)
+.Case("pwr7", "-mpower7")
+.Case("power7", "-mpower7")
+.Case("pwr8", "-mpower8")
+.Case("power8", "-mpower8")
+.Case("ppc64le", "-mpower8")
+.Case("pwr9", "-mpower9")
+.Case("power9", "-mpower9")
+.Default("-many");
+}
+
 void ppc::getPPCTargetFeatures(const Driver &D, const llvm::Triple &Triple,
const ArgList &Args,
std::vector &Features) {


Index: lib/Driver/ToolChains/Gnu.cpp
===
--- lib/Driver/ToolChains/Gnu.cpp
+++ lib/Driver/ToolChains/Gnu.cpp
@@ -11,6 +11,7 @@
 #include "Linux.h"
 #include "Arch/ARM.h"
 #include "Arch/Mips.h"
+#include "Arch/PPC.h"
 #include "Arch/Sparc.h"
 #include "Arch/SystemZ.h"
 #include "CommonArgs.h"
@@ -674,22 +675,28 @@
 else
   CmdArgs.push_back("--64");
 break;
-  case llvm::Triple::ppc:
+  case llvm::Triple::ppc: {
 CmdArgs.push_back("-a32");
 CmdArgs.push_back("-mppc");
-CmdArgs.push_back("-many");
+std::string CPU = getCPUName(Args, getToolChain().getTriple());
+CmdArgs.push_back(ppc::getPPCAsmModeForCPU(CPU));
 break;
-  case llvm::Triple::ppc64:
+  }
+  case llvm::Triple::ppc64: {
 CmdArgs.push_back("-a64");
 CmdArgs.push_back("-mppc64");
-CmdArgs.push_back("-many");
+std::string CPU = getCPUName(Args, getToolChain().getTriple());
+CmdArgs.push_back(ppc::getPPCAsmModeForCPU(CPU));
 break;
-  case llvm::Triple::ppc64le:
+  }
+  case llvm::Triple::ppc64le: {
 CmdArgs.push_back("-a64");
 CmdArgs.push_back("-mppc64");
-CmdArgs.push_back("-many");
 CmdArgs.push_back("-mlittle-endian");
+std::string CPU = getCPUName(Args, getToolChain().getTriple());
+CmdArgs.push_back(ppc::getPPCAsmModeForCPU(CPU));
 break;
+  }
   case llvm::Triple::sparc:
   case llvm::Triple::sparcel: {
 CmdArgs.push_back("-32");
Index: lib/Driver/ToolChains/Arch/PPC.h
===
--- lib/Driver/ToolChains/Arch/PPC.h
+++ lib/Driver/ToolChains/Arch/PPC.h
@@ -32,6 +32,7 @@
 FloatABI getPPCFloatABI(const Driver &D, const llvm::opt::ArgList &Args);
 
 std::string getPPCTargetCPU(const llvm::opt::ArgList &Args);
+const char *getPPCAsmModeForCPU(StringRef Name);
 
 void getPPCTargetFeatures(const Driver &D

[PATCH] D33820: [PowerPC] Pass CPU to assembler with -no-integrated-as

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai updated this revision to Diff 101169.
nemanjai added a comment.

Initially, forgot to add a test case.


Repository:
  rL LLVM

https://reviews.llvm.org/D33820

Files:
  lib/Driver/ToolChains/Arch/PPC.cpp
  lib/Driver/ToolChains/Arch/PPC.h
  lib/Driver/ToolChains/Gnu.cpp
  test/Driver/linux-as.c

Index: test/Driver/linux-as.c
===
--- test/Driver/linux-as.c
+++ test/Driver/linux-as.c
@@ -174,3 +174,18 @@
 // RUN:   -no-integrated-as -c %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHECK-Z-ARCH-Z196 %s
 // CHECK-Z-ARCH-Z196: as{{.*}} "-march=z196"
+//
+// RUN: %clang -target powerpc64le-linux -### \
+// RUN:   -no-integrated-as -c %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHECK-PPC64LE %s
+// CHECK-PPC64LE: as{{.*}} "-mpower8"
+//
+// RUN: %clang -target powerpc64-linux -mcpu=pwr7 -### \
+// RUN:   -no-integrated-as -c %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHECK-PPC64 %s
+// CHECK-PPC64: as{{.*}} "-mpower7"
+//
+// RUN: %clang -target powerpc-linux -mcpu=pwr9 -### \
+// RUN:   -no-integrated-as -c %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHECK-PPC32 %s
+// CHECK-PPC32: as{{.*}} "-mpower9"
Index: lib/Driver/ToolChains/Gnu.cpp
===
--- lib/Driver/ToolChains/Gnu.cpp
+++ lib/Driver/ToolChains/Gnu.cpp
@@ -11,6 +11,7 @@
 #include "Linux.h"
 #include "Arch/ARM.h"
 #include "Arch/Mips.h"
+#include "Arch/PPC.h"
 #include "Arch/Sparc.h"
 #include "Arch/SystemZ.h"
 #include "CommonArgs.h"
@@ -674,22 +675,28 @@
 else
   CmdArgs.push_back("--64");
 break;
-  case llvm::Triple::ppc:
+  case llvm::Triple::ppc: {
 CmdArgs.push_back("-a32");
 CmdArgs.push_back("-mppc");
-CmdArgs.push_back("-many");
+std::string CPU = getCPUName(Args, getToolChain().getTriple());
+CmdArgs.push_back(ppc::getPPCAsmModeForCPU(CPU));
 break;
-  case llvm::Triple::ppc64:
+  }
+  case llvm::Triple::ppc64: {
 CmdArgs.push_back("-a64");
 CmdArgs.push_back("-mppc64");
-CmdArgs.push_back("-many");
+std::string CPU = getCPUName(Args, getToolChain().getTriple());
+CmdArgs.push_back(ppc::getPPCAsmModeForCPU(CPU));
 break;
-  case llvm::Triple::ppc64le:
+  }
+  case llvm::Triple::ppc64le: {
 CmdArgs.push_back("-a64");
 CmdArgs.push_back("-mppc64");
-CmdArgs.push_back("-many");
 CmdArgs.push_back("-mlittle-endian");
+std::string CPU = getCPUName(Args, getToolChain().getTriple());
+CmdArgs.push_back(ppc::getPPCAsmModeForCPU(CPU));
 break;
+  }
   case llvm::Triple::sparc:
   case llvm::Triple::sparcel: {
 CmdArgs.push_back("-32");
Index: lib/Driver/ToolChains/Arch/PPC.h
===
--- lib/Driver/ToolChains/Arch/PPC.h
+++ lib/Driver/ToolChains/Arch/PPC.h
@@ -32,6 +32,7 @@
 FloatABI getPPCFloatABI(const Driver &D, const llvm::opt::ArgList &Args);
 
 std::string getPPCTargetCPU(const llvm::opt::ArgList &Args);
+const char *getPPCAsmModeForCPU(StringRef Name);
 
 void getPPCTargetFeatures(const Driver &D, const llvm::Triple &Triple,
   const llvm::opt::ArgList &Args,
Index: lib/Driver/ToolChains/Arch/PPC.cpp
===
--- lib/Driver/ToolChains/Arch/PPC.cpp
+++ lib/Driver/ToolChains/Arch/PPC.cpp
@@ -86,6 +86,18 @@
   return "";
 }
 
+const char *ppc::getPPCAsmModeForCPU(StringRef Name) {
+  return llvm::StringSwitch(Name)
+.Case("pwr7", "-mpower7")
+.Case("power7", "-mpower7")
+.Case("pwr8", "-mpower8")
+.Case("power8", "-mpower8")
+.Case("ppc64le", "-mpower8")
+.Case("pwr9", "-mpower9")
+.Case("power9", "-mpower9")
+.Default("-many");
+}
+
 void ppc::getPPCTargetFeatures(const Driver &D, const llvm::Triple &Triple,
const ArgList &Args,
std::vector &Features) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D33820: [PowerPC] Pass CPU to assembler with -no-integrated-as

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai updated this revision to Diff 101508.
nemanjai added a comment.

Remove the temporary string variable for the CPU.


Repository:
  rL LLVM

https://reviews.llvm.org/D33820

Files:
  lib/Driver/ToolChains/Arch/PPC.cpp
  lib/Driver/ToolChains/Arch/PPC.h
  lib/Driver/ToolChains/Gnu.cpp
  test/Driver/linux-as.c
  test/Driver/ppc-features.cpp

Index: test/Driver/ppc-features.cpp
===
--- test/Driver/ppc-features.cpp
+++ test/Driver/ppc-features.cpp
@@ -171,8 +171,8 @@
 
 // RUN: %clang -target powerpc64le-unknown-linux-gnu %s -### -o %t.o -no-integrated-as 2>&1 | FileCheck -check-prefix=CHECK_LE_AS_ARGS %s
 // CHECK_LE_AS_ARGS: "-mppc64"
-// CHECK_LE_AS_ARGS: "-many"
 // CHECK_LE_AS_ARGS: "-mlittle-endian"
+// CHECK_LE_AS_ARGS: "-mpower8"
 
 // linker features
 // RUN: %clang -target powerpc64-unknown-linux-gnu %s -### -o %t.o 2>&1 | FileCheck -check-prefix=CHECK_BE_LD_ARGS %s
Index: test/Driver/linux-as.c
===
--- test/Driver/linux-as.c
+++ test/Driver/linux-as.c
@@ -174,3 +174,18 @@
 // RUN:   -no-integrated-as -c %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHECK-Z-ARCH-Z196 %s
 // CHECK-Z-ARCH-Z196: as{{.*}} "-march=z196"
+//
+// RUN: %clang -target powerpc64le-linux -### \
+// RUN:   -no-integrated-as -c %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHECK-PPC64LE %s
+// CHECK-PPC64LE: as{{.*}} "-mpower8"
+//
+// RUN: %clang -target powerpc64-linux -mcpu=pwr7 -### \
+// RUN:   -no-integrated-as -c %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHECK-PPC64 %s
+// CHECK-PPC64: as{{.*}} "-mpower7"
+//
+// RUN: %clang -target powerpc-linux -mcpu=pwr9 -### \
+// RUN:   -no-integrated-as -c %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHECK-PPC32 %s
+// CHECK-PPC32: as{{.*}} "-mpower9"
Index: lib/Driver/ToolChains/Gnu.cpp
===
--- lib/Driver/ToolChains/Gnu.cpp
+++ lib/Driver/ToolChains/Gnu.cpp
@@ -11,6 +11,7 @@
 #include "Linux.h"
 #include "Arch/ARM.h"
 #include "Arch/Mips.h"
+#include "Arch/PPC.h"
 #include "Arch/Sparc.h"
 #include "Arch/SystemZ.h"
 #include "CommonArgs.h"
@@ -674,22 +675,28 @@
 else
   CmdArgs.push_back("--64");
 break;
-  case llvm::Triple::ppc:
+  case llvm::Triple::ppc: {
 CmdArgs.push_back("-a32");
 CmdArgs.push_back("-mppc");
-CmdArgs.push_back("-many");
+CmdArgs.push_back(
+  ppc::getPPCAsmModeForCPU(getCPUName(Args, getToolChain().getTriple(;
 break;
-  case llvm::Triple::ppc64:
+  }
+  case llvm::Triple::ppc64: {
 CmdArgs.push_back("-a64");
 CmdArgs.push_back("-mppc64");
-CmdArgs.push_back("-many");
+CmdArgs.push_back(
+  ppc::getPPCAsmModeForCPU(getCPUName(Args, getToolChain().getTriple(;
 break;
-  case llvm::Triple::ppc64le:
+  }
+  case llvm::Triple::ppc64le: {
 CmdArgs.push_back("-a64");
 CmdArgs.push_back("-mppc64");
-CmdArgs.push_back("-many");
 CmdArgs.push_back("-mlittle-endian");
+CmdArgs.push_back(
+  ppc::getPPCAsmModeForCPU(getCPUName(Args, getToolChain().getTriple(;
 break;
+  }
   case llvm::Triple::sparc:
   case llvm::Triple::sparcel: {
 CmdArgs.push_back("-32");
Index: lib/Driver/ToolChains/Arch/PPC.h
===
--- lib/Driver/ToolChains/Arch/PPC.h
+++ lib/Driver/ToolChains/Arch/PPC.h
@@ -32,6 +32,7 @@
 FloatABI getPPCFloatABI(const Driver &D, const llvm::opt::ArgList &Args);
 
 std::string getPPCTargetCPU(const llvm::opt::ArgList &Args);
+const char *getPPCAsmModeForCPU(StringRef Name);
 
 void getPPCTargetFeatures(const Driver &D, const llvm::Triple &Triple,
   const llvm::opt::ArgList &Args,
Index: lib/Driver/ToolChains/Arch/PPC.cpp
===
--- lib/Driver/ToolChains/Arch/PPC.cpp
+++ lib/Driver/ToolChains/Arch/PPC.cpp
@@ -86,6 +86,18 @@
   return "";
 }
 
+const char *ppc::getPPCAsmModeForCPU(StringRef Name) {
+  return llvm::StringSwitch(Name)
+.Case("pwr7", "-mpower7")
+.Case("power7", "-mpower7")
+.Case("pwr8", "-mpower8")
+.Case("power8", "-mpower8")
+.Case("ppc64le", "-mpower8")
+.Case("pwr9", "-mpower9")
+.Case("power9", "-mpower9")
+.Default("-many");
+}
+
 void ppc::getPPCTargetFeatures(const Driver &D, const llvm::Triple &Triple,
const ArgList &Args,
std::vector &Features) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D33981: Only print registered targets for `--version`

[Nemanja Ivanovic via Phabricator via cfe-commits]

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

LGTM. This cleans up the failures on PPC (and probably SystemZ) so the bots 
should go back to green.


https://reviews.llvm.org/D33981



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

[PATCH] D33499: [PPC] PPC32/Darwin ABI info

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added subscribers: iains, echristo.
nemanjai added a comment.

I'm not sure how much expertise there is for PPC32-Darwin. Perhaps @iains might 
be able to offer some insight here. Also, @echristo might have a thing or two 
to say in this regard.


Repository:
  rL LLVM

https://reviews.llvm.org/D33499



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

[PATCH] D54087: [PowerPC] [Clang] [AltiVec] The second parameter of vec_sr function should be modulo the number of bits in the element

[Nemanja Ivanovic via Phabricator via cfe-commits]

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

Just for clarification (and please add the text to the commit message), this is 
actually required by the ABI:

  Each element of the result vector is the result of logically right shifting 
the corresponding
  element of ARG1 by the number of bits specified by the value of the 
corresponding
  element of ARG2, modulo the number of bits in the element. The bits that are 
shifted out
  are replaced by zeros.


Repository:
  rC Clang

https://reviews.llvm.org/D54087



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

[PATCH] D53417: [Clang][Sema][PowerPC] Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

@hubert.reinterpretcast Have your comments been addressed adequately in the 
latest version of the patch? Do you have an opinion on adding the test case I 
proposed?




Comment at: clang/test/Sema/altivec-generic-overload.c:1
+// RUN: %clang_cc1 %s -triple=powerpc64le-unknown-linux -target-feature 
+altivec -target-feature +vsx -verify -verify-ignore-unexpected=note -pedantic 
-fsyntax-only
+

Do we perhaps want a test case that actually tests which overload was chosen to 
make sure this doesn't change with any potential future changes to overload 
resolution?


https://reviews.llvm.org/D53417



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

[PATCH] D54787: [PowerPC] Vector load/store builtins overstate alignment of pointers

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai created this revision.
nemanjai added reviewers: hfinkel, jsji, wuzish.
Herald added subscribers: kristina, kbarton.

A number of builtins in altivec.h load/store vectors from pointers to scalar 
types. Currently they just cast the pointer to a vector pointer, but 
expressions like that have the alignment of the target type. Of course, the 
input pointer did not have that alignment so this triggers UBSan (and rightly 
so).

This resolves https://bugs.llvm.org/show_bug.cgi?id=39704


Repository:
  rC Clang

https://reviews.llvm.org/D54787

Files:
  lib/Headers/altivec.h
  test/CodeGen/builtins-ppc-altivec.c
  test/CodeGen/builtins-ppc-vsx.c

Index: test/CodeGen/builtins-ppc-vsx.c
===
--- test/CodeGen/builtins-ppc-vsx.c
+++ test/CodeGen/builtins-ppc-vsx.c
@@ -1638,51 +1638,51 @@
 // CHECK-LE: @llvm.ppc.altivec.vsro
 
 res_vsll = vec_xl(sll, asll);
-// CHECK: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 16
-// CHECK-LE: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 16
+// CHECK: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 1
+// CHECK-LE: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 1
 
 res_vull = vec_xl(sll, aull);
-// CHECK: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 16
-// CHECK-LE: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 16
+// CHECK: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 1
+// CHECK-LE: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 1
 
 res_vd = vec_xl(sll, ad);
-// CHECK: load <2 x double>, <2 x double>* %{{[0-9]+}}, align 16
-// CHECK-LE: load <2 x double>, <2 x double>* %{{[0-9]+}}, align 16
+// CHECK: load <2 x double>, <2 x double>* %{{[0-9]+}}, align 1
+// CHECK-LE: load <2 x double>, <2 x double>* %{{[0-9]+}}, align 1
 
 vec_xst(vsll, sll, asll);
-// CHECK: store <2 x i64> %{{[0-9]+}}, <2 x i64>* %{{[0-9]+}}, align 16
-// CHECK-LE: store <2 x i64> %{{[0-9]+}}, <2 x i64>* %{{[0-9]+}}, align 16
+// CHECK: store <2 x i64> %{{[0-9]+}}, <2 x i64>* %{{[0-9]+}}, align 1
+// CHECK-LE: store <2 x i64> %{{[0-9]+}}, <2 x i64>* %{{[0-9]+}}, align 1
 
 vec_xst(vull, sll, aull);
-// CHECK: store <2 x i64> %{{[0-9]+}}, <2 x i64>* %{{[0-9]+}}, align 16
-// CHECK-LE: store <2 x i64> %{{[0-9]+}}, <2 x i64>* %{{[0-9]+}}, align 16
+// CHECK: store <2 x i64> %{{[0-9]+}}, <2 x i64>* %{{[0-9]+}}, align 1
+// CHECK-LE: store <2 x i64> %{{[0-9]+}}, <2 x i64>* %{{[0-9]+}}, align 1
 
 vec_xst(vd, sll, ad);
-// CHECK: store <2 x double> %{{[0-9]+}}, <2 x double>* %{{[0-9]+}}, align 16
-// CHECK-LE: store <2 x double> %{{[0-9]+}}, <2 x double>* %{{[0-9]+}}, align 16
+// CHECK: store <2 x double> %{{[0-9]+}}, <2 x double>* %{{[0-9]+}}, align 1
+// CHECK-LE: store <2 x double> %{{[0-9]+}}, <2 x double>* %{{[0-9]+}}, align 1
 
 res_vsll = vec_xl_be(sll, asll);
-// CHECK: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 16
+// CHECK: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 1
 // CHECK-LE: call <2 x double> @llvm.ppc.vsx.lxvd2x.be(i8* %{{[0-9]+}})
 
 res_vull = vec_xl_be(sll, aull);
-// CHECK: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 16
+// CHECK: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 1
 // CHECK-LE: call <2 x double> @llvm.ppc.vsx.lxvd2x.be(i8* %{{[0-9]+}})
 
 res_vd = vec_xl_be(sll, ad);
-// CHECK: load <2 x double>, <2 x double>* %{{[0-9]+}}, align 16
+// CHECK: load <2 x double>, <2 x double>* %{{[0-9]+}}, align 1
 // CHECK-LE: call <2 x double> @llvm.ppc.vsx.lxvd2x.be(i8* %{{[0-9]+}})
 
 vec_xst_be(vsll, sll, asll);
-// CHECK: store <2 x i64> %{{[0-9]+}}, <2 x i64>* %{{[0-9]+}}, align 16
+// CHECK: store <2 x i64> %{{[0-9]+}}, <2 x i64>* %{{[0-9]+}}, align 1
 // CHECK-LE: call void @llvm.ppc.vsx.stxvd2x.be(<2 x double> %{{[0-9]+}}, i8* %{{[0-9]+}})
 
 vec_xst_be(vull, sll, aull);
-// CHECK: store <2 x i64> %{{[0-9]+}}, <2 x i64>* %{{[0-9]+}}, align 16
+// CHECK: store <2 x i64> %{{[0-9]+}}, <2 x i64>* %{{[0-9]+}}, align 1
 // CHECK-LE: call void @llvm.ppc.vsx.stxvd2x.be(<2 x double> %{{[0-9]+}}, i8* %{{[0-9]+}})
 
 vec_xst_be(vd, sll, ad);
-// CHECK: store <2 x double> %{{[0-9]+}}, <2 x double>* %{{[0-9]+}}, align 16
+// CHECK: store <2 x double> %{{[0-9]+}}, <2 x double>* %{{[0-9]+}}, align 1
 // CHECK-LE: call void @llvm.ppc.vsx.stxvd2x.be(<2 x double> %{{[0-9]+}}, i8* %{{[0-9]+}})
 
   res_vf = vec_neg(vf);
Index: test/CodeGen/builtins-ppc-altivec.c
===
--- test/CodeGen/builtins-ppc-altivec.c
+++ test/CodeGen/builtins-ppc-altivec.c
@@ -9362,137 +9362,137 @@
   // CHECK-LABEL: define void @test9
   // CHECK-LE-LABEL: define void @test9
   res_vsc = vec_xl(param_sll, ¶m_sc);
-  // CHECK: load <16 x i8>, <16 x i8>* %{{[0-9]+}}, align 16
-  // CHECK-LE: load <16 x i8>, <16 x i8>* %{{[0-9]+}}, align 16
+  // CHECK: load <16 x i8>, <16 x i8>* %{{[0-9]+}}, align 1
+  // CHECK-LE: load <16 x i8>, <16 x i8>* %{{[0-9]+}}, align 1
 
   res_vuc = vec_xl(param_sll, ¶m_uc);
-  // CHECK: load <16 x i8>, <16 x i8>* %{{[0-9]+}}, align 16
-  // CHECK-LE: load <16 x i8>,

[PATCH] D54787: [PowerPC] Vector load/store builtins overstate alignment of pointers

[Nemanja Ivanovic via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL347556: [PowerPC] Vector load/store builtins overstate 
alignment of pointers (authored by nemanjai, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D54787?vs=174899&id=175243#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D54787

Files:
  cfe/trunk/lib/Headers/altivec.h
  cfe/trunk/test/CodeGen/builtins-ppc-altivec.c
  cfe/trunk/test/CodeGen/builtins-ppc-quadword.c
  cfe/trunk/test/CodeGen/builtins-ppc-vsx.c

Index: cfe/trunk/test/CodeGen/builtins-ppc-quadword.c
===
--- cfe/trunk/test/CodeGen/builtins-ppc-quadword.c
+++ cfe/trunk/test/CodeGen/builtins-ppc-quadword.c
@@ -205,45 +205,45 @@
 
   /* vec_xl */
   res_vlll = vec_xl(param_sll, ¶m_lll);
-  // CHECK: load <1 x i128>, <1 x i128>* %{{[0-9]+}}, align 16
-  // CHECK-LE: load <1 x i128>, <1 x i128>* %{{[0-9]+}}, align 16
+  // CHECK: load <1 x i128>, <1 x i128>* %{{[0-9]+}}, align 1
+  // CHECK-LE: load <1 x i128>, <1 x i128>* %{{[0-9]+}}, align 1
   // CHECK-PPC: error: call to 'vec_xl' is ambiguous
 
   res_vulll = vec_xl(param_sll, ¶m_ulll);
-  // CHECK: load <1 x i128>, <1 x i128>* %{{[0-9]+}}, align 16
-  // CHECK-LE: load <1 x i128>, <1 x i128>* %{{[0-9]+}}, align 16
+  // CHECK: load <1 x i128>, <1 x i128>* %{{[0-9]+}}, align 1
+  // CHECK-LE: load <1 x i128>, <1 x i128>* %{{[0-9]+}}, align 1
   // CHECK-PPC: error: call to 'vec_xl' is ambiguous
 
   /* vec_xst */
vec_xst(vlll, param_sll, ¶m_lll);
-  // CHECK: store <1 x i128> %{{[0-9]+}}, <1 x i128>* %{{[0-9]+}}, align 16
-  // CHECK-LE: store <1 x i128> %{{[0-9]+}}, <1 x i128>* %{{[0-9]+}}, align 16
+  // CHECK: store <1 x i128> %{{[0-9]+}}, <1 x i128>* %{{[0-9]+}}, align 1
+  // CHECK-LE: store <1 x i128> %{{[0-9]+}}, <1 x i128>* %{{[0-9]+}}, align 1
   // CHECK-PPC: error: call to 'vec_xst' is ambiguous
 
vec_xst(vulll, param_sll, ¶m_ulll);
-  // CHECK: store <1 x i128> %{{[0-9]+}}, <1 x i128>* %{{[0-9]+}}, align 16
-  // CHECK-LE: store <1 x i128> %{{[0-9]+}}, <1 x i128>* %{{[0-9]+}}, align 16
+  // CHECK: store <1 x i128> %{{[0-9]+}}, <1 x i128>* %{{[0-9]+}}, align 1
+  // CHECK-LE: store <1 x i128> %{{[0-9]+}}, <1 x i128>* %{{[0-9]+}}, align 1
   // CHECK-PPC: error: call to 'vec_xst' is ambiguous
 
   /* vec_xl_be */
   res_vlll = vec_xl_be(param_sll, ¶m_lll);
-  // CHECK: load <1 x i128>, <1 x i128>* %{{[0-9]+}}, align 16
-  // CHECK-LE: load <1 x i128>, <1 x i128>* %{{[0-9]+}}, align 16
+  // CHECK: load <1 x i128>, <1 x i128>* %{{[0-9]+}}, align 1
+  // CHECK-LE: load <1 x i128>, <1 x i128>* %{{[0-9]+}}, align 1
   // CHECK-PPC: error: call to 'vec_xl' is ambiguous
 
   res_vulll = vec_xl_be(param_sll, ¶m_ulll);
-  // CHECK: load <1 x i128>, <1 x i128>* %{{[0-9]+}}, align 16
-  // CHECK-LE: load <1 x i128>, <1 x i128>* %{{[0-9]+}}, align 16
+  // CHECK: load <1 x i128>, <1 x i128>* %{{[0-9]+}}, align 1
+  // CHECK-LE: load <1 x i128>, <1 x i128>* %{{[0-9]+}}, align 1
   // CHECK-PPC: error: call to 'vec_xl' is ambiguous
 
   /* vec_xst_be  */
vec_xst_be(vlll, param_sll, ¶m_lll);
-  // CHECK: store <1 x i128> %{{[0-9]+}}, <1 x i128>* %{{[0-9]+}}, align 16
-  // CHECK-LE: store <1 x i128> %{{[0-9]+}}, <1 x i128>* %{{[0-9]+}}, align 16
+  // CHECK: store <1 x i128> %{{[0-9]+}}, <1 x i128>* %{{[0-9]+}}, align 1
+  // CHECK-LE: store <1 x i128> %{{[0-9]+}}, <1 x i128>* %{{[0-9]+}}, align 1
   // CHECK-PPC: error: call to 'vec_xst' is ambiguous
 
vec_xst_be(vulll, param_sll, ¶m_ulll);
-  // CHECK: store <1 x i128> %{{[0-9]+}}, <1 x i128>* %{{[0-9]+}}, align 16
-  // CHECK-LE: store <1 x i128> %{{[0-9]+}}, <1 x i128>* %{{[0-9]+}}, align 16
+  // CHECK: store <1 x i128> %{{[0-9]+}}, <1 x i128>* %{{[0-9]+}}, align 1
+  // CHECK-LE: store <1 x i128> %{{[0-9]+}}, <1 x i128>* %{{[0-9]+}}, align 1
   // CHECK-PPC: error: call to 'vec_xst' is ambiguous
 }
Index: cfe/trunk/test/CodeGen/builtins-ppc-vsx.c
===
--- cfe/trunk/test/CodeGen/builtins-ppc-vsx.c
+++ cfe/trunk/test/CodeGen/builtins-ppc-vsx.c
@@ -1638,51 +1638,51 @@
 // CHECK-LE: @llvm.ppc.altivec.vsro
 
 res_vsll = vec_xl(sll, asll);
-// CHECK: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 16
-// CHECK-LE: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 16
+// CHECK: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 1
+// CHECK-LE: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 1
 
 res_vull = vec_xl(sll, aull);
-// CHECK: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 16
-// CHECK-LE: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 16
+// CHECK: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 1
+// CHECK-LE: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 1
 
 res_vd = vec_xl(sll, ad);
-// CHECK: load <2 x double>, <2 x double>* %{{[0-9]+}}, align 16
-// CHECK-LE: load <2 x double>, <2 x dou

[PATCH] D58497: Clear the KnownModules cache if the preprocessor is going away

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

Ping.


Repository:
  rC Clang

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

https://reviews.llvm.org/D58497



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

[PATCH] D59304: Fix invocation of Gold plugin with LTO after r355331

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai created this revision.
nemanjai added reviewers: xur, tejohnson, davidxl.
Herald added subscribers: dexonsmith, steven_wu, inglorion, mehdi_amini.
Herald added a project: clang.

The above commit tries to access the parameter to the `-fprofile-use` option 
without checking whether the option has actually been specified with a 
parameter. When the option was not specified with a parameter, this trips an 
assertion.
All of our builds with PGO/LTO use `-fprofile-use` without a parameter so this 
broke all such internal builds.

To reproduce (the contents of the C++ file don't actually matter as long as it 
can be linked/run):

  $ clang++ -O3 -fprofile-generate pgo-lto.cpp
  $ ./a.out
  $ clang++ -O3 -fprofile-use -flto=thin pgo-lto.cpp
  clang++: /home/nemanjai/llvm/llvm-clean/include/llvm/ADT/SmallVector.h:153: 
const T& llvm::SmallVectorTemplateCommon 
>::operator[](llvm::SmallVectorTemplateCommon 
>::size_type) const [with T = const char*;  = void; 
llvm::SmallVectorTemplateCommon >::const_reference 
= const char* const&; llvm::SmallVectorTemplateCommon >::size_type = long unsigned int]: Assertion `idx < 
size()' failed.

This patch fixes it by handling the option the same way it is handled elsewhere.

The original patch did not include any test cases, so I've added one for the 
problem case. Had the patch been committed with tests, this issue would 
probably not have happened.

I am hoping for a quick review of this so we can commit this and not have to 
change our build tools to specify the `default.profdata` default.


Repository:
  rC Clang

https://reviews.llvm.org/D59304

Files:
  lib/Driver/ToolChains/CommonArgs.cpp
  test/Driver/cspgo-lto.c


Index: test/Driver/cspgo-lto.c
===
--- test/Driver/cspgo-lto.c
+++ test/Driver/cspgo-lto.c
@@ -0,0 +1,6 @@
+// RUN: touch %t.o
+//
+// RUN: %clang -target x86_64-unknown-linux -### %t.o -flto=thin \
+// RUN:   -fprofile-use 2>&1 | FileCheck %s
+
+// CHECK: -plugin-opt=cs-profile-path=default.profdata
Index: lib/Driver/ToolChains/CommonArgs.cpp
===
--- lib/Driver/ToolChains/CommonArgs.cpp
+++ lib/Driver/ToolChains/CommonArgs.cpp
@@ -464,8 +464,12 @@
   CmdArgs.push_back(
   
Args.MakeArgString("-plugin-opt=cs-profile-path=default_%m.profraw"));
   } else if (ProfileUseArg) {
+SmallString<128> Path(
+ProfileUseArg->getNumValues() == 0 ? "" : ProfileUseArg->getValue());
+if (Path.empty() || llvm::sys::fs::is_directory(Path))
+  llvm::sys::path::append(Path, "default.profdata");
 CmdArgs.push_back(Args.MakeArgString(Twine("-plugin-opt=cs-profile-path=") 
+
- ProfileUseArg->getValue()));
+ Path));
   }
 
   // Need this flag to turn on new pass manager via Gold plugin.


Index: test/Driver/cspgo-lto.c
===
--- test/Driver/cspgo-lto.c
+++ test/Driver/cspgo-lto.c
@@ -0,0 +1,6 @@
+// RUN: touch %t.o
+//
+// RUN: %clang -target x86_64-unknown-linux -### %t.o -flto=thin \
+// RUN:   -fprofile-use 2>&1 | FileCheck %s
+
+// CHECK: -plugin-opt=cs-profile-path=default.profdata
Index: lib/Driver/ToolChains/CommonArgs.cpp
===
--- lib/Driver/ToolChains/CommonArgs.cpp
+++ lib/Driver/ToolChains/CommonArgs.cpp
@@ -464,8 +464,12 @@
   CmdArgs.push_back(
   Args.MakeArgString("-plugin-opt=cs-profile-path=default_%m.profraw"));
   } else if (ProfileUseArg) {
+SmallString<128> Path(
+ProfileUseArg->getNumValues() == 0 ? "" : ProfileUseArg->getValue());
+if (Path.empty() || llvm::sys::fs::is_directory(Path))
+  llvm::sys::path::append(Path, "default.profdata");
 CmdArgs.push_back(Args.MakeArgString(Twine("-plugin-opt=cs-profile-path=") +
- ProfileUseArg->getValue()));
+ Path));
   }
 
   // Need this flag to turn on new pass manager via Gold plugin.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59304: Fix invocation of Gold plugin with LTO after r355331

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

Thanks Teresa, I'll commit this soon.


Repository:
  rC Clang

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

https://reviews.llvm.org/D59304



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

[PATCH] D59304: Fix invocation of Gold plugin with LTO after r355331

[Nemanja Ivanovic via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL356111: Fix invocation of Gold plugin with LTO after r355331 
(authored by nemanjai, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D59304?vs=190429&id=190543#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D59304

Files:
  cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
  cfe/trunk/test/Driver/cspgo-lto.c


Index: cfe/trunk/test/Driver/cspgo-lto.c
===
--- cfe/trunk/test/Driver/cspgo-lto.c
+++ cfe/trunk/test/Driver/cspgo-lto.c
@@ -0,0 +1,6 @@
+// RUN: touch %t.o
+//
+// RUN: %clang -target x86_64-unknown-linux -### %t.o -flto=thin \
+// RUN:   -fprofile-use 2>&1 | FileCheck %s
+
+// CHECK: -plugin-opt=cs-profile-path=default.profdata
Index: cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
+++ cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
@@ -464,8 +464,12 @@
   CmdArgs.push_back(
   
Args.MakeArgString("-plugin-opt=cs-profile-path=default_%m.profraw"));
   } else if (ProfileUseArg) {
+SmallString<128> Path(
+ProfileUseArg->getNumValues() == 0 ? "" : ProfileUseArg->getValue());
+if (Path.empty() || llvm::sys::fs::is_directory(Path))
+  llvm::sys::path::append(Path, "default.profdata");
 CmdArgs.push_back(Args.MakeArgString(Twine("-plugin-opt=cs-profile-path=") 
+
- ProfileUseArg->getValue()));
+ Path));
   }
 
   // Need this flag to turn on new pass manager via Gold plugin.


Index: cfe/trunk/test/Driver/cspgo-lto.c
===
--- cfe/trunk/test/Driver/cspgo-lto.c
+++ cfe/trunk/test/Driver/cspgo-lto.c
@@ -0,0 +1,6 @@
+// RUN: touch %t.o
+//
+// RUN: %clang -target x86_64-unknown-linux -### %t.o -flto=thin \
+// RUN:   -fprofile-use 2>&1 | FileCheck %s
+
+// CHECK: -plugin-opt=cs-profile-path=default.profdata
Index: cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
+++ cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
@@ -464,8 +464,12 @@
   CmdArgs.push_back(
   Args.MakeArgString("-plugin-opt=cs-profile-path=default_%m.profraw"));
   } else if (ProfileUseArg) {
+SmallString<128> Path(
+ProfileUseArg->getNumValues() == 0 ? "" : ProfileUseArg->getValue());
+if (Path.empty() || llvm::sys::fs::is_directory(Path))
+  llvm::sys::path::append(Path, "default.profdata");
 CmdArgs.push_back(Args.MakeArgString(Twine("-plugin-opt=cs-profile-path=") +
- ProfileUseArg->getValue()));
+ Path));
   }
 
   // Need this flag to turn on new pass manager via Gold plugin.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D58497: Clear the KnownModules cache if the preprocessor is going away

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

Ping.

If there are no objections in the next week or so, I'll commit this and it can 
be reviewed post-commit.


Repository:
  rC Clang

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

https://reviews.llvm.org/D58497



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

[PATCH] D55326: [Driver] Fix incorrect GNU triplet for PowerPC on SUSE Linux

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.
Herald added a subscriber: jdoerfert.
Herald added a project: clang.

Do you plan to follow-up on these questions and comments?
At least the full context is needed and for the test case, I imagine it can be 
similar to other driver test cases. I imagine 
`tools/clang/test/Driver/linux-ld.c` can be augmented with this?


Repository:
  rC Clang

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

https://reviews.llvm.org/D55326



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

[PATCH] D58497: Clear the KnownModules cache if the preprocessor is going away

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

In D58497#1449306 , @dblaikie wrote:

> In D58497#1449243 , @nemanjai wrote:
>
> > Ping.
>
>
> Unfortunately Richard Smith is out for a few weeks at the moment, so might 
> take a little bit before he can get to this.
>
> It's odd to me that this lacks a test case - but you mention it's shown up on 
> buildbots? Does it reproduce consistently there? Under what conditions (which 
> buildbots/configurations show this - are they permanently failing because of 
> this?)?
>
> A test case, if at all possible, would be super helpful.


The failure this causes always shows up in the `Modules/builtins.m` test (at 
least in my experience). It is far from predictable and it does not 
consistently reproduce on any build bot. It occasionally shows up and slight 
perturbations in the source make it go away.
Honestly, I don't find this to be all that surprising. Using memory after 
freeing it has inherently unpredictable behaviour. There are certain toolchains 
that will diagnose freeing the same memory twice, but that's not the case here 
- we just happen to use it after freeing it.

> 
> 
>> If there are no objections in the next week or so, I'll commit this and it 
>> can be reviewed post-commit.
> 
> That's generally not considered acceptable practice - if something is sent 
> for review it's because it needs review & time doesn't change that. (there 
> are some exceptions to this - some folks send things out for "hey, anyone got 
> other ideas on this, otherwise I think it's fine" sort of thing)

I am really sorry about how this came across. I understand that given the 
context, this could quite reasonably be interpreted as me stating "I don't want 
to wait any longer, so I'm just going to commit this." That was not at all my 
intention. I merely meant to state that I don't believe this to be in any way 
controversial. I have shown quite clearly in my email that `KnownModules` will 
have pointers to data that the `Preprocessor` owns. If the existing 
`Preprocessor` shared pointer is the last reference, it will obviously be 
deleted now that we're reassigning to it. Thereby, we are deleting the 
`Preprocessor` which will delete all the data it owns and we are keeping 
`KnownModules` alive (with cached pointers to data that is being deleted). 
There is no situation I can think of in which it is reasonable to keep pointers 
to deleted data. If I came across an issue of this nature - clearly undefined 
behaviour - in the PPC back end where I spend most of my time, I'd probably not 
post for review as a fix is clearly in order. But since I am not intimately 
familiar with this code, I thought I'd get another opinion on the fix by 
sending an email to the dev list and posting on Phabricator.

All that being said, it sounds like there is an objection to me committing this 
so I certainly won't proceed without an approval on this review. If you or 
anyone else can offer a suggestion on how I might come up with a test case for 
this - or perhaps an alternative fix for this issue, I am more than happy to 
incorporate your suggestions.


Repository:
  rC Clang

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

https://reviews.llvm.org/D58497



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

[PATCH] D60539: Add -std=c++14 language standard option to tests that require C++14 default

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

> Do you need to build clangd? We explicitly don't aim to support building 
> everywhere clang can be built, maybe we should just disable in this case?

Our environment includes various OS levels running on PowerPC. We certainly 
wouldn't want to disable building/testing `clangd` on all our PowerPC machines. 
Is there a way to disable it only on certain OS levels?

Furthermore, it seems a little too intrusive to disable an otherwise functional 
component simply because some test cases rely on a specific language standard 
default.

Would it be an acceptable solution to add another `StringRef` parameter to 
`ShouldCollectSymbolTest::build()` - let's call it `ExtraArgs`, to which we can 
add options such as `-std=c++14` if the test being built relies on that option?


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

https://reviews.llvm.org/D60539



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

[PATCH] D58497: Clear the KnownModules cache if the preprocessor is going away

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.
Herald added a subscriber: jsji.

Ping. Does anyone think this is a good idea? Bad idea? Have any further 
comments?


Repository:
  rC Clang

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

https://reviews.llvm.org/D58497



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

[PATCH] D57577: Make predefined FLT16 macros conditional on support for the type

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai created this revision.
nemanjai added reviewers: rogfer01, bruno, ahatanak, scanon.
Herald added subscribers: aheejin, jgravelle-google, sbc100, dschuff.
Herald added a project: clang.

We unconditionally predefine these macros. However, they may be used to 
determine if the type is supported. In that case, there are unnecessary 
failures to compile the code.
This is the proposed fix for https://bugs.llvm.org/show_bug.cgi?id=40559


Repository:
  rC Clang

https://reviews.llvm.org/D57577

Files:
  lib/Basic/Targets/WebAssembly.h
  lib/Frontend/InitPreprocessor.cpp
  test/Headers/float16.c


Index: test/Headers/float16.c
===
--- test/Headers/float16.c
+++ test/Headers/float16.c
@@ -1,7 +1,11 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c89 -ffreestanding %s
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c99 -ffreestanding %s
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c11 -ffreestanding %s
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 -x c++ -ffreestanding %s
+// RUN: %clang_cc1 -triple=aarch64-none-none -fsyntax-only -verify -std=c89 \
+// RUN:   -ffreestanding %s
+// RUN: %clang_cc1 -triple=wasm64-unknown-unknown -fsyntax-only -verify \
+// RUN:   -std=c99 -ffreestanding %s
+// RUN: %clang_cc1 -triple=aarch64-none-none -fsyntax-only -verify -std=c11 \
+// RUN:   -ffreestanding %s
+// RUN: %clang_cc1 -triple=wasm64-unknown-unknown -fsyntax-only -verify \
+// RUN:   -std=c++11 -x c++ -ffreestanding %s
 // expected-no-diagnostics
 
 #define __STDC_WANT_IEC_60559_TYPES_EXT__
Index: lib/Frontend/InitPreprocessor.cpp
===
--- lib/Frontend/InitPreprocessor.cpp
+++ lib/Frontend/InitPreprocessor.cpp
@@ -830,7 +830,8 @@
   DefineFmt("__UINTPTR", TI.getUIntPtrType(), TI, Builder);
   DefineTypeWidth("__UINTPTR_WIDTH__", TI.getUIntPtrType(), TI, Builder);
 
-  DefineFloatMacros(Builder, "FLT16", &TI.getHalfFormat(), "F16");
+  if (TI.hasFloat16Type())
+DefineFloatMacros(Builder, "FLT16", &TI.getHalfFormat(), "F16");
   DefineFloatMacros(Builder, "FLT", &TI.getFloatFormat(), "F");
   DefineFloatMacros(Builder, "DBL", &TI.getDoubleFormat(), "");
   DefineFloatMacros(Builder, "LDBL", &TI.getLongDoubleFormat(), "L");
Index: lib/Basic/Targets/WebAssembly.h
===
--- lib/Basic/Targets/WebAssembly.h
+++ lib/Basic/Targets/WebAssembly.h
@@ -52,6 +52,7 @@
 SizeType = UnsignedLong;
 PtrDiffType = SignedLong;
 IntPtrType = SignedLong;
+HasFloat16 = true;
   }
 
 protected:


Index: test/Headers/float16.c
===
--- test/Headers/float16.c
+++ test/Headers/float16.c
@@ -1,7 +1,11 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c89 -ffreestanding %s
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c99 -ffreestanding %s
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c11 -ffreestanding %s
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 -x c++ -ffreestanding %s
+// RUN: %clang_cc1 -triple=aarch64-none-none -fsyntax-only -verify -std=c89 \
+// RUN:   -ffreestanding %s
+// RUN: %clang_cc1 -triple=wasm64-unknown-unknown -fsyntax-only -verify \
+// RUN:   -std=c99 -ffreestanding %s
+// RUN: %clang_cc1 -triple=aarch64-none-none -fsyntax-only -verify -std=c11 \
+// RUN:   -ffreestanding %s
+// RUN: %clang_cc1 -triple=wasm64-unknown-unknown -fsyntax-only -verify \
+// RUN:   -std=c++11 -x c++ -ffreestanding %s
 // expected-no-diagnostics
 
 #define __STDC_WANT_IEC_60559_TYPES_EXT__
Index: lib/Frontend/InitPreprocessor.cpp
===
--- lib/Frontend/InitPreprocessor.cpp
+++ lib/Frontend/InitPreprocessor.cpp
@@ -830,7 +830,8 @@
   DefineFmt("__UINTPTR", TI.getUIntPtrType(), TI, Builder);
   DefineTypeWidth("__UINTPTR_WIDTH__", TI.getUIntPtrType(), TI, Builder);
 
-  DefineFloatMacros(Builder, "FLT16", &TI.getHalfFormat(), "F16");
+  if (TI.hasFloat16Type())
+DefineFloatMacros(Builder, "FLT16", &TI.getHalfFormat(), "F16");
   DefineFloatMacros(Builder, "FLT", &TI.getFloatFormat(), "F");
   DefineFloatMacros(Builder, "DBL", &TI.getDoubleFormat(), "");
   DefineFloatMacros(Builder, "LDBL", &TI.getLongDoubleFormat(), "L");
Index: lib/Basic/Targets/WebAssembly.h
===
--- lib/Basic/Targets/WebAssembly.h
+++ lib/Basic/Targets/WebAssembly.h
@@ -52,6 +52,7 @@
 SizeType = UnsignedLong;
 PtrDiffType = SignedLong;
 IntPtrType = SignedLong;
+HasFloat16 = true;
   }
 
 protected:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D57577: Make predefined FLT16 macros conditional on support for the type

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai marked an inline comment as done.
nemanjai added inline comments.



Comment at: lib/Basic/Targets/WebAssembly.h:55
 IntPtrType = SignedLong;
+HasFloat16 = true;
   }

There are test cases that check for the macros for WebAssembly so I assumed 
they probably want the type to be valid on the target. If that's not the case, 
I can change the test case.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57577



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

[PATCH] D57581: Explicitly add language standard option to test cases that rely on the C++14 default

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai created this revision.
nemanjai added reviewers: ilya-biryukov, jfb, takuto.ikuta, rjmccall, rsmith, 
SjoerdMeijer, t.p.northover, erichkeane.
Herald added a subscriber: eraman.
Herald added a project: clang.

One of the platforms on which we do regular builds has some system headers that 
are not compatible with C++14. As a result, we can't compile any code 
(including `test-suite` tests) if we leave the default as is. So what we do is 
set the CMake option that allows us to set clang's default language level (we 
set it to `gnu++11` in our case). However, this causes failures in all of the 
lit tests attached.

This patch simply adds the `-std=gnu++14` option to match the typical default 
for clang that the test cases rely on.

I've tried to add people that have added/modified the tests as reviewers to 
this patch - so I am sorry about the very long list of reviewers. Please let me 
know if this is an acceptable change.


Repository:
  rC Clang

https://reviews.llvm.org/D57581

Files:
  test/CodeCompletion/crash-skipped-bodies-template-inst.cpp
  test/CodeCompletion/skip-auto-funcs.cpp
  test/CodeGenCXX/auto-var-init.cpp
  test/CodeGenCXX/dllexport-no-dllexport-inlines.cpp
  test/CodeGenCXX/new-overflow.cpp
  test/CodeGenCXX/new.cpp
  test/Lexer/cxx-features.cpp
  test/Lexer/half-literal.cpp
  test/Modules/friend-definition-2.cpp
  test/Modules/merge-lambdas.cpp
  test/SemaCXX/int-ptr-cast-SFINAE.cpp
  test/SemaTemplate/argument-dependent-lookup.cpp
  test/SemaTemplate/class-template-decl.cpp
  test/SemaTemplate/typo-dependent-name.cpp

Index: test/SemaTemplate/typo-dependent-name.cpp
===
--- test/SemaTemplate/typo-dependent-name.cpp
+++ test/SemaTemplate/typo-dependent-name.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -std=gnu++14 -fsyntax-only -verify %s
 
 using nullptr_t = decltype(nullptr);
 
Index: test/SemaTemplate/class-template-decl.cpp
===
--- test/SemaTemplate/class-template-decl.cpp
+++ test/SemaTemplate/class-template-decl.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -std=gnu++14 -fsyntax-only -verify %s
 
 template class A;
 
Index: test/SemaTemplate/argument-dependent-lookup.cpp
===
--- test/SemaTemplate/argument-dependent-lookup.cpp
+++ test/SemaTemplate/argument-dependent-lookup.cpp
@@ -1,5 +1,5 @@
-// RUN: %clang_cc1 -verify %s
-// RUN: %clang_cc1 -verify %s -DHAVE_UNQUALIFIED_LOOKUP_RESULTS
+// RUN: %clang_cc1 -std=gnu++14 -verify %s
+// RUN: %clang_cc1 -std=gnu++14 -verify %s -DHAVE_UNQUALIFIED_LOOKUP_RESULTS
 // expected-no-diagnostics
 
 namespace address_of {
Index: test/SemaCXX/int-ptr-cast-SFINAE.cpp
===
--- test/SemaCXX/int-ptr-cast-SFINAE.cpp
+++ test/SemaCXX/int-ptr-cast-SFINAE.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -fsyntax-only -verify %s -std=gnu++14
 // RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++17
 
 void foo(int* a, int *b) {
Index: test/Modules/merge-lambdas.cpp
===
--- test/Modules/merge-lambdas.cpp
+++ test/Modules/merge-lambdas.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fmodules -verify %s -emit-llvm-only
+// RUN: %clang_cc1 -std=gnu++14 -fmodules -verify %s -emit-llvm-only
 // expected-no-diagnostics
 
 #pragma clang module build A
Index: test/Modules/friend-definition-2.cpp
===
--- test/Modules/friend-definition-2.cpp
+++ test/Modules/friend-definition-2.cpp
@@ -1,5 +1,5 @@
-// RUN: %clang_cc1 -fmodules %s -verify
-// RUN: %clang_cc1 -fmodules %s -verify -triple i686-windows
+// RUN: %clang_cc1 -std=gnu++14 -fmodules %s -verify
+// RUN: %clang_cc1 -std=gnu++14 -fmodules %s -verify -triple i686-windows
 // expected-no-diagnostics
 #pragma clang module build A
 module A {}
Index: test/Lexer/half-literal.cpp
===
--- test/Lexer/half-literal.cpp
+++ test/Lexer/half-literal.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -pedantic -triple aarch64-linux-gnu %s
+// RUN: %clang_cc1 -std=gnu++14 -fsyntax-only -verify -pedantic -triple aarch64-linux-gnu %s
 float a = 1.0h; // expected-error{{no matching literal operator for call to 'operator""h' with argument of type 'long double' or 'const char *', and no matching literal operator template}}
 float b = 1.0H; // expected-error{{invalid suffix 'H' on floating constant}}
 
Index: test/Lexer/cxx-features.cpp
===
--- test/Lexer/cxx-features.cpp
+++ test/Lexer/cxx-features.cpp
@@ -6,9 +6,9 @@
 //
 // RUN: %clang_cc1 -std=c++17 -fcxx-exceptions -fsized-deallocation -frelaxed-temp

[PATCH] D57581: Explicitly add language standard option to test cases that rely on the C++14 default

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

In D57581#1380609 , @ilya-biryukov 
wrote:

> ...
>  Do have a comment, though. Any, reason to use `-std=gnu++14` and not 
> `-std=c++14`?
>  Most (all?) of the tests do not seem to have anything to do with the gnu 
> extensions, so why enable them?


I only used `gnu++14` in the test cases to match the current default in clang 
(i.e. not change how clang handles the test case). But I have no problem 
whatsoever with making these standard C++.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57581



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

[PATCH] D57577: Make predefined FLT16 macros conditional on support for the type

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai updated this revision to Diff 185088.
nemanjai added a comment.

As mentioned in a comment, the WASM tests weren't really meant to indicate that 
WASM supports the type. Removed the changes to the WASM target.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57577

Files:
  lib/Frontend/InitPreprocessor.cpp
  test/Headers/float16.c
  test/Preprocessor/init.c


Index: test/Preprocessor/init.c
===
--- test/Preprocessor/init.c
+++ test/Preprocessor/init.c
@@ -9166,20 +9166,6 @@
 // WEBASSEMBLY-NOT:#define __ELF__
 // WEBASSEMBLY-NEXT:#define __FINITE_MATH_ONLY__ 0
 // WEBASSEMBLY-NEXT:#define __FLOAT128__ 1
-// WEBASSEMBLY-NEXT:#define __FLT16_DECIMAL_DIG__ 5
-// WEBASSEMBLY-NEXT:#define __FLT16_DENORM_MIN__ 5.9604644775390625e-8F16
-// WEBASSEMBLY-NEXT:#define __FLT16_DIG__ 3
-// WEBASSEMBLY-NEXT:#define __FLT16_EPSILON__ 9.765625e-4F16
-// WEBASSEMBLY-NEXT:#define __FLT16_HAS_DENORM__ 1
-// WEBASSEMBLY-NEXT:#define __FLT16_HAS_INFINITY__ 1
-// WEBASSEMBLY-NEXT:#define __FLT16_HAS_QUIET_NAN__ 1
-// WEBASSEMBLY-NEXT:#define __FLT16_MANT_DIG__ 11
-// WEBASSEMBLY-NEXT:#define __FLT16_MAX_10_EXP__ 4
-// WEBASSEMBLY-NEXT:#define __FLT16_MAX_EXP__ 15
-// WEBASSEMBLY-NEXT:#define __FLT16_MAX__ 6.5504e+4F16
-// WEBASSEMBLY-NEXT:#define __FLT16_MIN_10_EXP__ (-13)
-// WEBASSEMBLY-NEXT:#define __FLT16_MIN_EXP__ (-14)
-// WEBASSEMBLY-NEXT:#define __FLT16_MIN__ 6.103515625e-5F16
 // WEBASSEMBLY-NEXT:#define __FLT_DECIMAL_DIG__ 9
 // WEBASSEMBLY-NEXT:#define __FLT_DENORM_MIN__ 1.40129846e-45F
 // WEBASSEMBLY-NEXT:#define __FLT_DIG__ 6
Index: test/Headers/float16.c
===
--- test/Headers/float16.c
+++ test/Headers/float16.c
@@ -1,7 +1,11 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c89 -ffreestanding %s
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c99 -ffreestanding %s
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c11 -ffreestanding %s
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 -x c++ -ffreestanding %s
+// RUN: %clang_cc1 -triple=aarch64-none-none -fsyntax-only -verify -std=c89 \
+// RUN:   -ffreestanding %s
+// RUN: %clang_cc1 -triple=aarch64-none-none -fsyntax-only -verify \
+// RUN:   -std=c99 -ffreestanding %s
+// RUN: %clang_cc1 -triple=aarch64-none-none -fsyntax-only -verify -std=c11 \
+// RUN:   -ffreestanding %s
+// RUN: %clang_cc1 -triple=aarch64-none-none -fsyntax-only -verify \
+// RUN:   -std=c++11 -x c++ -ffreestanding %s
 // expected-no-diagnostics
 
 #define __STDC_WANT_IEC_60559_TYPES_EXT__
Index: lib/Frontend/InitPreprocessor.cpp
===
--- lib/Frontend/InitPreprocessor.cpp
+++ lib/Frontend/InitPreprocessor.cpp
@@ -830,7 +830,8 @@
   DefineFmt("__UINTPTR", TI.getUIntPtrType(), TI, Builder);
   DefineTypeWidth("__UINTPTR_WIDTH__", TI.getUIntPtrType(), TI, Builder);
 
-  DefineFloatMacros(Builder, "FLT16", &TI.getHalfFormat(), "F16");
+  if (TI.hasFloat16Type())
+DefineFloatMacros(Builder, "FLT16", &TI.getHalfFormat(), "F16");
   DefineFloatMacros(Builder, "FLT", &TI.getFloatFormat(), "F");
   DefineFloatMacros(Builder, "DBL", &TI.getDoubleFormat(), "");
   DefineFloatMacros(Builder, "LDBL", &TI.getLongDoubleFormat(), "L");


Index: test/Preprocessor/init.c
===
--- test/Preprocessor/init.c
+++ test/Preprocessor/init.c
@@ -9166,20 +9166,6 @@
 // WEBASSEMBLY-NOT:#define __ELF__
 // WEBASSEMBLY-NEXT:#define __FINITE_MATH_ONLY__ 0
 // WEBASSEMBLY-NEXT:#define __FLOAT128__ 1
-// WEBASSEMBLY-NEXT:#define __FLT16_DECIMAL_DIG__ 5
-// WEBASSEMBLY-NEXT:#define __FLT16_DENORM_MIN__ 5.9604644775390625e-8F16
-// WEBASSEMBLY-NEXT:#define __FLT16_DIG__ 3
-// WEBASSEMBLY-NEXT:#define __FLT16_EPSILON__ 9.765625e-4F16
-// WEBASSEMBLY-NEXT:#define __FLT16_HAS_DENORM__ 1
-// WEBASSEMBLY-NEXT:#define __FLT16_HAS_INFINITY__ 1
-// WEBASSEMBLY-NEXT:#define __FLT16_HAS_QUIET_NAN__ 1
-// WEBASSEMBLY-NEXT:#define __FLT16_MANT_DIG__ 11
-// WEBASSEMBLY-NEXT:#define __FLT16_MAX_10_EXP__ 4
-// WEBASSEMBLY-NEXT:#define __FLT16_MAX_EXP__ 15
-// WEBASSEMBLY-NEXT:#define __FLT16_MAX__ 6.5504e+4F16
-// WEBASSEMBLY-NEXT:#define __FLT16_MIN_10_EXP__ (-13)
-// WEBASSEMBLY-NEXT:#define __FLT16_MIN_EXP__ (-14)
-// WEBASSEMBLY-NEXT:#define __FLT16_MIN__ 6.103515625e-5F16
 // WEBASSEMBLY-NEXT:#define __FLT_DECIMAL_DIG__ 9
 // WEBASSEMBLY-NEXT:#define __FLT_DENORM_MIN__ 1.40129846e-45F
 // WEBASSEMBLY-NEXT:#define __FLT_DIG__ 6
Index: test/Headers/float16.c
===
--- test/Headers/float16.c
+++ test/Headers/float16.c
@@ -1,7 +1,11 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c89 -ffreestanding %s
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c99 -ffreestanding %s
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c11 -ffreestanding %s
-// RUN: %

[PATCH] D57581: Explicitly add language standard option to test cases that rely on the C++14 default

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai updated this revision to Diff 185093.
nemanjai added a comment.

Changed the option to standard C++ rather than GNU extensions.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57581

Files:
  test/CodeCompletion/crash-skipped-bodies-template-inst.cpp
  test/CodeCompletion/skip-auto-funcs.cpp
  test/CodeGenCXX/auto-var-init.cpp
  test/CodeGenCXX/dllexport-no-dllexport-inlines.cpp
  test/CodeGenCXX/new-overflow.cpp
  test/CodeGenCXX/new.cpp
  test/Lexer/cxx-features.cpp
  test/Lexer/half-literal.cpp
  test/Modules/friend-definition-2.cpp
  test/Modules/merge-lambdas.cpp
  test/SemaCXX/int-ptr-cast-SFINAE.cpp
  test/SemaTemplate/argument-dependent-lookup.cpp
  test/SemaTemplate/class-template-decl.cpp
  test/SemaTemplate/typo-dependent-name.cpp

Index: test/SemaTemplate/typo-dependent-name.cpp
===
--- test/SemaTemplate/typo-dependent-name.cpp
+++ test/SemaTemplate/typo-dependent-name.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -std=c++14 -fsyntax-only -verify %s
 
 using nullptr_t = decltype(nullptr);
 
Index: test/SemaTemplate/class-template-decl.cpp
===
--- test/SemaTemplate/class-template-decl.cpp
+++ test/SemaTemplate/class-template-decl.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -std=c++14 -fsyntax-only -verify %s
 
 template class A;
 
Index: test/SemaTemplate/argument-dependent-lookup.cpp
===
--- test/SemaTemplate/argument-dependent-lookup.cpp
+++ test/SemaTemplate/argument-dependent-lookup.cpp
@@ -1,5 +1,5 @@
-// RUN: %clang_cc1 -verify %s
-// RUN: %clang_cc1 -verify %s -DHAVE_UNQUALIFIED_LOOKUP_RESULTS
+// RUN: %clang_cc1 -std=c++14 -verify %s
+// RUN: %clang_cc1 -std=c++14 -verify %s -DHAVE_UNQUALIFIED_LOOKUP_RESULTS
 // expected-no-diagnostics
 
 namespace address_of {
Index: test/SemaCXX/int-ptr-cast-SFINAE.cpp
===
--- test/SemaCXX/int-ptr-cast-SFINAE.cpp
+++ test/SemaCXX/int-ptr-cast-SFINAE.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++14
 // RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++17
 
 void foo(int* a, int *b) {
Index: test/Modules/merge-lambdas.cpp
===
--- test/Modules/merge-lambdas.cpp
+++ test/Modules/merge-lambdas.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fmodules -verify %s -emit-llvm-only
+// RUN: %clang_cc1 -std=c++14 -fmodules -verify %s -emit-llvm-only
 // expected-no-diagnostics
 
 #pragma clang module build A
Index: test/Modules/friend-definition-2.cpp
===
--- test/Modules/friend-definition-2.cpp
+++ test/Modules/friend-definition-2.cpp
@@ -1,5 +1,5 @@
-// RUN: %clang_cc1 -fmodules %s -verify
-// RUN: %clang_cc1 -fmodules %s -verify -triple i686-windows
+// RUN: %clang_cc1 -std=c++14 -fmodules %s -verify
+// RUN: %clang_cc1 -std=c++14 -fmodules %s -verify -triple i686-windows
 // expected-no-diagnostics
 #pragma clang module build A
 module A {}
Index: test/Lexer/half-literal.cpp
===
--- test/Lexer/half-literal.cpp
+++ test/Lexer/half-literal.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -pedantic -triple aarch64-linux-gnu %s
+// RUN: %clang_cc1 -std=c++14 -fsyntax-only -verify -pedantic -triple aarch64-linux-gnu %s
 float a = 1.0h; // expected-error{{no matching literal operator for call to 'operator""h' with argument of type 'long double' or 'const char *', and no matching literal operator template}}
 float b = 1.0H; // expected-error{{invalid suffix 'H' on floating constant}}
 
Index: test/Lexer/cxx-features.cpp
===
--- test/Lexer/cxx-features.cpp
+++ test/Lexer/cxx-features.cpp
@@ -6,9 +6,9 @@
 //
 // RUN: %clang_cc1 -std=c++17 -fcxx-exceptions -fsized-deallocation -frelaxed-template-template-args -DRELAXED_TEMPLATE_TEMPLATE_ARGS=1 -verify %s
 // RUN: %clang_cc1 -std=c++17 -fcxx-exceptions -fsized-deallocation -fconcepts-ts -DCONCEPTS_TS=1 -verify %s
-// RUN: %clang_cc1 -fno-rtti -fno-threadsafe-statics -verify %s -DNO_EXCEPTIONS -DNO_RTTI -DNO_THREADSAFE_STATICS -fsized-deallocation
-// RUN: %clang_cc1 -fcoroutines-ts -DNO_EXCEPTIONS -DCOROUTINES -verify -fsized-deallocation %s
-// RUN: %clang_cc1 -fchar8_t -DNO_EXCEPTIONS -DCHAR8_T -verify -fsized-deallocation %s
+// RUN: %clang_cc1 -std=c++14 -fno-rtti -fno-threadsafe-statics -verify %s -DNO_EXCEPTIONS -DNO_RTTI -DNO_THREADSAFE_STATICS -fsized-deallocation
+// RUN: %clang_cc1 -std=c++14 -fcoroutines-ts -DNO_EXCEPTIONS -DCOROUTINES -verify -fsized-deallocation %s
+// RUN: 

[PATCH] D57581: Explicitly add language standard option to test cases that rely on the C++14 default

[Nemanja Ivanovic via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL353163: [NFC] Explicitly add -std=c++14 option to tests that 
rely on the C++14 default (authored by nemanjai, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D57581?vs=185093&id=185278#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D57581

Files:
  cfe/trunk/test/CodeCompletion/crash-skipped-bodies-template-inst.cpp
  cfe/trunk/test/CodeCompletion/skip-auto-funcs.cpp
  cfe/trunk/test/CodeGenCXX/auto-var-init.cpp
  cfe/trunk/test/CodeGenCXX/dllexport-no-dllexport-inlines.cpp
  cfe/trunk/test/CodeGenCXX/new-overflow.cpp
  cfe/trunk/test/CodeGenCXX/new.cpp
  cfe/trunk/test/Lexer/cxx-features.cpp
  cfe/trunk/test/Lexer/half-literal.cpp
  cfe/trunk/test/Modules/friend-definition-2.cpp
  cfe/trunk/test/Modules/merge-lambdas.cpp
  cfe/trunk/test/SemaCXX/int-ptr-cast-SFINAE.cpp
  cfe/trunk/test/SemaTemplate/argument-dependent-lookup.cpp
  cfe/trunk/test/SemaTemplate/class-template-decl.cpp
  cfe/trunk/test/SemaTemplate/typo-dependent-name.cpp

Index: cfe/trunk/test/SemaTemplate/typo-dependent-name.cpp
===
--- cfe/trunk/test/SemaTemplate/typo-dependent-name.cpp
+++ cfe/trunk/test/SemaTemplate/typo-dependent-name.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -std=c++14 -fsyntax-only -verify %s
 
 using nullptr_t = decltype(nullptr);
 
Index: cfe/trunk/test/SemaTemplate/class-template-decl.cpp
===
--- cfe/trunk/test/SemaTemplate/class-template-decl.cpp
+++ cfe/trunk/test/SemaTemplate/class-template-decl.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -std=c++14 -fsyntax-only -verify %s
 
 template class A;
 
Index: cfe/trunk/test/SemaTemplate/argument-dependent-lookup.cpp
===
--- cfe/trunk/test/SemaTemplate/argument-dependent-lookup.cpp
+++ cfe/trunk/test/SemaTemplate/argument-dependent-lookup.cpp
@@ -1,5 +1,5 @@
-// RUN: %clang_cc1 -verify %s
-// RUN: %clang_cc1 -verify %s -DHAVE_UNQUALIFIED_LOOKUP_RESULTS
+// RUN: %clang_cc1 -std=c++14 -verify %s
+// RUN: %clang_cc1 -std=c++14 -verify %s -DHAVE_UNQUALIFIED_LOOKUP_RESULTS
 // expected-no-diagnostics
 
 namespace address_of {
Index: cfe/trunk/test/Lexer/cxx-features.cpp
===
--- cfe/trunk/test/Lexer/cxx-features.cpp
+++ cfe/trunk/test/Lexer/cxx-features.cpp
@@ -6,9 +6,9 @@
 //
 // RUN: %clang_cc1 -std=c++17 -fcxx-exceptions -fsized-deallocation -frelaxed-template-template-args -DRELAXED_TEMPLATE_TEMPLATE_ARGS=1 -verify %s
 // RUN: %clang_cc1 -std=c++17 -fcxx-exceptions -fsized-deallocation -fconcepts-ts -DCONCEPTS_TS=1 -verify %s
-// RUN: %clang_cc1 -fno-rtti -fno-threadsafe-statics -verify %s -DNO_EXCEPTIONS -DNO_RTTI -DNO_THREADSAFE_STATICS -fsized-deallocation
-// RUN: %clang_cc1 -fcoroutines-ts -DNO_EXCEPTIONS -DCOROUTINES -verify -fsized-deallocation %s
-// RUN: %clang_cc1 -fchar8_t -DNO_EXCEPTIONS -DCHAR8_T -verify -fsized-deallocation %s
+// RUN: %clang_cc1 -std=c++14 -fno-rtti -fno-threadsafe-statics -verify %s -DNO_EXCEPTIONS -DNO_RTTI -DNO_THREADSAFE_STATICS -fsized-deallocation
+// RUN: %clang_cc1 -std=c++14 -fcoroutines-ts -DNO_EXCEPTIONS -DCOROUTINES -verify -fsized-deallocation %s
+// RUN: %clang_cc1 -std=c++14 -fchar8_t -DNO_EXCEPTIONS -DCHAR8_T -verify -fsized-deallocation %s
 // RUN: %clang_cc1 -std=c++2a -fno-char8_t -DNO_EXCEPTIONS -DNO_CHAR8_T -verify -fsized-deallocation %s
 
 // expected-no-diagnostics
Index: cfe/trunk/test/Lexer/half-literal.cpp
===
--- cfe/trunk/test/Lexer/half-literal.cpp
+++ cfe/trunk/test/Lexer/half-literal.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -pedantic -triple aarch64-linux-gnu %s
+// RUN: %clang_cc1 -std=c++14 -fsyntax-only -verify -pedantic -triple aarch64-linux-gnu %s
 float a = 1.0h; // expected-error{{no matching literal operator for call to 'operator""h' with argument of type 'long double' or 'const char *', and no matching literal operator template}}
 float b = 1.0H; // expected-error{{invalid suffix 'H' on floating constant}}
 
Index: cfe/trunk/test/SemaCXX/int-ptr-cast-SFINAE.cpp
===
--- cfe/trunk/test/SemaCXX/int-ptr-cast-SFINAE.cpp
+++ cfe/trunk/test/SemaCXX/int-ptr-cast-SFINAE.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++14
 // RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++17
 
 void foo(int* a, int *b) {
Index: cfe/trunk/test/Modules/friend-definition-2.cpp
===

[PATCH] D57577: Make predefined FLT16 macros conditional on support for the type

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

Does anyone have any further comments or objections to this patch? I would like 
to commit this and close the PR.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57577



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

[PATCH] D49754: Add -m(no-)spe, and e500 CPU definitions and support to clang

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

There is a long series of comments in this patch and I am not clear at this 
point on whether this patch breaks anything or it is fine. Could you please 
`Request Changes` if this patch is broken or approve if it is fine?


Repository:
  rC Clang

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

https://reviews.llvm.org/D49754



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

[PATCH] D49754: Add -m(no-)spe, and e500 CPU definitions and support to clang

[Nemanja Ivanovic via Phabricator via cfe-commits]

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

Please, no more patches without context. This one was actually easy to review 
without context and the comments are minor, so I'm fine with these being 
addressed on the commit.




Comment at: lib/Basic/Targets/PPC.cpp:318
+  Features["spe"] = llvm::StringSwitch(CPU)
+.Case("e500", true)
+.Case("8548", true)

The `e500v2` that you added doesn't support SPE?



Comment at: test/Misc/target-invalid-cpu-note.c:82
 // PPC-SAME: 603e, 603ev, 604, 604e, 620, 630, g3, 7400, g4, 7450, g4+, 750,
-// PPC-SAME: 970, g5, a2, a2q, e500mc, e5500, power3, pwr3, power4, pwr4,
+// PPC-SAME: 970, g5, a2, a2q, e500, e500mc, e5500, power3, pwr3, power4, pwr4,
 // PPC-SAME: power5, pwr5, power5x, pwr5x, power6, pwr6, power6x, pwr6x, 
power7,

I think you may have missed adding `8548` to this line or above. Of course, the 
test should still pass, but we should add it.



Comment at: test/Preprocessor/init.c:7021
+//
+// PPC32-SPE:#define __SPE__ 1
+//

Please add a check for the other predefined macro you added.


Repository:
  rC Clang

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

https://reviews.llvm.org/D49754



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

[PATCH] D49754: Add -m(no-)spe, and e500 CPU definitions and support to clang

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

In D49754#1402790 , @vit9696 wrote:

> This is a series of patches, which I believe should merged altogether. 
> Currently the following patches are relevant:


No, please don't merge them together. It is much more manageable for review 
when they're separate patches. I realize that this makes it a bit more 
difficult for the author to keep the dependency ordering straight, but I think 
preference needs to be given to the "reviewability" of the code.


Repository:
  rC Clang

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

https://reviews.llvm.org/D49754



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

[PATCH] D57577: Make predefined FLT16 macros conditional on support for the type

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai marked an inline comment as done.
nemanjai added a comment.
Herald added a subscriber: jdoerfert.

Since I haven't seen any further objections to this, I'll commit this later 
today.




Comment at: test/Preprocessor/init.c:9169
 // WEBASSEMBLY-NEXT:#define __FLOAT128__ 1
-// WEBASSEMBLY-NEXT:#define __FLT16_DECIMAL_DIG__ 5
-// WEBASSEMBLY-NEXT:#define __FLT16_DENORM_MIN__ 5.9604644775390625e-8F16

SjoerdMeijer wrote:
> Perhaps change this in WEBASSEMBLY-NOT so that we also have one negative test 
> for this?
I will do this on the commit.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57577



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

[PATCH] D57577: Make predefined FLT16 macros conditional on support for the type

[Nemanja Ivanovic via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL354512: Make predefined FLT16 macros conditional on support 
for the type (authored by nemanjai, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D57577?vs=185088&id=187648#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D57577

Files:
  cfe/trunk/lib/Frontend/InitPreprocessor.cpp
  cfe/trunk/test/Headers/float16.c
  cfe/trunk/test/Preprocessor/init.c


Index: cfe/trunk/test/Preprocessor/init.c
===
--- cfe/trunk/test/Preprocessor/init.c
+++ cfe/trunk/test/Preprocessor/init.c
@@ -9166,20 +9166,20 @@
 // WEBASSEMBLY-NOT:#define __ELF__
 // WEBASSEMBLY-NEXT:#define __FINITE_MATH_ONLY__ 0
 // WEBASSEMBLY-NEXT:#define __FLOAT128__ 1
-// WEBASSEMBLY-NEXT:#define __FLT16_DECIMAL_DIG__ 5
-// WEBASSEMBLY-NEXT:#define __FLT16_DENORM_MIN__ 5.9604644775390625e-8F16
-// WEBASSEMBLY-NEXT:#define __FLT16_DIG__ 3
-// WEBASSEMBLY-NEXT:#define __FLT16_EPSILON__ 9.765625e-4F16
-// WEBASSEMBLY-NEXT:#define __FLT16_HAS_DENORM__ 1
-// WEBASSEMBLY-NEXT:#define __FLT16_HAS_INFINITY__ 1
-// WEBASSEMBLY-NEXT:#define __FLT16_HAS_QUIET_NAN__ 1
-// WEBASSEMBLY-NEXT:#define __FLT16_MANT_DIG__ 11
-// WEBASSEMBLY-NEXT:#define __FLT16_MAX_10_EXP__ 4
-// WEBASSEMBLY-NEXT:#define __FLT16_MAX_EXP__ 15
-// WEBASSEMBLY-NEXT:#define __FLT16_MAX__ 6.5504e+4F16
-// WEBASSEMBLY-NEXT:#define __FLT16_MIN_10_EXP__ (-13)
-// WEBASSEMBLY-NEXT:#define __FLT16_MIN_EXP__ (-14)
-// WEBASSEMBLY-NEXT:#define __FLT16_MIN__ 6.103515625e-5F16
+// WEBASSEMBLY-NOT:#define __FLT16_DECIMAL_DIG__
+// WEBASSEMBLY-NOT:#define __FLT16_DENORM_MIN__
+// WEBASSEMBLY-NOT:#define __FLT16_DIG__
+// WEBASSEMBLY-NOT:#define __FLT16_EPSILON__
+// WEBASSEMBLY-NOT:#define __FLT16_HAS_DENORM__
+// WEBASSEMBLY-NOT:#define __FLT16_HAS_INFINITY__
+// WEBASSEMBLY-NOT:#define __FLT16_HAS_QUIET_NAN__
+// WEBASSEMBLY-NOT:#define __FLT16_MANT_DIG__
+// WEBASSEMBLY-NOT:#define __FLT16_MAX_10_EXP__
+// WEBASSEMBLY-NOT:#define __FLT16_MAX_EXP__
+// WEBASSEMBLY-NOT:#define __FLT16_MAX__
+// WEBASSEMBLY-NOT:#define __FLT16_MIN_10_EXP__
+// WEBASSEMBLY-NOT:#define __FLT16_MIN_EXP__
+// WEBASSEMBLY-NOT:#define __FLT16_MIN__
 // WEBASSEMBLY-NEXT:#define __FLT_DECIMAL_DIG__ 9
 // WEBASSEMBLY-NEXT:#define __FLT_DENORM_MIN__ 1.40129846e-45F
 // WEBASSEMBLY-NEXT:#define __FLT_DIG__ 6
Index: cfe/trunk/test/Headers/float16.c
===
--- cfe/trunk/test/Headers/float16.c
+++ cfe/trunk/test/Headers/float16.c
@@ -1,7 +1,11 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c89 -ffreestanding %s
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c99 -ffreestanding %s
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c11 -ffreestanding %s
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 -x c++ -ffreestanding %s
+// RUN: %clang_cc1 -triple=aarch64-none-none -fsyntax-only -verify -std=c89 \
+// RUN:   -ffreestanding %s
+// RUN: %clang_cc1 -triple=aarch64-none-none -fsyntax-only -verify \
+// RUN:   -std=c99 -ffreestanding %s
+// RUN: %clang_cc1 -triple=aarch64-none-none -fsyntax-only -verify -std=c11 \
+// RUN:   -ffreestanding %s
+// RUN: %clang_cc1 -triple=aarch64-none-none -fsyntax-only -verify \
+// RUN:   -std=c++11 -x c++ -ffreestanding %s
 // expected-no-diagnostics
 
 #define __STDC_WANT_IEC_60559_TYPES_EXT__
Index: cfe/trunk/lib/Frontend/InitPreprocessor.cpp
===
--- cfe/trunk/lib/Frontend/InitPreprocessor.cpp
+++ cfe/trunk/lib/Frontend/InitPreprocessor.cpp
@@ -830,7 +830,8 @@
   DefineFmt("__UINTPTR", TI.getUIntPtrType(), TI, Builder);
   DefineTypeWidth("__UINTPTR_WIDTH__", TI.getUIntPtrType(), TI, Builder);
 
-  DefineFloatMacros(Builder, "FLT16", &TI.getHalfFormat(), "F16");
+  if (TI.hasFloat16Type())
+DefineFloatMacros(Builder, "FLT16", &TI.getHalfFormat(), "F16");
   DefineFloatMacros(Builder, "FLT", &TI.getFloatFormat(), "F");
   DefineFloatMacros(Builder, "DBL", &TI.getDoubleFormat(), "");
   DefineFloatMacros(Builder, "LDBL", &TI.getLongDoubleFormat(), "L");


Index: cfe/trunk/test/Preprocessor/init.c
===
--- cfe/trunk/test/Preprocessor/init.c
+++ cfe/trunk/test/Preprocessor/init.c
@@ -9166,20 +9166,20 @@
 // WEBASSEMBLY-NOT:#define __ELF__
 // WEBASSEMBLY-NEXT:#define __FINITE_MATH_ONLY__ 0
 // WEBASSEMBLY-NEXT:#define __FLOAT128__ 1
-// WEBASSEMBLY-NEXT:#define __FLT16_DECIMAL_DIG__ 5
-// WEBASSEMBLY-NEXT:#define __FLT16_DENORM_MIN__ 5.9604644775390625e-8F16
-// WEBASSEMBLY-NEXT:#define __FLT16_DIG__ 3
-// WEBASSEMBLY-NEXT:#define __FLT16_EPSILON__ 9.765625e-4F16
-// WEBASSEMBLY-NEXT:#define __FLT16_HAS_DENORM__ 1
-// WEBASSEMBLY-NEXT:#define __FLT16_HAS_INFINITY__ 1
-// WEBASSEMBLY-NEXT:#defi

[PATCH] D58497: Clear the KnownModules cache if the preprocessor is going away

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai created this revision.
nemanjai added a reviewer: rsmith.
Herald added a subscriber: jdoerfert.
Herald added a project: clang.

When the `Preprocessor (PP)` in compiler instance is going away, we should 
clear the cache of any pointers that it owns as they will be destroyed.

This is one possible fix for the issue I outlined in 
http://lists.llvm.org/pipermail/cfe-dev/2019-February/061293.html that received 
no responses. We have now encountered the issue in multiple internal buildbots 
and I have even seen it in external bots as well. This really should be fixed.

As outlined in my cfe-dev post, it is exceedingly difficult to produce a 
reliable test case for this (at least for me) so I have not provided one.

If others should be on the list of reviewers, please add them.


Repository:
  rC Clang

https://reviews.llvm.org/D58497

Files:
  lib/Frontend/CompilerInstance.cpp


Index: lib/Frontend/CompilerInstance.cpp
===
--- lib/Frontend/CompilerInstance.cpp
+++ lib/Frontend/CompilerInstance.cpp
@@ -374,7 +374,14 @@
   // The module manager holds a reference to the old preprocessor (if any).
   ModuleManager.reset();
 
-  // Create the Preprocessor.
+  // Create the Preprocessor. If this instance is replacing the existing
+  // preprocessor and that existing one is going away, we have to remove
+  // the Module* pointers it owns from KnownModules since they will be
+  // dangling. FIXME: Should this only remove pointers owned by the
+  // preprocessor that is going away or clear the entire map (or can
+  // the map even own any other Module* pointers)?
+  if (PP.unique())
+KnownModules.clear();
   HeaderSearch *HeaderInfo =
   new HeaderSearch(getHeaderSearchOptsPtr(), getSourceManager(),
getDiagnostics(), getLangOpts(), &getTarget());


Index: lib/Frontend/CompilerInstance.cpp
===
--- lib/Frontend/CompilerInstance.cpp
+++ lib/Frontend/CompilerInstance.cpp
@@ -374,7 +374,14 @@
   // The module manager holds a reference to the old preprocessor (if any).
   ModuleManager.reset();
 
-  // Create the Preprocessor.
+  // Create the Preprocessor. If this instance is replacing the existing
+  // preprocessor and that existing one is going away, we have to remove
+  // the Module* pointers it owns from KnownModules since they will be
+  // dangling. FIXME: Should this only remove pointers owned by the
+  // preprocessor that is going away or clear the entire map (or can
+  // the map even own any other Module* pointers)?
+  if (PP.unique())
+KnownModules.clear();
   HeaderSearch *HeaderInfo =
   new HeaderSearch(getHeaderSearchOptsPtr(), getSourceManager(),
getDiagnostics(), getLangOpts(), &getTarget());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D36431: Add powerpc64 to compiler-rt build infrastructure.

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai accepted this revision.
nemanjai added subscribers: hfinkel, echristo.
nemanjai added a comment.
This revision is now accepted and ready to land.

I hope I haven't lost track of the patches that precluded this. If I remember 
correctly, all the X86 80-bit stuff was sorted out. We now know why those test 
cases were running forever (i.e. a vaarg function invoked as a non-vaarg 
function). So this just enables the truly generic builtins along with some PPC 
builtins. If my understanding is correct, I'd say this is ready to proceed 
(unless it was subsumed by one of the other patches).

Long story short... LGTM.
You may want to get the green light from @hfinkel or @echristo and/or one of 
the compiler-rt experts as well.


https://reviews.llvm.org/D36431



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

[PATCH] D63636: [PowerPC][Altivec] Fix offsets for vec_xl and vec_xst

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai created this revision.
nemanjai added reviewers: hfinkel, jsji, rzurob, saghir.
Herald added a subscriber: kbarton.
Herald added a project: clang.

As we currently have it implemented in altivec.h, the offsets for these two 
intrinsics are element offsets. The documentation in the ABI (as well as the 
implementation in both XL and GCC) states that these should be byte offsets.


Repository:
  rC Clang

https://reviews.llvm.org/D63636

Files:
  lib/Headers/altivec.h
  test/CodeGen/builtins-ppc-xl-xst.c

Index: test/CodeGen/builtins-ppc-xl-xst.c
===
--- test/CodeGen/builtins-ppc-xl-xst.c
+++ test/CodeGen/builtins-ppc-xl-xst.c
@@ -0,0 +1,849 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// REQUIRES: powerpc-registered-target
+// RUN: %clang_cc1 -target-feature +altivec -target-feature +vsx -triple powerpc64-unknown-unknown -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -target-feature +altivec -target-feature +vsx -target-feature +power8-vector -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK-P8
+#include 
+
+// CHECK-LABEL: @test1(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[__VEC_ADDR_I:%.*]] = alloca <8 x i16>, align 16
+// CHECK-NEXT:[[__OFFSET_ADDR_I1:%.*]] = alloca i64, align 8
+// CHECK-NEXT:[[__PTR_ADDR_I2:%.*]] = alloca i16*, align 8
+// CHECK-NEXT:[[ADJUSTED_I3:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:[[__OFFSET_ADDR_I:%.*]] = alloca i64, align 8
+// CHECK-NEXT:[[__PTR_ADDR_I:%.*]] = alloca i16*, align 8
+// CHECK-NEXT:[[ADJUSTED_I:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:[[C_ADDR:%.*]] = alloca <8 x i16>*, align 8
+// CHECK-NEXT:[[PTR_ADDR:%.*]] = alloca i16*, align 8
+// CHECK-NEXT:store <8 x i16>* [[C:%.*]], <8 x i16>** [[C_ADDR]], align 8
+// CHECK-NEXT:store i16* [[PTR:%.*]], i16** [[PTR_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i16*, i16** [[PTR_ADDR]], align 8
+// CHECK-NEXT:store i64 3, i64* [[__OFFSET_ADDR_I]], align 8
+// CHECK-NEXT:store i16* [[TMP0]], i16** [[__PTR_ADDR_I]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = load i16*, i16** [[__PTR_ADDR_I]], align 8
+// CHECK-NEXT:[[TMP2:%.*]] = bitcast i16* [[TMP1]] to i8*
+// CHECK-NEXT:[[TMP3:%.*]] = load i64, i64* [[__OFFSET_ADDR_I]], align 8
+// CHECK-NEXT:[[ADD_PTR_I:%.*]] = getelementptr inbounds i8, i8* [[TMP2]], i64 [[TMP3]]
+// CHECK-NEXT:store i8* [[ADD_PTR_I]], i8** [[ADJUSTED_I]], align 8
+// CHECK-NEXT:[[TMP4:%.*]] = load i8*, i8** [[ADJUSTED_I]], align 8
+// CHECK-NEXT:[[TMP5:%.*]] = bitcast i8* [[TMP4]] to i16*
+// CHECK-NEXT:[[TMP6:%.*]] = bitcast i16* [[TMP5]] to <8 x i16>*
+// CHECK-NEXT:[[TMP7:%.*]] = load <8 x i16>, <8 x i16>* [[TMP6]], align 1
+// CHECK-NEXT:[[TMP8:%.*]] = load <8 x i16>*, <8 x i16>** [[C_ADDR]], align 8
+// CHECK-NEXT:store <8 x i16> [[TMP7]], <8 x i16>* [[TMP8]], align 16
+// CHECK-NEXT:[[TMP9:%.*]] = load <8 x i16>*, <8 x i16>** [[C_ADDR]], align 8
+// CHECK-NEXT:[[TMP10:%.*]] = load <8 x i16>, <8 x i16>* [[TMP9]], align 16
+// CHECK-NEXT:[[TMP11:%.*]] = load i16*, i16** [[PTR_ADDR]], align 8
+// CHECK-NEXT:store <8 x i16> [[TMP10]], <8 x i16>* [[__VEC_ADDR_I]], align 16
+// CHECK-NEXT:store i64 7, i64* [[__OFFSET_ADDR_I1]], align 8
+// CHECK-NEXT:store i16* [[TMP11]], i16** [[__PTR_ADDR_I2]], align 8
+// CHECK-NEXT:[[TMP12:%.*]] = load i16*, i16** [[__PTR_ADDR_I2]], align 8
+// CHECK-NEXT:[[TMP13:%.*]] = bitcast i16* [[TMP12]] to i8*
+// CHECK-NEXT:[[TMP14:%.*]] = load i64, i64* [[__OFFSET_ADDR_I1]], align 8
+// CHECK-NEXT:[[ADD_PTR_I4:%.*]] = getelementptr inbounds i8, i8* [[TMP13]], i64 [[TMP14]]
+// CHECK-NEXT:store i8* [[ADD_PTR_I4]], i8** [[ADJUSTED_I3]], align 8
+// CHECK-NEXT:[[TMP15:%.*]] = load <8 x i16>, <8 x i16>* [[__VEC_ADDR_I]], align 16
+// CHECK-NEXT:[[TMP16:%.*]] = load i8*, i8** [[ADJUSTED_I3]], align 8
+// CHECK-NEXT:[[TMP17:%.*]] = bitcast i8* [[TMP16]] to <8 x i16>*
+// CHECK-NEXT:store <8 x i16> [[TMP15]], <8 x i16>* [[TMP17]], align 1
+// CHECK-NEXT:ret void
+//
+// CHECK-P8-LABEL: @test1(
+// CHECK-P8-NEXT:  entry:
+// CHECK-P8-NEXT:[[__VEC_ADDR_I:%.*]] = alloca <8 x i16>, align 16
+// CHECK-P8-NEXT:[[__OFFSET_ADDR_I1:%.*]] = alloca i64, align 8
+// CHECK-P8-NEXT:[[__PTR_ADDR_I2:%.*]] = alloca i16*, align 8
+// CHECK-P8-NEXT:[[ADJUSTED_I3:%.*]] = alloca i8*, align 8
+// CHECK-P8-NEXT:[[__OFFSET_ADDR_I:%.*]] = alloca i64, align 8
+// CHECK-P8-NEXT:[[__PTR_ADDR_I:%.*]] = alloca i16*, align 8
+// CHECK-P8-NEXT:[[ADJUSTED_I:%.*]] = alloca i8*, align 8
+// CHECK-P8-NEXT:[[C_ADDR:%.*]] = alloca <8 x i16>*, align 8
+// CHECK-P8-NEXT:[[PTR_ADDR:%.*]] = alloca i16*, align 8
+// CHECK-P8-NEXT:store <8 x i16>* [[C:%.*]], <8 x i16>** [[C_ADDR]], align 8
+// CHECK-P8-NEXT:store i16* [[PTR:%.*]], i16** [[PTR_ADDR]], align 8
+// 

[PATCH] D63636: [PowerPC][Altivec] Fix offsets for vec_xl and vec_xst

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai marked 3 inline comments as done.
nemanjai added inline comments.



Comment at: lib/Headers/altivec.h:16364
   signed short *__ptr) {
-  return *(unaligned_vec_sshort *)(__ptr + __offset);
+  signed char *Adjusted = (signed char *)__ptr + __offset;
+  return *(unaligned_vec_sshort *)((signed short *)Adjusted);

jsji wrote:
> Why we name it `Adjusted`?  Why not just `__addr`? 
Sure. I don't really have any preference with respect to the name at all.



Comment at: lib/Headers/altivec.h:16365
+  signed char *Adjusted = (signed char *)__ptr + __offset;
+  return *(unaligned_vec_sshort *)((signed short *)Adjusted);
 }

jsji wrote:
> Why we want to cast it to `(signed short *)` again? Looks like unnecessary 
> casting to me?
Argh, yup the double cast is silly. I initially did something different for 
this and just missed cleaning up these. I'll update.



Comment at: test/CodeGen/builtins-ppc-xl-xst.c:4
+// RUN: %clang_cc1 -target-feature +altivec -target-feature +vsx -triple 
powerpc64-unknown-unknown -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -target-feature +altivec -target-feature +vsx 
-target-feature +power8-vector -triple powerpc64le-unknown-unknown -emit-llvm 
%s -o - | FileCheck %s -check-prefix=CHECK-P8
+#include 

jsji wrote:
> Any difference for results without `power8-vector `, except for `test9` and 
> `test10`?
> 
> Why not split `test9` and `test10` to another file for simplicity?
I like running all of them both with and without power8-vector. I can simplify 
this by using `check-prefixes=CHECK,CHECK-P8` so that we only have one sequence 
of checks for each function.


Repository:
  rC Clang

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

https://reviews.llvm.org/D63636



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

[PATCH] D63636: [PowerPC][Altivec] Fix offsets for vec_xl and vec_xst

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai updated this revision to Diff 206123.
nemanjai added a comment.

Remove the double cast. Simplify the test case. Rename the temp.


Repository:
  rC Clang

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

https://reviews.llvm.org/D63636

Files:
  lib/Headers/altivec.h
  test/CodeGen/builtins-ppc-xl-xst.c

Index: test/CodeGen/builtins-ppc-xl-xst.c
===
--- test/CodeGen/builtins-ppc-xl-xst.c
+++ test/CodeGen/builtins-ppc-xl-xst.c
@@ -0,0 +1,490 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// REQUIRES: powerpc-registered-target
+// RUN: %clang_cc1 -target-feature +altivec -target-feature +vsx \
+// RUN:   -triple powerpc64-unknown-unknown -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -target-feature +altivec -target-feature +vsx \
+// RUN:   -target-feature +power8-vector -triple powerpc64le-unknown-unknown \
+// RUN:   -emit-llvm %s -o - | FileCheck %s -check-prefixes=CHECK,CHECK-P8
+#include 
+
+// CHECK-LABEL: @test1(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[__VEC_ADDR_I:%.*]] = alloca <8 x i16>, align 16
+// CHECK-NEXT:[[__OFFSET_ADDR_I1:%.*]] = alloca i64, align 8
+// CHECK-NEXT:[[__PTR_ADDR_I2:%.*]] = alloca i16*, align 8
+// CHECK-NEXT:[[__ADDR_I3:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:[[__OFFSET_ADDR_I:%.*]] = alloca i64, align 8
+// CHECK-NEXT:[[__PTR_ADDR_I:%.*]] = alloca i16*, align 8
+// CHECK-NEXT:[[__ADDR_I:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:[[C_ADDR:%.*]] = alloca <8 x i16>*, align 8
+// CHECK-NEXT:[[PTR_ADDR:%.*]] = alloca i16*, align 8
+// CHECK-NEXT:store <8 x i16>* [[C:%.*]], <8 x i16>** [[C_ADDR]], align 8
+// CHECK-NEXT:store i16* [[PTR:%.*]], i16** [[PTR_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i16*, i16** [[PTR_ADDR]], align 8
+// CHECK-NEXT:store i64 3, i64* [[__OFFSET_ADDR_I]], align 8
+// CHECK-NEXT:store i16* [[TMP0]], i16** [[__PTR_ADDR_I]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = load i16*, i16** [[__PTR_ADDR_I]], align 8
+// CHECK-NEXT:[[TMP2:%.*]] = bitcast i16* [[TMP1]] to i8*
+// CHECK-NEXT:[[TMP3:%.*]] = load i64, i64* [[__OFFSET_ADDR_I]], align 8
+// CHECK-NEXT:[[ADD_PTR_I:%.*]] = getelementptr inbounds i8, i8* [[TMP2]], i64 [[TMP3]]
+// CHECK-NEXT:store i8* [[ADD_PTR_I]], i8** [[__ADDR_I]], align 8
+// CHECK-NEXT:[[TMP4:%.*]] = load i8*, i8** [[__ADDR_I]], align 8
+// CHECK-NEXT:[[TMP5:%.*]] = bitcast i8* [[TMP4]] to <8 x i16>*
+// CHECK-NEXT:[[TMP6:%.*]] = load <8 x i16>, <8 x i16>* [[TMP5]], align 1
+// CHECK-NEXT:[[TMP7:%.*]] = load <8 x i16>*, <8 x i16>** [[C_ADDR]], align 8
+// CHECK-NEXT:store <8 x i16> [[TMP6]], <8 x i16>* [[TMP7]], align 16
+// CHECK-NEXT:[[TMP8:%.*]] = load <8 x i16>*, <8 x i16>** [[C_ADDR]], align 8
+// CHECK-NEXT:[[TMP9:%.*]] = load <8 x i16>, <8 x i16>* [[TMP8]], align 16
+// CHECK-NEXT:[[TMP10:%.*]] = load i16*, i16** [[PTR_ADDR]], align 8
+// CHECK-NEXT:store <8 x i16> [[TMP9]], <8 x i16>* [[__VEC_ADDR_I]], align 16
+// CHECK-NEXT:store i64 7, i64* [[__OFFSET_ADDR_I1]], align 8
+// CHECK-NEXT:store i16* [[TMP10]], i16** [[__PTR_ADDR_I2]], align 8
+// CHECK-NEXT:[[TMP11:%.*]] = load i16*, i16** [[__PTR_ADDR_I2]], align 8
+// CHECK-NEXT:[[TMP12:%.*]] = bitcast i16* [[TMP11]] to i8*
+// CHECK-NEXT:[[TMP13:%.*]] = load i64, i64* [[__OFFSET_ADDR_I1]], align 8
+// CHECK-NEXT:[[ADD_PTR_I4:%.*]] = getelementptr inbounds i8, i8* [[TMP12]], i64 [[TMP13]]
+// CHECK-NEXT:store i8* [[ADD_PTR_I4]], i8** [[__ADDR_I3]], align 8
+// CHECK-NEXT:[[TMP14:%.*]] = load <8 x i16>, <8 x i16>* [[__VEC_ADDR_I]], align 16
+// CHECK-NEXT:[[TMP15:%.*]] = load i8*, i8** [[__ADDR_I3]], align 8
+// CHECK-NEXT:[[TMP16:%.*]] = bitcast i8* [[TMP15]] to <8 x i16>*
+// CHECK-NEXT:store <8 x i16> [[TMP14]], <8 x i16>* [[TMP16]], align 1
+// CHECK-NEXT:ret void
+//
+void test1(vector signed short *c, signed short *ptr) {
+*c = vec_xl(3ll, ptr);
+vec_xst(*c, 7ll, ptr);
+}
+
+// CHECK-LABEL: @test2(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[__VEC_ADDR_I:%.*]] = alloca <8 x i16>, align 16
+// CHECK-NEXT:[[__OFFSET_ADDR_I1:%.*]] = alloca i64, align 8
+// CHECK-NEXT:[[__PTR_ADDR_I2:%.*]] = alloca i16*, align 8
+// CHECK-NEXT:[[__ADDR_I3:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:[[__OFFSET_ADDR_I:%.*]] = alloca i64, align 8
+// CHECK-NEXT:[[__PTR_ADDR_I:%.*]] = alloca i16*, align 8
+// CHECK-NEXT:[[__ADDR_I:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:[[C_ADDR:%.*]] = alloca <8 x i16>*, align 8
+// CHECK-NEXT:[[PTR_ADDR:%.*]] = alloca i16*, align 8
+// CHECK-NEXT:store <8 x i16>* [[C:%.*]], <8 x i16>** [[C_ADDR]], align 8
+// CHECK-NEXT:store i16* [[PTR:%.*]], i16** [[PTR_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i16*, i16** [[PTR_ADDR]], align 8
+// CHECK-NEXT:store i64 3, i64* [[__OFFSET_ADDR_I]], align 8
+// C

[PATCH] D64024: [PowerPC][Altivec] Emit correct builtin for single precision vec_all_ne

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai created this revision.
nemanjai added reviewers: hfinkel, jsji, rzurob.
Herald added subscribers: kristina, kbarton.
Herald added a project: clang.

We currently emit a double precision comparison instruction for this, whereas 
we need to emit the single precision version.


Repository:
  rC Clang

https://reviews.llvm.org/D64024

Files:
  lib/Headers/altivec.h
  test/CodeGen/builtins-ppc-p8vector.c


Index: test/CodeGen/builtins-ppc-p8vector.c
===
--- test/CodeGen/builtins-ppc-p8vector.c
+++ test/CodeGen/builtins-ppc-p8vector.c
@@ -515,6 +515,13 @@
   dummy();
 // CHECK: @dummy
 
+  res_i = vec_all_ne(vfa, vfa);
+// CHECK: @llvm.ppc.vsx.xvcmpeqsp.p
+// CHECK-LE: @llvm.ppc.vsx.xvcmpeqsp.p
+
+  dummy();
+// CHECK: @dummy
+
   res_i = vec_all_nge(vda, vda);
 // CHECK: @llvm.ppc.vsx.xvcmpgedp.p
 // CHECK-LE: @llvm.ppc.vsx.xvcmpgedp.p
Index: lib/Headers/altivec.h
===
--- lib/Headers/altivec.h
+++ lib/Headers/altivec.h
@@ -14781,7 +14781,7 @@
 static __inline__ int __ATTRS_o_ai vec_all_ne(vector float __a,
   vector float __b) {
 #ifdef __VSX__
-  return __builtin_vsx_xvcmpeqdp_p(__CR6_EQ, __a, __b);
+  return __builtin_vsx_xvcmpeqsp_p(__CR6_EQ, __a, __b);
 #else
   return __builtin_altivec_vcmpeqfp_p(__CR6_EQ, __a, __b);
 #endif


Index: test/CodeGen/builtins-ppc-p8vector.c
===
--- test/CodeGen/builtins-ppc-p8vector.c
+++ test/CodeGen/builtins-ppc-p8vector.c
@@ -515,6 +515,13 @@
   dummy();
 // CHECK: @dummy
 
+  res_i = vec_all_ne(vfa, vfa);
+// CHECK: @llvm.ppc.vsx.xvcmpeqsp.p
+// CHECK-LE: @llvm.ppc.vsx.xvcmpeqsp.p
+
+  dummy();
+// CHECK: @dummy
+
   res_i = vec_all_nge(vda, vda);
 // CHECK: @llvm.ppc.vsx.xvcmpgedp.p
 // CHECK-LE: @llvm.ppc.vsx.xvcmpgedp.p
Index: lib/Headers/altivec.h
===
--- lib/Headers/altivec.h
+++ lib/Headers/altivec.h
@@ -14781,7 +14781,7 @@
 static __inline__ int __ATTRS_o_ai vec_all_ne(vector float __a,
   vector float __b) {
 #ifdef __VSX__
-  return __builtin_vsx_xvcmpeqdp_p(__CR6_EQ, __a, __b);
+  return __builtin_vsx_xvcmpeqsp_p(__CR6_EQ, __a, __b);
 #else
   return __builtin_altivec_vcmpeqfp_p(__CR6_EQ, __a, __b);
 #endif
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D33499: [PPC] PPC32/Darwin ABI info

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

In D33499#1341236 , 
@ken-cunningham-webuse wrote:

> @iains - I have interest in resolving this issue, and also a couple of other 
> lingering bugs in the PPC32Darwin ABI realm. If you have your WIP available 
> anywhere, I'd be happy to have a go at bringing it up to current.


A decision was made a while ago to remove Darwin support from the PPC back end. 
This was decided due to very little use of the code and essentially no 
maintenance being done on it. I think that support was already turned off in 
ToT with the plan to slowly rip out the code over the next couple of releases. 
So I believe that any improvements you plan to make it will need to be done on 
an older release out of tree unless you can make a compelling case for keeping 
this support in LLVM. Tagging some of the interested parties (@kbarton @hfinkel 
@echristo).


Repository:
  rL LLVM

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

https://reviews.llvm.org/D33499



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

[PATCH] D55326: [Driver] Fix incorrect GNU triplet for PowerPC on SUSE Linux

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai requested changes to this revision.
nemanjai added a comment.
This revision now requires changes to proceed.

A couple of questions since I am not all that familiar with clang and am 
certainly not familiar with this unusual SUSE 32-bit situation:

- We seem to be changing the set of aliases here, but what happens if someone 
actually explicitly specifies `--target=powerpc-suse-linux`?
- Do we need to change anything about include paths?
- Can you describe the default triple for clang on SUSE 32-bit PPC? Will it be 
`powerpc-suse-linux`? `powerpc64-suse-linux`?
- Will this change not affect 64-bit PPC SUSE? Namely will the default 
libraries on actual 64-bit PPC SUSE big endian systems now be 32-bit libraries?
- Can you please add a test case and a patch with full context before this 
patch can go any further?


Repository:
  rC Clang

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

https://reviews.llvm.org/D55326



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

[PATCH] D48044: [Power9] Update fp128 as a valid homogenous aggregate base type

[Nemanja Ivanovic via Phabricator via cfe-commits]

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

Other than a few style nits that can be fixed on the commit, this LGTM.




Comment at: include/clang/AST/Type.h:1802
   bool isFloat16Type() const;  // C11 extension ISO/IEC TS 18661
+  bool isFloat128Type() const;
   bool isRealType() const; // C99 6.2.5p17 (real floating + integer)

// IEEE 754 binary128



Comment at: lib/CodeGen/TargetInfo.cpp:4609
   // Homogeneous aggregates for ELFv2 must have base types of float,
   // double, long double, or 128-bit vectors.
   if (const BuiltinType *BT = Ty->getAs()) {

This comment should probably be updated.



Comment at: lib/CodeGen/TargetInfo.cpp:4633
   uint32_t NumRegs =
-  Base->isVectorType() ? 1 : (getContext().getTypeSize(Base) + 63) / 64;
+  ((getContext().getTargetInfo().hasFloat128Type() &&
+  Base->isFloat128Type()) ||

This expression looks very messy, I think it's probably better to rewrite it as 
multiple expressions or an `if` statement.



Comment at: test/CodeGen/ppc64le-f128Aggregates.c:19
+
+struct fp2a2b { __float128 a[2]; __float128 b[2]; };
+

Is it still a homogeneous aggregate if it's nested?
i.e. `struct fp10 { struct fp2 a, struct fp3 b };`

And if so, should we add that to the test?


https://reviews.llvm.org/D48044



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

[PATCH] D49424: [PowerPC] Handle __builtin_xxpermdi the same way as GCC does

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai created this revision.
nemanjai added reviewers: lu-zero, hfinkel.
Herald added a subscriber: kbarton.

The codegen for this builtin was initially implemented to match GCC. However, 
due to interest from users GCC changed behaviour to account for the big endian 
bias of the instruction and correct it. This patch brings the handling inline 
with GCC.


Repository:
  rC Clang

https://reviews.llvm.org/D49424

Files:
  lib/CodeGen/CGBuiltin.cpp
  test/CodeGen/builtins-ppc-vsx.c


Index: test/CodeGen/builtins-ppc-vsx.c
===
--- test/CodeGen/builtins-ppc-vsx.c
+++ test/CodeGen/builtins-ppc-vsx.c
@@ -1694,43 +1694,43 @@
 
 res_vd = vec_xxpermdi(vd, vd, 0);
 // CHECK: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
-// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
+// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
 
 res_vf = vec_xxpermdi(vf, vf, 1);
 // CHECK: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
-// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
+// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
 
 res_vsll = vec_xxpermdi(vsll, vsll, 2);
 // CHECK: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
-// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
+// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
 
 res_vull = vec_xxpermdi(vull, vull, 3);
 // CHECK: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
-// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
+// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
 
 res_vsi = vec_xxpermdi(vsi, vsi, 0);
 // CHECK: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
-// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
+// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
 
 res_vui = vec_xxpermdi(vui, vui, 1);
 // CHECK: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
-// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
+// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
 
 res_vss = vec_xxpermdi(vss, vss, 2);
 // CHECK: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
-// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
+// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
 
 res_vus = vec_xxpermdi(vus, vus, 3);
 // CHECK: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
-// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
+// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
 
 res_vsc = vec_xxpermdi(vsc, vsc, 0);
 // CHECK: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
-// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
+// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
 
 res_vuc = vec_xxpermdi(vuc, vuc, 1);
 // CHECK: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
-// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
+// CHECK-LE: shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, <2 x 
i32> 
 
 res_vd = vec_xxsldwi(vd, vd, 0);
 // CHECK: shufflevector <4 x i32> %{{[0-9]+}}, <4 x i32> %{{[0-9]+}}, <4 x 
i32> 
@@ -1786,7 +1786,7 @@
 
 // CHECK-LE:  bitcast <4 x i32> %{{[0-9]+}} to <2 x i64>
 // CHECK-LE-NEXT:  bitcast <4 x i32> %{{[0-9]+}} to <2 x i64>
-// CHECK-LE-NEXT:  shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, 
<2 x i32> 
+// CHECK-LE-NEXT:  shufflevector <2 x i64> %{{[0-9]+}}, <2 x i64> %{{[0-9]+}}, 
<2 x i32> 
 // CHECK-LE-NEXT:  bitcast <2 x i64> %{{[0-9]+}} to <4 x i32>
 }
 
Index: lib/CodeGen/CGBuiltin.cpp
===
--- lib/CodeGen/CGBuiltin.cpp
+++ lib/CodeGen/CGBuiltin.cpp
@@ -10778,15 +10778,8 @@
 // the second. The element indices within each vector are numbered in big
 // endian order so the shuffle mask must be adjusted for this on little
 // endian platforms (i.e. index is complemented and source vector 
reversed).
-unsigned ElemIdx0;
-unsigned ElemIdx1;
-if (getTarget().isLittleEndian()) {
-  ElemIdx0 = (~Index & 1) + 2;
-  ElemIdx1 = (~Index & 2) >> 1;
-} else { // BigEndian
-  ElemIdx0 = (Index & 2) >> 1;
-  ElemIdx1 = 2 + (Index & 1);
-}
+unsigned ElemIdx0 = (Index & 2) >> 1;;
+unsigned ElemIdx1 = 2 + (Index & 1);;
 
 Constant *ShuffleElts[2] = {ConstantInt::get(Int32Ty,

[PATCH] D49424: [PowerPC] Handle __builtin_xxpermdi the same way as GCC does

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added inline comments.



Comment at: lib/CodeGen/CGBuiltin.cpp:10780
 // endian order so the shuffle mask must be adjusted for this on little
 // endian platforms (i.e. index is complemented and source vector 
reversed).
+unsigned ElemIdx0 = (Index & 2) >> 1;;

efriedma wrote:
> Please fix the comment.
Ah yes. Good catch. Thanks Eli. I'll fix up the comment on the commit.


Repository:
  rC Clang

https://reviews.llvm.org/D49424



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

[PATCH] D80300: [Driver] Add DEFAULT_DYLD_PREFIX and DEFAULT_RPATH to complement DEFAULT_SYSROOT

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai accepted this revision.
nemanjai added subscribers: tstellar, brad, craig.topper, joerg.
nemanjai added a comment.
This revision is now accepted and ready to land.

Thank you for sorting this out. I think it is quite useful to be able to 
configure the compiler to use complete non-standard toolchains that include a 
dynamic linker.
Could you please ensure that the commit message describes that the 
`--dyld-prefix` option is added to test cases since they check for the dynamic 
linker and would fail on builds that specify a default prefix?
Also, you might want to add someone from some of the other targets/platforms as 
a reviewer to ensure there is no objections (perhaps @craig.topper, @tstellar, 
@brad or @joerg).

LGTM but maybe give others a few days to have a look.




Comment at: clang/lib/Driver/ToolChains/Gnu.cpp:452
   CmdArgs.push_back("-dynamic-linker");
-  CmdArgs.push_back(Args.MakeArgString(Loader));
+  CmdArgs.push_back(Args.MakeArgString(Twine(D.DyldPrefix) +
+   ToolChain.getDynamicLinker(Args)));

Is this just an orthogonal NFC change? If so, can you please commit it 
separately in an NFC commit?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80300



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

[PATCH] D80374: [Clang] Enable KF and KC mode for [_Complex] __float128

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai created this revision.
nemanjai added reviewers: rjmccall, rsmith, PowerPC, hfinkel.
Herald added subscribers: dexonsmith, kbarton.
Herald added a reviewer: aaron.ballman.
Herald added a project: clang.

The headers provided with recent GNU toolchains for PPC have code that includes 
typedefs such as:
`typedef _Complex float __cfloat128 __attribute__ ((__mode__ (__KC__)))`

Also, when I added `__float128`, I neglected to add support for `_Complex 
__float128` altogether. This patch fixes those oversights and allows clang to 
compile something like:

  #include 
  _Complex __float128 testkf(_Complex __float128 a, _Complex __float128 b) {
return a + b;
  }

with `-mfloat128` which it currently fails to compile due to the two reasons 
listed above.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80374

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Sema/DeclSpec.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGen/ppc64-complex-parms.c
  clang/test/CodeGen/ppc64-complex-return.c
  clang/test/Sema/attr-mode.c

Index: clang/test/Sema/attr-mode.c
===
--- clang/test/Sema/attr-mode.c
+++ clang/test/Sema/attr-mode.c
@@ -4,6 +4,8 @@
 // RUN:   -verify %s
 // RUN: %clang_cc1 -triple powerpc64-pc-linux-gnu -DTEST_64BIT_PPC64 -fsyntax-only \
 // RUN:   -verify %s
+// RUN: %clang_cc1 -triple powerpc64-pc-linux-gnu -DTEST_F128_PPC64 -fsyntax-only \
+// RUN:   -verify -target-feature +float128 %s
 // RUN: %clang_cc1 -triple x86_64-pc-linux-gnux32 -DTEST_64BIT_X86 -fsyntax-only \
 // RUN:   -verify %s
 // RUN: %clang_cc1 -triple mips-linux-gnu -DTEST_MIPS_32 -fsyntax-only \
@@ -90,6 +92,13 @@
 void f_ft128_complex_arg(_Complex long double *x);
 void test_TFtype(f128ibm *a) { f_ft128_arg (a); }
 void test_TCtype(c128ibm *a) { f_ft128_complex_arg (a); }
+#elif TEST_F128_PPC64
+typedef _Complex float cf128 __attribute__ ((mode (KC)));
+typedef float f128 __attribute__ ((mode (KF)));
+void f_f128_arg(__float128 *x);
+void f_f128_complex_arg(_Complex __float128 *x);
+void test_KFtype(f128 *a) { f_f128_arg (a); }
+void test_KCtype(cf128 *a) { f_f128_complex_arg (a); }
 #elif TEST_MIPS_32
 typedef unsigned int gcc_unwind_word __attribute__((mode(unwind_word)));
 int foo[sizeof(gcc_unwind_word) == 4 ? 1 : -1];
Index: clang/test/CodeGen/ppc64-complex-return.c
===
--- clang/test/CodeGen/ppc64-complex-return.c
+++ clang/test/CodeGen/ppc64-complex-return.c
@@ -1,9 +1,20 @@
 // REQUIRES: powerpc-registered-target
 // RUN: %clang_cc1 -triple powerpc64-unknown-linux-gnu -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -target-feature +float128 -DTEST_F128 -triple \
+// RUN:   powerpc64le-unknown-linux-gnu -emit-llvm -o - %s | FileCheck %s \
+// RUN:   --check-prefix CHECK-F128
 
 float crealf(_Complex float);
 double creal(_Complex double);
 long double creall(_Complex long double);
+#ifdef TEST_F128
+__float128 crealf128(_Complex __float128);
+_Complex __float128 foo_f128(_Complex __float128 x) {
+  return x;
+}
+
+// CHECK-F128: define { fp128, fp128 } @foo_f128(fp128 {{[%A-Za-z0-9.]+}}, fp128 {{[%A-Za-z0-9.]+}}) [[NUW:#[0-9]+]] {
+#endif
 
 _Complex float foo_float(_Complex float x) {
   return x;
@@ -80,6 +91,17 @@
 // CHECK: extractvalue { ppc_fp128, ppc_fp128 } [[VAR3]], 0
 // CHECK: extractvalue { ppc_fp128, ppc_fp128 } [[VAR3]], 1
 
+#ifdef TEST_F128
+__float128 bar_f128(void) {
+  return crealf128(foo_f128(2.0Q - 2.5Qi));
+}
+
+// CHECK-F128: define fp128 @bar_f128() [[NUW]] {
+// CHECK-F128: [[VAR3:[%A-Za-z0-9.]+]] = call { fp128, fp128 } @foo_f128
+// CHECK-F128: extractvalue { fp128, fp128 } [[VAR3]], 0
+// CHECK-F128: extractvalue { fp128, fp128 } [[VAR3]], 1
+#endif
+
 int bar_int(void) {
   return __real__(foo_int(2 - 3i));
 }
Index: clang/test/CodeGen/ppc64-complex-parms.c
===
--- clang/test/CodeGen/ppc64-complex-parms.c
+++ clang/test/CodeGen/ppc64-complex-parms.c
@@ -1,8 +1,20 @@
+// REQUIRES: powerpc-registered-target
 // RUN: %clang_cc1 -triple powerpc64-unknown-linux-gnu -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -target-feature +float128 -DTEST_F128 -triple \
+// RUN:   powerpc64le-unknown-linux-gnu -emit-llvm -o - %s | FileCheck %s \
+// RUN:   --check-prefix CHECK-F128
 
 float crealf(_Complex float);
 double creal(_Complex double);
 long double creall(_Complex long double);
+#ifdef TEST_F128
+__float128 crealf128(_Complex __float128);
+__float128 foo_f128(_Complex __float128 x) {
+  return crealf128(x);
+}
+// CHECK-F128: define fp128 @foo_f128(fp128 {{[%A-Za-z0-9.]+}}, fp128 {{[%A-Za-z0-9.]+}})
+#endif
+
 
 float foo_float(_Complex float x) {
   return crealf(x);
Index: clang/lib/Sema/SemaDeclAttr.cpp

[PATCH] D80294: Add support for vmsumudm

[Nemanja Ivanovic via Phabricator via cfe-commits]

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

LGTM.


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

https://reviews.llvm.org/D80294



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

[PATCH] D77542: [PowerPC] Treat 'Z' inline asm constraint as a true memory constraint

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai marked an inline comment as done.
nemanjai added inline comments.



Comment at: clang/test/CodeGen/ppc64-inline-asm.c:50
+// CHECK-LABEL: void @testZwOff(i8* %addr, i64 %off)
+// CHEC: %[[VAL:[^ ]+]] = getelementptr i8, i8* %addr, i64 %off
+// CHEC: call void asm sideeffect "dcbz ${0:y}\0A", "*Z,~{memory}"(i8* 
%[[VAL]])

amyk wrote:
> Missing a `k` in `CHECK`?
Great catch! Thank you.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77542



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

[PATCH] D77542: [PowerPC] Treat 'Z' inline asm constraint as a true memory constraint

[Nemanja Ivanovic via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGaede24ecaa08: [PowerPC] Treat 'Z' inline asm 
constraint as a true memory constraint (authored by nemanjai).

Changed prior to commit:
  https://reviews.llvm.org/D77542?vs=255291&id=265730#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77542

Files:
  clang/lib/Basic/Targets/PPC.h
  clang/test/CodeGen/ppc64-inline-asm.c


Index: clang/test/CodeGen/ppc64-inline-asm.c
===
--- clang/test/CodeGen/ppc64-inline-asm.c
+++ clang/test/CodeGen/ppc64-inline-asm.c
@@ -37,3 +37,16 @@
 // CHECK-LABEL: double @test_fmax(double %x, double %y)
 // CHECK: call double asm "xsmaxdp ${0:x}, ${1:x}, ${2:x}", 
"=^ws,^ws,^ws"(double %x, double %y)
 }
+
+void testZ(void *addr) {
+  asm volatile ("dcbz %y0\n" :: "Z"(*(unsigned char *)addr) : "memory");
+// CHECK-LABEL: void @testZ(i8* %addr)
+// CHECK: call void asm sideeffect "dcbz ${0:y}\0A", "*Z,~{memory}"(i8* %addr)
+}
+
+void testZwOff(void *addr, long long off) {
+  asm volatile ("dcbz %y0\n" :: "Z"(*(unsigned char *)(addr + off)) : 
"memory");
+// CHECK-LABEL: void @testZwOff(i8* %addr, i64 %off)
+// CHECK: %[[VAL:[^ ]+]] = getelementptr i8, i8* %addr, i64 %off
+// CHECK: call void asm sideeffect "dcbz ${0:y}\0A", "*Z,~{memory}"(i8* 
%[[VAL]])
+}
Index: clang/lib/Basic/Targets/PPC.h
===
--- clang/lib/Basic/Targets/PPC.h
+++ clang/lib/Basic/Targets/PPC.h
@@ -276,11 +276,12 @@
   break;
 case 'Q': // Memory operand that is an offset from a register (it is
   // usually better to use `m' or `es' in asm statements)
+  Info.setAllowsRegister();
+  LLVM_FALLTHROUGH;
 case 'Z': // Memory operand that is an indexed or indirect from a
   // register (it is usually better to use `m' or `es' in
   // asm statements)
   Info.setAllowsMemory();
-  Info.setAllowsRegister();
   break;
 case 'R': // AIX TOC entry
 case 'a': // Address operand that is an indexed or indirect from a


Index: clang/test/CodeGen/ppc64-inline-asm.c
===
--- clang/test/CodeGen/ppc64-inline-asm.c
+++ clang/test/CodeGen/ppc64-inline-asm.c
@@ -37,3 +37,16 @@
 // CHECK-LABEL: double @test_fmax(double %x, double %y)
 // CHECK: call double asm "xsmaxdp ${0:x}, ${1:x}, ${2:x}", "=^ws,^ws,^ws"(double %x, double %y)
 }
+
+void testZ(void *addr) {
+  asm volatile ("dcbz %y0\n" :: "Z"(*(unsigned char *)addr) : "memory");
+// CHECK-LABEL: void @testZ(i8* %addr)
+// CHECK: call void asm sideeffect "dcbz ${0:y}\0A", "*Z,~{memory}"(i8* %addr)
+}
+
+void testZwOff(void *addr, long long off) {
+  asm volatile ("dcbz %y0\n" :: "Z"(*(unsigned char *)(addr + off)) : "memory");
+// CHECK-LABEL: void @testZwOff(i8* %addr, i64 %off)
+// CHECK: %[[VAL:[^ ]+]] = getelementptr i8, i8* %addr, i64 %off
+// CHECK: call void asm sideeffect "dcbz ${0:y}\0A", "*Z,~{memory}"(i8* %[[VAL]])
+}
Index: clang/lib/Basic/Targets/PPC.h
===
--- clang/lib/Basic/Targets/PPC.h
+++ clang/lib/Basic/Targets/PPC.h
@@ -276,11 +276,12 @@
   break;
 case 'Q': // Memory operand that is an offset from a register (it is
   // usually better to use `m' or `es' in asm statements)
+  Info.setAllowsRegister();
+  LLVM_FALLTHROUGH;
 case 'Z': // Memory operand that is an indexed or indirect from a
   // register (it is usually better to use `m' or `es' in
   // asm statements)
   Info.setAllowsMemory();
-  Info.setAllowsRegister();
   break;
 case 'R': // AIX TOC entry
 case 'a': // Address operand that is an indexed or indirect from a
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D80533: [Clang] Enable _Complex __float

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai created this revision.
nemanjai added reviewers: rjmccall, rsmith, PowerPC.
Herald added a subscriber: kbarton.
Herald added a project: clang.

When I added `__float128` a while ago, I neglected to add support for the 
complex variant of the type. This patch just adds that.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80533

Files:
  clang/lib/Sema/DeclSpec.cpp
  clang/test/CodeGen/ppc64-complex-parms.c
  clang/test/CodeGen/ppc64-complex-return.c


Index: clang/test/CodeGen/ppc64-complex-return.c
===
--- clang/test/CodeGen/ppc64-complex-return.c
+++ clang/test/CodeGen/ppc64-complex-return.c
@@ -1,9 +1,20 @@
 // REQUIRES: powerpc-registered-target
 // RUN: %clang_cc1 -triple powerpc64-unknown-linux-gnu -emit-llvm -o - %s | 
FileCheck %s
+// RUN: %clang_cc1 -target-feature +float128 -DTEST_F128 -triple \
+// RUN:   powerpc64le-unknown-linux-gnu -emit-llvm -o - %s | FileCheck %s \
+// RUN:   --check-prefix CHECK-F128
 
 float crealf(_Complex float);
 double creal(_Complex double);
 long double creall(_Complex long double);
+#ifdef TEST_F128
+__float128 crealf128(_Complex __float128);
+_Complex __float128 foo_f128(_Complex __float128 x) {
+  return x;
+}
+
+// CHECK-F128: define { fp128, fp128 } @foo_f128(fp128 {{[%A-Za-z0-9.]+}}, 
fp128 {{[%A-Za-z0-9.]+}}) [[NUW:#[0-9]+]] {
+#endif
 
 _Complex float foo_float(_Complex float x) {
   return x;
@@ -80,6 +91,17 @@
 // CHECK: extractvalue { ppc_fp128, ppc_fp128 } [[VAR3]], 0
 // CHECK: extractvalue { ppc_fp128, ppc_fp128 } [[VAR3]], 1
 
+#ifdef TEST_F128
+__float128 bar_f128(void) {
+  return crealf128(foo_f128(2.0Q - 2.5Qi));
+}
+
+// CHECK-F128: define fp128 @bar_f128() [[NUW]] {
+// CHECK-F128: [[VAR3:[%A-Za-z0-9.]+]] = call { fp128, fp128 } @foo_f128
+// CHECK-F128: extractvalue { fp128, fp128 } [[VAR3]], 0
+// CHECK-F128: extractvalue { fp128, fp128 } [[VAR3]], 1
+#endif
+
 int bar_int(void) {
   return __real__(foo_int(2 - 3i));
 }
Index: clang/test/CodeGen/ppc64-complex-parms.c
===
--- clang/test/CodeGen/ppc64-complex-parms.c
+++ clang/test/CodeGen/ppc64-complex-parms.c
@@ -1,8 +1,19 @@
+// REQUIRES: powerpc-registered-target
 // RUN: %clang_cc1 -triple powerpc64-unknown-linux-gnu -emit-llvm -o - %s | 
FileCheck %s
+// RUN: %clang_cc1 -target-feature +float128 -DTEST_F128 -triple \
+// RUN:   powerpc64le-unknown-linux-gnu -emit-llvm -o - %s | FileCheck %s \
+// RUN:   --check-prefix CHECK-F128
 
 float crealf(_Complex float);
 double creal(_Complex double);
 long double creall(_Complex long double);
+#ifdef TEST_F128
+__float128 crealf128(_Complex __float128);
+__float128 foo_f128(_Complex __float128 x) {
+  return crealf128(x);
+}
+// CHECK-F128: define fp128 @foo_f128(fp128 {{[%A-Za-z0-9.]+}}, fp128 
{{[%A-Za-z0-9.]+}})
+#endif
 
 float foo_float(_Complex float x) {
   return crealf(x);
Index: clang/lib/Sema/DeclSpec.cpp
===
--- clang/lib/Sema/DeclSpec.cpp
+++ clang/lib/Sema/DeclSpec.cpp
@@ -1269,7 +1269,8 @@
   // Note that this intentionally doesn't include _Complex _Bool.
   if (!S.getLangOpts().CPlusPlus)
 S.Diag(TSTLoc, diag::ext_integer_complex);
-} else if (TypeSpecType != TST_float && TypeSpecType != TST_double) {
+} else if (TypeSpecType != TST_float && TypeSpecType != TST_double &&
+   TypeSpecType != TST_float128) {
   S.Diag(TSCLoc, diag::err_invalid_complex_spec)
 << getSpecifierName((TST)TypeSpecType, Policy);
   TypeSpecComplex = TSC_unspecified;


Index: clang/test/CodeGen/ppc64-complex-return.c
===
--- clang/test/CodeGen/ppc64-complex-return.c
+++ clang/test/CodeGen/ppc64-complex-return.c
@@ -1,9 +1,20 @@
 // REQUIRES: powerpc-registered-target
 // RUN: %clang_cc1 -triple powerpc64-unknown-linux-gnu -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -target-feature +float128 -DTEST_F128 -triple \
+// RUN:   powerpc64le-unknown-linux-gnu -emit-llvm -o - %s | FileCheck %s \
+// RUN:   --check-prefix CHECK-F128
 
 float crealf(_Complex float);
 double creal(_Complex double);
 long double creall(_Complex long double);
+#ifdef TEST_F128
+__float128 crealf128(_Complex __float128);
+_Complex __float128 foo_f128(_Complex __float128 x) {
+  return x;
+}
+
+// CHECK-F128: define { fp128, fp128 } @foo_f128(fp128 {{[%A-Za-z0-9.]+}}, fp128 {{[%A-Za-z0-9.]+}}) [[NUW:#[0-9]+]] {
+#endif
 
 _Complex float foo_float(_Complex float x) {
   return x;
@@ -80,6 +91,17 @@
 // CHECK: extractvalue { ppc_fp128, ppc_fp128 } [[VAR3]], 0
 // CHECK: extractvalue { ppc_fp128, ppc_fp128 } [[VAR3]], 1
 
+#ifdef TEST_F128
+__float128 bar_f128(void) {
+  return crealf128(foo_f128(2.0Q - 2.5Qi));
+}
+
+// CHECK-F128: define fp128 @bar_f128() [[NUW]] {
+// CHECK-F128: [[VAR3:[%A-Za-z0-9.]+]] = call { fp128, fp128 } @foo_f128
+// CHECK-F12

[PATCH] D80374: [Clang] Enable KF and KC mode for [_Complex] __float128

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

The support for `_Complex __float128` in https://reviews.llvm.org/D80533
I will repurpose leave only the addition of the `KF/KC` modes in this patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80374



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

[PATCH] D80374: [Clang] Enable KF and KC mode for [_Complex] __float128

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai updated this revision to Diff 266092.
nemanjai added a comment.

Remove handling for explicit `_Complex __float128`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80374

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Sema/attr-mode.c

Index: clang/test/Sema/attr-mode.c
===
--- clang/test/Sema/attr-mode.c
+++ clang/test/Sema/attr-mode.c
@@ -4,6 +4,8 @@
 // RUN:   -verify %s
 // RUN: %clang_cc1 -triple powerpc64-pc-linux-gnu -DTEST_64BIT_PPC64 -fsyntax-only \
 // RUN:   -verify %s
+// RUN: %clang_cc1 -triple powerpc64-pc-linux-gnu -DTEST_F128_PPC64 -fsyntax-only \
+// RUN:   -verify -target-feature +float128 %s
 // RUN: %clang_cc1 -triple x86_64-pc-linux-gnux32 -DTEST_64BIT_X86 -fsyntax-only \
 // RUN:   -verify %s
 // RUN: %clang_cc1 -triple mips-linux-gnu -DTEST_MIPS_32 -fsyntax-only \
@@ -90,6 +92,13 @@
 void f_ft128_complex_arg(_Complex long double *x);
 void test_TFtype(f128ibm *a) { f_ft128_arg (a); }
 void test_TCtype(c128ibm *a) { f_ft128_complex_arg (a); }
+#elif TEST_F128_PPC64
+typedef _Complex float cf128 __attribute__ ((mode (KC)));
+typedef float f128 __attribute__ ((mode (KF)));
+void f_f128_arg(__float128 *x);
+void f_f128_complex_arg(_Complex __float128 *x);
+void test_KFtype(f128 *a) { f_f128_arg (a); }
+void test_KCtype(cf128 *a) { f_f128_complex_arg (a); }
 #elif TEST_MIPS_32
 typedef unsigned int gcc_unwind_word __attribute__((mode(unwind_word)));
 int foo[sizeof(gcc_unwind_word) == 4 ? 1 : -1];
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -3942,7 +3942,8 @@
 /// parseModeAttrArg - Parses attribute mode string and returns parsed type
 /// attribute.
 static void parseModeAttrArg(Sema &S, StringRef Str, unsigned &DestWidth,
- bool &IntegerMode, bool &ComplexMode) {
+ bool &IntegerMode, bool &ComplexMode,
+ bool &ExplicitIEEE) {
   IntegerMode = true;
   ComplexMode = false;
   switch (Str.size()) {
@@ -3963,7 +3964,12 @@
 case 'X':
   DestWidth = 96;
   break;
+case 'K': // KFmode - IEEE quad precision (__float128)
+  ExplicitIEEE = true;
+  DestWidth = 128;
+  break;
 case 'T':
+  ExplicitIEEE = false;
   DestWidth = 128;
   break;
 }
@@ -4024,6 +4030,7 @@
   unsigned DestWidth = 0;
   bool IntegerMode = true;
   bool ComplexMode = false;
+  bool ExplicitIEEE = false;
   llvm::APInt VectorSize(64, 0);
   if (Str.size() >= 4 && Str[0] == 'V') {
 // Minimal length of vector mode is 4: 'V' + NUMBER(>=1) + TYPE(>=2).
@@ -4036,7 +4043,7 @@
 !Str.substr(1, VectorStringLength).getAsInteger(10, VectorSize) &&
 VectorSize.isPowerOf2()) {
   parseModeAttrArg(*this, Str.substr(VectorStringLength + 1), DestWidth,
-   IntegerMode, ComplexMode);
+   IntegerMode, ComplexMode, ExplicitIEEE);
   // Avoid duplicate warning from template instantiation.
   if (!InInstantiation)
 Diag(AttrLoc, diag::warn_vector_mode_deprecated);
@@ -4046,7 +4053,8 @@
   }
 
   if (!VectorSize)
-parseModeAttrArg(*this, Str, DestWidth, IntegerMode, ComplexMode);
+parseModeAttrArg(*this, Str, DestWidth, IntegerMode, ComplexMode,
+ ExplicitIEEE);
 
   // FIXME: Sync this with InitializePredefinedMacros; we need to match int8_t
   // and friends, at least with glibc.
@@ -4112,7 +4120,7 @@
 NewElemTy = Context.getIntTypeForBitwidth(DestWidth,
   OldElemTy->isSignedIntegerType());
   else
-NewElemTy = Context.getRealTypeForBitwidth(DestWidth);
+NewElemTy = Context.getRealTypeForBitwidth(DestWidth, ExplicitIEEE);
 
   if (NewElemTy.isNull()) {
 Diag(AttrLoc, diag::err_machine_mode) << 1 /*Unsupported*/ << Name;
Index: clang/lib/Basic/TargetInfo.cpp
===
--- clang/lib/Basic/TargetInfo.cpp
+++ clang/lib/Basic/TargetInfo.cpp
@@ -265,7 +265,8 @@
   return NoInt;
 }
 
-TargetInfo::RealType TargetInfo::getRealTypeByWidth(unsigned BitWidth) const {
+TargetInfo::RealType TargetInfo::getRealTypeByWidth(unsigned BitWidth,
+bool ExplicitIEEE) const {
   if (getFloatWidth() == BitWidth)
 return Float;
   if (getDoubleWidth() == BitWidth)
@@ -277,6 +278,10 @@
   return LongDouble;
 break;
   case 128:
+// The caller explicitly asked for an IEEE compliant type but we still
+// have to check if the target supports it.
+if (ExplicitIEEE)
+  return hasFloat128Type() ? Float12

[PATCH] D80020: [PowerPC] Add support for -mcpu=pwr10 in both clang and llvm

[Nemanja Ivanovic via Phabricator via cfe-commits]

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

LGTM aside from a couple of minor nits.




Comment at: clang/lib/Basic/Targets/PPC.cpp:319
 .Case("ppc64le", true)
+.Case("pwr10", true)
 .Case("pwr9", true)

Please remove this since HTM was removed in P10.



Comment at: clang/test/Preprocessor/init-ppc64.c:644
+// PPCPOWER10:#define _ARCH_PWR7 1
+// PPCPOWER10:#define _ARCH_PWR9 1
+//

I am not sure what the story is with not checking for `_ARCH_PWR8` for the P9 
test, but I don't think we need to continue that precedent.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80020



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

[PATCH] D80374: [Clang] Enable KF and KC mode for [_Complex] __float128

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai updated this revision to Diff 266820.
nemanjai added a comment.

Handled invalid uses of `KI` as there is no corresponding integer mode and 
added testing for it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80374

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Sema/attr-mode.c

Index: clang/test/Sema/attr-mode.c
===
--- clang/test/Sema/attr-mode.c
+++ clang/test/Sema/attr-mode.c
@@ -4,6 +4,8 @@
 // RUN:   -verify %s
 // RUN: %clang_cc1 -triple powerpc64-pc-linux-gnu -DTEST_64BIT_PPC64 -fsyntax-only \
 // RUN:   -verify %s
+// RUN: %clang_cc1 -triple powerpc64-pc-linux-gnu -DTEST_F128_PPC64 -fsyntax-only \
+// RUN:   -verify -target-feature +float128 %s
 // RUN: %clang_cc1 -triple x86_64-pc-linux-gnux32 -DTEST_64BIT_X86 -fsyntax-only \
 // RUN:   -verify %s
 // RUN: %clang_cc1 -triple mips-linux-gnu -DTEST_MIPS_32 -fsyntax-only \
@@ -90,6 +92,15 @@
 void f_ft128_complex_arg(_Complex long double *x);
 void test_TFtype(f128ibm *a) { f_ft128_arg (a); }
 void test_TCtype(c128ibm *a) { f_ft128_complex_arg (a); }
+#elif TEST_F128_PPC64
+typedef int invalid_7 __attribute((mode(KF))); // expected-error{{type of machine mode does not match type of base type}}
+typedef int invalid_8 __attribute((mode(KI))); // expected-error{{unknown machine mode}}
+typedef _Complex float cf128 __attribute__((mode(KC)));
+typedef float f128 __attribute__((mode(KF)));
+void f_f128_arg(__float128 *x);
+void f_f128_complex_arg(_Complex __float128 *x);
+void test_KFtype(f128 *a) { f_f128_arg(a); }
+void test_KCtype(cf128 *a) { f_f128_complex_arg(a); }
 #elif TEST_MIPS_32
 typedef unsigned int gcc_unwind_word __attribute__((mode(unwind_word)));
 int foo[sizeof(gcc_unwind_word) == 4 ? 1 : -1];
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -3942,7 +3942,8 @@
 /// parseModeAttrArg - Parses attribute mode string and returns parsed type
 /// attribute.
 static void parseModeAttrArg(Sema &S, StringRef Str, unsigned &DestWidth,
- bool &IntegerMode, bool &ComplexMode) {
+ bool &IntegerMode, bool &ComplexMode,
+ bool &ExplicitIEEE) {
   IntegerMode = true;
   ComplexMode = false;
   switch (Str.size()) {
@@ -3963,7 +3964,12 @@
 case 'X':
   DestWidth = 96;
   break;
+case 'K': // KFmode - IEEE quad precision (__float128)
+  ExplicitIEEE = true;
+  DestWidth = Str[1] == 'I' ? 0 : 128;
+  break;
 case 'T':
+  ExplicitIEEE = false;
   DestWidth = 128;
   break;
 }
@@ -4024,6 +4030,7 @@
   unsigned DestWidth = 0;
   bool IntegerMode = true;
   bool ComplexMode = false;
+  bool ExplicitIEEE = false;
   llvm::APInt VectorSize(64, 0);
   if (Str.size() >= 4 && Str[0] == 'V') {
 // Minimal length of vector mode is 4: 'V' + NUMBER(>=1) + TYPE(>=2).
@@ -4036,7 +4043,7 @@
 !Str.substr(1, VectorStringLength).getAsInteger(10, VectorSize) &&
 VectorSize.isPowerOf2()) {
   parseModeAttrArg(*this, Str.substr(VectorStringLength + 1), DestWidth,
-   IntegerMode, ComplexMode);
+   IntegerMode, ComplexMode, ExplicitIEEE);
   // Avoid duplicate warning from template instantiation.
   if (!InInstantiation)
 Diag(AttrLoc, diag::warn_vector_mode_deprecated);
@@ -4046,7 +4053,8 @@
   }
 
   if (!VectorSize)
-parseModeAttrArg(*this, Str, DestWidth, IntegerMode, ComplexMode);
+parseModeAttrArg(*this, Str, DestWidth, IntegerMode, ComplexMode,
+ ExplicitIEEE);
 
   // FIXME: Sync this with InitializePredefinedMacros; we need to match int8_t
   // and friends, at least with glibc.
@@ -4112,7 +4120,7 @@
 NewElemTy = Context.getIntTypeForBitwidth(DestWidth,
   OldElemTy->isSignedIntegerType());
   else
-NewElemTy = Context.getRealTypeForBitwidth(DestWidth);
+NewElemTy = Context.getRealTypeForBitwidth(DestWidth, ExplicitIEEE);
 
   if (NewElemTy.isNull()) {
 Diag(AttrLoc, diag::err_machine_mode) << 1 /*Unsupported*/ << Name;
Index: clang/lib/Basic/TargetInfo.cpp
===
--- clang/lib/Basic/TargetInfo.cpp
+++ clang/lib/Basic/TargetInfo.cpp
@@ -265,7 +265,8 @@
   return NoInt;
 }
 
-TargetInfo::RealType TargetInfo::getRealTypeByWidth(unsigned BitWidth) const {
+TargetInfo::RealType TargetInfo::getRealTypeByWidth(unsigned BitWidth,
+bool ExplicitIEEE) const {
   if (getFloatWidth() == BitWidth)
 return Float;
   if (getDoubleWidth() =

[PATCH] D80374: [Clang] Enable KF and KC mode for [_Complex] __float128

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai marked 3 inline comments as done.
nemanjai added inline comments.



Comment at: clang/lib/Sema/SemaDeclAttr.cpp:3970
+  DestWidth = 128;
+  break;
 case 'T':

rjmccall wrote:
> rjmccall wrote:
> > Are there interactions with the other mode specifiers?  For example, should 
> > this be allowed with integer modes?  If so, I think this needs more tests.
> I shouldn't have said "if so" — *either way*, this needs more tests.
Very good point. Thank you. Added.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80374



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

[PATCH] D80533: [Clang] Enable _Complex __float

[Nemanja Ivanovic via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGf9e94eb8688d: [Clang] Enable _Complex __float128 (authored 
by nemanjai).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80533

Files:
  clang/lib/Sema/DeclSpec.cpp
  clang/test/CodeGen/ppc64-complex-parms.c
  clang/test/CodeGen/ppc64-complex-return.c


Index: clang/test/CodeGen/ppc64-complex-return.c
===
--- clang/test/CodeGen/ppc64-complex-return.c
+++ clang/test/CodeGen/ppc64-complex-return.c
@@ -1,9 +1,20 @@
 // REQUIRES: powerpc-registered-target
 // RUN: %clang_cc1 -triple powerpc64-unknown-linux-gnu -emit-llvm -o - %s | 
FileCheck %s
+// RUN: %clang_cc1 -target-feature +float128 -DTEST_F128 -triple \
+// RUN:   powerpc64le-unknown-linux-gnu -emit-llvm -o - %s | FileCheck %s \
+// RUN:   --check-prefix CHECK-F128
 
 float crealf(_Complex float);
 double creal(_Complex double);
 long double creall(_Complex long double);
+#ifdef TEST_F128
+__float128 crealf128(_Complex __float128);
+_Complex __float128 foo_f128(_Complex __float128 x) {
+  return x;
+}
+
+// CHECK-F128: define { fp128, fp128 } @foo_f128(fp128 {{[%A-Za-z0-9.]+}}, 
fp128 {{[%A-Za-z0-9.]+}}) [[NUW:#[0-9]+]] {
+#endif
 
 _Complex float foo_float(_Complex float x) {
   return x;
@@ -80,6 +91,17 @@
 // CHECK: extractvalue { ppc_fp128, ppc_fp128 } [[VAR3]], 0
 // CHECK: extractvalue { ppc_fp128, ppc_fp128 } [[VAR3]], 1
 
+#ifdef TEST_F128
+__float128 bar_f128(void) {
+  return crealf128(foo_f128(2.0Q - 2.5Qi));
+}
+
+// CHECK-F128: define fp128 @bar_f128() [[NUW]] {
+// CHECK-F128: [[VAR3:[%A-Za-z0-9.]+]] = call { fp128, fp128 } @foo_f128
+// CHECK-F128: extractvalue { fp128, fp128 } [[VAR3]], 0
+// CHECK-F128: extractvalue { fp128, fp128 } [[VAR3]], 1
+#endif
+
 int bar_int(void) {
   return __real__(foo_int(2 - 3i));
 }
Index: clang/test/CodeGen/ppc64-complex-parms.c
===
--- clang/test/CodeGen/ppc64-complex-parms.c
+++ clang/test/CodeGen/ppc64-complex-parms.c
@@ -1,8 +1,19 @@
+// REQUIRES: powerpc-registered-target
 // RUN: %clang_cc1 -triple powerpc64-unknown-linux-gnu -emit-llvm -o - %s | 
FileCheck %s
+// RUN: %clang_cc1 -target-feature +float128 -DTEST_F128 -triple \
+// RUN:   powerpc64le-unknown-linux-gnu -emit-llvm -o - %s | FileCheck %s \
+// RUN:   --check-prefix CHECK-F128
 
 float crealf(_Complex float);
 double creal(_Complex double);
 long double creall(_Complex long double);
+#ifdef TEST_F128
+__float128 crealf128(_Complex __float128);
+__float128 foo_f128(_Complex __float128 x) {
+  return crealf128(x);
+}
+// CHECK-F128: define fp128 @foo_f128(fp128 {{[%A-Za-z0-9.]+}}, fp128 
{{[%A-Za-z0-9.]+}})
+#endif
 
 float foo_float(_Complex float x) {
   return crealf(x);
Index: clang/lib/Sema/DeclSpec.cpp
===
--- clang/lib/Sema/DeclSpec.cpp
+++ clang/lib/Sema/DeclSpec.cpp
@@ -1269,7 +1269,8 @@
   // Note that this intentionally doesn't include _Complex _Bool.
   if (!S.getLangOpts().CPlusPlus)
 S.Diag(TSTLoc, diag::ext_integer_complex);
-} else if (TypeSpecType != TST_float && TypeSpecType != TST_double) {
+} else if (TypeSpecType != TST_float && TypeSpecType != TST_double &&
+   TypeSpecType != TST_float128) {
   S.Diag(TSCLoc, diag::err_invalid_complex_spec)
 << getSpecifierName((TST)TypeSpecType, Policy);
   TypeSpecComplex = TSC_unspecified;


Index: clang/test/CodeGen/ppc64-complex-return.c
===
--- clang/test/CodeGen/ppc64-complex-return.c
+++ clang/test/CodeGen/ppc64-complex-return.c
@@ -1,9 +1,20 @@
 // REQUIRES: powerpc-registered-target
 // RUN: %clang_cc1 -triple powerpc64-unknown-linux-gnu -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -target-feature +float128 -DTEST_F128 -triple \
+// RUN:   powerpc64le-unknown-linux-gnu -emit-llvm -o - %s | FileCheck %s \
+// RUN:   --check-prefix CHECK-F128
 
 float crealf(_Complex float);
 double creal(_Complex double);
 long double creall(_Complex long double);
+#ifdef TEST_F128
+__float128 crealf128(_Complex __float128);
+_Complex __float128 foo_f128(_Complex __float128 x) {
+  return x;
+}
+
+// CHECK-F128: define { fp128, fp128 } @foo_f128(fp128 {{[%A-Za-z0-9.]+}}, fp128 {{[%A-Za-z0-9.]+}}) [[NUW:#[0-9]+]] {
+#endif
 
 _Complex float foo_float(_Complex float x) {
   return x;
@@ -80,6 +91,17 @@
 // CHECK: extractvalue { ppc_fp128, ppc_fp128 } [[VAR3]], 0
 // CHECK: extractvalue { ppc_fp128, ppc_fp128 } [[VAR3]], 1
 
+#ifdef TEST_F128
+__float128 bar_f128(void) {
+  return crealf128(foo_f128(2.0Q - 2.5Qi));
+}
+
+// CHECK-F128: define fp128 @bar_f128() [[NUW]] {
+// CHECK-F128: [[VAR3:[%A-Za-z0-9.]+]] = call { fp128, fp128 } @foo_f128
+// CHECK-F128: extractvalue { fp128, fp128 } [[VAR3]], 0
+// CHE

[PATCH] D80374: [Clang] Enable KF and KC mode for [_Complex] __float128

[Nemanja Ivanovic via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
nemanjai marked an inline comment as done.
Closed by commit rG9021ce9576e4: [Clang] Enable KF and KC mode for [_Complex] 
__float128 (authored by nemanjai).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80374

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Sema/attr-mode.c

Index: clang/test/Sema/attr-mode.c
===
--- clang/test/Sema/attr-mode.c
+++ clang/test/Sema/attr-mode.c
@@ -4,6 +4,8 @@
 // RUN:   -verify %s
 // RUN: %clang_cc1 -triple powerpc64-pc-linux-gnu -DTEST_64BIT_PPC64 -fsyntax-only \
 // RUN:   -verify %s
+// RUN: %clang_cc1 -triple powerpc64-pc-linux-gnu -DTEST_F128_PPC64 -fsyntax-only \
+// RUN:   -verify -target-feature +float128 %s
 // RUN: %clang_cc1 -triple x86_64-pc-linux-gnux32 -DTEST_64BIT_X86 -fsyntax-only \
 // RUN:   -verify %s
 // RUN: %clang_cc1 -triple mips-linux-gnu -DTEST_MIPS_32 -fsyntax-only \
@@ -90,6 +92,15 @@
 void f_ft128_complex_arg(_Complex long double *x);
 void test_TFtype(f128ibm *a) { f_ft128_arg (a); }
 void test_TCtype(c128ibm *a) { f_ft128_complex_arg (a); }
+#elif TEST_F128_PPC64
+typedef int invalid_7 __attribute((mode(KF))); // expected-error{{type of machine mode does not match type of base type}}
+typedef int invalid_8 __attribute((mode(KI))); // expected-error{{unknown machine mode}}
+typedef _Complex float cf128 __attribute__((mode(KC)));
+typedef float f128 __attribute__((mode(KF)));
+void f_f128_arg(__float128 *x);
+void f_f128_complex_arg(_Complex __float128 *x);
+void test_KFtype(f128 *a) { f_f128_arg(a); }
+void test_KCtype(cf128 *a) { f_f128_complex_arg(a); }
 #elif TEST_MIPS_32
 typedef unsigned int gcc_unwind_word __attribute__((mode(unwind_word)));
 int foo[sizeof(gcc_unwind_word) == 4 ? 1 : -1];
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -3942,7 +3942,8 @@
 /// parseModeAttrArg - Parses attribute mode string and returns parsed type
 /// attribute.
 static void parseModeAttrArg(Sema &S, StringRef Str, unsigned &DestWidth,
- bool &IntegerMode, bool &ComplexMode) {
+ bool &IntegerMode, bool &ComplexMode,
+ bool &ExplicitIEEE) {
   IntegerMode = true;
   ComplexMode = false;
   switch (Str.size()) {
@@ -3963,7 +3964,12 @@
 case 'X':
   DestWidth = 96;
   break;
+case 'K': // KFmode - IEEE quad precision (__float128)
+  ExplicitIEEE = true;
+  DestWidth = Str[1] == 'I' ? 0 : 128;
+  break;
 case 'T':
+  ExplicitIEEE = false;
   DestWidth = 128;
   break;
 }
@@ -4024,6 +4030,7 @@
   unsigned DestWidth = 0;
   bool IntegerMode = true;
   bool ComplexMode = false;
+  bool ExplicitIEEE = false;
   llvm::APInt VectorSize(64, 0);
   if (Str.size() >= 4 && Str[0] == 'V') {
 // Minimal length of vector mode is 4: 'V' + NUMBER(>=1) + TYPE(>=2).
@@ -4036,7 +4043,7 @@
 !Str.substr(1, VectorStringLength).getAsInteger(10, VectorSize) &&
 VectorSize.isPowerOf2()) {
   parseModeAttrArg(*this, Str.substr(VectorStringLength + 1), DestWidth,
-   IntegerMode, ComplexMode);
+   IntegerMode, ComplexMode, ExplicitIEEE);
   // Avoid duplicate warning from template instantiation.
   if (!InInstantiation)
 Diag(AttrLoc, diag::warn_vector_mode_deprecated);
@@ -4046,7 +4053,8 @@
   }
 
   if (!VectorSize)
-parseModeAttrArg(*this, Str, DestWidth, IntegerMode, ComplexMode);
+parseModeAttrArg(*this, Str, DestWidth, IntegerMode, ComplexMode,
+ ExplicitIEEE);
 
   // FIXME: Sync this with InitializePredefinedMacros; we need to match int8_t
   // and friends, at least with glibc.
@@ -4112,7 +4120,7 @@
 NewElemTy = Context.getIntTypeForBitwidth(DestWidth,
   OldElemTy->isSignedIntegerType());
   else
-NewElemTy = Context.getRealTypeForBitwidth(DestWidth);
+NewElemTy = Context.getRealTypeForBitwidth(DestWidth, ExplicitIEEE);
 
   if (NewElemTy.isNull()) {
 Diag(AttrLoc, diag::err_machine_mode) << 1 /*Unsupported*/ << Name;
Index: clang/lib/Basic/TargetInfo.cpp
===
--- clang/lib/Basic/TargetInfo.cpp
+++ clang/lib/Basic/TargetInfo.cpp
@@ -265,7 +265,8 @@
   return NoInt;
 }
 
-TargetInfo::RealType TargetInfo::getRealTypeByWidth(unsigned BitWidth) const {
+TargetInfo::RealType TargetInfo::getRealTypeByWidth(unsigned BitWidth,
+bool ExplicitIEEE) const {
   if (getFloatWidth()

[PATCH] D80941: [PowerPC][Power10] Implement Count Leading/Trailing Zeroes Builtins in LLVM/Clang

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai requested changes to this revision.
nemanjai added a comment.
This revision now requires changes to proceed.

In D80941#2066931 , @lebedev.ri wrote:

> Why not lower it to `@llvm.cttz(and(a, b))`?


That's a great idea. Particularly in the back end where this pattern can appear 
irrespective of the use of the builtins.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80941



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

[PATCH] D83500: [PowerPC][Power10] Implement custom codegen for the vec_replace_elt and vec_replace_unaligned builtins.

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai requested changes to this revision.
nemanjai added a comment.
This revision now requires changes to proceed.

The description includes `... however it is more preferable to use bitcast`. It 
is not a question of preference but of correctness. The fp to int conversions 
truncate while bitcasts don't. The semantics of the builtins require that no 
truncation happen.

Also, please include checks in SemaChecking for:

- Third argument being constant
- Third argument being within range
- Second argument having the same type as the element type of the first




Comment at: clang/lib/CodeGen/CGBuiltin.cpp:14275
+ConstantInt *ArgCI = dyn_cast(Ops[2]);
+assert(ArgCI &&
+   "Third Arg to vinsw/vinsd intrinsic must be a constant integer!");

Where is the code that ensures this? There does not appear to be a Sema check 
to emit a meaningful message for this. We also need a test with a non-constant 
argument to show the message.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:14278
+llvm::Type *ResultType = ConvertType(E->getType());
+llvm::Function *F = CGM.getIntrinsic(Intrinsic::ppc_altivec_vinsw);
+int64_t ConstArg = ArgCI->getSExtValue();

I don't think we should be creating the declaration if we may not use it. Just 
initialize this to `nullptr` here and set it for each case.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:14307
+  // Perform additional handling if the second argument is a double.
+  if (Ops[1]->getType()->isDoubleTy()) {
+Ops[0] = Builder.CreateBitCast(Ops[0],

Please change this to a negative condition (i.e. if the type is **not** `i64`). 
Similarly in other similar conditions.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:14319
+  }
+  case PPC::BI__builtin_altivec_vec_replace_unaligned: {
+// The third argument of vec_replace_unaligned must be a compile time

Can we reorganize this as something like:
```
case PPC::BI__builtin_altivec_vec_replace_elt:
case PPC::BI__builtin_altivec_vec_replace_unaligned: {
  // Define variables that are needed
  unsigned ArgWidth = Ops[1]->getType()->getPrimitiveSizeInBits();
  if (BuiltinID == PPC::BI__builtin_altivec_vec_replace_elt)
ConstArg *= ArgWidth / 8;
  assert((ArgWidth == 32 || ArgWidth == 64) && "Invalid argument width");
  if (ArgWidth == 32) {
// set up what is needed for vinsw
  } else {
// set up what is needed for vinsd
  }
  // Emit the call
  if (BuiltinID == PPC::BI__builtin_altivec_vec_replace_elt)
// add the bitcast of the result
}
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83500



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

[PATCH] D84291: [PowerPC][Power10] Fix the Test LSB by Byte (xvtlsbb) Builtins Implementation

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai accepted this revision.
nemanjai added a comment.

LGTM. The test case addition can be done on the commit.




Comment at: llvm/test/CodeGen/PowerPC/builtins-ppc-p10vsx.ll:2
 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
 ; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
 ; RUN:   -mcpu=pwr10 -ppc-asm-full-reg-names -ppc-vsr-nums-as-vr < %s | \

Since the issue was discovered when compiling with `-O0`, can you please add a 
`RUN` line with `-O0` to this test case?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84291



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

[PATCH] D77542: [PowerPC] Treat 'Z' inline asm constraint as a true memory constraint

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai created this revision.
nemanjai added reviewers: hfinkel, PowerPC.
Herald added subscribers: cfe-commits, shchenz, kbarton.
Herald added a project: clang.

We currently emit incorrect codegen for this constraint because we set it as a 
constraint that allows registers. This will cause the value to be copied to the 
stack and that address to be passed as the address. This is not what we want.

Fixes: https://bugs.llvm.org/show_bug.cgi?id=42762


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D77542

Files:
  clang/lib/Basic/Targets/PPC.h
  clang/test/CodeGen/ppc64-inline-asm.c


Index: clang/test/CodeGen/ppc64-inline-asm.c
===
--- clang/test/CodeGen/ppc64-inline-asm.c
+++ clang/test/CodeGen/ppc64-inline-asm.c
@@ -37,3 +37,16 @@
 // CHECK-LABEL: double @test_fmax(double %x, double %y)
 // CHECK: call double asm "xsmaxdp ${0:x}, ${1:x}, ${2:x}", 
"=^ws,^ws,^ws"(double %x, double %y)
 }
+
+void testZ(void *addr) {
+  asm volatile ("dcbz %y0\n" :: "Z"(*(unsigned char *)addr) : "memory");
+// CHECK-LABEL: void @testZ(i8* %addr)
+// CHECK: call void asm sideeffect "dcbz ${0:y}\0A", "*Z,~{memory}"(i8* %addr)
+}
+
+void testZwOff(void *addr, long long off) {
+  asm volatile ("dcbz %y0\n" :: "Z"(*(unsigned char *)(addr + off)) : 
"memory");
+// CHECK-LABEL: void @testZwOff(i8* %addr, i64 %off)
+// CHEC: %[[VAL:[^ ]+]] = getelementptr i8, i8* %addr, i64 %off
+// CHEC: call void asm sideeffect "dcbz ${0:y}\0A", "*Z,~{memory}"(i8* 
%[[VAL]])
+}
Index: clang/lib/Basic/Targets/PPC.h
===
--- clang/lib/Basic/Targets/PPC.h
+++ clang/lib/Basic/Targets/PPC.h
@@ -276,11 +276,12 @@
   break;
 case 'Q': // Memory operand that is an offset from a register (it is
   // usually better to use `m' or `es' in asm statements)
+  Info.setAllowsRegister();
+  LLVM_FALLTHROUGH;
 case 'Z': // Memory operand that is an indexed or indirect from a
   // register (it is usually better to use `m' or `es' in
   // asm statements)
   Info.setAllowsMemory();
-  Info.setAllowsRegister();
   break;
 case 'R': // AIX TOC entry
 case 'a': // Address operand that is an indexed or indirect from a


Index: clang/test/CodeGen/ppc64-inline-asm.c
===
--- clang/test/CodeGen/ppc64-inline-asm.c
+++ clang/test/CodeGen/ppc64-inline-asm.c
@@ -37,3 +37,16 @@
 // CHECK-LABEL: double @test_fmax(double %x, double %y)
 // CHECK: call double asm "xsmaxdp ${0:x}, ${1:x}, ${2:x}", "=^ws,^ws,^ws"(double %x, double %y)
 }
+
+void testZ(void *addr) {
+  asm volatile ("dcbz %y0\n" :: "Z"(*(unsigned char *)addr) : "memory");
+// CHECK-LABEL: void @testZ(i8* %addr)
+// CHECK: call void asm sideeffect "dcbz ${0:y}\0A", "*Z,~{memory}"(i8* %addr)
+}
+
+void testZwOff(void *addr, long long off) {
+  asm volatile ("dcbz %y0\n" :: "Z"(*(unsigned char *)(addr + off)) : "memory");
+// CHECK-LABEL: void @testZwOff(i8* %addr, i64 %off)
+// CHEC: %[[VAL:[^ ]+]] = getelementptr i8, i8* %addr, i64 %off
+// CHEC: call void asm sideeffect "dcbz ${0:y}\0A", "*Z,~{memory}"(i8* %[[VAL]])
+}
Index: clang/lib/Basic/Targets/PPC.h
===
--- clang/lib/Basic/Targets/PPC.h
+++ clang/lib/Basic/Targets/PPC.h
@@ -276,11 +276,12 @@
   break;
 case 'Q': // Memory operand that is an offset from a register (it is
   // usually better to use `m' or `es' in asm statements)
+  Info.setAllowsRegister();
+  LLVM_FALLTHROUGH;
 case 'Z': // Memory operand that is an indexed or indirect from a
   // register (it is usually better to use `m' or `es' in
   // asm statements)
   Info.setAllowsMemory();
-  Info.setAllowsRegister();
   break;
 case 'R': // AIX TOC entry
 case 'a': // Address operand that is an indexed or indirect from a
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D77085: [clang-tidy] Added support for validating configuration options

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.
Herald added a subscriber: wuzish.

A recent commit has taken down a whole bunch of bots. The build error messages 
all seem to point to code in this patch. If this is indeed the cause, please 
revert.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77085



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

[PATCH] D77085: [clang-tidy] Added support for validating configuration options

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

In D77085#1967864 , @njames93 wrote:

> In D77085#1967807 , @nemanjai wrote:
>
> > A recent commit has taken down a whole bunch of bots. The build error 
> > messages all seem to point to code in this patch. If this is indeed the 
> > cause, please revert.
>
>
> I was aware and hopefully this fixes the issue 
> https://github.com/llvm/llvm-project/commit/0361798dbeb6ead0a79ab7985f02da347fce988e


Awesome, thanks. Certainly fixes the compile time failures in my local build. 
There is still a link-time failure (undefined reference) with my shared 
libraries build:

  
tools/clang/tools/extra/clang-tidy/tool/CMakeFiles/obj.clangTidyMain.dir/ClangTidyMain.cpp.o:
 In function 
`clang::ast_matchers::internal::matcher_isAllowedToContainClauseKind0Matcher::matches(clang::OMPExecutableDirective
 const&, clang::ast_matchers::internal::ASTMatchFinder*, 
clang::ast_matchers::internal::BoundNodesTreeBuilder*) const':
  
ClangTidyMain.cpp:(.text._ZNK5clang12ast_matchers8internal44matcher_isAllowedToContainClauseKind0Matcher7matchesERKNS_22OMPExecutableDirectiveEPNS1_14ASTMatchFinderEPNS1_21BoundNodesTreeBuilderE[_ZNK5clang12ast_matchers8internal44matcher_isAllowedToContainClauseKind0Matcher7matchesERKNS_22OMPExecutableDirectiveEPNS1_14ASTMatchFinderEPNS1_21BoundNodesTreeBuilderE]+0x50):
 undefined reference to 
`llvm::omp::isAllowedClauseForDirective(llvm::omp::Directive, 
llvm::omp::Clause, unsigned int)'
  collect2: error: ld returned 1 exit status

But that may be unrelated to this patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77085



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

[PATCH] D80300: [Driver] Add DEFAULT_DYLD_PREFIX and DEFAULT_RPATH to complement DEFAULT_SYSROOT

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

According to https://clang.llvm.org/docs/CrossCompilation.html (under 
`Toolchain Options` option 2) it is quite likely that a user that desires to 
cross-compile will have the necessary toolchain installed into a directory that 
will not require the use of `--sysroot`.

So I think that letting `--target` override the default 
`--sysroot/--dyld-prefix/--rpath` is reasonable. What I am suggesting is that 
if `--target` is specified on the command line, it clears any default setting 
of these three options (i.e. clears them unless they were explicitly specified 
on the command line).

Namely, something along the lines of:

  diff --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
  index 5c726b2..9a85394 100644
  --- a/clang/lib/Driver/Driver.cpp
  +++ b/clang/lib/Driver/Driver.cpp
  @@ -1073,8 +1073,13 @@ Compilation *Driver::BuildCompilation(ArrayRef ArgList) {
   T.setObjectFormat(llvm::Triple::COFF);
   TargetTriple = T.str();
 }
  -  if (const Arg *A = Args.getLastArg(options::OPT_target))
  +  if (const Arg *A = Args.getLastArg(options::OPT_target)) {
   TargetTriple = A->getValue();
  +if (!Args.getLastArg(options::OPT__sysroot_EQ))
  +  SysRoot = "";
  +if (!Args.getLastArg(options::OPT__dyld_prefix_EQ))
  +  DyldPrefix = "";
  +  }

And something similar for `DEFAULT_RPATH`.

Would something like this be satisfactory for everyone here? Or do others think 
this is the "worst of both worlds"? :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80300



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

[PATCH] D80941: [PowerPC][Power10] Implement Count Leading/Trailing Zeroes Builtins under bit Mask in LLVM/Clang

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

Amy, I am really sorry. I initially did not read the description of the 
instructions in the ISA carefully. The semantics of these instructions are not 
actually `(op (and a, b))`. The mask is used to determine if a leading/trailing 
zero is counted or skipped.
Take for example the following two binary values:

  Mask:  100
  Value: 0010011

the result of `cntlzdm Value, Mask` should be `3` whereas the result of `(ctlz 
(and Value, Mask))` would be `5`. Namely, the instruction will count the first 
leading zero, ignore the next two bits and then count the next two zeros.

So you will need to revert back to the initial implementation. I am so sorry 
about going back and forth like this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80941



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

[PATCH] D80941: [PowerPC][Power10] Implement Count Leading/Trailing Zeroes Builtins under bit Mask in LLVM/Clang

[Nemanja Ivanovic via Phabricator via cfe-commits]

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

LGTM. Thanks Amy.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80941



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

[PATCH] D83497: [PowerPC][Power10] Fix VINS* (vector insert byte/half/word) instructions to have i32 arguments.

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai accepted this revision.
nemanjai added a comment.

LGTM aside from a minor nit regarding the description.




Comment at: clang/include/clang/Basic/BuiltinsPPC.def:324
 // P10 Vector Insert built-ins.
-BUILTIN(__builtin_altivec_vinsblx, "V16UcV16UcULLiULLi", "")
-BUILTIN(__builtin_altivec_vinsbrx, "V16UcV16UcULLiULLi", "")
-BUILTIN(__builtin_altivec_vinshlx, "V8UsV8UsULLiULLi", "")
-BUILTIN(__builtin_altivec_vinshrx, "V8UsV8UsULLiULLi", "")
-BUILTIN(__builtin_altivec_vinswlx, "V4UiV4UiULLiULLi", "")
-BUILTIN(__builtin_altivec_vinswrx, "V4UiV4UiULLiULLi", "")
+BUILTIN(__builtin_altivec_vinsblx, "V16UcV16UcUiUi", "")
+BUILTIN(__builtin_altivec_vinsbrx, "V16UcV16UcUiUi", "")

The description of this review mentions the second argument but you are 
changing the second and third argument. Please fix the description.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83497



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

[PATCH] D83497: [PowerPC][Power10] Fix VINS* (vector insert byte/half/word) instructions to have i32 arguments.

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

@rzurob This cannot proceed without your approval since you requested changes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83497



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

[PATCH] D83722: [PowerPC] Add options to control paired vector memops support

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

Please re-upload this and provide the missing context.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83722



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

[PATCH] D81442: [PowerPC] Add clang options to control MMA support

[Nemanja Ivanovic via Phabricator via cfe-commits]

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

Since clang will now add `+/-mma` to the TargetFeatures list, please add a test 
case that specifies `-mattr=+/-mma` to `llc` to show that `llc` accepts it.
Other than that, LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81442



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

[PATCH] D80952: [FPEnv][Clang][Driver] Disable constrained floating point on targets lacking support.

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai accepted this revision.
nemanjai added a comment.

As far as I'm concerned, this is fine for now. We can remove these once all 
in-tree target have implemented their support.
LGTM but maybe give a couple of days for others to chime in.




Comment at: clang/lib/Basic/Targets/PPC.h:86
+
+HasStrictFP = true;
   }

I don't think we need this for now. Close is not quite there. @steven.zhang I 
would prefer that we initially turn this off and only flip it on once the 
support is complete.
Also, is the support that is currently under development for both 32 and 64 bit 
architectures? If it is 64 bit only, then we can enable it only there once it 
is done.


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

https://reviews.llvm.org/D80952



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

[PATCH] D78308: [NFC][PowerPC] Refactor ppcUserFeaturesCheck()

[Nemanja Ivanovic via Phabricator via cfe-commits]

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

LGTM. Thanks for refactoring this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78308



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

[PATCH] D73290: [PowerPC] Add clang -msvr4-struct-return for 32-bit ELF

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai accepted this revision.
nemanjai added a comment.

Aside from a couple of minor nits that shouldn't require another review, LGTM.




Comment at: clang/docs/ClangCommandLineReference.rst:2631
+
+Override the default ABI for 32-bit targets to return small structs in
+registers, as in the System V ABI (1995).

Can you specify that "small" means 8 bytes or smaller?



Comment at: clang/lib/CodeGen/TargetInfo.cpp:4378
+const llvm::Triple &Triple, const CodeGenOptions &Opts) {
+  assert(Triple.getArch() == llvm::Triple::ppc);
+

Please add text to the assert to help anyone who ends up tripping it. Perhaps:
```
assert(Triple.getArch() == llvm::Triple::ppc &&
   "Invalid triple for a 32-bit PowerPC target");
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73290



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

[PATCH] D77542: [PowerPC] Treat 'Z' inline asm constraint as a true memory constraint

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai marked an inline comment as done.
nemanjai added inline comments.



Comment at: clang/lib/Basic/Targets/PPC.h:277
   break;
 case 'Q': // Memory operand that is an offset from a register (it is
   // usually better to use `m' or `es' in asm statements)

amyk wrote:
> Just curious, but does this case still require `Info.setAllowsMemory();` as 
> well?
I don't want to change the behaviour of a QPX-specific asm constraint, so I'd 
rather leave it as-is. `Q` will set both, `Z` will only set "memory".


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77542



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

[PATCH] D36431: Add powerpc64 to compiler-rt build infrastructure.

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

This has been sitting in approved state for more than 2 months. As far as I can 
tell, it wasn't committed. Do you plan to commit this soon or are you 
abandoning it for some reason?


https://reviews.llvm.org/D36431



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

[PATCH] D133338: [clang][PowerPC] PPC64 VAArg use coerced integer type for direct aggregate fits in register

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

I am not crazy about adding the Boolean parameter here or about the name. Seems 
somewhat unclear when a caller wants to pass `true` there.

What I think would be a more robust solution would be to use the same logic 
that decides whether to coerce the struct argument to an integer type. It seems 
that any big endian ABI that does this would want to ensure the access is on 
the right side.

Ultimately what I am getting at here is that we consider how the caller passes 
the value and how the callee accesses it separately - which is what leads to 
problems like this. Can we decide using the same function for the caller and 
the callee?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D18

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

[PATCH] D127189: [clang][AIX] Add option to control quadword lock free atomics ABI on AIX

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

I am ok with this change overall, I just have a couple of questions about 
naming of the option.

1. Is there any precedent for options that start with `-maix` or `-m` for 
any other OS?
2. Is `quadword` the best word to use? There is no type information and this is 
restricted to integers. Would something like `-maix-i128-atomics` be a better 
name?
3. Since this is kind of an ABI-related decision, would it make sense (and 
would it be possible) to make this a further suboption to the `-mabi` option? 
Something like `-mabi=vec-extabi,i128-atomics,ieeelongdouble`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127189

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

[PATCH] D128652: [PowerPC] Finished kill_canary implementation and debugging

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

"Made a new phabricator review because of git issues" is not an appropriate 
description of a review/revision.

Hopefully the description you add will describe what this intrinsic is supposed 
to do. It seems to me that this is a poorly designed feature if it is meant to 
work the way it was implemented. Namely, it seems like this intrinsic clobbers 
the stack protect global value rather than clobbering the corresponding value 
on the stack for the specific function it is enclosed in. I would have thought 
that it will clobber the stack in the function, thereby allowing stack 
protection to work as expected for other functions in the module.




Comment at: llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp:5014
+
+if (IntrinsicID == Intrinsic::ppc_kill_canary) {
+  CurDAG->SelectNodeTo(N, PPC::NOP, MVT::Other, N->getOperand(0));

I think it would be preferable to handle this intrinsic in one place. The `nop` 
is not actually necessary here. We should simply remove the intrinsic from the 
stream in `PPCISelLowering.cpp` and not pass it on.



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:11132
+  case Intrinsic::ppc_kill_canary: { 
+MachineFunction &MF = DAG.getMachineFunction();
+if (MF.getFunction().hasFnAttribute(Attribute::SafeStack) ||

The formatting of this entire block is quite messed up. Please run 
`clang-format` on this.



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:11138
+
+IRBuilder<> B(&MF.getFunction().getEntryBlock().front());
+

Do we use this?



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:11144
+
+if (GV == nullptr) break;
+EVT VT = DAG.getTargetLoweringInfo().getValueType(DAG.getDataLayout(), 
GV->getType(), true); 

Is it ok to just ignore a failure to get the GV here? Should this not be an 
assert?



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:11156-11168
+SDValue Store = DAG.getStore( 
+Op->getOperand(0), 
+DL,
+   DAG.getNode(
+ISD::XOR,
+   DL,
+   VT,

What is happening here? We load the value, XOR it with itself, store it again? 
Isn't that just zeroing it out? Why do we even need to load it then?



Comment at: llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll:2
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix \
+; RUN:   --ppc-asm-full-reg-names < %s | FileCheck %s

At the very least, this has to also include a RUN line for Linux.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128652

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

[PATCH] D129016: [PowerPC] implemented @llvm.ppc.kill.canary to corrupt stack guard

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai requested changes to this revision.
nemanjai added a comment.
This revision now requires changes to proceed.

Please run clang-format, rebase and re-upload. It doesn't apply cleanly to ToT.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129016

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

[PATCH] D129855: [clang][PowerPC] Set lld as clang's default linker for PowerPC Linux

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

In D129855#3667191 , @MaskRay wrote:

> In D129855#3662457 , @quinnp wrote:
>
>> In D129855#3657006 , @MaskRay 
>> wrote:
>>
>>> This is not right as using `ld.lld` as the default linker isn't the 
>>> majority case. If you want to change the default for your distribution, set 
>>> `-DCLANG_DEFAULT_LINKER=lld`.
>>> (Alternatively, you can have a `ld` symlink pointing to `lld`.)
>>
>> Hi @MaskRay! Do you mean I should abandon this change or find a way to set 
>> the CMake variable `CLANG_DEFAULT_LINKER` to `lld` as default when building 
>> for PowerPC Linux? I wasn't able to find any examples of people setting 
>> CMake variables for specific distributions.
>>
>> Thanks!
>
> You can customize `CLANG_DEFAULT_LINKER` in your clang distribution. I don't 
> find convincing argument to change the default for `PPCLinuxToolChain` and 
> diverge from `Linux`.

The reason we would like the default linker to be `ld.lld` for most/default 
builds on PPC is because using LTO without the GPL-licensed Gold plugin 
requires LLD. The idea is that a typical user can pull the source and build it 
with minimal CMake macros and get a working LTO without having to build the 
Gold plugin.

Of course, this may not be the way to accomplish this (i.e. this will make it 
diverge from the value specified in `CLANG_DEFAULT_LINKER` in 
`$LLVM_BUILD/tools/clang/include/clang/Config/config.h`). So I would prefer 
that we handle this in the CMake files if @MaskRay doesn't object.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129855

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

[PATCH] D130526: [Driver][PowerPC] Support -mtune=

[Nemanja Ivanovic via Phabricator via cfe-commits]

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

Thanks. We'll eventually start doing something with the option in the back end. 
LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130526

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

[PATCH] D131346: [clang] LLVM_FALLTHROUGH => [[fallthrough]]. NFC

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

Why? There are many years of precedent for using `LLVM_FALLTHROUGH` and it is 
very clear and obvious. What do we gain by getting rid of it?
Don't get me wrong, I am not super opposed to using a standard string instead 
of an LLVM-specific macro. However, it seems that this leaves us with a mixture 
of the macro and the standard attribute. If we are ready to replace all 
occurrences in all projects and get rid of the macro altogether (with some 
warning to downstream users), that seems reasonable. Replacing only some of 
them seems worse than what we now have.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131346

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

[PATCH] D129016: [PowerPC] implemented @llvm.ppc.kill.canary to corrupt stack guard

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added inline comments.



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:10702
+
+// If SafeStack or !StackProtector, kill_canary is not supported.
+if (MF.getFunction().hasFnAttribute(Attribute::SafeStack) ||

Again, this comment is nothing more than a re-reading of the code. As such, it 
is not useful. The comment should say what is happening and why. Something 
along the lines of:
```
// The kill_canary intrinsic only makes sense when the Stack Protector
// feature is on in the function. It can also not be used in conjunction
// with safe stack because the latter splits the stack and the canary
// value isn't used (i.e. safe stack supersedes stack protector).
// In situations where the kill_canary intrinsic is not supported,
// we simply replace uses of its chain with its input chain, causing
// the SDAG CSE to remove the node.
```



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:10720-10749
+if (useLoadStackGuardNode()) {
+  MachineSDNode *LSG =
+  DAG.getMachineNode(PPC::LOAD_STACK_GUARD, DL, VT, Op->getOperand(0));
+  Load = SDValue(LSG, 0);
+
+  // Frame index used to determine stack guard location if
+  // LOAD_STACK_GUARD is used.

The common code should just be common. Seems like the only thing that changes 
is how we load the value. Please refactor this to something like:
```
if (useLoadStackGuardNode()) {
  ...
  Load = ... // stack guard load
} else if (Value *GV = getSDagStackGuard(*M)) {
  ...
  Load = ... // canary word global load
} else
  llvm_unreachable("Unhandled stack guard case");

Store = ... // common store
return Store; // (or you can just create the store in-line and return it 
directly)
```



Comment at: llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll:2
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc-unknown-aix 
-ppc-vsr-nums-as-vr \
+; RUN:   -mcpu=pwr7 --ppc-asm-full-reg-names < %s | FileCheck %s 
-check-prefix=CHECK-AIX

Please add one RUN line with `-O0` to ensure that this works as expected with 
Fast ISel.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129016

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

[PATCH] D129016: [PowerPC] implemented @llvm.ppc.kill.canary to corrupt stack guard

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai accepted this revision.
nemanjai 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/D129016/new/

https://reviews.llvm.org/D129016

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

[PATCH] D104744: [PowerPC] Add PowerPC rotate related builtins and emit target independent code for XL compatibility

[Nemanja Ivanovic via Phabricator via cfe-commits]

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

LGTM other than a couple of nits.




Comment at: clang/lib/CodeGen/CGBuiltin.cpp:15064
   }
+  case PPC::BI__builtin_ppc_rldimi:
+  case PPC::BI__builtin_ppc_rlwimi: {

Please add a comment describing the emitted code. Something like:
```
// Rotate and insert under mask operation.
// __rlwimi(rs, is, shift, mask)
// rotl(rs, shift) & mask) | (is & ~mask)
```



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:15070
+  Ops[2] = Builder.CreateZExt(Ops[2], Int64Ty);
+Value *shift = Builder.CreateCall(F, {Ops[0], Ops[0], Ops[2]});
+Value *X = Builder.CreateAnd(shift, Ops[3]);

Nit: `s/shift/Shift` to conform to variable naming conventions. Here and 
elsewhere.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104744

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

[PATCH] D105946: [PowerPC] Store, load, move from and to registers related builtins

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai requested changes to this revision.
nemanjai added a comment.
This revision now requires changes to proceed.

We have encountered an issue with `lwarx/ldarx` that required that they emit 
inline asm rather than an intrinsic. What makes `lbarx/lharx` different?




Comment at: clang/lib/Sema/SemaChecking.cpp:3370
+  case PPC::BI__builtin_ppc_lbarx:
+return SemaFeatureCheck(*this, TheCall, "extdiv",
+diag::err_ppc_builtin_only_on_arch, "8");

Why do these need the `extdiv` feature?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105946

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

[PATCH] D106065: [Clang] Add an empty builtins.h file.

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added inline comments.



Comment at: clang/lib/Headers/builtins.h:8
+\*===--===*/
+
+#ifndef __BUILTINS_H

Please describe the purpose of this header file in a comment here.



Comment at: clang/test/Headers/builtins-header.c:1
+// RUN: %clang_cc1 -triple powerpc64-unknown-unknown -ffreestanding -emit-llvm 
-o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -ffreestanding 
-emit-llvm -o - %s | FileCheck %s

Does this need something like `REQUIRES: powerpc-registered-target`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106065

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

[PATCH] D104386: [PowerPC][Builtins] Added a number of builtins for compatibility with XL.

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

Can the test cases that just check for specific IR being produced be merged 
together? Seems unnecessary to have all of these separate test cases.
Perhaps something along the lines of:

- Test case for diagnostics of invalid use
- Test case for produced IR
- Test case for specific metadata being produced




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:9732
   "argument should be an 8-bit value shifted by a multiple of 8 bits, or in 
the form 0x??FF">;
+def err_argument_not_contiguous_bit_field : Error<
+  "argument %0 value should represent a contiguous bit field">;

I think this comes from another patch that is up for review. You should base 
this patch on top of that patch and mark the review as a dependency. It makes 
the review easier if the review only contains code that is meant to go in this 
commit.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:15257-15258
+const Expr *Ptr = E->getArg(1);
+Value *PtrValue = EmitScalarExpr(Ptr);
+Value *AlignmentValue = EmitScalarExpr(E->getArg(0));
+ConstantInt *AlignmentCI = cast(AlignmentValue);

Are these two just `Ops[0], Ops[1]`?



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:15270-15271
+  case PPC::BI__builtin_ppc_rdlam: {
+Value *Src = EmitScalarExpr(E->getArg(0));
+Value *ShiftAmt = EmitScalarExpr(E->getArg(1));
+

Same comment as above.



Comment at: clang/test/CodeGen/builtins-ppc-xlcompat-expect.c:1
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 -triple powerpc64-unknown-unknown \

Should this not test for the meta data that `__builtin_expect` produces?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104386

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

[PATCH] D105930: [PowerPC] Implement XL compact math builtins

[Nemanja Ivanovic via Phabricator via cfe-commits]

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

LGTM other than the comment that wasn't addressed (which I assume will be 
addressed in a subsequent patch).




Comment at: llvm/lib/Target/PowerPC/PPCInstrInfo.td:3087
 // RM should be set.
+let hasSideEffects = 1 in {
 def MTFSB0 : XForm_43<63, 70, (outs), (ins u5imm:$FM),

nemanjai wrote:
> I think we should conservatively set RM as an implicit def here. @ZhangKang 
> you modified this code most recently, please provide your opinion here.
This was not addressed. Will this be added in a follow-up patch?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105930

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

[PATCH] D106021: [PowerPC] Add PowerPC population count, reversed load and store related builtins and instrinsics for XL compatibility

[Nemanja Ivanovic via Phabricator via cfe-commits]

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

LGTM as long as the redundant clear is removed.




Comment at: clang/lib/CodeGen/CGBuiltin.cpp:15098
+  case PPC::BI__builtin_ppc_poppar8: {
+Value *ArgValue = EmitScalarExpr(E->getArg(0));
+

Isn't this just `Ops[0]`?



Comment at: llvm/lib/Target/PowerPC/PPCInstrInfo.td:5276
+def : Pat<(int_ppc_store2r gprc:$a, ForceXForm:$ptr),
+  (STHBRX (RLWINM gprc:$a, 0, 16, 31), ForceXForm:$ptr)>;
+def : Pat<(int_ppc_store4r gprc:$a, ForceXForm:$ptr),

The clear is redundant. Why do we need to clear the bits that we won't store to 
begin with?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106021

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

[PATCH] D105946: [PowerPC] Store, load, move from and to registers related builtins

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai requested changes to this revision.
nemanjai added a comment.
This revision now requires changes to proceed.

Taking this off the review queue until `lharx/lbarx` are changed to emit inline 
asm in line with `lwarx/ldarx`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105946

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

[PATCH] D105946: [PowerPC] Store, load, move from and to registers related builtins

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai requested changes to this revision.
nemanjai added a comment.
This revision now requires changes to proceed.

This is getting close to approval. The newly added `__stfiw` needs to be fixed 
and some nits need to be addressed.




Comment at: clang/lib/Sema/SemaChecking.cpp:3369
+  case PPC::BI__builtin_ppc_stfiw:
+return SemaFeatureCheck(*this, TheCall, "isa-v30-instructions",
+diag::err_ppc_builtin_only_on_arch, "9");

This is not correct. The instruction (non-VSX version) has existed since 
Power3. The VSX version was added in Power8. No changes to the instruction came 
in Power9 so I have no idea where the decision to add this check came from.

In fact, this would also blow up in the back end if you compiled with something 
like `-mcpu=pwr9 -mno-altivec` or `-mcpu=pwr9 -mno-vsx`.



Comment at: llvm/include/llvm/IR/IntrinsicsPowerPC.td:1568
 [IntrWriteMem]>;
+  def int_ppc_sthcx : Intrinsic<[llvm_i32_ty], [llvm_ptr_ty, llvm_i32_ty], 
[IntrWriteMem]>;
+  def int_ppc_dcbtstt : GCCBuiltin<"__builtin_ppc_dcbtstt">,

Nit: line too long.



Comment at: llvm/include/llvm/IR/IntrinsicsPowerPC.td:1577
+  Intrinsic<[llvm_i32_ty], [], [IntrNoMem]>;
+def int_ppc_stfiw : GCCBuiltin<"__builtin_ppc_stfiw">,
+Intrinsic<[], [llvm_ptr_ty, llvm_double_ty], 
[IntrWriteMem]>;

Nit: indentation is inconsistent here.



Comment at: llvm/lib/Target/PowerPC/PPCInstrVSX.td:4072
+
+def : Pat<(int_ppc_stfiw ForceXForm:$dst, f64:$XT),
+  (STXSIWX f64:$XT, ForceXForm:$dst)>;

This needs the non-VSX pattern as well.



Comment at: llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-stfiw.ll:1
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \

One of the run lines should be with `-mattr=-vsx`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105946

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

[PATCH] D106120: [PowerPC] Implement vector bool/pixel initialization under -faltivec-src-compat=xl

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai requested changes to this revision.
nemanjai added a comment.
This revision now requires changes to proceed.

Why are `vector-scalar-altivec-init.c` and `vector-scalar-altivec-init2.c` 
added? There is no initialization of `vector bool` or `vector pixel` in them so 
I don't really see the need to add them. If it is just to test that the 
existing behaviour doesn't change for those, you can simply add two run lines 
for `xl` and `mixed` to existing test cases.

Also, please unify `vector-bool-pixel-altivec-init.c` and 
`vector-bool-pixel-altivec-init2.c` into a single test case. It is not 
immediately obvious to the reader that the difference is parenthesized vs. 
unparenthesized initialization.




Comment at: clang/include/clang/Sema/Sema.h:6097
+  // option, these types also splat the scalar value.
+  bool ShouldSplatAltivecScalarInCast(Sema &Self, const VectorType *VecTy);
+

Why take a `Sema &` parameter? It is called `Self` so presumably it is expected 
to point to `*this`. Is there a use case where it points to a different 
instance of `Sema`?



Comment at: clang/lib/Sema/SemaCast.cpp:2627
 
+// Checks if we have a valid AltiVec vector type, and splats the value into
+// the vector accordingly. If a 'vector bool' or 'vector pixel' type is used

No need to repeat the comment on the implementation.



Comment at: clang/test/CodeGen/vector-bool-pixel-altivec-init.c:57
+  // MIXED: insertelement <8 x i16>
+  // XL: %splat.splatinsert1 = insertelement <8 x i16>
+  // XL-NEXT: %splat.splat2 = shufflevector <8 x i16> %splat.splatinsert1

It is generally not safe to hard-code names of virtual registers 
(`llvm::Value*`'s) in test cases. The naming is different in Release vs. Debug 
builds and it could also change for any other reason as no guarantee is ever 
made about the names.

You should test for what's important:
- The `insertelement` of the right type (save the name with `[[INS:%.*]]`)
- The use of that value for a `shufflevector` where you check the shuffle mask 
(presumably `zeroinitializer`)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106120

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

[PATCH] D106065: [Clang] Add an empty builtins.h file.

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai accepted this revision.
nemanjai 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/D106065/new/

https://reviews.llvm.org/D106065

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

[PATCH] D105984: [PowerPC] Restore FastMathFlags of Builder for Vector FDiv Builtins

[Nemanja Ivanovic via Phabricator via cfe-commits]

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

LGTM. Thanks for fixing this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105984

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

[PATCH] D106130: [PowerPC] Implemented mtmsr, mfspr, mtspr Builtins

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai requested changes to this revision.
nemanjai added a comment.
This revision now requires changes to proceed.

Why does this review have no reviewers listed?




Comment at: clang/lib/CodeGen/CGBuiltin.cpp:15586
+  case PPC::BI__builtin_ppc_mfspr: {
+llvm::Type *RetType = CGM.getDataLayout().getTypeSizeInBits(VoidPtrTy) == 
32
+  ? Int32Ty

Is this the formatting that `clang-format` produces? Seems surprising it would 
format it that way.



Comment at: clang/lib/Sema/SemaChecking.cpp:3374
+  case PPC::BI__builtin_ppc_mfspr:
+return SemaBuiltinConstantArgRange(TheCall, 0, 1, 898);
 #define CUSTOM_BUILTIN(Name, Intr, Types, Acc) \

I don't think we should enforce the range. The architecture may add more SPR's 
in the future and then this check will need to be updated. Just ensure that the 
register number (as well as the value for `mtspr`) are constants.



Comment at: llvm/include/llvm/IR/IntrinsicsPowerPC.td:1581
   Intrinsic<[llvm_i32_ty], [], [IntrNoMem]>;
+  def int_ppc_mfspr : Intrinsic<[llvm_anyint_ty], [llvm_i32_ty], 
[ImmArg>]>;
+  def int_ppc_mtmsr

Nit: line too long



Comment at: llvm/lib/Target/PowerPC/PPCInstr64Bit.td:415
 
-
 
//===--===//

Unrelated whitespace change.



Comment at: llvm/lib/Target/PowerPC/PPCInstrInfo.td:5442
 def : Pat<(int_ppc_mftbu), (MFTB 269)>;
+def : Pat<(i32 (int_ppc_mfspr i32:$SPR)),
+  (MFSPR $SPR)>;

Shouldn't this be `imm` instead of `i32`?
Have you tried compiling the test cases with `-filetype=obj` and/or with 
`-ppc-asm-full-reg-names`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106130

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

[PATCH] D105869: [Driver] fix PowerPC SPE musl dynamic linker name

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a subscriber: jhibbits.
nemanjai added a comment.

I personally don't see anything wrong with this, but then again I am not really 
familiar with SPE. I'll defer to @jhibbits for the approval.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105869

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