[PATCH] D99949: [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

2021-04-20 Thread Pushpinder Singh via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG3194761d2763: [AMDGPU][OpenMP] Add amdgpu-arch tool to list 
AMD GPUs installed (authored by pdhaliwal).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99949

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/AMDGPU.cpp
  clang/lib/Driver/ToolChains/AMDGPU.h
  clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
  clang/test/Driver/Inputs/amdgpu-arch/amdgpu_arch_different
  clang/test/Driver/Inputs/amdgpu-arch/amdgpu_arch_fail
  clang/test/Driver/Inputs/amdgpu-arch/amdgpu_arch_gfx906
  clang/test/Driver/Inputs/amdgpu-arch/amdgpu_arch_gfx908_gfx908
  clang/test/Driver/amdgpu-openmp-system-arch-fail.c
  clang/test/Driver/amdgpu-openmp-system-arch.c
  clang/tools/CMakeLists.txt
  clang/tools/amdgpu-arch/AMDGPUArch.cpp
  clang/tools/amdgpu-arch/CMakeLists.txt

Index: clang/tools/amdgpu-arch/CMakeLists.txt
===
--- /dev/null
+++ clang/tools/amdgpu-arch/CMakeLists.txt
@@ -0,0 +1,17 @@
+# //===--===//
+# //
+# // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+# // See https://llvm.org/LICENSE.txt for details.
+# // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+# //
+# //===--===//
+
+find_package(hsa-runtime64 QUIET 1.2.0 HINTS ${CMAKE_INSTALL_PREFIX} PATHS /opt/rocm)
+if (NOT ${hsa-runtime64_FOUND})
+  message(STATUS "Not building amdgpu-arch: hsa-runtime64 not found")
+  return()
+endif()
+
+add_clang_tool(amdgpu-arch AMDGPUArch.cpp)
+
+clang_target_link_libraries(amdgpu-arch PRIVATE hsa-runtime64::hsa-runtime64)
Index: clang/tools/amdgpu-arch/AMDGPUArch.cpp
===
--- /dev/null
+++ clang/tools/amdgpu-arch/AMDGPUArch.cpp
@@ -0,0 +1,59 @@
+//===- AMDGPUArch.cpp - list AMDGPU installed --*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file implements a tool for detecting name of AMDGPU installed in system
+// using HSA. This tool is used by AMDGPU OpenMP driver.
+//
+//===--===//
+
+#include 
+#include 
+#include 
+
+static hsa_status_t iterateAgentsCallback(hsa_agent_t Agent, void *Data) {
+  hsa_device_type_t DeviceType;
+  hsa_status_t Status =
+  hsa_agent_get_info(Agent, HSA_AGENT_INFO_DEVICE, );
+
+  // continue only if device type if GPU
+  if (Status != HSA_STATUS_SUCCESS || DeviceType != HSA_DEVICE_TYPE_GPU) {
+return Status;
+  }
+
+  std::vector *GPUs =
+  static_cast *>(Data);
+  char GPUName[64];
+  Status = hsa_agent_get_info(Agent, HSA_AGENT_INFO_NAME, GPUName);
+  if (Status != HSA_STATUS_SUCCESS) {
+return Status;
+  }
+  GPUs->push_back(GPUName);
+  return HSA_STATUS_SUCCESS;
+}
+
+int main() {
+  hsa_status_t Status = hsa_init();
+  if (Status != HSA_STATUS_SUCCESS) {
+return 1;
+  }
+
+  std::vector GPUs;
+  Status = hsa_iterate_agents(iterateAgentsCallback, );
+  if (Status != HSA_STATUS_SUCCESS) {
+return 1;
+  }
+
+  for (const auto  : GPUs)
+printf("%s\n", GPU.c_str());
+
+  if (GPUs.size() < 1)
+return 1;
+
+  hsa_shut_down();
+  return 0;
+}
Index: clang/tools/CMakeLists.txt
===
--- clang/tools/CMakeLists.txt
+++ clang/tools/CMakeLists.txt
@@ -43,3 +43,5 @@
 
 # libclang may require clang-tidy in clang-tools-extra.
 add_clang_subdirectory(libclang)
+
+add_clang_subdirectory(amdgpu-arch)
Index: clang/test/Driver/amdgpu-openmp-system-arch.c
===
--- /dev/null
+++ clang/test/Driver/amdgpu-openmp-system-arch.c
@@ -0,0 +1,24 @@
+// REQUIRES: system-linux
+// REQUIRES: x86-registered-target
+// REQUIRES: amdgpu-registered-target
+// REQUIRES: shell
+
+// RUN: mkdir -p %t
+// RUN: rm -f %t/amdgpu_arch_gfx906
+// RUN: cp %S/Inputs/amdgpu-arch/amdgpu_arch_gfx906 %t/
+// RUN: cp %S/Inputs/amdgpu-arch/amdgpu_arch_gfx908_gfx908 %t/
+// RUN: chmod +x %t/amdgpu_arch_gfx906
+// RUN: chmod +x %t/amdgpu_arch_gfx908_gfx908
+
+// RUN:   %clang -### --target=x86_64-unknown-linux-gnu -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -nogpulib --amdgpu-arch-tool=%t/amdgpu_arch_gfx906 %s 2>&1 \
+// RUN:   | FileCheck %s
+// CHECK: clang{{.*}}"-cc1"{{.*}}"-triple" "amdgcn-amd-amdhsa"{{.*}}"-target-cpu" 

[clang] 3194761 - [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

2021-04-20 Thread Pushpinder Singh via cfe-commits

Author: Pushpinder Singh
Date: 2021-04-21T05:05:49Z
New Revision: 3194761d2763a471dc6426a3e77c1445cb9ded3b

URL: 
https://github.com/llvm/llvm-project/commit/3194761d2763a471dc6426a3e77c1445cb9ded3b
DIFF: 
https://github.com/llvm/llvm-project/commit/3194761d2763a471dc6426a3e77c1445cb9ded3b.diff

LOG: [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

This patch adds new clang tool named amdgpu-arch which uses
HSA to detect installed AMDGPU and report back latter's march.
This tool is built only if system has HSA installed.

The value printed by amdgpu-arch is used to fill -march when
latter is not explicitly provided in -Xopenmp-target.

Reviewed By: JonChesterfield, gregrodgers

Differential Revision: https://reviews.llvm.org/D99949

Added: 
clang/test/Driver/Inputs/amdgpu-arch/amdgpu_arch_different
clang/test/Driver/Inputs/amdgpu-arch/amdgpu_arch_fail
clang/test/Driver/Inputs/amdgpu-arch/amdgpu_arch_gfx906
clang/test/Driver/Inputs/amdgpu-arch/amdgpu_arch_gfx908_gfx908
clang/test/Driver/amdgpu-openmp-system-arch-fail.c
clang/test/Driver/amdgpu-openmp-system-arch.c
clang/tools/amdgpu-arch/AMDGPUArch.cpp
clang/tools/amdgpu-arch/CMakeLists.txt

Modified: 
clang/include/clang/Basic/DiagnosticDriverKinds.td
clang/include/clang/Driver/Options.td
clang/lib/Driver/ToolChains/AMDGPU.cpp
clang/lib/Driver/ToolChains/AMDGPU.h
clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
clang/tools/CMakeLists.txt

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticDriverKinds.td 
b/clang/include/clang/Basic/DiagnosticDriverKinds.td
index 5e580cc4fbb7a..a2ffe1378cb6d 100644
--- a/clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ b/clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -67,6 +67,8 @@ def err_drv_no_hip_runtime : Error<
   "cannot find HIP runtime. Provide its path via --rocm-path, or pass "
   "-nogpuinc to build without HIP runtime.">;
 
+def err_drv_undetermined_amdgpu_arch : Error<
+  "Cannot determine AMDGPU architecture: %0. Consider passing it via 
--march.">;
 def err_drv_cuda_version_unsupported : Error<
   "GPU arch %0 is supported by CUDA versions between %1 and %2 (inclusive), "
   "but installation at %3 is %4. Use --cuda-path to specify a 
diff erent CUDA "

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index f93b8a2496e07..dbdb6c6dab3ac 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -924,6 +924,8 @@ def rocm_path_EQ : Joined<["--"], "rocm-path=">, 
Group,
   HelpText<"ROCm installation path, used for finding and automatically linking 
required bitcode libraries.">;
 def hip_path_EQ : Joined<["--"], "hip-path=">, Group,
   HelpText<"HIP runtime installation path, used for finding HIP version and 
adding HIP include path.">;
+def amdgpu_arch_tool_EQ : Joined<["--"], "amdgpu-arch-tool=">, Group,
+  HelpText<"Tool used for detecting AMD GPU arch in the system.">;
 def rocm_device_lib_path_EQ : Joined<["--"], "rocm-device-lib-path=">, 
Group,
   HelpText<"ROCm device library path. Alternative to rocm-path.">;
 def : Joined<["--"], "hip-device-lib-path=">, Alias;

diff  --git a/clang/lib/Driver/ToolChains/AMDGPU.cpp 
b/clang/lib/Driver/ToolChains/AMDGPU.cpp
index dc9c9751c851d..328753b21f8ea 100644
--- a/clang/lib/Driver/ToolChains/AMDGPU.cpp
+++ b/clang/lib/Driver/ToolChains/AMDGPU.cpp
@@ -12,9 +12,16 @@
 #include "clang/Basic/TargetID.h"
 #include "clang/Driver/Compilation.h"
 #include "clang/Driver/DriverDiagnostic.h"
+#include "clang/Driver/Options.h"
 #include "llvm/Option/ArgList.h"
+#include "llvm/Support/Error.h"
+#include "llvm/Support/FileUtilities.h"
+#include "llvm/Support/LineIterator.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/VirtualFileSystem.h"
+#include 
+
+#define AMDGPU_ARCH_PROGRAM_NAME "amdgpu-arch"
 
 using namespace clang::driver;
 using namespace clang::driver::tools;
@@ -715,6 +722,78 @@ void AMDGPUToolChain::checkTargetID(
   }
 }
 
+llvm::Error
+AMDGPUToolChain::detectSystemGPUs(const ArgList ,
+  SmallVector ) const 
{
+  std::string Program;
+  if (Arg *A = Args.getLastArg(options::OPT_amdgpu_arch_tool_EQ))
+Program = A->getValue();
+  else
+Program = GetProgramPath(AMDGPU_ARCH_PROGRAM_NAME);
+  llvm::SmallString<64> OutputFile;
+  llvm::sys::fs::createTemporaryFile("print-system-gpus", "" /* No Suffix */,
+ OutputFile);
+  llvm::FileRemover OutputRemover(OutputFile.c_str());
+  llvm::Optional Redirects[] = {
+  {""},
+  StringRef(OutputFile),
+  {""},
+  };
+
+  std::string ErrorMessage;
+  if (int Result = llvm::sys::ExecuteAndWait(
+  Program.c_str(), {}, {}, Redirects, /* SecondsToWait */ 0,
+  /*MemoryLimit*/ 0, )) {
+if (Result > 0) {
+  ErrorMessage = "Exited with error code " + 

[PATCH] D77013: [AMDGPU] Add options -mamdgpu-ieee -mno-amdgpu-ieee

2021-04-20 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticDriverKinds.td:130-131
   "invalid argument '%0' only allowed with '%1'">;
+def err_drv_argument_only_allowed_with_or_equivalent : Error<
+  "invalid argument '%0' only allowed with '%1' or equivalent">;
 def err_drv_argument_not_allowed_with : Error<

arsenm wrote:
> This seems like a confusing message. Equivalent of what?
will fix



Comment at: clang/include/clang/Driver/Options.td:3176
+  CodeGenOpts<"EmitIEEENaNCompliantInsts">, DefaultTrue,
+  PosFlag s/Setting a bit/Sets the IEEE bit/
will do



Comment at: clang/test/CodeGenOpenCL/amdgpu-ieee.cl:20
+
+// Check diagnostics when using -mno-amdgpu-ieee without NoHornorNaNs.
+

arsenm wrote:
> Typo Hornor
will fix


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

https://reviews.llvm.org/D77013

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


[PATCH] D77013: [AMDGPU] Add options -mamdgpu-ieee -mno-amdgpu-ieee

2021-04-20 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl updated this revision to Diff 339092.
yaxunl marked 3 inline comments as done.
yaxunl added a comment.

revised by Matt's comments


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

https://reviews.llvm.org/D77013

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGenOpenCL/amdgpu-ieee.cl

Index: clang/test/CodeGenOpenCL/amdgpu-ieee.cl
===
--- /dev/null
+++ clang/test/CodeGenOpenCL/amdgpu-ieee.cl
@@ -0,0 +1,47 @@
+// REQUIRES: amdgpu-registered-target
+//
+// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -O0 -emit-llvm -o - %s \
+// RUN:   | FileCheck -check-prefixes=COMMON,ON %s
+// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -O0 -emit-llvm -o - %s \
+// RUN:   -mno-amdgpu-ieee -menable-no-nans \
+// RUN:   | FileCheck -check-prefixes=COMMON,OFF %s
+// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -O0 -emit-llvm -o - %s \
+// RUN:   -mno-amdgpu-ieee -cl-fast-relaxed-math \
+// RUN:   | FileCheck -check-prefixes=COMMON,OFF %s
+
+// Check AMDGCN ISA generation.
+
+// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -O3 -S -o - %s \
+// RUN:   | FileCheck -check-prefixes=ISA-ON %s
+// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -O3 -S -o - %s \
+// RUN:   -mno-amdgpu-ieee -menable-no-nans \
+// RUN:   | FileCheck -check-prefixes=ISA-OFF %s
+
+// Check diagnostics when using -mno-amdgpu-ieee without NoHonorNaNs.
+
+// RUN: not %clang_cc1 -triple amdgcn-amd-amdhsa -O0 -emit-llvm -o - %s \
+// RUN:   -mno-amdgpu-ieee 2>&1 | FileCheck -check-prefixes=DIAG %s
+
+// COMMON: define{{.*}} amdgpu_kernel void @kern{{.*}} [[ATTRS1:#[0-9]+]]
+// ISA-ON: v_mul_f32_e64 v{{[0-9]+}}, 1.0, s{{[0-9]+}}
+// ISA-ON: v_mul_f32_e64 v{{[0-9]+}}, 1.0, s{{[0-9]+}}
+// ISA-ON: v_min_f32_e32
+// ISA-ON: ; IeeeMode: 1
+// ISA-OFF-NOT: v_mul_f32_e64 v{{[0-9]+}}, 1.0, s{{[0-9]+}}
+// ISA-OFF-NOT: v_mul_f32_e64 v{{[0-9]+}}, 1.0, s{{[0-9]+}}
+// ISA-OFF: v_min_f32_e32
+// ISA-OFF: ; IeeeMode: 0
+kernel void kern(global float *x, float y, float z) {
+  *x = __builtin_fmin(y, z);
+}
+
+// COMMON: define{{.*}}void @fun() [[ATTRS2:#[0-9]+]]
+void fun() {
+}
+
+// ON-NOT: attributes [[ATTRS1]] = {{.*}} "amdgpu-ieee"
+// OFF: attributes [[ATTRS1]] = {{.*}} "amdgpu-ieee"="false"{{.*}}"no-nans-fp-math"="true"{{.*}}"no-trapping-math"="true"
+// ON-NOT: attributes [[ATTRS2]] = {{.*}} "amdgpu-ieee"
+// OFF: attributes [[ATTRS2]] = {{.*}} "amdgpu-ieee"="false"{{.*}}"no-nans-fp-math"="true"{{.*}}"no-trapping-math"="true"
+
+// DIAG: invalid argument '-mno-amdgpu-ieee' only allowed with floating point options which do not honor NaNs, e.g. '-fno-honor-nans', '-ffast-math', '-ffinite-math-only', etc.
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -1943,6 +1943,11 @@
   else if (Args.hasArg(options::OPT_fno_finite_loops))
 Opts.FiniteLoops = CodeGenOptions::FiniteLoopsKind::Never;
 
+  Opts.EmitIEEENaNCompliantInsts =
+  Args.hasFlag(options::OPT_mamdgpu_ieee, options::OPT_mno_amdgpu_ieee);
+  if (!Opts.EmitIEEENaNCompliantInsts && !LangOptsRef.NoHonorNaNs)
+Diags.Report(diag::err_drv_amdgpu_ieee_without_no_honor_nans);
+
   return Diags.getNumErrors() == NumErrorsBefore;
 }
 
Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ clang/lib/CodeGen/TargetInfo.cpp
@@ -9166,6 +9166,9 @@
 
   if (M.getContext().getTargetInfo().allowAMDGPUUnsafeFPAtomics())
 F->addFnAttr("amdgpu-unsafe-fp-atomics", "true");
+
+  if (!getABIInfo().getCodeGenOpts().EmitIEEENaNCompliantInsts)
+F->addFnAttr("amdgpu-ieee", "false");
 }
 
 unsigned AMDGPUTargetCodeGenInfo::getOpenCLKernelCallingConv() const {
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -3171,6 +3171,14 @@
  Values<"command,reactor">,
  HelpText<"Execution model (WebAssembly only)">;
 
+defm amdgpu_ieee : BoolOption<"m", "amdgpu-ieee",
+  CodeGenOpts<"EmitIEEENaNCompliantInsts">, DefaultTrue,
+  PosFlag,
+  NegFlag>, Group;
+
 def mcode_object_version_EQ : Joined<["-"], "mcode-object-version=">, Group,
   HelpText<"Specify code object ABI version. Defaults to 3. (AMDGPU only)">,
   MetaVarName<"">, Values<"2,3,4">;
Index: clang/include/clang/Basic/DiagnosticDriverKinds.td
===
--- clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -127,6 +127,10 @@
   "invalid 

[PATCH] D100879: [Clang] Propagate guaranteed alignment for malloc and others

2021-04-20 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

Please addd tests, including tests that we suppress this assumption under e.g. 
`-fno-builtin-malloc`


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

https://reviews.llvm.org/D100879

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


[PATCH] D45639: [Driver] Support default libc++ library location on Darwin

2021-04-20 Thread Jonas Devlieghere via Phabricator via cfe-commits
JDevlieghere added a comment.

@phosek I've reverted this in 05eeed9691aeb3e0316712195b998e9078cdceb0 
 to turn 
the bot green again. Happy to help you look into this tomorrow.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D45639

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


[clang] 05eeed9 - Revert "[Driver] Support default libc++ library location on Darwin"

2021-04-20 Thread Jonas Devlieghere via cfe-commits

Author: Jonas Devlieghere
Date: 2021-04-20T20:42:50-07:00
New Revision: 05eeed9691aeb3e0316712195b998e9078cdceb0

URL: 
https://github.com/llvm/llvm-project/commit/05eeed9691aeb3e0316712195b998e9078cdceb0
DIFF: 
https://github.com/llvm/llvm-project/commit/05eeed9691aeb3e0316712195b998e9078cdceb0.diff

LOG: Revert "[Driver] Support default libc++ library location on Darwin"

This reverts the following commits because it breaks
TestAppleSimulatorOSType.py on GreenDragon [1].

caff17e503fe81d69e90dd69b14f5149659f9db4
f5efe0aa048b2bd3363b3a53efe9ae7367244801
ae8b2cab67408a043a4fe964d16e4803553c4ee0

[1] http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/31346/

Added: 


Modified: 
clang/lib/Driver/ToolChains/Darwin.cpp
clang/test/Driver/darwin-ld.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Darwin.cpp 
b/clang/lib/Driver/ToolChains/Darwin.cpp
index 06d4f2f4df0bc..bc59b6beafc78 100644
--- a/clang/lib/Driver/ToolChains/Darwin.cpp
+++ b/clang/lib/Driver/ToolChains/Darwin.cpp
@@ -615,8 +615,6 @@ void darwin::Linker::ConstructJob(Compilation , const 
JobAction ,
 
   Args.AddAllArgs(CmdArgs, options::OPT_L);
 
-  getToolChain().AddFilePathLibArgs(Args, CmdArgs);
-
   AddLinkerInputs(getToolChain(), Inputs, Args, CmdArgs, JA);
   // Build the input file for -filelist (list of linker input files) in case we
   // need it later
@@ -804,7 +802,6 @@ MachO::MachO(const Driver , const llvm::Triple , 
const ArgList )
   getProgramPaths().push_back(getDriver().getInstalledDir());
   if (getDriver().getInstalledDir() != getDriver().Dir)
 getProgramPaths().push_back(getDriver().Dir);
-  getFilePaths().push_back(getDriver().Dir + "/../lib");
 }
 
 /// Darwin - Darwin tool chain for i386 and x86_64.

diff  --git a/clang/test/Driver/darwin-ld.c b/clang/test/Driver/darwin-ld.c
index 9fe68f1821c96..15e5d100afcbc 100644
--- a/clang/test/Driver/darwin-ld.c
+++ b/clang/test/Driver/darwin-ld.c
@@ -365,7 +365,3 @@
 // RUN: FileCheck -check-prefix=MNO_OUTLINE %s < %t.log
 // MNO_OUTLINE: {{ld(.exe)?"}}
 // MNO_OUTLINE-SAME: "-mllvm" "-enable-machine-outliner=never"
-
-// RUN: %clang -target x86_64-apple-darwin10 -### %t.o 2> %t.log
-// RUN: FileCheck -check-prefix=INSTALL-DIR %s < %t.log
-// INSTALL-DIR: "-L{{.*}}{{/|}}..{{/|}}lib"



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


[PATCH] D100739: [Coroutines] Handle overaligned frame allocation (2)

2021-04-20 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu added inline comments.



Comment at: clang/docs/LanguageExtensions.rst:2689
 
-  size_t __builtin_coro_size()
+  size_t __builtin_coro_size(bool alloc)
   void  *__builtin_coro_frame()

ychen wrote:
> ChuanqiXu wrote:
> > ychen wrote:
> > > lxfind wrote:
> > > > Do we need to change __builtin_coro_size? The argument will always be 
> > > > 1, right?
> > > > It only starts to change in LLVM intrinsics, if I read the impl 
> > > > correctly.
> > > Yeah, It is always 1 for Clang until the spec is fixed (then we could 
> > > revert it back to 0).  Other clients using `__builtin_coro_size` may use 
> > > 0 if the client doesn't care about overaligned frame or it could handle 
> > > overaligned frame by itself. 
> > BTW, is it OK to edit the `builtin`s directly? Since builtin is different 
> > with intrinsic which is only visible in the internal of compiler, builtin 
> > could be used by any end users. Although I know there should be  little 
> > users who would use `__builtin_coro` APIs, I worry if there is any guide 
> > principle for editing the `builtin`s.
> > BTW, is it OK to edit the builtins directly? Since builtin is different 
> > with intrinsic which is only visible in the internal of compiler, builtin 
> > could be used by any end users. Although I know there should be little 
> > users who would use __builtin_coro APIs, I worry if there is any guide 
> > principle for editing the builtins.
> 
> I think it is ok to change these if it is justified like anything else.
> 
> builtins/intrinsics are interfaces on different levels. I'm trying to make 
> __builtin_coro_size consistent with llvm.coro.size because I don't have a 
> good reason for not doing that. (assume that we keep this opt-in overaligned 
> frame handling in LLVM even after the spec is fixed since it helps solve a 
> practical problem and the maintenance cost is low)
> 
> 
It doesn't make sense to me that we need to change the signature for 
`__builtin_coro_size` in this patch. In other words, why do we need to change 
`__builtin_coro_size `? What are problems that can't be solved if we don't 
change `__builtin_coro_size`? At least, if it is necessary to change 
`__builtin_coro_size`, we could make it in successive patches.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100739

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


[PATCH] D100739: [Coroutines] Handle overaligned frame allocation (2)

2021-04-20 Thread Yuanfang Chen via Phabricator via cfe-commits
ychen added inline comments.



Comment at: clang/docs/LanguageExtensions.rst:2689
 
-  size_t __builtin_coro_size()
+  size_t __builtin_coro_size(bool alloc)
   void  *__builtin_coro_frame()

ChuanqiXu wrote:
> ychen wrote:
> > lxfind wrote:
> > > Do we need to change __builtin_coro_size? The argument will always be 1, 
> > > right?
> > > It only starts to change in LLVM intrinsics, if I read the impl correctly.
> > Yeah, It is always 1 for Clang until the spec is fixed (then we could 
> > revert it back to 0).  Other clients using `__builtin_coro_size` may use 0 
> > if the client doesn't care about overaligned frame or it could handle 
> > overaligned frame by itself. 
> BTW, is it OK to edit the `builtin`s directly? Since builtin is different 
> with intrinsic which is only visible in the internal of compiler, builtin 
> could be used by any end users. Although I know there should be  little users 
> who would use `__builtin_coro` APIs, I worry if there is any guide principle 
> for editing the `builtin`s.
> BTW, is it OK to edit the builtins directly? Since builtin is different with 
> intrinsic which is only visible in the internal of compiler, builtin could be 
> used by any end users. Although I know there should be little users who would 
> use __builtin_coro APIs, I worry if there is any guide principle for editing 
> the builtins.

I think it is ok to change these if it is justified like anything else.

builtins/intrinsics are interfaces on different levels. I'm trying to make 
__builtin_coro_size consistent with llvm.coro.size because I don't have a good 
reason for not doing that. (assume that we keep this opt-in overaligned frame 
handling in LLVM even after the spec is fixed since it helps solve a practical 
problem and the maintenance cost is low)




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100739

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


[PATCH] D45639: [Driver] Support default libc++ library location on Darwin

2021-04-20 Thread Jonas Devlieghere via Phabricator via cfe-commits
JDevlieghere added a comment.

This breaks `TestAppleSimulatorOSType.py ` on GreenDragon. First failed build: 
http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/31346/

  /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/bin/clang  main.o 
-g -O0 -fno-builtin -isysroot 
"/Applications/Xcode.app/Contents/Developer/Platforms/WatchSimulator.platform/Developer/SDKs/WatchSimulator6.2.sdk"
 -arch i386  
-I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/make/../../../../../include
 
-I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/test/API/tools/lldb-server
 
-I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/make
 -include 
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/make/test_common.h
  -fno-limit-debug-info -target i386-apple-watchos6.2-simulator 
-mwatchos-simulator-version-min=6.2 -D__STDC_LIMIT_MACROS 
-D__STDC_FORMAT_MACROS   --driver-mode=g++ -o "test_simulator_platform_watchos"
  ld: warning: ignoring file 
/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lib/libc++.dylib, 
building for watchOS Simulator-i386 but attempting to link with file built for 
macOS-x86_64

Based on your description above, shouldn't it prefer the libc++ form the 
sysroot?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D45639

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


[PATCH] D100919: [AArch64] Support customizing stack protector guard

2021-04-20 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers planned changes to this revision.
nickdesaulniers added a comment.

Pretty sure I need to do something with non-zero values of 
`-mstack-protector-guard-offset=0`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100919

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


[PATCH] D100794: [HIP] Support overloaded math functions for hipRTC

2021-04-20 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl marked an inline comment as done.
yaxunl added inline comments.



Comment at: clang/lib/Headers/__clang_hip_cmath.h:347
+  static const bool value = !is_same::value;
 };
 

yaxunl wrote:
> tra wrote:
> > Nit: `}; // namespace __hip`
> will do
actually this is end of struct `__numeric_type`. end of namespace `__hip` is at 
line 390


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

https://reviews.llvm.org/D100794

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


[PATCH] D100794: [HIP] Support overloaded math functions for hipRTC

2021-04-20 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl marked an inline comment as done.
yaxunl added inline comments.



Comment at: clang/lib/Headers/__clang_hip_cmath.h:347
+  static const bool value = !is_same::value;
 };
 

tra wrote:
> Nit: `}; // namespace __hip`
will do


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

https://reviews.llvm.org/D100794

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


[PATCH] D100830: [RISCV] [1/2] Add IR intrinsic for Zbp extension

2021-04-20 Thread LevyHsu via Phabricator via cfe-commits
LevyHsu updated this revision to Diff 339086.
LevyHsu added a comment.

Change Log:

1. llvm/lib/Target/RISCV/RISCVInstrInfoB.td
  - Aligned SDNode def for shflw/unshfl/unshflw
  - Reordered def : PatGprImm;
  - Merged Pat def when Predicates = [HasStdExtZbp]

2. llvm/test/CodeGen/RISCV/rv32zbp-intrinsic.ll 
llvm/test/CodeGen/RISCV/rv64zbp-intrinsic.ll 
llvm/test/MC/RISCV/rv32b-aliases-valid.s 
llvm/test/MC/RISCV/rv64b-aliases-valid.s
  - Replaced all imm from 29 to 4


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100830

Files:
  clang/include/clang/Basic/BuiltinsRISCV.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbp.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbp.c
  llvm/include/llvm/IR/IntrinsicsRISCV.td
  llvm/lib/Target/RISCV/RISCVISelLowering.cpp
  llvm/lib/Target/RISCV/RISCVISelLowering.h
  llvm/lib/Target/RISCV/RISCVInstrInfoB.td
  llvm/test/CodeGen/RISCV/rv32zbp-intrinsic.ll
  llvm/test/CodeGen/RISCV/rv64zbp-intrinsic.ll
  llvm/test/MC/RISCV/rv32b-aliases-valid.s
  llvm/test/MC/RISCV/rv64b-aliases-valid.s

Index: llvm/test/MC/RISCV/rv64b-aliases-valid.s
===
--- llvm/test/MC/RISCV/rv64b-aliases-valid.s
+++ llvm/test/MC/RISCV/rv64b-aliases-valid.s
@@ -338,3 +338,27 @@
 # CHECK-S-OBJ-NOALIAS: bexti t0, t1, 8
 # CHECK-S-OBJ: bexti t0, t1, 8
 bext x5, x6, 8
+
+# CHECK-S-OBJ-NOALIAS: grevi t0, t1, 4
+# CHECK-S-OBJ: grevi t0, t1, 4
+grev x5, x6, 4
+
+# CHECK-S-OBJ-NOALIAS: gorci t0, t1, 4
+# CHECK-S-OBJ: gorci t0, t1, 4
+gorc x5, x6, 4
+
+# CHECK-S-OBJ-NOALIAS: shfli t0, t1, 4
+# CHECK-S-OBJ: shfli t0, t1, 4
+shfl x5, x6, 4
+
+# CHECK-S-OBJ-NOALIAS: unshfli t0, t1, 4
+# CHECK-S-OBJ: unshfli t0, t1, 4
+unshfl x5, x6, 4
+
+# CHECK-S-OBJ-NOALIAS: greviw t0, t1, 4
+# CHECK-S-OBJ: greviw t0, t1, 4
+grevw x5, x6, 4
+
+# CHECK-S-OBJ-NOALIAS: gorciw t0, t1, 4
+# CHECK-S-OBJ: gorciw t0, t1, 4
+gorcw x5, x6, 4
Index: llvm/test/MC/RISCV/rv32b-aliases-valid.s
===
--- llvm/test/MC/RISCV/rv32b-aliases-valid.s
+++ llvm/test/MC/RISCV/rv32b-aliases-valid.s
@@ -242,3 +242,19 @@
 # CHECK-S-OBJ-NOALIAS: bexti t0, t1, 8
 # CHECK-S-OBJ: bexti t0, t1, 8
 bext x5, x6, 8
+
+# CHECK-S-OBJ-NOALIAS: grevi t0, t1, 4
+# CHECK-S-OBJ: grevi t0, t1, 4
+grev x5, x6, 4
+
+# CHECK-S-OBJ-NOALIAS: gorci t0, t1, 4
+# CHECK-S-OBJ: gorci t0, t1, 4
+gorc x5, x6, 4
+
+# CHECK-S-OBJ-NOALIAS: shfli t0, t1, 4
+# CHECK-S-OBJ: shfli t0, t1, 4
+shfl x5, x6, 4
+
+# CHECK-S-OBJ-NOALIAS: unshfli t0, t1, 4
+# CHECK-S-OBJ: unshfli t0, t1, 4
+unshfl x5, x6, 4
Index: llvm/test/CodeGen/RISCV/rv64zbp-intrinsic.ll
===
--- /dev/null
+++ llvm/test/CodeGen/RISCV/rv64zbp-intrinsic.ll
@@ -0,0 +1,325 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple=riscv64 -mattr=+experimental-b -verify-machineinstrs < %s \
+; RUN:   | FileCheck %s -check-prefix=RV64IB
+; RUN: llc -mtriple=riscv64 -mattr=+experimental-zbp -verify-machineinstrs < %s \
+; RUN:   | FileCheck %s -check-prefix=RV64IBP
+
+declare i32 @llvm.riscv.grev.i32(i32 %a, i32 %b)
+
+define signext i32 @grev32(i32 signext %a, i32 signext %b) nounwind {
+; RV64IB-LABEL: grev32:
+; RV64IB:   # %bb.0:
+; RV64IB-NEXT:grevw a0, a0, a1
+; RV64IB-NEXT:ret
+;
+; RV64IBP-LABEL: grev32:
+; RV64IBP:   # %bb.0:
+; RV64IBP-NEXT:grevw a0, a0, a1
+; RV64IBP-NEXT:ret
+  %tmp = call i32 @llvm.riscv.grev.i32(i32 %a, i32 %b)
+ ret i32 %tmp
+}
+
+declare i32 @llvm.riscv.grevi.i32(i32 %a)
+
+define signext i32 @grevi32(i32 signext %a) nounwind {
+; RV64IB-LABEL: grevi32:
+; RV64IB:   # %bb.0:
+; RV64IB-NEXT:greviw a0, a0, 4
+; RV64IB-NEXT:ret
+;
+; RV64IBP-LABEL: grevi32:
+; RV64IBP:   # %bb.0:
+; RV64IBP-NEXT:greviw a0, a0, 4
+; RV64IBP-NEXT:ret
+  %tmp = call i32 @llvm.riscv.grev.i32(i32 %a, i32 4)
+ ret i32 %tmp
+}
+
+declare i32 @llvm.riscv.gorc.i32(i32 %a, i32 %b)
+
+define signext i32 @gorc32(i32 signext %a, i32 signext %b) nounwind {
+; RV64IB-LABEL: gorc32:
+; RV64IB:   # %bb.0:
+; RV64IB-NEXT:gorcw a0, a0, a1
+; RV64IB-NEXT:ret
+;
+; RV64IBP-LABEL: gorc32:
+; RV64IBP:   # %bb.0:
+; RV64IBP-NEXT:gorcw a0, a0, a1
+; RV64IBP-NEXT:ret
+  %tmp = call i32 @llvm.riscv.gorc.i32(i32 %a, i32 %b)
+ ret i32 %tmp
+}
+
+declare i32 @llvm.riscv.gorci.i32(i32 %a)
+
+define signext i32 @gorci32(i32 signext %a) nounwind {
+; RV64IB-LABEL: gorci32:
+; RV64IB:   # %bb.0:
+; RV64IB-NEXT:gorciw a0, a0, 4
+; RV64IB-NEXT:ret
+;
+; RV64IBP-LABEL: gorci32:
+; RV64IBP:   # %bb.0:
+; RV64IBP-NEXT:gorciw a0, a0, 4
+; RV64IBP-NEXT:ret
+  %tmp = call i32 @llvm.riscv.gorc.i32(i32 %a, i32 4)
+ ret i32 %tmp
+}
+
+declare i32 @llvm.riscv.shfl.i32(i32 %a, i32 %b)
+
+define signext i32 

[PATCH] D100368: [X86] Support some missing intrinsics

2021-04-20 Thread LiuChen via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG72e4bf12eec4: [X86] Support some missing intrinsics 
(authored by LiuChen3).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100368

Files:
  clang/lib/Headers/avx512fintrin.h
  clang/test/CodeGen/X86/avx512f-builtins.c

Index: clang/test/CodeGen/X86/avx512f-builtins.c
===
--- clang/test/CodeGen/X86/avx512f-builtins.c
+++ clang/test/CodeGen/X86/avx512f-builtins.c
@@ -10819,3 +10819,51 @@
   // CHECK: shufflevector <4 x i64> %{{.*}}, <4 x i64> %{{.*}}, <8 x i32> 
   return _mm512_zextsi256_si512(A);
 }
+
+__m512d test_mm512_i32logather_pd(__m512i __index, void const *__addr) {
+  // CHECK-LABEL: @test_mm512_i32logather_pd
+  // CHECK: @llvm.x86.avx512.mask.gather.dpd.512
+  return _mm512_i32logather_pd(__index, __addr, 2);
+}
+
+__m512d test_mm512_mask_i32logather_pd(__m512d __v1_old, __mmask8 __mask, __m512i __index, void const *__addr) {
+  // CHECK-LABEL: @test_mm512_mask_i32logather_pd
+  // CHECK: @llvm.x86.avx512.mask.gather.dpd.512
+  return _mm512_mask_i32logather_pd(__v1_old, __mask, __index, __addr, 2);
+}
+
+void test_mm512_i32loscatter_pd(void *__addr, __m512i __index, __m512d __v1) {
+  // CHECK-LABEL: @test_mm512_i32loscatter_pd
+  // CHECK: @llvm.x86.avx512.mask.scatter.dpd.512
+  return _mm512_i32loscatter_pd(__addr, __index, __v1, 2);
+}
+
+void test_mm512_mask_i32loscatter_pd(void *__addr, __mmask8 __mask, __m512i __index, __m512d __v1) {
+  // CHECK-LABEL: @test_mm512_mask_i32loscatter_pd
+  // CHECK: @llvm.x86.avx512.mask.scatter.dpd.512
+  return _mm512_mask_i32loscatter_pd(__addr, __mask, __index, __v1, 2);
+}
+
+__m512i test_mm512_i32logather_epi64(__m512i __index, void const *__addr) {
+  // CHECK-LABEL: @test_mm512_i32logather_epi64
+  // CHECK: @llvm.x86.avx512.mask.gather.dpq.512
+  return _mm512_i32logather_epi64(__index, __addr, 2);
+}
+
+__m512i test_mm512_mask_i32logather_epi64(__m512i __v1_old, __mmask8 __mask, __m512i __index, void const *__addr) {
+  // CHECK-LABEL: @test_mm512_mask_i32logather_epi64
+  // CHECK: @llvm.x86.avx512.mask.gather.dpq.512
+  return _mm512_mask_i32logather_epi64(__v1_old, __mask, __index, __addr, 2);
+}
+
+void test_mm512_i32loscatter_epi64(void *__addr, __m512i __index, __m512i __v1) {
+  // CHECK-LABEL: @test_mm512_i32loscatter_epi64
+  // CHECK: @llvm.x86.avx512.mask.scatter.dpq.512
+  _mm512_i32loscatter_epi64(__addr, __index, __v1, 2);
+}
+
+void test_mm512_mask_i32loscatter_epi64(void *__addr, __mmask8 __mask, __m512i __index, __m512i __v1) {
+  // CHECK-LABEL: @test_mm512_mask_i32loscatter_epi64
+  // CHECK: @llvm.x86.avx512.mask.scatter.dpq.512
+  _mm512_mask_i32loscatter_epi64(__addr, __mask, __index, __v1, 2);
+}
Index: clang/lib/Headers/avx512fintrin.h
===
--- clang/lib/Headers/avx512fintrin.h
+++ clang/lib/Headers/avx512fintrin.h
@@ -9588,6 +9588,169 @@
   return __b[0];
 }
 
+/// Loads 8 double-precision (64-bit) floating-point elements stored at memory
+/// locations starting at location \a base_addr at packed 32-bit integer indices
+/// stored in the lower half of \a vindex scaled by \a scale them in dst.
+///
+/// This intrinsic corresponds to the  VGATHERDPD  instructions.
+///
+/// \operation
+/// FOR j := 0 to 7
+///   i := j*64
+///   m := j*32
+///   addr := base_addr + SignExtend64(vindex[m+31:m]) * ZeroExtend64(scale) * 8
+///   dst[i+63:i] := MEM[addr+63:addr]
+/// ENDFOR
+/// dst[MAX:512] := 0
+/// \endoperation
+#define _mm512_i32logather_pd(vindex, base_addr, scale)\
+  _mm512_i32gather_pd(_mm512_castsi512_si256(vindex), (base_addr), (scale))
+
+/// Loads 8 double-precision (64-bit) floating-point elements from memory
+/// starting at location \a base_addr at packed 32-bit integer indices stored in
+/// the lower half of \a vindex scaled by \a scale into dst using writemask
+/// \a mask (elements are copied from \a src when the corresponding mask bit is
+/// not set).
+///
+/// This intrinsic corresponds to the  VGATHERDPD  instructions.
+///
+/// \operation
+/// FOR j := 0 to 7
+///   i := j*64
+///   m := j*32
+///   IF mask[j]
+/// addr := base_addr + SignExtend64(vindex[m+31:m]) * ZeroExtend64(scale) * 8
+/// dst[i+63:i] := MEM[addr+63:addr]
+///   ELSE
+/// dst[i+63:i] := src[i+63:i]
+///   FI
+/// ENDFOR
+/// dst[MAX:512] := 0
+/// \endoperation
+#define _mm512_mask_i32logather_pd(src, mask, vindex, base_addr, scale)\
+  _mm512_mask_i32gather_pd((src), (mask), _mm512_castsi512_si256(vindex),  \
+   (base_addr), (scale))
+
+/// Loads 8 64-bit integer elements from memory starting at location \a base_addr
+/// at packed 32-bit integer indices stored in the lower half of \a vindex
+/// 

[clang] 72e4bf1 - [X86] Support some missing intrinsics

2021-04-20 Thread via cfe-commits

Author: Liu, Chen3
Date: 2021-04-21T10:50:37+08:00
New Revision: 72e4bf12eec4e1526187b4f9445bc66a168552dd

URL: 
https://github.com/llvm/llvm-project/commit/72e4bf12eec4e1526187b4f9445bc66a168552dd
DIFF: 
https://github.com/llvm/llvm-project/commit/72e4bf12eec4e1526187b4f9445bc66a168552dd.diff

LOG: [X86] Support some missing intrinsics

Support for _mm512_i32logather_pd, _mm512_mask_i32logather_pd,
_mm512_i32logather_epi64, _mm512_mask_i32logather_epi64, _mm512_i32loscatter_pd,
_mm512_mask_i32loscatter_pd, _mm512_i32loscatter_epi64,
_mm512_mask_i32loscatter_epi64.

Differential Revision: https://reviews.llvm.org/D100368

Added: 


Modified: 
clang/lib/Headers/avx512fintrin.h
clang/test/CodeGen/X86/avx512f-builtins.c

Removed: 




diff  --git a/clang/lib/Headers/avx512fintrin.h 
b/clang/lib/Headers/avx512fintrin.h
index e60cb5f3df1f1..010bcadab0195 100644
--- a/clang/lib/Headers/avx512fintrin.h
+++ b/clang/lib/Headers/avx512fintrin.h
@@ -9588,6 +9588,169 @@ _mm512_cvtsi512_si32(__m512i __A) {
   return __b[0];
 }
 
+/// Loads 8 double-precision (64-bit) floating-point elements stored at memory
+/// locations starting at location \a base_addr at packed 32-bit integer 
indices
+/// stored in the lower half of \a vindex scaled by \a scale them in dst.
+///
+/// This intrinsic corresponds to the  VGATHERDPD  instructions.
+///
+/// \operation
+/// FOR j := 0 to 7
+///   i := j*64
+///   m := j*32
+///   addr := base_addr + SignExtend64(vindex[m+31:m]) * ZeroExtend64(scale) * 
8
+///   dst[i+63:i] := MEM[addr+63:addr]
+/// ENDFOR
+/// dst[MAX:512] := 0
+/// \endoperation
+#define _mm512_i32logather_pd(vindex, base_addr, scale)
\
+  _mm512_i32gather_pd(_mm512_castsi512_si256(vindex), (base_addr), (scale))
+
+/// Loads 8 double-precision (64-bit) floating-point elements from memory
+/// starting at location \a base_addr at packed 32-bit integer indices stored 
in
+/// the lower half of \a vindex scaled by \a scale into dst using writemask
+/// \a mask (elements are copied from \a src when the corresponding mask bit is
+/// not set).
+///
+/// This intrinsic corresponds to the  VGATHERDPD  instructions.
+///
+/// \operation
+/// FOR j := 0 to 7
+///   i := j*64
+///   m := j*32
+///   IF mask[j]
+/// addr := base_addr + SignExtend64(vindex[m+31:m]) * ZeroExtend64(scale) 
* 8
+/// dst[i+63:i] := MEM[addr+63:addr]
+///   ELSE
+/// dst[i+63:i] := src[i+63:i]
+///   FI
+/// ENDFOR
+/// dst[MAX:512] := 0
+/// \endoperation
+#define _mm512_mask_i32logather_pd(src, mask, vindex, base_addr, scale)
\
+  _mm512_mask_i32gather_pd((src), (mask), _mm512_castsi512_si256(vindex),  
\
+   (base_addr), (scale))
+
+/// Loads 8 64-bit integer elements from memory starting at location \a 
base_addr
+/// at packed 32-bit integer indices stored in the lower half of \a vindex
+/// scaled by \a scale and stores them in dst.
+///
+/// This intrinsic corresponds to the  VPGATHERDQ  instructions.
+///
+/// \operation
+/// FOR j := 0 to 7
+///   i := j*64
+///   m := j*32
+///   addr := base_addr + SignExtend64(vindex[m+31:m]) * ZeroExtend64(scale) * 
8
+///   dst[i+63:i] := MEM[addr+63:addr]
+/// ENDFOR
+/// dst[MAX:512] := 0
+/// \endoperation
+#define _mm512_i32logather_epi64(vindex, base_addr, scale) 
\
+  _mm512_i32gather_epi64(_mm512_castsi512_si256(vindex), (base_addr), (scale))
+
+/// Loads 8 64-bit integer elements from memory starting at location \a 
base_addr
+/// at packed 32-bit integer indices stored in the lower half of \a vindex
+/// scaled by \a scale and stores them in dst using writemask \a mask (elements
+/// are copied from \a src when the corresponding mask bit is not set).
+///
+/// This intrinsic corresponds to the  VPGATHERDQ  instructions.
+///
+/// \operation
+/// FOR j := 0 to 7
+///   i := j*64
+///   m := j*32
+///   IF mask[j]
+/// addr := base_addr + SignExtend64(vindex[m+31:m]) * ZeroExtend64(scale) 
* 8
+/// dst[i+63:i] := MEM[addr+63:addr]
+///   ELSE
+/// dst[i+63:i] := src[i+63:i]
+///   FI
+/// ENDFOR
+/// dst[MAX:512] := 0
+/// \endoperation
+#define _mm512_mask_i32logather_epi64(src, mask, vindex, base_addr, scale) 
\
+  _mm512_mask_i32gather_epi64((src), (mask), _mm512_castsi512_si256(vindex),   
\
+  (base_addr), (scale))
+
+/// Stores 8 packed double-precision (64-bit) floating-point elements in \a v1
+/// and to memory locations starting at location \a base_addr at packed 32-bit
+/// integer indices stored in \a vindex scaled by \a scale.
+///
+/// This intrinsic corresponds to the  VSCATTERDPD  instructions.
+///
+/// \operation
+/// FOR j := 0 to 7
+///   i := j*64
+///   m := j*32
+///   addr := base_addr + SignExtend64(vindex[m+31:m]) * ZeroExtend64(scale) * 
8
+///   MEM[addr+63:addr] := v1[i+63:i]
+/// ENDFOR
+/// \endoperation
+#define 

[PATCH] D100919: [AArch64] Support customizing stack protector guard

2021-04-20 Thread Xiang Zhang via Phabricator via cfe-commits
xiangzhangllvm accepted this revision.
xiangzhangllvm added a comment.
This revision is now accepted and ready to land.

I didn't find any problem in the main context of the patch, +1 first.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100919

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


[PATCH] D100739: [Coroutines] Handle overaligned frame allocation (2)

2021-04-20 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu added a comment.

There is something I am still confused about these two patch. Maybe I don't get 
the problem right.
The example problem shows if user uses `alignas` to specify the alignment for 
promise_type, the actual alignment for the promise isn't correctly due to 
compiler didn't call `new` method with alignment which isn't specified in the 
spec.
Then these two patches are trying to add paddings to the frame type to make the 
alignment of promise_type right. Here is a gap, in fact the problem comes from 
the alignment promise. But we want to solve it by over align the frame. It is 
odd for me.
I wonder if it is possible to simply adjust the alignment for the alloca of 
promise, like:

  %promise = alloca %promise_type, align 64




Comment at: clang/docs/LanguageExtensions.rst:2689
 
-  size_t __builtin_coro_size()
+  size_t __builtin_coro_size(bool alloc)
   void  *__builtin_coro_frame()

ychen wrote:
> lxfind wrote:
> > Do we need to change __builtin_coro_size? The argument will always be 1, 
> > right?
> > It only starts to change in LLVM intrinsics, if I read the impl correctly.
> Yeah, It is always 1 for Clang until the spec is fixed (then we could revert 
> it back to 0).  Other clients using `__builtin_coro_size` may use 0 if the 
> client doesn't care about overaligned frame or it could handle overaligned 
> frame by itself. 
BTW, is it OK to edit the `builtin`s directly? Since builtin is different with 
intrinsic which is only visible in the internal of compiler, builtin could be 
used by any end users. Although I know there should be  little users who would 
use `__builtin_coro` APIs, I worry if there is any guide principle for editing 
the `builtin`s.



Comment at: llvm/docs/Coroutines.rst:961
+declare i32 @llvm.coro.align.i32()
+declare i64 @llvm.coro.align.i64()
+

Maybe I was missing something. I think these two intrinsic should take one i8* 
argument to specify the coroutine handle. Otherwise, it may be confusing if 
there are some coroutines get inlined into other coroutine.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100739

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


[PATCH] D100776: [clang/Basic] Make TargetInfo.h not use DataLayout again

2021-04-20 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

> This keeps the assert that checks that the llvm DataLayout and the user label 
> prefix are in sync. See the NDEBUG in Mangle.cpp here-ish: 
> https://reviews.llvm.org/D100776#change-NN4Lz7xH29fo (I measured that that 
> assert doesn't slow down `check-clang` in a release+assert build too). So I 
> don't think this regresses safety.

It also keeps the easier-to-use resetDataLayout() API and sets the user label 
prefix as a 2nd (optional) arg in that function. That makes it harder to get 
them out of sync. And if you do get them out of sync, the assert will catch it 
as long as there's any test at all for that target. And if there isn't, you 
kind of have bigger problems :)


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

https://reviews.llvm.org/D100776

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


[PATCH] D100776: [clang/Basic] Make TargetInfo.h not use DataLayout again

2021-04-20 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

> So, if this is really causing some consternation then we can pull back and 
> reinstate what we had, but it was a direction around solving a set of hard to 
> find bugs.
>
> Thoughts?

This keeps the assert that checks that the llvm DataLayout and the user label 
prefix are in sync. See the NDEBUG in Mangle.cpp here-ish: 
https://reviews.llvm.org/D100776#change-NN4Lz7xH29fo (I measured that that 
assert doesn't slow down `check-clang` in a release+assert build too). So I 
don't think this regresses safety.


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

https://reviews.llvm.org/D100776

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


[PATCH] D100919: [AArch64] Support customizing stack protector guard

2021-04-20 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:3138
 }
+if (EffectiveTriple.isAArch64() && Value != "sp_el0") {
+  D.Diag(diag::err_drv_invalid_value_with_suggestion)

TODO: can we re-use `AArch64SysReg::lookupSysRegByName` in the frontend?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100919

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


[PATCH] D100919: [AArch64] Support customizing stack protector guard

2021-04-20 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers added a comment.

I still have some todos that I will get to tomorrow, but posting this early for 
review.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100919

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


[PATCH] D100919: [AArch64] Support customizing stack protector guard

2021-04-20 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers created this revision.
nickdesaulniers added reviewers: xiangzhangllvm, efriedma, MaskRay.
Herald added subscribers: dexonsmith, danielkiss, hiraditya, kristof.beyls.
nickdesaulniers requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

Follow up to D88631  but for aarch64; the 
Linux kernel uses the command
line flags:

1. -mstack-protector-guard=sysreg
2. -mstack-protector-guard-reg=sp_el0
3. -mstack-protector-guard-offset=0

to use the system register sp_el0 for the stack canary, enabling the
kernel to have a unique stack canary per task (like a thread, but not
limited to userspace as the kernel can preempt itself).

Address pr/47341 for aarch64.

Fixes: https://github.com/ClangBuiltLinux/linux/issues/289
Signed-off-by: Nick Desaulniers 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100919

Files:
  clang/include/clang/Basic/CodeGenOptions.h
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/stack-protector-guard.c
  llvm/include/llvm/Target/TargetOptions.h
  llvm/lib/CodeGen/CommandFlags.cpp
  llvm/lib/Target/AArch64/AArch64InstrInfo.cpp
  llvm/test/CodeGen/AArch64/stack-guard-sysreg.ll

Index: llvm/test/CodeGen/AArch64/stack-guard-sysreg.ll
===
--- /dev/null
+++ llvm/test/CodeGen/AArch64/stack-guard-sysreg.ll
@@ -0,0 +1,47 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc %s --stack-protector-guard=sysreg \
+; RUN:   --stack-protector-guard-reg=sp_el0 \
+; RUN:   --stack-protector-guard-offset=0 -o - | FileCheck %s
+
+target triple = "aarch64-unknown-linux-gnu"
+
+; Verify that we `mrs` from `SP_EL0` twice, rather than load from
+; __stack_chk_guard.
+define dso_local void @foo(i64 %t) local_unnamed_addr #0 {
+; CHECK-LABEL: foo:
+; CHECK:   // %bb.0: // %entry
+; CHECK-NEXT:stp x29, x30, [sp, #-16]! // 16-byte Folded Spill
+; CHECK-NEXT:mov x29, sp
+; CHECK-NEXT:sub sp, sp, #16 // =16
+; CHECK-NEXT:.cfi_def_cfa w29, 16
+; CHECK-NEXT:.cfi_offset w30, -8
+; CHECK-NEXT:.cfi_offset w29, -16
+; CHECK-NEXT:lsl x9, x0, #2
+; CHECK-NEXT:add x9, x9, #15 // =15
+; CHECK-NEXT:mrs x8, SP_EL0
+; CHECK-NEXT:stur x8, [x29, #-8]
+; CHECK-NEXT:mov x8, sp
+; CHECK-NEXT:and x9, x9, #0xfff0
+; CHECK-NEXT:sub x0, x8, x9
+; CHECK-NEXT:mov sp, x0
+; CHECK-NEXT:bl baz
+; CHECK-NEXT:ldur x8, [x29, #-8]
+; CHECK-NEXT:mrs x9, SP_EL0
+; CHECK-NEXT:cmp x9, x8
+; CHECK-NEXT:b.ne .LBB0_2
+; CHECK-NEXT:  // %bb.1: // %entry
+; CHECK-NEXT:mov sp, x29
+; CHECK-NEXT:ldp x29, x30, [sp], #16 // 16-byte Folded Reload
+; CHECK-NEXT:ret
+; CHECK-NEXT:  .LBB0_2: // %entry
+; CHECK-NEXT:bl __stack_chk_fail
+; CHECK-NOT: __stack_chk_guard
+entry:
+  %vla = alloca i32, i64 %t, align 4
+  call void @baz(i32* nonnull %vla)
+  ret void
+}
+
+declare dso_local void @baz(i32*) local_unnamed_addr
+
+attributes #0 = { sspstrong }
Index: llvm/lib/Target/AArch64/AArch64InstrInfo.cpp
===
--- llvm/lib/Target/AArch64/AArch64InstrInfo.cpp
+++ llvm/lib/Target/AArch64/AArch64InstrInfo.cpp
@@ -1752,6 +1752,21 @@
   }
 
   Register Reg = MI.getOperand(0).getReg();
+  if (MI.getOpcode() == AArch64::LOAD_STACK_GUARD) {
+TargetOptions Options = MI.getParent()->getParent()->getTarget().Options;
+if (Options.StackProtectorGuard == StackProtectorGuards::SysReg) {
+  const AArch64SysReg::SysReg *SrcReg =
+  AArch64SysReg::lookupSysRegByName(Options.StackProtectorGuardReg);
+  // TODO: if we're given a non-sense StackProtectorGuardReg, so
+  // SrcReg is nullptr, what should we do?
+  BuildMI(MBB, MI, DL, get(AArch64::MRS))
+  .addReg(Reg, getKillRegState(false))
+  .addImm(SrcReg->Encoding);
+  MBB.erase(MI);
+  return true;
+}
+  }
+
   const GlobalValue *GV =
   cast((*MI.memoperands_begin())->getValue());
   const TargetMachine  = MBB.getParent()->getTarget();
Index: llvm/lib/CodeGen/CommandFlags.cpp
===
--- llvm/lib/CodeGen/CommandFlags.cpp
+++ llvm/lib/CodeGen/CommandFlags.cpp
@@ -502,6 +502,8 @@
 return StackProtectorGuards::TLS;
   if (getStackProtectorGuard() == "global")
 return StackProtectorGuards::Global;
+  if (getStackProtectorGuard() == "sysreg")
+return StackProtectorGuards::SysReg;
   if (getStackProtectorGuard() != "none") {
 ErrorOr> MBOrErr =
 MemoryBuffer::getFile(getStackProtectorGuard());
Index: llvm/include/llvm/Target/TargetOptions.h
===
--- llvm/include/llvm/Target/TargetOptions.h
+++ llvm/include/llvm/Target/TargetOptions.h
@@ -73,11 +73,7 @@
 None// Do not use 

[PATCH] D100739: [Coroutines] Handle overaligned frame allocation (2)

2021-04-20 Thread Yuanfang Chen via Phabricator via cfe-commits
ychen added inline comments.



Comment at: clang/docs/LanguageExtensions.rst:2689
 
-  size_t __builtin_coro_size()
+  size_t __builtin_coro_size(bool alloc)
   void  *__builtin_coro_frame()

lxfind wrote:
> Do we need to change __builtin_coro_size? The argument will always be 1, 
> right?
> It only starts to change in LLVM intrinsics, if I read the impl correctly.
Yeah, It is always 1 for Clang until the spec is fixed (then we could revert it 
back to 0).  Other clients using `__builtin_coro_size` may use 0 if the client 
doesn't care about overaligned frame or it could handle overaligned frame by 
itself. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100739

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


[PATCH] D100739: [Coroutines] Handle overaligned frame allocation (2)

2021-04-20 Thread Xun Li via Phabricator via cfe-commits
lxfind added inline comments.



Comment at: clang/docs/LanguageExtensions.rst:2689
 
-  size_t __builtin_coro_size()
+  size_t __builtin_coro_size(bool alloc)
   void  *__builtin_coro_frame()

Do we need to change __builtin_coro_size? The argument will always be 1, right?
It only starts to change in LLVM intrinsics, if I read the impl correctly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100739

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


[PATCH] D77013: [AMDGPU] Add options -mamdgpu-ieee -mno-amdgpu-ieee

2021-04-20 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticDriverKinds.td:130-131
   "invalid argument '%0' only allowed with '%1'">;
+def err_drv_argument_only_allowed_with_or_equivalent : Error<
+  "invalid argument '%0' only allowed with '%1' or equivalent">;
 def err_drv_argument_not_allowed_with : Error<

This seems like a confusing message. Equivalent of what?



Comment at: clang/include/clang/Driver/Options.td:3176
+  CodeGenOpts<"EmitIEEENaNCompliantInsts">, DefaultTrue,
+  PosFlaghttps://reviews.llvm.org/D77013/new/

https://reviews.llvm.org/D77013

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


[PATCH] D100276: [clang] p1099 using enum part 1

2021-04-20 Thread Bruno Cardoso Lopes via Phabricator via cfe-commits
bruno added a comment.

Hi Nathan, thanks for implementing this. Besides formatting nitpicks, few other 
comments/questions:

- Update needed in cxx_status.html
- Should we support this as an extension for earlier C++ versions? This is a 
very handy feature. In clang terms, 
`warn_cxx17_compat_constexpr_body_invalid_stmt` and 
`ext_constexpr_body_invalid_stmt_cxx20` would be examples for that.

> Perhaps deferring the scope check until after construction of the 
> shadow-decls in the parsing case would be preferred?

Doing it as part of `BuildUsingDeclaration` seem reasonable, anything that 
might not work because of that?




Comment at: clang/lib/Sema/SemaDeclCXX.cpp:12353
+  ED = R->getAsSingle();
+else if (UD && UD->shadow_size () == 1)
+  ED = dyn_cast(UD->shadow_begin()->getTargetDecl());

-> `UD->shadow_size()`



Comment at: clang/lib/Sema/SemaDeclCXX.cpp:12370
 // If we weren't able to compute a valid scope, it might validly be a
 // dependent class scope or a dependent enumeration unscoped scope. If
 // we have a 'typename' keyword, the scope must resolve to a class type.

Does this comment needs update?



Comment at: clang/lib/Sema/SemaDeclCXX.cpp:12452
+  // The current scope is a record.
+
   if (!NamedContext->isRecord()) {

trim off newline



Comment at: clang/lib/Sema/SemaDeclCXX.cpp:12538
 
+
 Decl *Sema::ActOnAliasDeclaration(Scope *S, AccessSpecifier AS,

same here.



Comment at: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp:3079
+  // recheck the inheritance
+
   if (NameInfo.getName().getNameKind() == DeclarationName::CXXConstructorName)

here too



Comment at: clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p3.cpp:20
 class C {
+public:
   int g();

> The change to clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p3.cpp 
> is to silence an uninteresting access error that the above change causes.

The fact that the access check changed for previous version of the language 
(not necessarily related to p1099) indicates that this specific change deserves 
its own patch.



Comment at: 
clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p7-cxx20.cpp:1
+// RUN: %clang_cc1 -fsyntax-only -std=c++14 -verify %s
+// RUN: %clang_cc1 -fsyntax-only -std=c++20 -verify %s

Why not c++17?


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

https://reviews.llvm.org/D100276

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


[PATCH] D100823: [RISCV] Implement the pseudo compare builtin.

2021-04-20 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added a comment.

Thinking about this more, I'd like to consider doing this in the backend 
specifically for the compares for a few reasons.

-vmsgt(u).vv intrinsic already selects vmslt(u).vv with swapped operands in the 
backend. This was needed for SEW=64 on RV32.
-Inconsistent that some compare IR intrinsics accept vector or scalar second 
argument, but some only support scalar.
-We can probably generate better code for masked vmsge(u).vx if we defer 
expansion to post register allocation.
-Unifies the compare intrinsic implementation in the frontend.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100823

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


[PATCH] D100907: [lsan][docs] Clarify supported platforms

2021-04-20 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay marked an inline comment as done.
MaskRay added subscribers: fjricci, delcypher.
MaskRay added inline comments.



Comment at: clang/docs/LeakSanitizer.rst:49
+
+* Android aarch64/i386/x86_64
+* Linux arm/aarch64/mips64/ppc64/ppc64le/s390x/i386/x86\_64

vitalybuka wrote:
> MaskRay wrote:
> > vitalybuka wrote:
> > > Apple is incomplete and riscv is missing
> > > 
> > > ```
> > > if(APPLE)
> > >   set(ALL_LSAN_SUPPORTED_ARCH ${X86} ${X86_64} ${MIPS64} ${ARM64})
> > > else()
> > >   set(ALL_LSAN_SUPPORTED_ARCH ${X86} ${X86_64} ${MIPS64} ${ARM64} 
> > > ${ARM32} ${PPC64} ${S390X} ${RISCV64})
> > > endif()
> > > ```
> > I'll add riscv64 for Linux.
> > 
> > But wait, lib/sanitizer_common/sanitizer_stoptheworld_mac.cpp doesn't 
> > mention mips64...
> maybe work in progress
Likely a copy-paste error from de3b9a2ecc7e9ebe3fc1780aede0223821c52d2a 

I can delete it.

CC @delcypher @fjricci  who have touched the macOS code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100907

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


[PATCH] D100914: [clang] Revert "Re-fix _lrotl/_lrotr to always take Long, no matter the platform."

2021-04-20 Thread Alex Lorenz via Phabricator via cfe-commits
arphaman created this revision.
arphaman added reviewers: erichkeane, Bigcheese.
Herald added a subscriber: ributzka.
arphaman requested review of this revision.
Herald added a project: clang.

This reverts commit 92146ce399cdb26c3a9aa4d68af8cacb7c1c0fef. The original 
commit is from 2019, but we were unable to ship this change in clang in Xcode 
due to the issue explained below, so we would like to upstream the revert of 
this commit to help our clients test their build with upstream clang.

  

This commit broke users targeting LP64 (e.g. Microsoft's build of office for 
macOS) systems that expect these
intrinsics to match the MSVC behavior of working on 32 bit integers.
These users use a LONG macro which is defined as long on Windows
(LLP64), and int when targeting LP64 systems. Without this behavior
there is no intrinsic for 32 bit rotates on these platforms.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100914

Files:
  clang/include/clang/Basic/Builtins.def
  clang/test/CodeGen/ms-intrinsics-rotations.c


Index: clang/test/CodeGen/ms-intrinsics-rotations.c
===
--- clang/test/CodeGen/ms-intrinsics-rotations.c
+++ clang/test/CodeGen/ms-intrinsics-rotations.c
@@ -12,10 +12,17 @@
 // RUN: | FileCheck %s --check-prefixes CHECK,CHECK-32BIT-LONG
 // RUN: %clang_cc1 -ffreestanding -fms-extensions -fms-compatibility 
-fms-compatibility-version=17.00 \
 // RUN: -triple x86_64--linux -emit-llvm %s -o - \
-// RUN: | FileCheck %s --check-prefixes CHECK,CHECK-64BIT-LONG
+// RUN: | FileCheck %s --check-prefixes CHECK,CHECK-32BIT-LONG
 // RUN: %clang_cc1 -ffreestanding -fms-extensions \
 // RUN: -triple x86_64--darwin -emit-llvm %s -o - \
-// RUN: | FileCheck %s --check-prefixes CHECK,CHECK-64BIT-LONG
+// RUN: | FileCheck %s --check-prefixes CHECK,CHECK-32BIT-LONG
+
+// LP64 targets use 'long' as 'int' for MS intrinsics (-fms-extensions)
+#ifdef __LP64__
+#define LONG int
+#else
+#define LONG long
+#endif
 
 // rotate left
 
@@ -40,15 +47,12 @@
 // CHECK:   [[R:%.*]] = call i32 @llvm.fshl.i32(i32 [[X:%.*]], i32 [[X]], i32 
[[Y:%.*]])
 // CHECK:   ret i32 [[R]]
 
-unsigned long test_lrotl(unsigned long value, int shift) {
+unsigned LONG test_lrotl(unsigned LONG value, int shift) {
   return _lrotl(value, shift);
 }
 // CHECK-32BIT-LONG: i32 @test_lrotl
 // CHECK-32BIT-LONG:   [[R:%.*]] = call i32 @llvm.fshl.i32(i32 [[X:%.*]], i32 
[[X]], i32 [[Y:%.*]])
 // CHECK-32BIT-LONG:   ret i32 [[R]]
-// CHECK-64BIT-LONG: i64 @test_lrotl
-// CHECK-64BIT-LONG:   [[R:%.*]] = call i64 @llvm.fshl.i64(i64 [[X:%.*]], i64 
[[X]], i64 [[Y:%.*]])
-// CHECK-64BIT-LONG:   ret i64 [[R]]
 
 unsigned __int64 test_rotl64(unsigned __int64 value, int shift) {
   return _rotl64(value, shift);
@@ -80,15 +84,12 @@
 // CHECK:   [[R:%.*]] = call i32 @llvm.fshr.i32(i32 [[X:%.*]], i32 [[X]], i32 
[[Y:%.*]])
 // CHECK:   ret i32 [[R]]
 
-unsigned long test_lrotr(unsigned long value, int shift) {
+unsigned LONG test_lrotr(unsigned LONG value, int shift) {
   return _lrotr(value, shift);
 }
 // CHECK-32BIT-LONG: i32 @test_lrotr
 // CHECK-32BIT-LONG:   [[R:%.*]] = call i32 @llvm.fshr.i32(i32 [[X:%.*]], i32 
[[X]], i32 [[Y:%.*]])
 // CHECK-32BIT-LONG:   ret i32 [[R]]
-// CHECK-64BIT-LONG: i64 @test_lrotr
-// CHECK-64BIT-LONG:   [[R:%.*]] = call i64 @llvm.fshr.i64(i64 [[X:%.*]], i64 
[[X]], i64 [[Y:%.*]])
-// CHECK-64BIT-LONG:   ret i64 [[R]]
 
 unsigned __int64 test_rotr64(unsigned __int64 value, int shift) {
   return _rotr64(value, shift);
Index: clang/include/clang/Basic/Builtins.def
===
--- clang/include/clang/Basic/Builtins.def
+++ clang/include/clang/Basic/Builtins.def
@@ -947,12 +947,12 @@
 LANGBUILTIN(_rotl8,  "UcUcUc","n", ALL_MS_LANGUAGES)
 LANGBUILTIN(_rotl16, "UsUsUc","n", ALL_MS_LANGUAGES)
 LANGBUILTIN(_rotl,   "UiUii", "n", ALL_MS_LANGUAGES)
-LANGBUILTIN(_lrotl,  "ULiULii",   "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(_lrotl,  "UNiUNii",   "n", ALL_MS_LANGUAGES)
 LANGBUILTIN(_rotl64, "UWiUWii",   "n", ALL_MS_LANGUAGES)
 LANGBUILTIN(_rotr8,  "UcUcUc","n", ALL_MS_LANGUAGES)
 LANGBUILTIN(_rotr16, "UsUsUc","n", ALL_MS_LANGUAGES)
 LANGBUILTIN(_rotr,   "UiUii", "n", ALL_MS_LANGUAGES)
-LANGBUILTIN(_lrotr,  "ULiULii",   "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(_lrotr,  "UNiUNii",   "n", ALL_MS_LANGUAGES)
 LANGBUILTIN(_rotr64, "UWiUWii",   "n", ALL_MS_LANGUAGES)
 LANGBUILTIN(__va_start,   "vc**.", "nt", ALL_MS_LANGUAGES)
 LANGBUILTIN(__fastfail, "vUi","nr", ALL_MS_LANGUAGES)


Index: clang/test/CodeGen/ms-intrinsics-rotations.c
===
--- clang/test/CodeGen/ms-intrinsics-rotations.c
+++ clang/test/CodeGen/ms-intrinsics-rotations.c
@@ -12,10 +12,17 @@
 // RUN: | FileCheck %s --check-prefixes CHECK,CHECK-32BIT-LONG
 // RUN: %clang_cc1 -ffreestanding 

[PATCH] D100907: [lsan][docs] Clarify supported platforms

2021-04-20 Thread Vitaly Buka via Phabricator via cfe-commits
vitalybuka accepted this revision.
vitalybuka added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/docs/LeakSanitizer.rst:49
+
+* Android aarch64/i386/x86_64
+* Linux arm/aarch64/mips64/ppc64/ppc64le/s390x/i386/x86\_64

MaskRay wrote:
> vitalybuka wrote:
> > Apple is incomplete and riscv is missing
> > 
> > ```
> > if(APPLE)
> >   set(ALL_LSAN_SUPPORTED_ARCH ${X86} ${X86_64} ${MIPS64} ${ARM64})
> > else()
> >   set(ALL_LSAN_SUPPORTED_ARCH ${X86} ${X86_64} ${MIPS64} ${ARM64} ${ARM32} 
> > ${PPC64} ${S390X} ${RISCV64})
> > endif()
> > ```
> I'll add riscv64 for Linux.
> 
> But wait, lib/sanitizer_common/sanitizer_stoptheworld_mac.cpp doesn't mention 
> mips64...
maybe work in progress


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100907

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


[PATCH] D85802: [clang] Add -fc++-abi= flag for specifying which C++ ABI to use

2021-04-20 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan reopened this revision.
leonardchan added a comment.
This revision is now accepted and ready to land.
Herald added a subscriber: jansvoboda11.

Re-opening this based on discussions in D93668 
. The consensus is that this is OK as long as 
the compiler knows which ABIs work on which targets and rejects the unsupported 
configurations. (Still need to update this.)

This will also be used as a driver flag for selecting multilibs as part of the 
Fuchsia toolchain.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85802

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


[PATCH] D100834: Bug 49739 - [Matrix] Support #pragma clang fp

2021-04-20 Thread Hamza Mahfooz via Phabricator via cfe-commits
effective-light updated this revision to Diff 339048.
effective-light added a comment.

Use the correct clang command.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100834

Files:
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/test/CodeGen/fp-matrix-pragma.c


Index: clang/test/CodeGen/fp-matrix-pragma.c
===
--- /dev/null
+++ clang/test/CodeGen/fp-matrix-pragma.c
@@ -0,0 +1,33 @@
+// RUN: %clang -emit-llvm -S -fenable-matrix -mllvm -disable-llvm-optzns %s -o 
- | FileCheck %s
+
+typedef float fx2x2_t __attribute__((matrix_type(2, 2)));
+typedef int ix2x2_t __attribute__((matrix_type(2, 2)));
+
+fx2x2_t fp_matrix_contract(fx2x2_t a, fx2x2_t b, float c, float d) {
+// CHECK: call contract <4 x float> @llvm.matrix.multiply.v4f32.v4f32.v4f32
+// CHECK: fdiv contract <4 x float>
+// CHECK: fmul contract <4 x float>
+#pragma clang fp contract(fast)
+  return (a * b / c) * d;
+}
+
+fx2x2_t fp_matrix_reassoc(fx2x2_t a, fx2x2_t b, fx2x2_t c) {
+// CHECK: fadd reassoc <4 x float>
+// CHECK: fsub reassoc <4 x float>
+#pragma clang fp reassociate(on)
+  return a + b - c;
+}
+
+fx2x2_t fp_matrix_ops(fx2x2_t a, fx2x2_t b, fx2x2_t c) {
+// CHECK: call reassoc contract <4 x float> 
@llvm.matrix.multiply.v4f32.v4f32.v4f32
+// CHECK: fadd reassoc contract <4 x float>
+#pragma clang fp contract(fast) reassociate(on)
+  return a * b + c;
+}
+
+ix2x2_t int_matrix_ops(ix2x2_t a, ix2x2_t b, ix2x2_t c) {
+// CHECK: call <4 x i32> @llvm.matrix.multiply.v4i32.v4i32.v4i32
+// CHECK: add <4 x i32>
+#pragma clang fp contract(fast) reassociate(on)
+  return a * b + c;
+}
Index: clang/lib/CodeGen/CGExprScalar.cpp
===
--- clang/lib/CodeGen/CGExprScalar.cpp
+++ clang/lib/CodeGen/CGExprScalar.cpp
@@ -732,6 +732,7 @@
   BO->getLHS()->getType().getCanonicalType());
   auto *RHSMatTy = dyn_cast(
   BO->getRHS()->getType().getCanonicalType());
+  CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, Ops.FPFeatures);
   if (LHSMatTy && RHSMatTy)
 return MB.CreateMatrixMultiply(Ops.LHS, Ops.RHS, 
LHSMatTy->getNumRows(),
LHSMatTy->getNumColumns(),
@@ -3206,6 +3207,7 @@
 "first operand must be a matrix");
 assert(BO->getRHS()->getType().getCanonicalType()->isArithmeticType() &&
"second operand must be an arithmetic type");
+CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, Ops.FPFeatures);
 return MB.CreateScalarDiv(Ops.LHS, Ops.RHS,
   Ops.Ty->hasUnsignedIntegerRepresentation());
   }
@@ -3585,6 +3587,7 @@
 
   if (op.Ty->isConstantMatrixType()) {
 llvm::MatrixBuilder MB(Builder);
+CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, op.FPFeatures);
 return MB.CreateAdd(op.LHS, op.RHS);
   }
 
@@ -3734,6 +3737,7 @@
 
 if (op.Ty->isConstantMatrixType()) {
   llvm::MatrixBuilder MB(Builder);
+  CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, op.FPFeatures);
   return MB.CreateSub(op.LHS, op.RHS);
 }
 


Index: clang/test/CodeGen/fp-matrix-pragma.c
===
--- /dev/null
+++ clang/test/CodeGen/fp-matrix-pragma.c
@@ -0,0 +1,33 @@
+// RUN: %clang -emit-llvm -S -fenable-matrix -mllvm -disable-llvm-optzns %s -o - | FileCheck %s
+
+typedef float fx2x2_t __attribute__((matrix_type(2, 2)));
+typedef int ix2x2_t __attribute__((matrix_type(2, 2)));
+
+fx2x2_t fp_matrix_contract(fx2x2_t a, fx2x2_t b, float c, float d) {
+// CHECK: call contract <4 x float> @llvm.matrix.multiply.v4f32.v4f32.v4f32
+// CHECK: fdiv contract <4 x float>
+// CHECK: fmul contract <4 x float>
+#pragma clang fp contract(fast)
+  return (a * b / c) * d;
+}
+
+fx2x2_t fp_matrix_reassoc(fx2x2_t a, fx2x2_t b, fx2x2_t c) {
+// CHECK: fadd reassoc <4 x float>
+// CHECK: fsub reassoc <4 x float>
+#pragma clang fp reassociate(on)
+  return a + b - c;
+}
+
+fx2x2_t fp_matrix_ops(fx2x2_t a, fx2x2_t b, fx2x2_t c) {
+// CHECK: call reassoc contract <4 x float> @llvm.matrix.multiply.v4f32.v4f32.v4f32
+// CHECK: fadd reassoc contract <4 x float>
+#pragma clang fp contract(fast) reassociate(on)
+  return a * b + c;
+}
+
+ix2x2_t int_matrix_ops(ix2x2_t a, ix2x2_t b, ix2x2_t c) {
+// CHECK: call <4 x i32> @llvm.matrix.multiply.v4i32.v4i32.v4i32
+// CHECK: add <4 x i32>
+#pragma clang fp contract(fast) reassociate(on)
+  return a * b + c;
+}
Index: clang/lib/CodeGen/CGExprScalar.cpp
===
--- clang/lib/CodeGen/CGExprScalar.cpp
+++ clang/lib/CodeGen/CGExprScalar.cpp
@@ -732,6 +732,7 @@
   BO->getLHS()->getType().getCanonicalType());
   auto *RHSMatTy = dyn_cast(
   BO->getRHS()->getType().getCanonicalType());
+  CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, Ops.FPFeatures);
   if 

[PATCH] D100907: [lsan][docs] Clarify supported platforms

2021-04-20 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay updated this revision to Diff 339045.
MaskRay added a comment.

Fuchsia -> Fuchsia aarch64/x86_64


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100907

Files:
  clang/docs/LeakSanitizer.rst


Index: clang/docs/LeakSanitizer.rst
===
--- clang/docs/LeakSanitizer.rst
+++ clang/docs/LeakSanitizer.rst
@@ -17,8 +17,8 @@
 Usage
 =
 
-LeakSanitizer is supported on x86\_64 Linux and macOS. In order to use it,
-simply build your program with :doc:`AddressSanitizer`:
+:doc:`AddressSanitizer`: integrates LeakSanitizer and enables it by default on
+supported platforms.
 
 .. code-block:: console
 
@@ -43,6 +43,15 @@
 link step, so that it would link in proper LeakSanitizer run-time library
 into the final executable.
 
+Supported Platforms
+===
+
+* Android aarch64/i386/x86_64
+* Fuchsia aarch64/x86_64
+* Linux arm/aarch64/mips64/ppc64/ppc64le/riscv64/s390x/i386/x86\_64
+* macOS aarch64/i386/x86\_64
+* NetBSD i386/x86_64
+
 More Information
 
 


Index: clang/docs/LeakSanitizer.rst
===
--- clang/docs/LeakSanitizer.rst
+++ clang/docs/LeakSanitizer.rst
@@ -17,8 +17,8 @@
 Usage
 =
 
-LeakSanitizer is supported on x86\_64 Linux and macOS. In order to use it,
-simply build your program with :doc:`AddressSanitizer`:
+:doc:`AddressSanitizer`: integrates LeakSanitizer and enables it by default on
+supported platforms.
 
 .. code-block:: console
 
@@ -43,6 +43,15 @@
 link step, so that it would link in proper LeakSanitizer run-time library
 into the final executable.
 
+Supported Platforms
+===
+
+* Android aarch64/i386/x86_64
+* Fuchsia aarch64/x86_64
+* Linux arm/aarch64/mips64/ppc64/ppc64le/riscv64/s390x/i386/x86\_64
+* macOS aarch64/i386/x86\_64
+* NetBSD i386/x86_64
+
 More Information
 
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D100907: [lsan][docs] Clarify supported platforms

2021-04-20 Thread Petr Hosek via Phabricator via cfe-commits
phosek added inline comments.



Comment at: clang/docs/LeakSanitizer.rst:50
+* Android aarch64/i386/x86_64
+* Fuchsia
+* Linux arm/aarch64/mips64/ppc64/ppc64le/riscv64/s390x/i386/x86\_64

You can clarify that Fuchsia supports aarch64 and x86_64.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100907

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


[PATCH] D100415: [Coroutines] Split coroutine during CoroEarly into an init and ramp function

2021-04-20 Thread Xun Li via Phabricator via cfe-commits
lxfind planned changes to this revision.
lxfind added a comment.

Plan to add documentation, fix Legacy pass and address comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100415

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


[PATCH] D100907: [lsan][docs] Clarify supported platforms

2021-04-20 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay updated this revision to Diff 339039.
MaskRay added a comment.
Herald added subscribers: phosek, s.egerton, simoncook.

Add Linux riscv64.
Add Fuchsia


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100907

Files:
  clang/docs/LeakSanitizer.rst


Index: clang/docs/LeakSanitizer.rst
===
--- clang/docs/LeakSanitizer.rst
+++ clang/docs/LeakSanitizer.rst
@@ -17,8 +17,8 @@
 Usage
 =
 
-LeakSanitizer is supported on x86\_64 Linux and macOS. In order to use it,
-simply build your program with :doc:`AddressSanitizer`:
+:doc:`AddressSanitizer`: integrates LeakSanitizer and enables it by default on
+supported platforms.
 
 .. code-block:: console
 
@@ -43,6 +43,15 @@
 link step, so that it would link in proper LeakSanitizer run-time library
 into the final executable.
 
+Supported Platforms
+===
+
+* Android aarch64/i386/x86_64
+* Fuchsia
+* Linux arm/aarch64/mips64/ppc64/ppc64le/riscv64/s390x/i386/x86\_64
+* macOS aarch64/i386/x86\_64
+* NetBSD i386/x86_64
+
 More Information
 
 


Index: clang/docs/LeakSanitizer.rst
===
--- clang/docs/LeakSanitizer.rst
+++ clang/docs/LeakSanitizer.rst
@@ -17,8 +17,8 @@
 Usage
 =
 
-LeakSanitizer is supported on x86\_64 Linux and macOS. In order to use it,
-simply build your program with :doc:`AddressSanitizer`:
+:doc:`AddressSanitizer`: integrates LeakSanitizer and enables it by default on
+supported platforms.
 
 .. code-block:: console
 
@@ -43,6 +43,15 @@
 link step, so that it would link in proper LeakSanitizer run-time library
 into the final executable.
 
+Supported Platforms
+===
+
+* Android aarch64/i386/x86_64
+* Fuchsia
+* Linux arm/aarch64/mips64/ppc64/ppc64le/riscv64/s390x/i386/x86\_64
+* macOS aarch64/i386/x86\_64
+* NetBSD i386/x86_64
+
 More Information
 
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D100794: [HIP] Support overloaded math functions for hipRTC

2021-04-20 Thread Artem Belevich via Phabricator via cfe-commits
tra accepted this revision.
tra added a comment.
This revision is now accepted and ready to land.

LGTM.




Comment at: clang/lib/Headers/__clang_hip_cmath.h:347
+  static const bool value = !is_same::value;
 };
 

Nit: `}; // namespace __hip`


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

https://reviews.llvm.org/D100794

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


[PATCH] D100907: [lsan][docs] Clarify supported platforms

2021-04-20 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added inline comments.



Comment at: clang/docs/LeakSanitizer.rst:49
+
+* Android aarch64/i386/x86_64
+* Linux arm/aarch64/mips64/ppc64/ppc64le/s390x/i386/x86\_64

vitalybuka wrote:
> Apple is incomplete and riscv is missing
> 
> ```
> if(APPLE)
>   set(ALL_LSAN_SUPPORTED_ARCH ${X86} ${X86_64} ${MIPS64} ${ARM64})
> else()
>   set(ALL_LSAN_SUPPORTED_ARCH ${X86} ${X86_64} ${MIPS64} ${ARM64} ${ARM32} 
> ${PPC64} ${S390X} ${RISCV64})
> endif()
> ```
I'll add riscv64 for Linux.

But wait, lib/sanitizer_common/sanitizer_stoptheworld_mac.cpp doesn't mention 
mips64...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100907

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


[PATCH] D100000: [clang] WIP: Implement simpler alternative to two-phase lookup for NRVO

2021-04-20 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov updated this revision to Diff 339035.
mizvekov added a comment.
Herald added a subscriber: dexonsmith.

Initial implementation, still WIP.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D10

Files:
  clang/include/clang/AST/Expr.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Specifiers.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ExprClassification.cpp
  clang/lib/AST/JSONNodeDumper.cpp
  clang/lib/AST/TextNodeDumper.cpp
  clang/lib/CodeGen/CGDecl.cpp
  clang/lib/CodeGen/CGObjC.cpp
  clang/lib/Sema/SemaCodeComplete.cpp
  clang/lib/Sema/SemaCoroutine.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaInit.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/test/CXX/class/class.init/class.copy.elision/p3.cpp
  clang/test/SemaCXX/P1155.cpp
  clang/test/SemaCXX/conversion-function.cpp
  clang/test/SemaCXX/coroutine-rvo.cpp
  clang/test/SemaCXX/warn-return-std-move.cpp

Index: clang/test/SemaCXX/warn-return-std-move.cpp
===
--- clang/test/SemaCXX/warn-return-std-move.cpp
+++ clang/test/SemaCXX/warn-return-std-move.cpp
@@ -1,8 +1,8 @@
-// RUN: %clang_cc1 -std=c++2b -fsyntax-only -verify=cxx20_2b,cxx2b -fcxx-exceptions -Wreturn-std-move %s
-// RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify=cxx20_2b   -fcxx-exceptions -Wreturn-std-move %s
-// RUN: %clang_cc1 -std=c++17 -fsyntax-only -verify=cxx11_17   -fcxx-exceptions -Wreturn-std-move %s
-// RUN: %clang_cc1 -std=c++14 -fsyntax-only -verify=cxx11_17   -fcxx-exceptions -Wreturn-std-move %s
-// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify=cxx11_17   -fcxx-exceptions -Wreturn-std-move %s
+// RUN: %clang_cc1 -std=c++2b -fsyntax-only -verify=expected,cxx20_2b,cxx2b-fcxx-exceptions -Wreturn-std-move %s
+// RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify=expected,cxx20_2b,cxx11_20 -fcxx-exceptions -Wreturn-std-move %s
+// RUN: %clang_cc1 -std=c++17 -fsyntax-only -verify=expected,cxx11_17,cxx11_20 -fcxx-exceptions -Wreturn-std-move %s
+// RUN: %clang_cc1 -std=c++14 -fsyntax-only -verify=expected,cxx11_17,cxx11_20 -fcxx-exceptions -Wreturn-std-move %s
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify=expected,cxx11_17,cxx11_20 -fcxx-exceptions -Wreturn-std-move %s
 
 // RUN: %clang_cc1 -std=c++17 -fsyntax-only -fcxx-exceptions -Wreturn-std-move -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s -check-prefix=CHECK
 // RUN: %clang_cc1 -std=c++14 -fsyntax-only -fcxx-exceptions -Wreturn-std-move -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s -check-prefix=CHECK
@@ -78,9 +78,6 @@
 Base test2() {
 Derived d2;
 return d2;  // e1
-// cxx11_17-warning@-1{{will be copied despite being returned by name}}
-// cxx11_17-note@-2{{to avoid copying}}
-// CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:12-[[@LINE-3]]:14}:"std::move(d2)"
 }
 ConstructFromDerived test3() {
   Derived d3;
@@ -89,23 +86,14 @@
 ConstructFromBase test4() {
 Derived d4;
 return d4;  // e3
-// cxx11_17-warning@-1{{will be copied despite being returned by name}}
-// cxx11_17-note@-2{{to avoid copying}}
-// CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:12-[[@LINE-3]]:14}:"std::move(d4)"
 }
 ConvertFromDerived test5() {
 Derived d5;
 return d5;  // e4
-// cxx11_17-warning@-1{{will be copied despite being returned by name}}
-// cxx11_17-note@-2{{to avoid copying}}
-// CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:12-[[@LINE-3]]:14}:"std::move(d5)"
 }
 ConvertFromBase test6() {
 Derived d6;
 return d6;  // e5
-// cxx11_17-warning@-1{{will be copied despite being returned by name}}
-// cxx11_17-note@-2{{to avoid copying}}
-// CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:12-[[@LINE-3]]:14}:"std::move(d6)"
 }
 
 // These test cases should not produce the warning.
@@ -152,30 +140,18 @@
 Derived testParam1(Derived d) { return d; }
 Base testParam2(Derived d) {
 return d;  // e6
-// cxx11_17-warning@-1{{will be copied despite being returned by name}}
-// cxx11_17-note@-2{{to avoid copying}}
-// CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:12-[[@LINE-3]]:13}:"std::move(d)"
 }
 ConstructFromDerived testParam3(Derived d) {
   return d; // ok
 }
 ConstructFromBase testParam4(Derived d) {
 return d;  // e8
-// cxx11_17-warning@-1{{will be copied despite being returned by name}}
-// cxx11_17-note@-2{{to avoid copying}}
-// CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:12-[[@LINE-3]]:13}:"std::move(d)"
 }
 ConvertFromDerived testParam5(Derived d) {
 return d;  // e9
-// cxx11_17-warning@-1{{will be copied despite being returned by name}}
-// cxx11_17-note@-2{{to avoid copying}}
-// CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:12-[[@LINE-3]]:13}:"std::move(d)"
 }
 ConvertFromBase testParam6(Derived d) {
 return d;  // e10

[PATCH] D100907: [lsan][docs] Clarify supported platforms

2021-04-20 Thread Vitaly Buka via Phabricator via cfe-commits
vitalybuka added inline comments.



Comment at: clang/docs/LeakSanitizer.rst:49
+
+* Android aarch64/i386/x86_64
+* Linux arm/aarch64/mips64/ppc64/ppc64le/s390x/i386/x86\_64

Apple is incomplete and riscv is missing

```
if(APPLE)
  set(ALL_LSAN_SUPPORTED_ARCH ${X86} ${X86_64} ${MIPS64} ${ARM64})
else()
  set(ALL_LSAN_SUPPORTED_ARCH ${X86} ${X86_64} ${MIPS64} ${ARM64} ${ARM32} 
${PPC64} ${S390X} ${RISCV64})
endif()
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100907

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


[PATCH] D100907: [lsan][docs] Clarify supported platforms

2021-04-20 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay updated this revision to Diff 339032.
MaskRay added a comment.

add i386/aarch64 to macOS


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100907

Files:
  clang/docs/LeakSanitizer.rst


Index: clang/docs/LeakSanitizer.rst
===
--- clang/docs/LeakSanitizer.rst
+++ clang/docs/LeakSanitizer.rst
@@ -17,8 +17,8 @@
 Usage
 =
 
-LeakSanitizer is supported on x86\_64 Linux and macOS. In order to use it,
-simply build your program with :doc:`AddressSanitizer`:
+:doc:`AddressSanitizer`: integrates LeakSanitizer and enables it by default on
+supported platforms.
 
 .. code-block:: console
 
@@ -43,6 +43,14 @@
 link step, so that it would link in proper LeakSanitizer run-time library
 into the final executable.
 
+Supported Platforms
+===
+
+* Android aarch64/i386/x86_64
+* Linux arm/aarch64/mips64/ppc64/ppc64le/s390x/i386/x86\_64
+* macOS aarch64/i386/x86\_64
+* NetBSD i386/x86_64
+
 More Information
 
 


Index: clang/docs/LeakSanitizer.rst
===
--- clang/docs/LeakSanitizer.rst
+++ clang/docs/LeakSanitizer.rst
@@ -17,8 +17,8 @@
 Usage
 =
 
-LeakSanitizer is supported on x86\_64 Linux and macOS. In order to use it,
-simply build your program with :doc:`AddressSanitizer`:
+:doc:`AddressSanitizer`: integrates LeakSanitizer and enables it by default on
+supported platforms.
 
 .. code-block:: console
 
@@ -43,6 +43,14 @@
 link step, so that it would link in proper LeakSanitizer run-time library
 into the final executable.
 
+Supported Platforms
+===
+
+* Android aarch64/i386/x86_64
+* Linux arm/aarch64/mips64/ppc64/ppc64le/s390x/i386/x86\_64
+* macOS aarch64/i386/x86\_64
+* NetBSD i386/x86_64
+
 More Information
 
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D100907: [lsan][docs] Clarify supported platforms

2021-04-20 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay created this revision.
MaskRay added reviewers: Sanitizers, vitalybuka.
MaskRay requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100907

Files:
  clang/docs/LeakSanitizer.rst


Index: clang/docs/LeakSanitizer.rst
===
--- clang/docs/LeakSanitizer.rst
+++ clang/docs/LeakSanitizer.rst
@@ -17,8 +17,8 @@
 Usage
 =
 
-LeakSanitizer is supported on x86\_64 Linux and macOS. In order to use it,
-simply build your program with :doc:`AddressSanitizer`:
+:doc:`AddressSanitizer`: integrates LeakSanitizer and enables it by default on
+supported platforms.
 
 .. code-block:: console
 
@@ -43,6 +43,14 @@
 link step, so that it would link in proper LeakSanitizer run-time library
 into the final executable.
 
+Supported Platforms
+===
+
+* Android aarch64/i386/x86_64
+* Linux arm/aarch64/mips64/ppc64/ppc64le/s390x/i386/x86\_64
+* macOS x86\_64
+* NetBSD i386/x86_64
+
 More Information
 
 


Index: clang/docs/LeakSanitizer.rst
===
--- clang/docs/LeakSanitizer.rst
+++ clang/docs/LeakSanitizer.rst
@@ -17,8 +17,8 @@
 Usage
 =
 
-LeakSanitizer is supported on x86\_64 Linux and macOS. In order to use it,
-simply build your program with :doc:`AddressSanitizer`:
+:doc:`AddressSanitizer`: integrates LeakSanitizer and enables it by default on
+supported platforms.
 
 .. code-block:: console
 
@@ -43,6 +43,14 @@
 link step, so that it would link in proper LeakSanitizer run-time library
 into the final executable.
 
+Supported Platforms
+===
+
+* Android aarch64/i386/x86_64
+* Linux arm/aarch64/mips64/ppc64/ppc64le/s390x/i386/x86\_64
+* macOS x86\_64
+* NetBSD i386/x86_64
+
 More Information
 
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D100807: [clang][driver] Use the canonical Darwin arch name when printing out the triple for a Darwin target

2021-04-20 Thread Alex Lorenz via Phabricator via cfe-commits
arphaman added a comment.

In D100807#2702675 , @ab wrote:

> This sounds nice!  One idea, maybe more dangerous, not sure which is better:  
> in `setTripleTypeForMachOArchName`, we already have a couple `setArchName` 
> calls, I think that's why `arm64e` is left alone in the `aarch64-cpus.c` 
> test.  Maybe we can do the `setArchName` call for every arch there?

Thanks for the suggestion! I like your idea better, so I updated the patch.

> Another question, probably a completely separate problem: why is it still 
> reporting darwin?  Ideally we'd want it to report macos, right?  With that + 
> your change the triple there would be the actual triple we use to build.  
> (but maybe the macos bit only comes later when we pick up an SDK in 
> DarwinClang or whatever?)

I think that's the default we set in the build. I do want to get rid of the 
'Darwin' triple OS and just leave it as an alias for the driver at some point 
in the future as I don't think it's serving a good purpose anymore, but I 
haven't gotten around to it. I can explore using 'macOS' triples for the build 
before then though.


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

https://reviews.llvm.org/D100807

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


[PATCH] D100807: [clang][driver] Use the canonical Darwin arch name when printing out the triple for a Darwin target

2021-04-20 Thread Alex Lorenz via Phabricator via cfe-commits
arphaman updated this revision to Diff 339027.
arphaman added a comment.

Updated with Ahmed's suggestion.


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

https://reviews.llvm.org/D100807

Files:
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/test/Driver/aarch64-cpus.c
  clang/test/Driver/arm64_32-link.c
  clang/test/Driver/darwin-version.c
  clang/test/Driver/default-toolchain.c


Index: clang/test/Driver/default-toolchain.c
===
--- clang/test/Driver/default-toolchain.c
+++ clang/test/Driver/default-toolchain.c
@@ -6,3 +6,6 @@
 
 // RUN: %clang -target i386-apple-darwin9 -arch ppc64 -m32 -v 2> %t
 // RUN: grep 'Target: powerpc-apple-darwin9' %t
+
+// RUN: %clang -target x86_64-apple-macos11 -arch arm64 -v 2>&1 | FileCheck 
--check-prefix=ARM64 %s
+// ARM64: Target: arm64-apple-macos11
Index: clang/test/Driver/darwin-version.c
===
--- clang/test/Driver/darwin-version.c
+++ clang/test/Driver/darwin-version.c
@@ -60,17 +60,17 @@
 // RUN:   FileCheck --check-prefix=CHECK-VERSION-OSX4 %s
 // RUN: %clang -target i686-apple-darwin9 -mmacosx-version-min=10.4 -c %s -### 
2>&1 | \
 // RUN:   FileCheck --check-prefix=CHECK-VERSION-OSX4 %s
-// CHECK-VERSION-OSX4: "i386-apple-macosx10.4.0"
+// CHECK-VERSION-OSX4: "i686-apple-macosx10.4.0"
 // RUN: %clang -target i686-apple-darwin9 -c %s -### 2>&1 | \
 // RUN:   FileCheck --check-prefix=CHECK-VERSION-OSX5 %s
 // RUN: %clang -target i686-apple-darwin9 -mmacosx-version-min=10.5 -c %s -### 
2>&1 | \
 // RUN:   FileCheck --check-prefix=CHECK-VERSION-OSX5 %s
-// CHECK-VERSION-OSX5: "i386-apple-macosx10.5.0"
+// CHECK-VERSION-OSX5: "i686-apple-macosx10.5.0"
 // RUN: %clang -target i686-apple-darwin10 -c %s -### 2>&1 | \
 // RUN:   FileCheck --check-prefix=CHECK-VERSION-OSX6 %s
 // RUN: %clang -target i686-apple-darwin9 -mmacosx-version-min=10.6 -c %s -### 
2>&1 | \
 // RUN:   FileCheck --check-prefix=CHECK-VERSION-OSX6 %s
-// CHECK-VERSION-OSX6: "i386-apple-macosx10.6.0"
+// CHECK-VERSION-OSX6: "i686-apple-macosx10.6.0"
 // RUN: %clang -target x86_64-apple-darwin14 -c %s -### 2>&1 | \
 // RUN:   FileCheck --check-prefix=CHECK-VERSION-OSX10 %s
 // RUN: %clang -target x86_64-apple-darwin -mmacosx-version-min=10.10 -c %s 
-### 2>&1 | \
@@ -100,7 +100,7 @@
 
 // Check environment variable gets interpreted correctly
 // RUN: env MACOSX_DEPLOYMENT_TARGET=10.5 IPHONEOS_DEPLOYMENT_TARGET=2.0 \
-// RUN:   %clang -target i386-apple-darwin9 -c %s -### 2>&1 | \
+// RUN:   %clang -target i686-apple-darwin9 -c %s -### 2>&1 | \
 // RUN:   FileCheck --check-prefix=CHECK-VERSION-OSX5 %s
 // RUN: env MACOSX_DEPLOYMENT_TARGET=10.5 IPHONEOS_DEPLOYMENT_TARGET=2.0 \
 // RUN:   %clang -target armv6-apple-darwin9 -c %s -### 2>&1 | \
Index: clang/test/Driver/arm64_32-link.c
===
--- clang/test/Driver/arm64_32-link.c
+++ clang/test/Driver/arm64_32-link.c
@@ -1,4 +1,4 @@
 // RUN: %clang -target x86_64-apple-darwin -arch arm64_32 
-miphoneos-version-min=8.0 %s -### 2>&1 | FileCheck %s
 
-// CHECK: "-cc1"{{.*}} "-triple" "aarch64_32-apple-ios8.0.0"
+// CHECK: "-cc1"{{.*}} "-triple" "arm64_32-apple-ios8.0.0"
 // CHECK: ld{{.*}} "-arch" "arm64_32"
Index: clang/test/Driver/aarch64-cpus.c
===
--- clang/test/Driver/aarch64-cpus.c
+++ clang/test/Driver/aarch64-cpus.c
@@ -33,7 +33,7 @@
 // ARM64E-DARWIN: "-cc1"{{.*}} "-triple" "arm64e{{.*}}" "-target-cpu" 
"apple-a12"
 
 // RUN: %clang -target arm64-apple-darwin -arch arm64_32 -### -c %s 2>&1 | 
FileCheck -check-prefix=ARM64_32-DARWIN %s
-// ARM64_32-DARWIN: "-cc1"{{.*}} "-triple" "aarch64_32{{.*}}" "-target-cpu" 
"apple-s4"
+// ARM64_32-DARWIN: "-cc1"{{.*}} "-triple" "arm64_32{{.*}}" "-target-cpu" 
"apple-s4"
 
 // RUN: %clang -target aarch64 -mcpu=cortex-a35 -### -c %s 2>&1 | FileCheck 
-check-prefix=CA35 %s
 // RUN: %clang -target aarch64 -mlittle-endian -mcpu=cortex-a35 -### -c %s 
2>&1 | FileCheck -check-prefix=CA35 %s
Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -74,12 +74,12 @@
   const llvm::Triple::ArchType Arch = getArchTypeForMachOArchName(Str);
   llvm::ARM::ArchKind ArchKind = llvm::ARM::parseArch(Str);
   T.setArch(Arch);
-
-  if (Str == "x86_64h" || Str == "arm64e")
+  if (Arch != llvm::Triple::UnknownArch)
 T.setArchName(Str);
-  else if (ArchKind == llvm::ARM::ArchKind::ARMV6M ||
-   ArchKind == llvm::ARM::ArchKind::ARMV7M ||
-   ArchKind == llvm::ARM::ArchKind::ARMV7EM) {
+
+  if (ArchKind == llvm::ARM::ArchKind::ARMV6M ||
+  ArchKind == llvm::ARM::ArchKind::ARMV7M ||
+  ArchKind == llvm::ARM::ArchKind::ARMV7EM) {
 T.setOS(llvm::Triple::UnknownOS);
 

[PATCH] D100872: Use OpenFlags instead of boolean to set a file as text/binary

2021-04-20 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a subscriber: dexonsmith.
rnk added a comment.

+@dexonsmith who touched this API last.




Comment at: clang/include/clang/Frontend/CompilerInstance.h:738-740
+  createOutputFileImpl(StringRef OutputPath, llvm::sys::fs::OpenFlags Flags,
bool RemoveFileOnSignal, bool UseTemporary,
bool CreateMissingDirectories);

I think this is only going to be worth it if we can roll up all of these 
booleans into a new flags enum for compiler instance. It also prevents 
introducing a new use of FileSystem.h, which is an expensive header to include.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100872

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


[PATCH] D100776: [clang/Basic] Make TargetInfo.h not use DataLayout again

2021-04-20 Thread Eric Christopher via Phabricator via cfe-commits
echristo added a comment.

In D100776#2699603 , @thakis wrote:

> In D100776#2699565 , @rnk wrote:
>
>> Of the three people who commented on D17183 
>> , you and I are on the only ones in favor 
>> of this approach. I think @echristo and @jyknight both preferred approach 2. 
>> I'd like to get at least an agreement to disagree from one of them before 
>> approving this.
>
> That's 50% in people, and 15/24 voting by changes that landed in clang/ since 
> start of year ;) Don't know why 2/4 is "only".

I mean that's fair ;)

> I'm also not dismissing approach 2: I implemented it as well, and it's 
> ready-to-go as soon as someone wants to pursue the direction mentioned there. 
> If someone wants to do that, I don't have a problem with it, but until then 
> this here is simpler and more self-consistent since it preserves the original 
> design of TargetInfo.

how about some historical context. I'm reasonably certain I was one of the 
motivators behind this change. The prior state often lead to either very subtle 
bugs that were hard to diagnose without an asserts build or a fairly 
inscrutable assert that the front and back ends disagreed on what context a 
string should have. The idea was that you could then ask the "backend" how to 
construct up a layout for what was wanted.

As is mentioned there are tradeoffs around this though: a) it does make it 
harder to have clang generate code without a backend or llvm itself around, b) 
it does have a dependency when none existed.

So, if this is really causing some consternation then we can pull back and 
reinstate what we had, but it was a direction around solving a set of hard to 
find bugs.

Thoughts?

-eric


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

https://reviews.llvm.org/D100776

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


[PATCH] D100148: [Driver] Fix compiler-rt lookup for x32

2021-04-20 Thread John Paul Adrian Glaubitz via Phabricator via cfe-commits
glaubitz added a comment.

@hvdijk I just noticed that the sanitizer defines `SANITIZER_X32` for x32, so I 
assume your patch itself is already correct.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100148

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


[PATCH] D100509: Support GCC's -fstack-usage flag

2021-04-20 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:5474
+  if (Args.hasArg(options::OPT_fstack_usage)) {
+CmdArgs.push_back(Args.MakeArgString("-fstack-usage"));
+

CC1 needs two options? 

If you infer the filename in the driver, CC1 can use "whether StackUsageOutput 
is empty".



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:5480
+  CmdArgs.push_back(Args.MakeArgString("-fstack-usage=" +
+   std::string(OutputFilename.str(;
+}

`"-fstack-usage=" + OutputFilename.str()`

MakeArgString works with a Twine.



Comment at: clang/test/CodeGen/stack-usage.c:1
+// REQUIRES: 
x86-registered-target,aarch64-registered-target,arm-registered-target
+

Such llvm specific tests break layering but we don't have better way for 
testing so this might be ok...

However, not sure we need three targets. Usually one is sufficient.





Comment at: clang/test/CodeGen/stack-usage.c:3
+
+// RUN: %clang_cc1 -triple x86_64-unknown -fstack-usage -fstack-usage=%T/a.su 
-emit-obj %s -o %T/a.o
+// RUN: FileCheck %s < %T/a.su

%T is a deprecated lit replacement. Use `rm -rf %t && mkdir %t`



Comment at: clang/test/Driver/stack-usage.c:1
+// RUN: %clang -target x86_64-unknown %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-ABSENT
+// RUN: %clang -target aarch64-unknown %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-ABSENT

Not sure we need three. One suffices.



Comment at: clang/test/Driver/stack-usage.c:9
+// RUN: %clang -target arm-unknown -fstack-usage %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-PRESENT
+// CHECK-PRESENT: -fstack-usage
+

Include quotes



Comment at: llvm/include/llvm/CodeGen/AsmPrinter.h:179
+  /// Output stream for the stack usage file (i.e., .su file).
+  std::unique_ptr StackUsageStream = nullptr;
+

Delete `= nullptr`



Comment at: llvm/include/llvm/Target/TargetOptions.h:350
+/// for foo.c)
+std::string StackUsageOutput = "";
+

Delete `= ""`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100509

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


[PATCH] D100896: [CMake][clang] add_clang_library's functions require default visibility

2021-04-20 Thread Jim Radford via Phabricator via cfe-commits
radford created this revision.
radford added a reviewer: arphaman.
Herald added a subscriber: mgorny.
radford requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Compiling LLVM, as a cmake sub-project that compiles with visibility
hidden, will generate a "cannot export hidden symbol" error because we
require default visibility.  Even though we export using
-Wl,-exported_symbols_list,libclang.exports, if each .cpp file is
compiled with -fvisibility=hidden, then you'll get this warning and
linking will fail. Essentially -exported_symbols_list is not strong
enough to reverse the -fvisibility=hidden.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100896

Files:
  clang/cmake/modules/AddClang.cmake


Index: clang/cmake/modules/AddClang.cmake
===
--- clang/cmake/modules/AddClang.cmake
+++ clang/cmake/modules/AddClang.cmake
@@ -142,6 +142,7 @@
 endif()
   endforeach()
 
+  set_target_properties(${name} PROPERTIES CXX_VISIBILITY_PRESET default)
   set_target_properties(${name} PROPERTIES FOLDER "Clang libraries")
   set_clang_windows_version_resource_properties(${name})
 endmacro(add_clang_library)


Index: clang/cmake/modules/AddClang.cmake
===
--- clang/cmake/modules/AddClang.cmake
+++ clang/cmake/modules/AddClang.cmake
@@ -142,6 +142,7 @@
 endif()
   endforeach()
 
+  set_target_properties(${name} PROPERTIES CXX_VISIBILITY_PRESET default)
   set_target_properties(${name} PROPERTIES FOLDER "Clang libraries")
   set_clang_windows_version_resource_properties(${name})
 endmacro(add_clang_library)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D100834: Bug 49739 - [Matrix] Support #pragma clang fp

2021-04-20 Thread Hamza Mahfooz via Phabricator via cfe-commits
effective-light updated this revision to Diff 339012.
effective-light added a comment.

Fix build


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100834

Files:
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/test/CodeGen/fp-matrix-pragma.c


Index: clang/test/CodeGen/fp-matrix-pragma.c
===
--- /dev/null
+++ clang/test/CodeGen/fp-matrix-pragma.c
@@ -0,0 +1,33 @@
+// RUN: %clang_cc1 -emit-llvm -S -fenable-matrix -mllvm -disable-llvm-optzns 
%s -o - | FileCheck %s
+
+typedef float fx2x2_t __attribute__((matrix_type(2, 2)));
+typedef int ix2x2_t __attribute__((matrix_type(2, 2)));
+
+fx2x2_t fp_matrix_contract(fx2x2_t a, fx2x2_t b, float c, float d) {
+// CHECK: call contract <4 x float> @llvm.matrix.multiply.v4f32.v4f32.v4f32
+// CHECK: fdiv contract <4 x float>
+// CHECK: fmul contract <4 x float>
+#pragma clang fp contract(fast)
+  return (a * b / c) * d;
+}
+
+fx2x2_t fp_matrix_reassoc(fx2x2_t a, fx2x2_t b, fx2x2_t c) {
+// CHECK: fadd reassoc <4 x float>
+// CHECK: fsub reassoc <4 x float>
+#pragma clang fp reassociate(on)
+  return a + b - c;
+}
+
+fx2x2_t fp_matrix_ops(fx2x2_t a, fx2x2_t b, fx2x2_t c) {
+// CHECK: call reassoc contract <4 x float> 
@llvm.matrix.multiply.v4f32.v4f32.v4f32
+// CHECK: fadd reassoc contract <4 x float>
+#pragma clang fp contract(fast) reassociate(on)
+  return a * b + c;
+}
+
+ix2x2_t int_matrix_ops(ix2x2_t a, ix2x2_t b, ix2x2_t c) {
+// CHECK: call <4 x i32> @llvm.matrix.multiply.v4i32.v4i32.v4i32
+// CHECK: add <4 x i32>
+#pragma clang fp contract(fast) reassociate(on)
+  return a * b + c;
+}
Index: clang/lib/CodeGen/CGExprScalar.cpp
===
--- clang/lib/CodeGen/CGExprScalar.cpp
+++ clang/lib/CodeGen/CGExprScalar.cpp
@@ -732,6 +732,7 @@
   BO->getLHS()->getType().getCanonicalType());
   auto *RHSMatTy = dyn_cast(
   BO->getRHS()->getType().getCanonicalType());
+  CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, Ops.FPFeatures);
   if (LHSMatTy && RHSMatTy)
 return MB.CreateMatrixMultiply(Ops.LHS, Ops.RHS, 
LHSMatTy->getNumRows(),
LHSMatTy->getNumColumns(),
@@ -3206,6 +3207,7 @@
 "first operand must be a matrix");
 assert(BO->getRHS()->getType().getCanonicalType()->isArithmeticType() &&
"second operand must be an arithmetic type");
+CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, Ops.FPFeatures);
 return MB.CreateScalarDiv(Ops.LHS, Ops.RHS,
   Ops.Ty->hasUnsignedIntegerRepresentation());
   }
@@ -3585,6 +3587,7 @@
 
   if (op.Ty->isConstantMatrixType()) {
 llvm::MatrixBuilder MB(Builder);
+CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, op.FPFeatures);
 return MB.CreateAdd(op.LHS, op.RHS);
   }
 
@@ -3734,6 +3737,7 @@
 
 if (op.Ty->isConstantMatrixType()) {
   llvm::MatrixBuilder MB(Builder);
+  CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, op.FPFeatures);
   return MB.CreateSub(op.LHS, op.RHS);
 }
 


Index: clang/test/CodeGen/fp-matrix-pragma.c
===
--- /dev/null
+++ clang/test/CodeGen/fp-matrix-pragma.c
@@ -0,0 +1,33 @@
+// RUN: %clang_cc1 -emit-llvm -S -fenable-matrix -mllvm -disable-llvm-optzns %s -o - | FileCheck %s
+
+typedef float fx2x2_t __attribute__((matrix_type(2, 2)));
+typedef int ix2x2_t __attribute__((matrix_type(2, 2)));
+
+fx2x2_t fp_matrix_contract(fx2x2_t a, fx2x2_t b, float c, float d) {
+// CHECK: call contract <4 x float> @llvm.matrix.multiply.v4f32.v4f32.v4f32
+// CHECK: fdiv contract <4 x float>
+// CHECK: fmul contract <4 x float>
+#pragma clang fp contract(fast)
+  return (a * b / c) * d;
+}
+
+fx2x2_t fp_matrix_reassoc(fx2x2_t a, fx2x2_t b, fx2x2_t c) {
+// CHECK: fadd reassoc <4 x float>
+// CHECK: fsub reassoc <4 x float>
+#pragma clang fp reassociate(on)
+  return a + b - c;
+}
+
+fx2x2_t fp_matrix_ops(fx2x2_t a, fx2x2_t b, fx2x2_t c) {
+// CHECK: call reassoc contract <4 x float> @llvm.matrix.multiply.v4f32.v4f32.v4f32
+// CHECK: fadd reassoc contract <4 x float>
+#pragma clang fp contract(fast) reassociate(on)
+  return a * b + c;
+}
+
+ix2x2_t int_matrix_ops(ix2x2_t a, ix2x2_t b, ix2x2_t c) {
+// CHECK: call <4 x i32> @llvm.matrix.multiply.v4i32.v4i32.v4i32
+// CHECK: add <4 x i32>
+#pragma clang fp contract(fast) reassociate(on)
+  return a * b + c;
+}
Index: clang/lib/CodeGen/CGExprScalar.cpp
===
--- clang/lib/CodeGen/CGExprScalar.cpp
+++ clang/lib/CodeGen/CGExprScalar.cpp
@@ -732,6 +732,7 @@
   BO->getLHS()->getType().getCanonicalType());
   auto *RHSMatTy = dyn_cast(
   BO->getRHS()->getType().getCanonicalType());
+  CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, Ops.FPFeatures);
   if (LHSMatTy && 

[PATCH] D100794: [HIP] Support overloaded math functions for hipRTC

2021-04-20 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl updated this revision to Diff 339009.
yaxunl marked an inline comment as done.
yaxunl added a comment.

fix __hip::__numeric_type


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

https://reviews.llvm.org/D100794

Files:
  clang/lib/Headers/__clang_hip_cmath.h
  clang/lib/Headers/__clang_hip_runtime_wrapper.h
  clang/test/Headers/hip-header.hip

Index: clang/test/Headers/hip-header.hip
===
--- clang/test/Headers/hip-header.hip
+++ clang/test/Headers/hip-header.hip
@@ -12,16 +12,41 @@
 // RUN:   -target-cpu gfx906 -emit-llvm %s -fcuda-is-device -o - \
 // RUN:   -D__HIPCC_RTC__ -std=c++14 | FileCheck %s
 
-
 // expected-no-diagnostics
 
+struct Number {
+  __device__ Number(float _x) : x(_x) {}
+  float x;
+};
+
+// Check __hip::__numeric_type can be used with a class without default ctor.
+#if __cplusplus >= 201103L
+__device__ void test_numeric_type() {
+  int x = __hip::__numeric_type::value;
+}
+#endif
+
 // CHECK-LABEL: amdgpu_kernel void @_Z4kernPff
 __global__ void kern(float *x, float y) {
   *x = sin(y);
 }
 
 // CHECK-LABEL: define{{.*}} i64 @_Z11test_size_tv
-// CHEC: ret i64 8
+// CHECK: ret i64 8
 __device__ size_t test_size_t() {
   return sizeof(size_t);
 }
+
+// Check there is no ambiguity when calling overloaded math functions.
+
+// CHECK-LABEL: define{{.*}}@_Z10test_floorv
+// CHECK: call {{.*}}double @__ocml_floor_f64(double
+__device__ float test_floor() {
+  return floor(5);
+}
+
+// CHECK-LABEL: define{{.*}}@_Z8test_maxv
+// CHECK: call {{.*}}double @__ocml_fmax_f64(double {{.*}}, double
+__device__ float test_max() {
+  return max(5, 6.0);
+}
Index: clang/lib/Headers/__clang_hip_runtime_wrapper.h
===
--- clang/lib/Headers/__clang_hip_runtime_wrapper.h
+++ clang/lib/Headers/__clang_hip_runtime_wrapper.h
@@ -72,12 +72,13 @@
 #include <__clang_hip_libdevice_declares.h>
 #include <__clang_hip_math.h>
 
-#if !defined(__HIPCC_RTC__)
 #if !_OPENMP || __HIP_ENABLE_CUDA_WRAPPER_FOR_OPENMP__
+#if defined(__HIPCC_RTC__)
+#include <__clang_hip_cmath.h>
+#else
 #include <__clang_cuda_math_forward_declares.h>
 #include <__clang_hip_cmath.h>
 #include <__clang_cuda_complex_builtins.h>
-
 #include 
 #include 
 #include 
Index: clang/lib/Headers/__clang_hip_cmath.h
===
--- clang/lib/Headers/__clang_hip_cmath.h
+++ clang/lib/Headers/__clang_hip_cmath.h
@@ -22,7 +22,7 @@
 #endif
 #include 
 #include 
-#endif // __HIPCC_RTC__
+#endif // !defined(__HIPCC_RTC__)
 
 #pragma push_macro("__DEVICE__")
 #define __DEVICE__ static __device__ inline __attribute__((always_inline))
@@ -36,6 +36,9 @@
 __DEVICE__ float fma(float __x, float __y, float __z) {
   return ::fmaf(__x, __y, __z);
 }
+#if !defined(__HIPCC_RTC__)
+// The value returned by fpclassify is platform dependent, therefore it is not
+// supported by hipRTC.
 __DEVICE__ int fpclassify(float __x) {
   return __builtin_fpclassify(FP_NAN, FP_INFINITE, FP_NORMAL, FP_SUBNORMAL,
   FP_ZERO, __x);
@@ -44,6 +47,8 @@
   return __builtin_fpclassify(FP_NAN, FP_INFINITE, FP_NORMAL, FP_SUBNORMAL,
   FP_ZERO, __x);
 }
+#endif // !defined(__HIPCC_RTC__)
+
 __DEVICE__ float frexp(float __arg, int *__exp) {
   return ::frexpf(__arg, __exp);
 }
@@ -209,11 +214,119 @@
 
 template  struct __hip_enable_if { typedef __T type; };
 
+namespace __hip {
+template  struct is_integral {
+  enum { value = 0 };
+};
+template <> struct is_integral {
+  enum { value = 1 };
+};
+template <> struct is_integral {
+  enum { value = 1 };
+};
+template <> struct is_integral {
+  enum { value = 1 };
+};
+template <> struct is_integral {
+  enum { value = 1 };
+};
+template <> struct is_integral {
+  enum { value = 1 };
+};
+template <> struct is_integral {
+  enum { value = 1 };
+};
+template <> struct is_integral {
+  enum { value = 1 };
+};
+template <> struct is_integral {
+  enum { value = 1 };
+};
+template <> struct is_integral {
+  enum { value = 1 };
+};
+template <> struct is_integral {
+  enum { value = 1 };
+};
+template <> struct is_integral {
+  enum { value = 1 };
+};
+template <> struct is_integral {
+  enum { value = 1 };
+};
+template <> struct is_integral {
+  enum { value = 1 };
+};
+
+template  struct is_arithmetic {
+  enum { value = 0 };
+};
+template <> struct is_arithmetic {
+  enum { value = 1 };
+};
+template <> struct is_arithmetic {
+  enum { value = 1 };
+};
+template <> struct is_arithmetic {
+  enum { value = 1 };
+};
+template <> struct is_arithmetic {
+  enum { value = 1 };
+};
+template <> struct is_arithmetic {
+  enum { value = 1 };
+};
+template <> struct is_arithmetic {
+  enum { value = 1 };
+};
+template <> struct is_arithmetic {
+  enum { value = 1 };
+};
+template <> struct is_arithmetic {
+  enum { value = 1 };
+};
+template <> struct is_arithmetic {
+  enum { value = 1 };
+};

[clang] 9f1e2ee - [Clang, builtins] Added aligned_alloc, memalign support

2021-04-20 Thread Dávid Bolvanský via cfe-commits

Author: Dávid Bolvanský
Date: 2021-04-21T00:11:54+02:00
New Revision: 9f1e2ee46251b09565eb87124aa836291aaf799d

URL: 
https://github.com/llvm/llvm-project/commit/9f1e2ee46251b09565eb87124aa836291aaf799d
DIFF: 
https://github.com/llvm/llvm-project/commit/9f1e2ee46251b09565eb87124aa836291aaf799d.diff

LOG: [Clang, builtins] Added aligned_alloc, memalign support

Added: 
clang/test/CodeGen/aligned_alloc-libcall.c
clang/test/CodeGen/memalign-libcall.c

Modified: 
clang/include/clang/Basic/Builtins.def

Removed: 




diff  --git a/clang/include/clang/Basic/Builtins.def 
b/clang/include/clang/Basic/Builtins.def
index 92da70ea05db3..ead84e2e62797 100644
--- a/clang/include/clang/Basic/Builtins.def
+++ b/clang/include/clang/Basic/Builtins.def
@@ -980,6 +980,8 @@ LIBBUILTIN(strtol, "LicC*c**i",   "f", "stdlib.h", 
ALL_LANGUAGES)
 LIBBUILTIN(strtoll, "LLicC*c**i", "f", "stdlib.h", ALL_LANGUAGES)
 LIBBUILTIN(strtoul, "ULicC*c**i", "f", "stdlib.h", ALL_LANGUAGES)
 LIBBUILTIN(strtoull, "ULLicC*c**i", "f",   "stdlib.h", ALL_LANGUAGES)
+// C11 stdlib.h
+LIBBUILTIN(aligned_alloc, "v*zz", "f", "stdlib.h", ALL_LANGUAGES)
 // C99 string.h
 LIBBUILTIN(memcpy, "v*v*vC*z","f", "string.h", ALL_LANGUAGES)
 LIBBUILTIN(memcmp, "ivC*vC*z","f", "string.h", ALL_LANGUAGES)
@@ -1061,6 +1063,8 @@ LIBBUILTIN(longjmp, "vJi","frT",   "setjmp.h", 
ALL_LANGUAGES)
 // all languages, because losing this attribute would result in miscompilation
 // when these functions are used in non-GNU mode. PR16138.
 LIBBUILTIN(alloca, "v*z", "f", "stdlib.h", ALL_GNU_LANGUAGES)
+// POSIX malloc.h
+LIBBUILTIN(memalign, "v*zz",  "f", "malloc.h", ALL_GNU_LANGUAGES)
 // POSIX string.h
 LIBBUILTIN(memccpy, "v*v*vC*iz",  "f", "string.h", ALL_GNU_LANGUAGES)
 LIBBUILTIN(mempcpy, "v*v*vC*z",   "f", "string.h", ALL_GNU_LANGUAGES)

diff  --git a/clang/test/CodeGen/aligned_alloc-libcall.c 
b/clang/test/CodeGen/aligned_alloc-libcall.c
new file mode 100644
index 0..ee44fc38b393f
--- /dev/null
+++ b/clang/test/CodeGen/aligned_alloc-libcall.c
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -fno-builtin-aligned_alloc -emit-llvm < %s | FileCheck %s
+
+typedef __SIZE_TYPE__ size_t;
+
+void *aligned_alloc(size_t, size_t);
+
+void *test(size_t alignment, size_t size) {
+  // CHECK: call i8* @aligned_alloc{{.*}} #2
+  return aligned_alloc(alignment, size);
+}
+
+// CHECK: attributes #2 = { nobuiltin "no-builtin-aligned_alloc" } 
\ No newline at end of file

diff  --git a/clang/test/CodeGen/memalign-libcall.c 
b/clang/test/CodeGen/memalign-libcall.c
new file mode 100644
index 0..ec040456d885d
--- /dev/null
+++ b/clang/test/CodeGen/memalign-libcall.c
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -fno-builtin-memalign -emit-llvm < %s | FileCheck %s
+
+typedef __SIZE_TYPE__ size_t;
+
+void *memalign(size_t, size_t);
+
+void *test(size_t alignment, size_t size) {
+  // CHECK: call i8* @memalign{{.*}} #2
+  return memalign(alignment, size);
+}
+
+// CHECK: attributes #2 = { nobuiltin "no-builtin-memalign" } 
\ No newline at end of file



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


[PATCH] D100891: CMake fixes to enable LLVM as a sub-project

2021-04-20 Thread Jim Radford via Phabricator via cfe-commits
radford created this revision.
Herald added a subscriber: mgorny.
radford requested review of this revision.
Herald added projects: clang, LLDB, LLVM.
Herald added subscribers: llvm-commits, lldb-commits, cfe-commits.

[CMake][llvm] Using -D in COMPILE_DEFINITIONS can create a lone -D 
w/generator-expressions

[CMake][llvm] LLVM_DEFINITIONS are a list, not space separated

[CMake][clang] add_clang_library's functions require default visibility

[CMake][lldb] add_lldb_library's functions require default visibility

[CMake][llvm] add_llvm_library's functions require default visibility

[CMake][llvm] avoid changing global flags (may be used outside of llvm)

Changing global flags can break builds of projects that include/build
llvm as a sub-project, as the effect is global.  Ideally we would
disable this warning at the directory level instead, but the obvious
way (disabling warning D9025 ) isn't supported. 
 At least we can limit
the effect to only MSVC.

[CMake][llvm] The first argument to check_linker_flag is the language

[CMake][llvm] avoid includes with generator-expressions in add_custom_command


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100891

Files:
  clang/cmake/modules/AddClang.cmake
  lldb/cmake/modules/AddLLDB.cmake
  llvm/cmake/modules/AddLLVM.cmake
  llvm/cmake/modules/AddLLVMDefinitions.cmake
  llvm/cmake/modules/HandleLLVMOptions.cmake
  llvm/cmake/modules/TableGen.cmake

Index: llvm/cmake/modules/TableGen.cmake
===
--- llvm/cmake/modules/TableGen.cmake
+++ llvm/cmake/modules/TableGen.cmake
@@ -95,6 +95,8 @@
   # ("${${project}_TABLEGEN_TARGET}" STREQUAL "${${project}_TABLEGEN_EXE}")
   # but lets us having smaller and cleaner code here.
   get_directory_property(tblgen_includes INCLUDE_DIRECTORIES)
+  # No support for generator-expressions in add_custom_command, so strip them
+  list(TRANSFORM tblgen_includes GENEX_STRIP)
   list(TRANSFORM tblgen_includes PREPEND -I)
 
   add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${ofn}
Index: llvm/cmake/modules/HandleLLVMOptions.cmake
===
--- llvm/cmake/modules/HandleLLVMOptions.cmake
+++ llvm/cmake/modules/HandleLLVMOptions.cmake
@@ -62,18 +62,19 @@
 # NOTE: use `add_compile_options` rather than `add_definitions` since
 # `add_definitions` does not support generator expressions.
 add_compile_options($<$,$>:-UNDEBUG>)
-
-# Also remove /D NDEBUG to avoid MSVC warnings about conflicting defines.
-foreach (flags_var_to_scrub
-CMAKE_CXX_FLAGS_RELEASE
-CMAKE_CXX_FLAGS_RELWITHDEBINFO
-CMAKE_CXX_FLAGS_MINSIZEREL
-CMAKE_C_FLAGS_RELEASE
-CMAKE_C_FLAGS_RELWITHDEBINFO
-CMAKE_C_FLAGS_MINSIZEREL)
-  string (REGEX REPLACE "(^| )[/-]D *NDEBUG($| )" " "
-"${flags_var_to_scrub}" "${${flags_var_to_scrub}}")
-endforeach()
+if (MSVC)
+  # Also remove /D NDEBUG to avoid MSVC warnings about conflicting defines.
+  foreach (flags_var_to_scrub
+  CMAKE_CXX_FLAGS_RELEASE
+  CMAKE_CXX_FLAGS_RELWITHDEBINFO
+  CMAKE_CXX_FLAGS_MINSIZEREL
+  CMAKE_C_FLAGS_RELEASE
+  CMAKE_C_FLAGS_RELWITHDEBINFO
+  CMAKE_C_FLAGS_MINSIZEREL)
+string (REGEX REPLACE "(^| )[/-]D *NDEBUG($| )" " "
+  "${flags_var_to_scrub}" "${${flags_var_to_scrub}}")
+  endforeach()
+ endif()
   endif()
 endif()
 
@@ -899,7 +900,7 @@
 # lld doesn't print colored diagnostics when invoked from Ninja
 if (UNIX AND CMAKE_GENERATOR STREQUAL "Ninja")
   include(CheckLinkerFlag)
-  check_linker_flag("-Wl,--color-diagnostics" LINKER_SUPPORTS_COLOR_DIAGNOSTICS)
+  check_linker_flag(CXX "-Wl,--color-diagnostics" LINKER_SUPPORTS_COLOR_DIAGNOSTICS)
   append_if(LINKER_SUPPORTS_COLOR_DIAGNOSTICS "-Wl,--color-diagnostics"
 CMAKE_EXE_LINKER_FLAGS CMAKE_MODULE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS)
 endif()
@@ -1128,14 +1129,7 @@
 
 function(get_compile_definitions)
   get_directory_property(top_dir_definitions DIRECTORY ${CMAKE_SOURCE_DIR} COMPILE_DEFINITIONS)
-  foreach(definition ${top_dir_definitions})
-if(DEFINED result)
-  string(APPEND result " -D${definition}")
-else()
-  set(result "-D${definition}")
-endif()
-  endforeach()
-  set(LLVM_DEFINITIONS "${result}" PARENT_SCOPE)
+  set(LLVM_DEFINITIONS "${top_dir_definitions}" PARENT_SCOPE)
 endfunction()
 get_compile_definitions()
 
Index: llvm/cmake/modules/AddLLVMDefinitions.cmake
===
--- llvm/cmake/modules/AddLLVMDefinitions.cmake
+++ llvm/cmake/modules/AddLLVMDefinitions.cmake
@@ -6,12 +6,6 @@
 
 macro(add_llvm_definitions)
   # We don't want no semicolons on LLVM_DEFINITIONS:
-  foreach(arg ${ARGN})
-if(DEFINED LLVM_DEFINITIONS)
-  set(LLVM_DEFINITIONS "${LLVM_DEFINITIONS} ${arg}")
-else()
-  set(LLVM_DEFINITIONS 

[PATCH] D100755: [llvm-rc] [3/4] Run clang to preprocess input files

2021-04-20 Thread Alexandre Ganea via Phabricator via cfe-commits
aganea accepted this revision.
aganea added a comment.

LGTM.




Comment at: llvm/tools/llvm-rc/llvm-rc.cpp:94
+
+ErrorOr findClang(const char *Argv0) {
+  StringRef Parent = llvm::sys::path::parent_path(Argv0);

mstorsjo wrote:
> aganea wrote:
> > Since you're not using the `std::error_code` below in the call site, should 
> > this return `Expected<...>`? In that case, the variable `Path` shouldn't be 
> > needed?
> With `Expected<>` I'd need to craft an `Error` at the end if I don't have a 
> path to return, but do you mean `Optional<>`? I guess that'd work - but as 
> `findProgramByName()` returns `ErrorOr` I kept the same 
> signature.
> 
> Even if returning `Optional<>`, we need a local variable to receive the 
> `ErrorOr` from `findProgramByName()` and inspect it.
> 
> In the future (after a release or so) I'd intend for this to be a hard error, 
> so at that point, the returned error code actually would be printed.
I see, thanks for the explanation!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100755

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


[PATCH] D100755: [llvm-rc] [3/4] Run clang to preprocess input files

2021-04-20 Thread Martin Storsjö via Phabricator via cfe-commits
mstorsjo added inline comments.



Comment at: llvm/tools/llvm-rc/llvm-rc.cpp:94
+
+ErrorOr findClang(const char *Argv0) {
+  StringRef Parent = llvm::sys::path::parent_path(Argv0);

aganea wrote:
> Since you're not using the `std::error_code` below in the call site, should 
> this return `Expected<...>`? In that case, the variable `Path` shouldn't be 
> needed?
With `Expected<>` I'd need to craft an `Error` at the end if I don't have a 
path to return, but do you mean `Optional<>`? I guess that'd work - but as 
`findProgramByName()` returns `ErrorOr` I kept the same signature.

Even if returning `Optional<>`, we need a local variable to receive the 
`ErrorOr` from `findProgramByName()` and inspect it.

In the future (after a release or so) I'd intend for this to be a hard error, 
so at that point, the returned error code actually would be printed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100755

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


[PATCH] D100874: [OpenMP] Use irbuilder as default for masked and master construct

2021-04-20 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.

In D100874#2702897 , @cchen wrote:

> I mark this patch as "plan changed" since the assert message indicates that 
> something wrong in IRBuilder or Codegen, however, main branch also have the 
> same issue so I think this patch does not trigger the issue.

what assertion?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100874

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


[PATCH] D81624: [CodeGen] Simplify the way lifetime of block captures is extended

2021-04-20 Thread Sharon Xu via Phabricator via cfe-commits
SharonXu added a comment.

Hi @ahatanak , @rjmccall, we found that this diff causes an issue: 
When -fobjc-arc is enabled, if a block is passed as an argument to a function 
whose corresponding parameter type is && rvalue and attributed as noescape, the 
object captured by the block can get destructed before the block invocation.  
More details and code example is in https://bugs.llvm.org/show_bug.cgi?id=50043 
we filed.

We've tried locally reverted this patch, and the test cases mentioned in that 
bug report passed successfully. I am wondering could you please take a look at 
the bug report and see if you have a quick fix or something? Thanks!!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81624

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


[PATCH] D100755: [llvm-rc] [3/4] Run clang to preprocess input files

2021-04-20 Thread Alexandre Ganea via Phabricator via cfe-commits
aganea added inline comments.



Comment at: llvm/tools/llvm-rc/llvm-rc.cpp:94
+
+ErrorOr findClang(const char *Argv0) {
+  StringRef Parent = llvm::sys::path::parent_path(Argv0);

Since you're not using the `std::error_code` below in the call site, should 
this return `Expected<...>`? In that case, the variable `Path` shouldn't be 
needed?



Comment at: llvm/tools/llvm-rc/llvm-rc.cpp:154
+  Args.push_back("-U");
+  break;
+}

thakis wrote:
> mstorsjo wrote:
> > thakis wrote:
> > > Here's our chromium wrapper: 
> > > https://source.chromium.org/chromium/chromium/src/+/master:build/toolchain/win/rc/rc.py
> > > 
> > > On Windows, /winsysroot support and possibly -imsvc support would be nice 
> > > too.
> > Those sound useful - but I think I'd prefer to defer adding support for 
> > more nonstandard preprocessing options to a later patch.
> > 
> > What do you think of a generic `--preprocessor-arg` like in the windres 
> > frontend, which might be useful for @aganea?
> We don't need a general `--preprocessor-arg` as long as common args work.
> 
> Oh, on that note: 
> https://source.chromium.org/chromium/chromium/src/+/master:build/toolchain/win/rc/rc.py
>  also has `/showIncludes` support which is necessary to make ninja re-build 
> .rc files if either
> 
> * an included .h file is changed (needs preprocessor output)
> * an included resource file (.ico or similar) is changed (needs llvm-rc 
> support)
> 
> Don't know if llvm-rc has support for the latter part. If it doesn't, that'd 
> be nice to add, and some test that checks that both parts work would be nice. 
> (Neither in this patch; just thinking about what we'd need to switch.)
> We don't need a general --preprocessor-arg as long as common args work.
+1 with Nico. Native arguments in `llvm-rc` would be better (later).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100755

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


[PATCH] D45639: [Driver] Support default libc++ library location on Darwin

2021-04-20 Thread Petr Hosek via Phabricator via cfe-commits
phosek added a comment.

Another attempt is rGcaff17e503fe 
.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D45639

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


[clang] caff17e - [Driver] Don't use capture for InstalledDir

2021-04-20 Thread Petr Hosek via cfe-commits

Author: Petr Hosek
Date: 2021-04-20T13:43:56-07:00
New Revision: caff17e503fe81d69e90dd69b14f5149659f9db4

URL: 
https://github.com/llvm/llvm-project/commit/caff17e503fe81d69e90dd69b14f5149659f9db4
DIFF: 
https://github.com/llvm/llvm-project/commit/caff17e503fe81d69e90dd69b14f5149659f9db4.diff

LOG: [Driver] Don't use capture for InstalledDir

This is another attempt to address the issue introduced in
ae8b2cab67408a043a4fe964d16e4803553c4ee0.

We cannot capture InstalledDir because FileCheck doesn't handle
the backslashes correctly, so instead we just consume the entire
path prefix which is what other tests are doing.

Added: 


Modified: 
clang/test/Driver/darwin-ld.c

Removed: 




diff  --git a/clang/test/Driver/darwin-ld.c b/clang/test/Driver/darwin-ld.c
index 7c782e1cb5bf..9fe68f1821c9 100644
--- a/clang/test/Driver/darwin-ld.c
+++ b/clang/test/Driver/darwin-ld.c
@@ -368,5 +368,4 @@
 
 // RUN: %clang -target x86_64-apple-darwin10 -### %t.o 2> %t.log
 // RUN: FileCheck -check-prefix=INSTALL-DIR %s < %t.log
-// INSTALL-DIR: InstalledDir: [[INSTALLDIR:.+$]]
-// INSTALL-DIR: "-L[[INSTALLDIR]]{{/|}}..{{/|}}lib"
+// INSTALL-DIR: "-L{{.*}}{{/|}}..{{/|}}lib"



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


[PATCH] D100874: [OpenMP] Use irbuilder as default for masked and master construct

2021-04-20 Thread Chi Chun Chen via Phabricator via cfe-commits
cchen added a comment.

I mark this patch as "plan changed" since the assert message indicates that 
something wrong in IRBuilder or Codegen, however, main branch also have the 
same issue so I think this patch does not trigger the issue.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100874

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


[PATCH] D93031: Enable fexec-charset option

2021-04-20 Thread ThePhD via Phabricator via cfe-commits
ThePhD added a comment.

Just a tiny comment: could you please make sure the name of the resolved 
encoding is also propagated to InitPreprocessor.cpp that sets the 
`__clang_literal_encoding__` macro? 
(https://github.com/llvm/llvm-project/blob/main/clang/lib/Frontend/InitPreprocessor.cpp#L784)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93031

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


[PATCH] D45639: [Driver] Support default libc++ library location on Darwin

2021-04-20 Thread Petr Hosek via Phabricator via cfe-commits
phosek added a comment.

In D45639#2702746 , @thakis wrote:

> Looks like this breaks tests on windows: 
> http://45.33.8.238/win/37191/step_7.txt

Should be addressed by rGf5efe0aa048b 
.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D45639

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


[PATCH] D100756: [llvm-rc] [4/4] Add a GNU windres-like frontend to llvm-rc

2021-04-20 Thread Martin Storsjö via Phabricator via cfe-commits
mstorsjo updated this revision to Diff 338978.
mstorsjo added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Rebased on top of the updated preceding patch. Adjusted the logic for picking th
e default triple, to preserve the exact spelling of the default triple, if 
isWindowsGNUEnvironment() is true. Added a preprocessing test under clang.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100756

Files:
  clang/test/CMakeLists.txt
  clang/test/Preprocessor/Inputs/llvm-windres.h
  clang/test/Preprocessor/llvm-windres.rc
  llvm/test/CMakeLists.txt
  llvm/test/lit.cfg.py
  llvm/test/tools/llvm-rc/codepage.test
  llvm/test/tools/llvm-rc/language.test
  llvm/test/tools/llvm-rc/windres-format.test
  llvm/test/tools/llvm-rc/windres-prefix.test
  llvm/test/tools/llvm-rc/windres-preproc.test
  llvm/test/tools/llvm-rc/windres-target.test
  llvm/test/tools/llvm-rc/windres-version.test
  llvm/tools/llvm-rc/CMakeLists.txt
  llvm/tools/llvm-rc/WindresOpts.td
  llvm/tools/llvm-rc/llvm-rc.cpp

Index: llvm/tools/llvm-rc/llvm-rc.cpp
===
--- llvm/tools/llvm-rc/llvm-rc.cpp
+++ llvm/tools/llvm-rc/llvm-rc.cpp
@@ -18,8 +18,10 @@
 #include "ResourceScriptToken.h"
 
 #include "llvm/ADT/Triple.h"
+#include "llvm/Object/WindowsResource.h"
 #include "llvm/Option/Arg.h"
 #include "llvm/Option/ArgList.h"
+#include "llvm/Support/CommandLine.h"
 #include "llvm/Support/Error.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/FileUtilities.h"
@@ -75,8 +77,39 @@
   RcOptTable() : OptTable(InfoTable, /* IgnoreCase = */ true) {}
 };
 
+enum Windres_ID {
+  WINDRES_INVALID = 0, // This is not a correct option ID.
+#define OPTION(PREFIX, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,  \
+   HELPTEXT, METAVAR, VALUES)  \
+  WINDRES_##ID,
+#include "WindresOpts.inc"
+#undef OPTION
+};
+
+#define PREFIX(NAME, VALUE) const char *const WINDRES_##NAME[] = VALUE;
+#include "WindresOpts.inc"
+#undef PREFIX
+
+static const opt::OptTable::Info WindresInfoTable[] = {
+#define OPTION(PREFIX, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,  \
+   HELPTEXT, METAVAR, VALUES)  \
+  {\
+  WINDRES_##PREFIX, NAME, HELPTEXT,\
+  METAVAR,  WINDRES_##ID, opt::Option::KIND##Class,\
+  PARAM,FLAGS,WINDRES_##GROUP, \
+  WINDRES_##ALIAS,  ALIASARGS,VALUES},
+#include "WindresOpts.inc"
+#undef OPTION
+};
+
+class WindresOptTable : public opt::OptTable {
+public:
+  WindresOptTable() : OptTable(WindresInfoTable, /* IgnoreCase = */ false) {}
+};
+
 static ExitOnError ExitOnErr;
 static FileRemover TempPreprocFile;
+static FileRemover TempResFile;
 
 LLVM_ATTRIBUTE_NORETURN static void fatalError(const Twine ) {
   errs() << Message << "\n";
@@ -121,10 +154,43 @@
   return T.str();
 }
 
-bool preprocess(StringRef Src, StringRef Dst, opt::InputArgList ,
+std::string getMingwTriple() {
+  Triple T(sys::getDefaultTargetTriple());
+  if (T.isWindowsGNUEnvironment())
+return T.str();
+  // Write out the literal form of the vendor/env here, instead of
+  // constructing them with enum values (which end up with them in
+  // normalized form). The literal form of the triple can matter for
+  // finding include files.
+  return (Twine(T.getArchName()) + "-w64-mingw32").str();
+}
+
+enum Format { Rc, Res, Coff, Unknown };
+
+struct RcOptions {
+  bool Preprocess = true;
+  bool PrintCmdAndExit = false;
+  std::string Triple;
+  std::vector PreprocessCmd;
+  std::vector PreprocessArgs;
+
+  std::string InputFile;
+  Format InputFormat = Rc;
+  std::string OutputFile;
+  Format OutputFormat = Res;
+
+  bool BeVerbose = false;
+  WriterParams Params;
+  bool AppendNull = false;
+  bool IsDryRun = false;
+  // Set the default language; choose en-US arbitrarily.
+  unsigned LangId = (/*PrimaryLangId*/ 0x09) | (/*SubLangId*/ 0x01 << 10);
+};
+
+bool preprocess(StringRef Src, StringRef Dst, const RcOptions ,
 const char *Argv0) {
   std::string Clang;
-  if (InputArgs.hasArg(OPT__HASH_HASH_HASH)) {
+  if (Opts.PrintCmdAndExit) {
 Clang = "clang";
   } else {
 ErrorOr ClangOrErr = findClang(Argv0);
@@ -139,40 +205,27 @@
   return false;
 }
   }
-  std::string PreprocTriple = getClangClTriple();
 
   SmallVector Args = {
-  Clang, "--driver-mode=gcc", "-target", PreprocTriple, "-E",
-  "-xc", "-DRC_INVOKED",  Src,   "-o",  Dst};
-  if (InputArgs.hasArg(OPT_noinclude)) {
-#ifdef _WIN32
-::_putenv("INCLUDE=");
-#else
-::unsetenv("INCLUDE");
-#endif
-  }
-  for (const auto *Arg :
-   InputArgs.filtered(OPT_includepath, 

[clang] f5efe0a - [Driver] Support both slashes

2021-04-20 Thread Petr Hosek via cfe-commits

Author: Petr Hosek
Date: 2021-04-20T13:25:38-07:00
New Revision: f5efe0aa048b2bd3363b3a53efe9ae7367244801

URL: 
https://github.com/llvm/llvm-project/commit/f5efe0aa048b2bd3363b3a53efe9ae7367244801
DIFF: 
https://github.com/llvm/llvm-project/commit/f5efe0aa048b2bd3363b3a53efe9ae7367244801.diff

LOG: [Driver] Support both slashes

This addresses Windows breakage introduced by
ae8b2cab67408a043a4fe964d16e4803553c4ee0.

Added: 


Modified: 
clang/test/Driver/darwin-ld.c

Removed: 




diff  --git a/clang/test/Driver/darwin-ld.c b/clang/test/Driver/darwin-ld.c
index 4de850fad9d8..7c782e1cb5bf 100644
--- a/clang/test/Driver/darwin-ld.c
+++ b/clang/test/Driver/darwin-ld.c
@@ -369,4 +369,4 @@
 // RUN: %clang -target x86_64-apple-darwin10 -### %t.o 2> %t.log
 // RUN: FileCheck -check-prefix=INSTALL-DIR %s < %t.log
 // INSTALL-DIR: InstalledDir: [[INSTALLDIR:.+$]]
-// INSTALL-DIR: "-L[[INSTALLDIR]]/../lib"
+// INSTALL-DIR: "-L[[INSTALLDIR]]{{/|}}..{{/|}}lib"



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


[PATCH] D100874: [OpenMP] Use irbuilder as default for masked and master construct

2021-04-20 Thread Chi Chun Chen via Phabricator via cfe-commits
cchen planned changes to this revision.
cchen added a comment.

This change seems to expose bugs in IRBuilder.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100874

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


[PATCH] D77013: [AMDGPU] Add options -mamdgpu-ieee -mno-amdgpu-ieee

2021-04-20 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl updated this revision to Diff 338975.
yaxunl marked 4 inline comments as done.
yaxunl edited the summary of this revision.
yaxunl added a comment.

revised by Matt's comments


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

https://reviews.llvm.org/D77013

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGenOpenCL/amdgpu-ieee.cl

Index: clang/test/CodeGenOpenCL/amdgpu-ieee.cl
===
--- /dev/null
+++ clang/test/CodeGenOpenCL/amdgpu-ieee.cl
@@ -0,0 +1,47 @@
+// REQUIRES: amdgpu-registered-target
+//
+// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -O0 -emit-llvm -o - %s \
+// RUN:   | FileCheck -check-prefixes=COMMON,ON %s
+// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -O0 -emit-llvm -o - %s \
+// RUN:   -mno-amdgpu-ieee -menable-no-nans \
+// RUN:   | FileCheck -check-prefixes=COMMON,OFF %s
+// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -O0 -emit-llvm -o - %s \
+// RUN:   -mno-amdgpu-ieee -cl-fast-relaxed-math \
+// RUN:   | FileCheck -check-prefixes=COMMON,OFF %s
+
+// Check AMDGCN ISA generation.
+
+// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -O3 -S -o - %s \
+// RUN:   | FileCheck -check-prefixes=ISA-ON %s
+// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -O3 -S -o - %s \
+// RUN:   -mno-amdgpu-ieee -menable-no-nans \
+// RUN:   | FileCheck -check-prefixes=ISA-OFF %s
+
+// Check diagnostics when using -mno-amdgpu-ieee without NoHornorNaNs.
+
+// RUN: not %clang_cc1 -triple amdgcn-amd-amdhsa -O0 -emit-llvm -o - %s \
+// RUN:   -mno-amdgpu-ieee 2>&1 | FileCheck -check-prefixes=DIAG %s
+
+// COMMON: define{{.*}} amdgpu_kernel void @kern{{.*}} [[ATTRS1:#[0-9]+]]
+// ISA-ON: v_mul_f32_e64 v{{[0-9]+}}, 1.0, s{{[0-9]+}}
+// ISA-ON: v_mul_f32_e64 v{{[0-9]+}}, 1.0, s{{[0-9]+}}
+// ISA-ON: v_min_f32_e32
+// ISA-ON: ; IeeeMode: 1
+// ISA-OFF-NOT: v_mul_f32_e64 v{{[0-9]+}}, 1.0, s{{[0-9]+}}
+// ISA-OFF-NOT: v_mul_f32_e64 v{{[0-9]+}}, 1.0, s{{[0-9]+}}
+// ISA-OFF: v_min_f32_e32
+// ISA-OFF: ; IeeeMode: 0
+kernel void kern(global float *x, float y, float z) {
+  *x = __builtin_fmin(y, z);
+}
+
+// COMMON: define{{.*}}void @fun() [[ATTRS2:#[0-9]+]]
+void fun() {
+}
+
+// ON-NOT: attributes [[ATTRS1]] = {{.*}} "amdgpu-ieee"
+// OFF: attributes [[ATTRS1]] = {{.*}} "amdgpu-ieee"="false"{{.*}}"no-nans-fp-math"="true"{{.*}}"no-trapping-math"="true"
+// ON-NOT: attributes [[ATTRS2]] = {{.*}} "amdgpu-ieee"
+// OFF: attributes [[ATTRS2]] = {{.*}} "amdgpu-ieee"="false"{{.*}}"no-nans-fp-math"="true"{{.*}}"no-trapping-math"="true"
+
+// DIAG: invalid argument '-mno-amdgpu-ieee' only allowed with '-fno-honor-nans'
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -1943,6 +1943,14 @@
   else if (Args.hasArg(options::OPT_fno_finite_loops))
 Opts.FiniteLoops = CodeGenOptions::FiniteLoopsKind::Never;
 
+  Opts.EmitIEEENaNCompliantInsts =
+  Args.hasFlag(options::OPT_mamdgpu_ieee, options::OPT_mno_amdgpu_ieee);
+  if (!Opts.EmitIEEENaNCompliantInsts && !LangOptsRef.NoHonorNaNs) {
+Diags.Report(diag::err_drv_argument_only_allowed_with_or_equivalent)
+<< "-mno-amdgpu-ieee"
+<< "-fno-honor-nans";
+  }
+
   return Diags.getNumErrors() == NumErrorsBefore;
 }
 
Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ clang/lib/CodeGen/TargetInfo.cpp
@@ -9166,6 +9166,9 @@
 
   if (M.getContext().getTargetInfo().allowAMDGPUUnsafeFPAtomics())
 F->addFnAttr("amdgpu-unsafe-fp-atomics", "true");
+
+  if (!getABIInfo().getCodeGenOpts().EmitIEEENaNCompliantInsts)
+F->addFnAttr("amdgpu-ieee", "false");
 }
 
 unsigned AMDGPUTargetCodeGenInfo::getOpenCLKernelCallingConv() const {
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -3171,6 +3171,14 @@
  Values<"command,reactor">,
  HelpText<"Execution model (WebAssembly only)">;
 
+defm amdgpu_ieee : BoolOption<"m", "amdgpu-ieee",
+  CodeGenOpts<"EmitIEEENaNCompliantInsts">, DefaultTrue,
+  PosFlag,
+  NegFlag>, Group;
+
 def mcode_object_version_EQ : Joined<["-"], "mcode-object-version=">, Group,
   HelpText<"Specify code object ABI version. Defaults to 3. (AMDGPU only)">,
   MetaVarName<"">, Values<"2,3,4">;
Index: clang/include/clang/Basic/DiagnosticDriverKinds.td
===
--- clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -127,6 +127,8 @@
   

[PATCH] D100820: [RISCV] Implement the vnot.v builtin.

2021-04-20 Thread Craig Topper via Phabricator via cfe-commits
craig.topper accepted this revision.
craig.topper 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/D100820/new/

https://reviews.llvm.org/D100820

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


[PATCH] D100822: [RISCV] Implement the vfabs.v/vfneg.v builtin.

2021-04-20 Thread Craig Topper via Phabricator via cfe-commits
craig.topper accepted this revision.
craig.topper 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/D100822/new/

https://reviews.llvm.org/D100822

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


[PATCH] D100755: [llvm-rc] [3/4] Run clang to preprocess input files

2021-04-20 Thread Martin Storsjö via Phabricator via cfe-commits
mstorsjo updated this revision to Diff 338969.
mstorsjo added a comment.
Herald added subscribers: cfe-commits, mgorny.
Herald added a project: clang.

- Added a testcase under clang/test/Preprocessor
- Changed the option to -no-preprocess
- Removed the env var for disabling preprocessing
- Made it look for both clang and clang-cl

This still uses --driver-mode=gcc; it currently doesn't allow setting options 
where --driver-mode=cl would matter, and allowing that does complicate things a 
little. So I'd leave that as a future improvement for when/if it becomes 
possible to set such options where it matters.

I'm also not adding any more convenience options like -winsysroot, -imsvc, 
-showincludes for now; leaving those to future patches (also possibly for 
people who actually use them who can verify that their use makes sense.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100755

Files:
  clang/test/CMakeLists.txt
  clang/test/Preprocessor/Inputs/llvm-rc.h
  clang/test/Preprocessor/llvm-rc.rc
  clang/test/lit.cfg.py
  llvm/test/tools/llvm-rc/absolute.test
  llvm/test/tools/llvm-rc/codepage.test
  llvm/test/tools/llvm-rc/cpp-output.test
  llvm/test/tools/llvm-rc/flags.test
  llvm/test/tools/llvm-rc/helpmsg.test
  llvm/test/tools/llvm-rc/include-paths.test
  llvm/test/tools/llvm-rc/language.test
  llvm/test/tools/llvm-rc/memoryflags-stringtable.test
  llvm/test/tools/llvm-rc/memoryflags.test
  llvm/test/tools/llvm-rc/not-expr.test
  llvm/test/tools/llvm-rc/parser-expr.test
  llvm/test/tools/llvm-rc/parser.test
  llvm/test/tools/llvm-rc/preproc.test
  llvm/test/tools/llvm-rc/tag-accelerators.test
  llvm/test/tools/llvm-rc/tag-dialog.test
  llvm/test/tools/llvm-rc/tag-escape.test
  llvm/test/tools/llvm-rc/tag-html.test
  llvm/test/tools/llvm-rc/tag-icon-cursor.test
  llvm/test/tools/llvm-rc/tag-menu.test
  llvm/test/tools/llvm-rc/tag-stringtable.test
  llvm/test/tools/llvm-rc/tag-user.test
  llvm/test/tools/llvm-rc/tag-versioninfo.test
  llvm/test/tools/llvm-rc/tokenizer.test
  llvm/test/tools/llvm-rc/versioninfo-padding.test
  llvm/tools/llvm-rc/Opts.td
  llvm/tools/llvm-rc/llvm-rc.cpp

Index: llvm/tools/llvm-rc/llvm-rc.cpp
===
--- llvm/tools/llvm-rc/llvm-rc.cpp
+++ llvm/tools/llvm-rc/llvm-rc.cpp
@@ -17,17 +17,22 @@
 #include "ResourceScriptStmt.h"
 #include "ResourceScriptToken.h"
 
+#include "llvm/ADT/Triple.h"
 #include "llvm/Option/Arg.h"
 #include "llvm/Option/ArgList.h"
 #include "llvm/Support/Error.h"
 #include "llvm/Support/FileSystem.h"
+#include "llvm/Support/FileUtilities.h"
+#include "llvm/Support/Host.h"
 #include "llvm/Support/InitLLVM.h"
 #include "llvm/Support/ManagedStatic.h"
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/PrettyStackTrace.h"
 #include "llvm/Support/Process.h"
+#include "llvm/Support/Program.h"
 #include "llvm/Support/Signals.h"
+#include "llvm/Support/StringSaver.h"
 #include "llvm/Support/raw_ostream.h"
 
 #include 
@@ -71,12 +76,114 @@
 };
 
 static ExitOnError ExitOnErr;
+static FileRemover TempPreprocFile;
 
 LLVM_ATTRIBUTE_NORETURN static void fatalError(const Twine ) {
   errs() << Message << "\n";
   exit(1);
 }
 
+std::string createTempFile(const Twine , StringRef Suffix) {
+  std::error_code EC;
+  SmallString<128> FileName;
+  if ((EC = sys::fs::createTemporaryFile(Prefix, Suffix, FileName)))
+fatalError("Unable to create temp file: " + EC.message());
+  return static_cast(FileName);
+}
+
+ErrorOr findClang(const char *Argv0) {
+  StringRef Parent = llvm::sys::path::parent_path(Argv0);
+  ErrorOr Path = std::error_code();
+  if (!Parent.empty()) {
+// First look for the tool with all potential names in the specific
+// directory of Argv0, if known
+for (const auto Name : {"clang", "clang-cl"}) {
+  Path = sys::findProgramByName(Name, Parent);
+  if (Path)
+return Path;
+}
+  }
+  // If no Parent directory known, or not found there, look everywhere in PATH
+  for (const auto Name : {"clang", "clang-cl"}) {
+Path = sys::findProgramByName(Name);
+if (Path)
+  return Path;
+  }
+  return Path;
+}
+
+std::string getClangClTriple() {
+  Triple T(sys::getDefaultTargetTriple());
+  T.setOS(llvm::Triple::Win32);
+  T.setVendor(llvm::Triple::PC);
+  T.setEnvironment(llvm::Triple::MSVC);
+  T.setObjectFormat(llvm::Triple::COFF);
+  return T.str();
+}
+
+bool preprocess(StringRef Src, StringRef Dst, opt::InputArgList ,
+const char *Argv0) {
+  std::string Clang;
+  if (InputArgs.hasArg(OPT__HASH_HASH_HASH)) {
+Clang = "clang";
+  } else {
+ErrorOr ClangOrErr = findClang(Argv0);
+if (ClangOrErr) {
+  Clang = *ClangOrErr;
+} else {
+  errs() << "llvm-rc: Unable to find clang, skipping preprocessing."
+ << "\n";
+  errs() << "Pass -no-cpp to disable preprocessing. This will be an 

[PATCH] D45639: [Driver] Support default libc++ library location on Darwin

2021-04-20 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

Looks like this breaks tests on windows: http://45.33.8.238/win/37191/step_7.txt


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D45639

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


[PATCH] D100794: [HIP] Support overloaded math functions for hipRTC

2021-04-20 Thread Justin Lebar via Phabricator via cfe-commits
jlebar added a comment.

Other than the declval issue discussed above, this looks reasonable to me.  I 
don't notice anything wrong with the standard library reimplementations here.


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

https://reviews.llvm.org/D100794

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


[PATCH] D100807: [clang][driver] Use the canonical Darwin arch name when printing out the triple for a Darwin target

2021-04-20 Thread Ahmed Bougacha via Phabricator via cfe-commits
ab added a comment.

This sounds nice!  One idea, maybe more dangerous, not sure which is better:  
in `setTripleTypeForMachOArchName`, we already have a couple `setArchName` 
calls, I think that's why `arm64e` is left alone in the `aarch64-cpus.c` test.  
Maybe we can do the `setArchName` call for every arch there?

Another question, probably a completely separate problem: why is it still 
reporting darwin?  Ideally we'd want it to report macos, right?  With that + 
your change the triple there would be the actual triple we use to build.  (but 
maybe the macos bit only comes later when we pick up an SDK in DarwinClang or 
whatever?)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100807

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


[PATCH] D91950: [clang-format] Add BreakBeforeInlineASMColon configuration

2021-04-20 Thread Anastasiia Lukianenko via Phabricator via cfe-commits
anastasiia_lukianenko updated this revision to Diff 338958.

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

https://reviews.llvm.org/D91950

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/ContinuationIndenter.cpp
  clang/lib/Format/Format.cpp
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -2666,12 +2666,15 @@
 TEST_F(FormatTest, FormatsInlineASM) {
   verifyFormat("asm(\"xyz\" : \"=a\"(a), \"=d\"(b) : \"a\"(data));");
   verifyFormat("asm(\"nop\" ::: \"memory\");");
+
+  FormatStyle Style = getLLVMStyle();
+  Style.BreakBeforeInlineASMColon = true;
   verifyFormat(
   "asm(\"movq\\t%%rbx, %%rsi\\n\\t\"\n"
   "\"cpuid\\n\\t\"\n"
   "\"xchgq\\t%%rbx, %%rsi\\n\\t\"\n"
   ": \"=a\"(*rEAX), \"=S\"(*rEBX), \"=c\"(*rECX), \"=d\"(*rEDX)\n"
-  ": \"a\"(value));");
+  ": \"a\"(value));", Style);
   EXPECT_EQ(
   "void NS_InvokeByIndex(void *that, unsigned int methodIndex) {\n"
   "  __asm {\n"
@@ -5069,6 +5072,43 @@
 format(Input, Style));
 }
 
+TEST_F(FormatTest, BreakBeforeInlineASMColon) {
+  FormatStyle Style = getLLVMStyle();
+  Style.BreakStringLiterals = false;
+  Style.BreakBeforeInlineASMColon = false;
+  /* Test the behaviour with long lines */
+  Style.ColumnLimit = 40;
+  verifyFormat("asm volatile(\"lng\",\n"
+   " : : val);",
+   Style);
+  verifyFormat("asm volatile(\"lng\",\n"
+   " : val1 : val2);",
+   Style);
+  Style.ColumnLimit = 80;
+  verifyFormat("asm volatile(\"string\", : : val);", Style);
+  verifyFormat("asm volatile(\"string\", : val1 : val2);", Style);
+
+  Style.BreakBeforeInlineASMColon = true;
+  verifyFormat("asm volatile(\"string\",\n"
+   " :\n"
+   " : val);",
+   Style);
+  verifyFormat("asm volatile(\"string\",\n"
+   " : val1\n"
+   " : val2);",
+   Style);
+  /* Test the behaviour with long lines */
+  Style.ColumnLimit = 40;
+  verifyFormat("asm volatile(\"lng\",\n"
+   " :\n"
+   " : val);",
+   Style);
+  verifyFormat("asm volatile(\"lng\",\n"
+   " : val1\n"
+   " : val2);",
+   Style);
+}
+
 TEST_F(FormatTest, BreakConstructorInitializersAfterColon) {
   FormatStyle Style = getLLVMStyle();
   Style.BreakConstructorInitializers = FormatStyle::BCIS_AfterColon;
@@ -18420,15 +18460,17 @@
   // A list of several ASM symbolic names.
   verifyFormat(R"(asm("mov %[e], %[d]" : [d] "=rm"(d), [e] "rm"(*e));)");
 
+  // ASM symbolic names in inline ASM with no outputs.
+  verifyFormat(R"(asm("mov %[e], %[d]" : : [d] "=rm"(d), [e] "rm"(*e));)");
+
+  format::FormatStyle Style = format::getLLVMStyle();
+  Style.BreakBeforeInlineASMColon = true;
   // ASM symbolic names in inline ASM with inputs and outputs.
   verifyFormat(R"(//
 asm("cmoveq %1, %2, %[result]"
 : [result] "=r"(result)
 : "r"(test), "r"(new), "[result]"(old));
-)");
-
-  // ASM symbolic names in inline ASM with no outputs.
-  verifyFormat(R"(asm("mov %[e], %[d]" : : [d] "=rm"(d), [e] "rm"(*e));)");
+)", Style);
 }
 
 TEST_F(FormatTest, GuessedLanguageWithInlineAsmClobbers) {
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -3514,6 +3514,9 @@
   const FormatToken  = *Right.Previous;
   if (Right.NewlinesBefore > 1 && Style.MaxEmptyLinesToKeep > 0)
 return true;
+  if (Line.startsWith(tok::kw_asm) && Right.is(TT_InlineASMColon) &&
+  Style.BreakBeforeInlineASMColon)
+return true;
 
   if (Style.isCSharp()) {
 if (Right.is(TT_CSharpNamedArgumentColon) ||
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -554,6 +554,9 @@
 Style.BreakInheritanceList == FormatStyle::BILS_BeforeColon)
   Style.BreakInheritanceList = FormatStyle::BILS_BeforeComma;
 
+IO.mapOptional("BreakBeforeInlineASMColon",
+   Style.BreakBeforeInlineASMColon);
+
 IO.mapOptional("BreakBeforeTernaryOperators",
Style.BreakBeforeTernaryOperators);
 
@@ -940,6 +943,7 @@
   LLVMStyle.BinPackParameters = true;
   LLVMStyle.BreakBeforeBinaryOperators = FormatStyle::BOS_None;
   LLVMStyle.BreakBeforeConceptDeclarations = true;
+  LLVMStyle.BreakBeforeInlineASMColon = false;
  

[PATCH] D45639: [Driver] Support default libc++ library location on Darwin

2021-04-20 Thread Petr Hosek via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGae8b2cab6740: [Driver] Support default libc++ library 
location on Darwin (authored by phosek).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D45639

Files:
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/test/Driver/darwin-ld.c


Index: clang/test/Driver/darwin-ld.c
===
--- clang/test/Driver/darwin-ld.c
+++ clang/test/Driver/darwin-ld.c
@@ -365,3 +365,8 @@
 // RUN: FileCheck -check-prefix=MNO_OUTLINE %s < %t.log
 // MNO_OUTLINE: {{ld(.exe)?"}}
 // MNO_OUTLINE-SAME: "-mllvm" "-enable-machine-outliner=never"
+
+// RUN: %clang -target x86_64-apple-darwin10 -### %t.o 2> %t.log
+// RUN: FileCheck -check-prefix=INSTALL-DIR %s < %t.log
+// INSTALL-DIR: InstalledDir: [[INSTALLDIR:.+$]]
+// INSTALL-DIR: "-L[[INSTALLDIR]]/../lib"
Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -615,6 +615,8 @@
 
   Args.AddAllArgs(CmdArgs, options::OPT_L);
 
+  getToolChain().AddFilePathLibArgs(Args, CmdArgs);
+
   AddLinkerInputs(getToolChain(), Inputs, Args, CmdArgs, JA);
   // Build the input file for -filelist (list of linker input files) in case we
   // need it later
@@ -802,6 +804,7 @@
   getProgramPaths().push_back(getDriver().getInstalledDir());
   if (getDriver().getInstalledDir() != getDriver().Dir)
 getProgramPaths().push_back(getDriver().Dir);
+  getFilePaths().push_back(getDriver().Dir + "/../lib");
 }
 
 /// Darwin - Darwin tool chain for i386 and x86_64.


Index: clang/test/Driver/darwin-ld.c
===
--- clang/test/Driver/darwin-ld.c
+++ clang/test/Driver/darwin-ld.c
@@ -365,3 +365,8 @@
 // RUN: FileCheck -check-prefix=MNO_OUTLINE %s < %t.log
 // MNO_OUTLINE: {{ld(.exe)?"}}
 // MNO_OUTLINE-SAME: "-mllvm" "-enable-machine-outliner=never"
+
+// RUN: %clang -target x86_64-apple-darwin10 -### %t.o 2> %t.log
+// RUN: FileCheck -check-prefix=INSTALL-DIR %s < %t.log
+// INSTALL-DIR: InstalledDir: [[INSTALLDIR:.+$]]
+// INSTALL-DIR: "-L[[INSTALLDIR]]/../lib"
Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -615,6 +615,8 @@
 
   Args.AddAllArgs(CmdArgs, options::OPT_L);
 
+  getToolChain().AddFilePathLibArgs(Args, CmdArgs);
+
   AddLinkerInputs(getToolChain(), Inputs, Args, CmdArgs, JA);
   // Build the input file for -filelist (list of linker input files) in case we
   // need it later
@@ -802,6 +804,7 @@
   getProgramPaths().push_back(getDriver().getInstalledDir());
   if (getDriver().getInstalledDir() != getDriver().Dir)
 getProgramPaths().push_back(getDriver().Dir);
+  getFilePaths().push_back(getDriver().Dir + "/../lib");
 }
 
 /// Darwin - Darwin tool chain for i386 and x86_64.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] ae8b2ca - [Driver] Support default libc++ library location on Darwin

2021-04-20 Thread Petr Hosek via cfe-commits

Author: Petr Hosek
Date: 2021-04-20T12:30:35-07:00
New Revision: ae8b2cab67408a043a4fe964d16e4803553c4ee0

URL: 
https://github.com/llvm/llvm-project/commit/ae8b2cab67408a043a4fe964d16e4803553c4ee0
DIFF: 
https://github.com/llvm/llvm-project/commit/ae8b2cab67408a043a4fe964d16e4803553c4ee0.diff

LOG: [Driver] Support default libc++ library location on Darwin

Darwin driver currently uses libc++ headers that are part of Clang
toolchain when available (by default ../include/c++/v1 relative to
executable), but it completely ignores the libc++ library itself
because it doesn't pass the location of libc++ library that's part
of Clang (by default ../lib relative to the exceutable) to the linker
always using the system copy of libc++.

This may lead to subtle issues when the compilation fails because the
headers that are part of Clang toolchain are incompatible with the
system library. Either the driver should ignore both headers as well as
the library, or it should always try to use both when available.

This patch changes the driver behavior to do the latter which seems more
reasonable, it makes it easy to test and use custom libc++ build on
Darwin while still allowing the use of system version. This also matches
the Clang driver behavior on other systems.

Differential Revision: https://reviews.llvm.org/D45639

Added: 


Modified: 
clang/lib/Driver/ToolChains/Darwin.cpp
clang/test/Driver/darwin-ld.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Darwin.cpp 
b/clang/lib/Driver/ToolChains/Darwin.cpp
index bc59b6beafc7..06d4f2f4df0b 100644
--- a/clang/lib/Driver/ToolChains/Darwin.cpp
+++ b/clang/lib/Driver/ToolChains/Darwin.cpp
@@ -615,6 +615,8 @@ void darwin::Linker::ConstructJob(Compilation , const 
JobAction ,
 
   Args.AddAllArgs(CmdArgs, options::OPT_L);
 
+  getToolChain().AddFilePathLibArgs(Args, CmdArgs);
+
   AddLinkerInputs(getToolChain(), Inputs, Args, CmdArgs, JA);
   // Build the input file for -filelist (list of linker input files) in case we
   // need it later
@@ -802,6 +804,7 @@ MachO::MachO(const Driver , const llvm::Triple , 
const ArgList )
   getProgramPaths().push_back(getDriver().getInstalledDir());
   if (getDriver().getInstalledDir() != getDriver().Dir)
 getProgramPaths().push_back(getDriver().Dir);
+  getFilePaths().push_back(getDriver().Dir + "/../lib");
 }
 
 /// Darwin - Darwin tool chain for i386 and x86_64.

diff  --git a/clang/test/Driver/darwin-ld.c b/clang/test/Driver/darwin-ld.c
index 15e5d100afcb..4de850fad9d8 100644
--- a/clang/test/Driver/darwin-ld.c
+++ b/clang/test/Driver/darwin-ld.c
@@ -365,3 +365,8 @@
 // RUN: FileCheck -check-prefix=MNO_OUTLINE %s < %t.log
 // MNO_OUTLINE: {{ld(.exe)?"}}
 // MNO_OUTLINE-SAME: "-mllvm" "-enable-machine-outliner=never"
+
+// RUN: %clang -target x86_64-apple-darwin10 -### %t.o 2> %t.log
+// RUN: FileCheck -check-prefix=INSTALL-DIR %s < %t.log
+// INSTALL-DIR: InstalledDir: [[INSTALLDIR:.+$]]
+// INSTALL-DIR: "-L[[INSTALLDIR]]/../lib"



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


[PATCH] D100830: [RISCV] [1/2] Add IR intrinsic for Zbp extension

2021-04-20 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoB.td:33
 def riscv_shfl   : SDNode<"RISCVISD::SHFL",   SDTIntBinOp>;
+def riscv_shflw   : SDNode<"RISCVISD::SHFLW",   SDT_RISCVIntBinOpW>;
+def riscv_unshfl   : SDNode<"RISCVISD::UNSHFL",   SDTIntBinOp>;

Line the colons up



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoB.td:749
 def : PatGprImm;
+def : PatGprImm;
 } // Predicates = [HasStdExtZbp]

Put this between riscv_shfl and riscv_grev so that shfl and unshfl are together



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoB.td:946
+let Predicates = [HasStdExtZbp] in {
+def : PatGprGpr;
+def : PatGprGpr;

Put these in the same block that has PatGprImmhttps://reviews.llvm.org/D100830/new/

https://reviews.llvm.org/D100830

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


[PATCH] D100794: [HIP] Support overloaded math functions for hipRTC

2021-04-20 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl marked 2 inline comments as done.
yaxunl added inline comments.



Comment at: clang/lib/Headers/__clang_hip_cmath.h:341
 
-  typedef decltype(__test(std::declval<_Tp>())) type;
-  static const bool value = !std::is_same::value;
+  typedef decltype(__test(_Tp{})) type;
+  static const bool value = !is_same::value;

tra wrote:
> tra wrote:
> > @jlebar : Should we expect any observable surprises here?
> `_Tp{}` may break if `_Tp` does not have a default constructor. At least it 
> does so with C++20, while the old code did not: 
> https://godbolt.org/z/PGEff5Mvv
Right. It occurred to me that users may overload these math functions with 
arguments without default ctor, then we will hit the issue.

I will fix this.


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

https://reviews.llvm.org/D100794

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


[PATCH] D100879: [Clang] Propagate guaranteed alignment for malloc and others

2021-04-20 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added a comment.

GCC already knows about this guaranteed alignment, check:
https://godbolt.org/z/sxn6K7Yq7

Alignment checks were optimized out.


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

https://reviews.llvm.org/D100879

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


[PATCH] D100879: [Clang] Propagate guaranteed alignment for malloc and others

2021-04-20 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added inline comments.



Comment at: clang/lib/CodeGen/CGCall.cpp:2060
+case Builtin::BIstrndup:
+  RetAttrs.addAlignmentAttr(Context.getTargetInfo().getNewAlign() /
+Context.getTargetInfo().getCharWidth());

lebedev.ri wrote:
> malloc != new
But the comment for the implementation of this value points on eg. gcc's docs:

https://clang.llvm.org/doxygen/Basic_2TargetInfo_8cpp_source.html line 67

   // From the glibc documentation, on GNU systems, malloc guarantees 16-byte
   // alignment on 64-bit systems and 8-byte alignment on 32-bit systems. See
   // https://www.gnu.org/software/libc/manual/html_node/Malloc-Examples.html.
   // This alignment guarantee also applies to Windows and Android. On Darwin,
   // the alignment is 16 bytes on both 64-bit and 32-bit systems.

So this value is correct to be used for malloc and friends IMHO.


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

https://reviews.llvm.org/D100879

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


[PATCH] D100879: [Clang] Propagate guaranteed alignment for malloc and others

2021-04-20 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added inline comments.



Comment at: clang/lib/CodeGen/CGCall.cpp:2060
+case Builtin::BIstrndup:
+  RetAttrs.addAlignmentAttr(Context.getTargetInfo().getNewAlign() /
+Context.getTargetInfo().getCharWidth());

malloc != new


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

https://reviews.llvm.org/D100879

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


[PATCH] D100879: [Clang] Propagate guaranteed alignment for malloc and others

2021-04-20 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added inline comments.



Comment at: clang/lib/CodeGen/CGCall.cpp:2059
+case Builtin::BIstrdup:
+case Builtin::BIstrndup:
+  RetAttrs.addAlignmentAttr(Context.getTargetInfo().getNewAlign() /

As a followup, I need to teach Clang about aligned_alloc and memalign.


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

https://reviews.llvm.org/D100879

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


[PATCH] D100879: [Clang] Propagate guaranteed alignment for malloc and others

2021-04-20 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 updated this revision to Diff 338950.
xbolva00 added a reviewer: jdoerfert.

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

https://reviews.llvm.org/D100879

Files:
  clang/lib/CodeGen/CGCall.cpp


Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -2048,6 +2048,22 @@
   // allows it to work on indirect virtual function calls.
   if (AttrOnCallSite && TargetDecl->hasAttr())
 FuncAttrs.addAttribute(llvm::Attribute::NoMerge);
+
+  // Add known guaranteed alignment for allocation functions
+  if (unsigned BuiltinID = Fn->getBuiltinID()) {
+switch (BuiltinID) {
+case Builtin::BImalloc:
+case Builtin::BIcalloc:
+case Builtin::BIrealloc:
+case Builtin::BIstrdup:
+case Builtin::BIstrndup:
+  RetAttrs.addAlignmentAttr(Context.getTargetInfo().getNewAlign() /
+Context.getTargetInfo().getCharWidth());
+  break;
+default:
+  break;
+}
+  }
 }
 
 // 'const', 'pure' and 'noalias' attributed functions are also nounwind.


Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -2048,6 +2048,22 @@
   // allows it to work on indirect virtual function calls.
   if (AttrOnCallSite && TargetDecl->hasAttr())
 FuncAttrs.addAttribute(llvm::Attribute::NoMerge);
+
+  // Add known guaranteed alignment for allocation functions
+  if (unsigned BuiltinID = Fn->getBuiltinID()) {
+switch (BuiltinID) {
+case Builtin::BImalloc:
+case Builtin::BIcalloc:
+case Builtin::BIrealloc:
+case Builtin::BIstrdup:
+case Builtin::BIstrndup:
+  RetAttrs.addAlignmentAttr(Context.getTargetInfo().getNewAlign() /
+Context.getTargetInfo().getCharWidth());
+  break;
+default:
+  break;
+}
+  }
 }
 
 // 'const', 'pure' and 'noalias' attributed functions are also nounwind.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D100879: [Clang] Propagate guaranteed alignment for malloc and others

2021-04-20 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added a comment.

If this approach makes sense, I will update / add tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100879

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


[PATCH] D100879: [Clang] Propagate guaranteed alignment for malloc and others

2021-04-20 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 created this revision.
xbolva00 added reviewers: aaron.ballman, rjmccall.
xbolva00 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

LLVM should be smarter about *known* malloc's alignment and this knowledge may 
enable other optimizations.

Originally started as LLVM patch - https://reviews.llvm.org/D100862 but this 
logic should be really in Clang.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100879

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/Sema/SemaDecl.cpp


Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -45,6 +45,7 @@
 #include "clang/Sema/Template.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/ADT/Triple.h"
+ #include "llvm/IR/Attributes.h"
 #include 
 #include 
 #include 
Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -2048,6 +2048,22 @@
   // allows it to work on indirect virtual function calls.
   if (AttrOnCallSite && TargetDecl->hasAttr())
 FuncAttrs.addAttribute(llvm::Attribute::NoMerge);
+
+  // Add known guaranteed alignment for allocation functions
+  if (unsigned BuiltinID = Fn->getBuiltinID()) {
+switch (BuiltinID) {
+case Builtin::BImalloc:
+case Builtin::BIcalloc:
+case Builtin::BIrealloc:
+case Builtin::BIstrdup:
+case Builtin::BIstrndup:
+  RetAttrs.addAlignmentAttr(Context.getTargetInfo().getNewAlign() /
+Context.getTargetInfo().getCharWidth());
+  break;
+default:
+  break;
+}
+  }
 }
 
 // 'const', 'pure' and 'noalias' attributed functions are also nounwind.


Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -45,6 +45,7 @@
 #include "clang/Sema/Template.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/ADT/Triple.h"
+ #include "llvm/IR/Attributes.h"
 #include 
 #include 
 #include 
Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -2048,6 +2048,22 @@
   // allows it to work on indirect virtual function calls.
   if (AttrOnCallSite && TargetDecl->hasAttr())
 FuncAttrs.addAttribute(llvm::Attribute::NoMerge);
+
+  // Add known guaranteed alignment for allocation functions
+  if (unsigned BuiltinID = Fn->getBuiltinID()) {
+switch (BuiltinID) {
+case Builtin::BImalloc:
+case Builtin::BIcalloc:
+case Builtin::BIrealloc:
+case Builtin::BIstrdup:
+case Builtin::BIstrndup:
+  RetAttrs.addAlignmentAttr(Context.getTargetInfo().getNewAlign() /
+Context.getTargetInfo().getCharWidth());
+  break;
+default:
+  break;
+}
+  }
 }
 
 // 'const', 'pure' and 'noalias' attributed functions are also nounwind.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D100834: Bug 49739 - [Matrix] Support #pragma clang fp

2021-04-20 Thread Kevin P. Neal via Phabricator via cfe-commits
kpn added a comment.

I don't know the matrix implementation so I can't swear this hits every place 
needed, but the uses of CGFPOptionsRAII in this patch look correct at least.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100834

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


[PATCH] D77013: [AMDGPU] Add options -mamdgpu-ieee -mno-amdgpu-ieee

2021-04-20 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl marked 2 inline comments as done.
yaxunl added inline comments.



Comment at: clang/lib/Frontend/CompilerInvocation.cpp:1951
+  Args.hasFlag(options::OPT_mamdgpu_ieee, options::OPT_mno_amdgpu_ieee,
+   !LangOptsRef.NoHonorNaNs);
+

arsenm wrote:
> yaxunl wrote:
> > arsenm wrote:
> > > This should not be implied by no honor nans. This is an ABI changing 
> > > option. We need to require that no nans FP math is enabled to use this 
> > > mode correctly though
> > OK I plan to make changes about this. However I need to clarify about when 
> > should we add function attribute amdgpu-ieee=false:
> > 
> > 1. when neither -mamdgpu-ieee nor -mno-amdgpu-ieee is specified, we will 
> > add func attr amdgpu-ieee=false if LangOptsRef.NoHonorNaNs is true
> > 
> > 2. when -mamdgpu-ieee or -mno-amdgpu-ieee is specified, we will add func 
> > attr amdgpu-ieee=false solely based on these two options, disregarding 
> > LangOptsRef.NoHonorNaNs
> > 
> > Is that correct?
>   # You should only add the attribute "amdgpu-ieee"="false" if and only if 
> -mno-amdgpu-ieee is used. This is entirely orthogonal to NoHonorNaNs. The 
> default is amdgpu-ieee=true, and there's no need to explicitly mark the 
> function
> 
>   # It is an error to use -mno-amdgpu-ieee without NoHonorNaNs because we do 
> not implement the legalization required to manually quiet signaling nans. We 
> cannot silently drop the use of of this
> 
I can add diagnostics in clang -cc1 when -mno-amdgpu-ieee is used without 
NoHonorNaNs. I cannot diagnose it in clang driver because there are multiple 
driver options affecting NoHonorNaNs and they could override each other.


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

https://reviews.llvm.org/D77013

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


[PATCH] D100794: [HIP] Support overloaded math functions for hipRTC

2021-04-20 Thread Artem Belevich via Phabricator via cfe-commits
tra added inline comments.



Comment at: clang/lib/Headers/__clang_hip_cmath.h:341
 
-  typedef decltype(__test(std::declval<_Tp>())) type;
-  static const bool value = !std::is_same::value;
+  typedef decltype(__test(_Tp{})) type;
+  static const bool value = !is_same::value;

tra wrote:
> @jlebar : Should we expect any observable surprises here?
`_Tp{}` may break if `_Tp` does not have a default constructor. At least it 
does so with C++20, while the old code did not: https://godbolt.org/z/PGEff5Mvv


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

https://reviews.llvm.org/D100794

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


[PATCH] D100874: [OpenMP] Use irbuilder as default for masked and master construct

2021-04-20 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

Patch description is empty.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100874

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


[PATCH] D100834: Bug 49739 - [Matrix] Support #pragma clang fp

2021-04-20 Thread Hamza Mahfooz via Phabricator via cfe-commits
effective-light updated this revision to Diff 338941.
effective-light added a comment.

Whoops


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100834

Files:
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/test/CodeGen/fp-matrix-pragma.c


Index: clang/test/CodeGen/fp-matrix-pragma.c
===
--- /dev/null
+++ clang/test/CodeGen/fp-matrix-pragma.c
@@ -0,0 +1,33 @@
+// RUN: %clang_cc1 -emit-llvm -S -fenable-matrix -mllvm -disable-llvm-optzns 
-o - | FileCheck %s
+
+typedef float fx2x2_t __attribute__((matrix_type(2, 2)));
+typedef int ix2x2_t __attribute__((matrix_type(2, 2)));
+
+fx2x2_t fp_matrix_contract(fx2x2_t a, fx2x2_t b, float c, float d) {
+// CHECK: call contract <4 x float> @llvm.matrix.multiply.v4f32.v4f32.v4f32
+// CHECK: fdiv contract <4 x float>
+// CHECK: fmul contract <4 x float>
+#pragma clang fp contract(fast)
+  return (a * b / c) * d;
+}
+
+fx2x2_t fp_matrix_reassoc(fx2x2_t a, fx2x2_t b, fx2x2_t c) {
+// CHECK: fadd reassoc <4 x float>
+// CHECK: fsub reassoc <4 x float>
+#pragma clang fp reassociate(on)
+  return a + b - c;
+}
+
+fx2x2_t fp_matrix_ops(fx2x2_t a, fx2x2_t b, fx2x2_t c) {
+// CHECK: call reassoc contract <4 x float> 
@llvm.matrix.multiply.v4f32.v4f32.v4f32
+// CHECK: fadd reassoc contract <4 x float>
+#pragma clang fp contract(fast) reassociate(on)
+  return a * b + c;
+}
+
+ix2x2_t int_matrix_ops(ix2x2_t a, ix2x2_t b, ix2x2_t c) {
+// CHECK: call <4 x i32> @llvm.matrix.multiply.v4i32.v4i32.v4i32
+// CHECK: add <4 x i32>
+#pragma clang fp contract(fast) reassociate(on)
+  return a * b + c;
+}
Index: clang/lib/CodeGen/CGExprScalar.cpp
===
--- clang/lib/CodeGen/CGExprScalar.cpp
+++ clang/lib/CodeGen/CGExprScalar.cpp
@@ -732,6 +732,7 @@
   BO->getLHS()->getType().getCanonicalType());
   auto *RHSMatTy = dyn_cast(
   BO->getRHS()->getType().getCanonicalType());
+  CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, Ops.FPFeatures);
   if (LHSMatTy && RHSMatTy)
 return MB.CreateMatrixMultiply(Ops.LHS, Ops.RHS, 
LHSMatTy->getNumRows(),
LHSMatTy->getNumColumns(),
@@ -3206,6 +3207,7 @@
 "first operand must be a matrix");
 assert(BO->getRHS()->getType().getCanonicalType()->isArithmeticType() &&
"second operand must be an arithmetic type");
+CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, Ops.FPFeatures);
 return MB.CreateScalarDiv(Ops.LHS, Ops.RHS,
   Ops.Ty->hasUnsignedIntegerRepresentation());
   }
@@ -3585,6 +3587,7 @@
 
   if (op.Ty->isConstantMatrixType()) {
 llvm::MatrixBuilder MB(Builder);
+CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, op.FPFeatures);
 return MB.CreateAdd(op.LHS, op.RHS);
   }
 
@@ -3734,6 +3737,7 @@
 
 if (op.Ty->isConstantMatrixType()) {
   llvm::MatrixBuilder MB(Builder);
+  CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, op.FPFeatures);
   return MB.CreateSub(op.LHS, op.RHS);
 }
 


Index: clang/test/CodeGen/fp-matrix-pragma.c
===
--- /dev/null
+++ clang/test/CodeGen/fp-matrix-pragma.c
@@ -0,0 +1,33 @@
+// RUN: %clang_cc1 -emit-llvm -S -fenable-matrix -mllvm -disable-llvm-optzns -o - | FileCheck %s
+
+typedef float fx2x2_t __attribute__((matrix_type(2, 2)));
+typedef int ix2x2_t __attribute__((matrix_type(2, 2)));
+
+fx2x2_t fp_matrix_contract(fx2x2_t a, fx2x2_t b, float c, float d) {
+// CHECK: call contract <4 x float> @llvm.matrix.multiply.v4f32.v4f32.v4f32
+// CHECK: fdiv contract <4 x float>
+// CHECK: fmul contract <4 x float>
+#pragma clang fp contract(fast)
+  return (a * b / c) * d;
+}
+
+fx2x2_t fp_matrix_reassoc(fx2x2_t a, fx2x2_t b, fx2x2_t c) {
+// CHECK: fadd reassoc <4 x float>
+// CHECK: fsub reassoc <4 x float>
+#pragma clang fp reassociate(on)
+  return a + b - c;
+}
+
+fx2x2_t fp_matrix_ops(fx2x2_t a, fx2x2_t b, fx2x2_t c) {
+// CHECK: call reassoc contract <4 x float> @llvm.matrix.multiply.v4f32.v4f32.v4f32
+// CHECK: fadd reassoc contract <4 x float>
+#pragma clang fp contract(fast) reassociate(on)
+  return a * b + c;
+}
+
+ix2x2_t int_matrix_ops(ix2x2_t a, ix2x2_t b, ix2x2_t c) {
+// CHECK: call <4 x i32> @llvm.matrix.multiply.v4i32.v4i32.v4i32
+// CHECK: add <4 x i32>
+#pragma clang fp contract(fast) reassociate(on)
+  return a * b + c;
+}
Index: clang/lib/CodeGen/CGExprScalar.cpp
===
--- clang/lib/CodeGen/CGExprScalar.cpp
+++ clang/lib/CodeGen/CGExprScalar.cpp
@@ -732,6 +732,7 @@
   BO->getLHS()->getType().getCanonicalType());
   auto *RHSMatTy = dyn_cast(
   BO->getRHS()->getType().getCanonicalType());
+  CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, Ops.FPFeatures);
   if (LHSMatTy && RHSMatTy)
   

[clang] 057b6f5 - clang: Update libstdc++ issue workaround

2021-04-20 Thread Nathan Sidwell via cfe-commits

Author: Nathan Sidwell
Date: 2021-04-20T11:34:12-07:00
New Revision: 057b6f5d0b3ec1c1d0a87eb3d99ac4a46ca68cb4

URL: 
https://github.com/llvm/llvm-project/commit/057b6f5d0b3ec1c1d0a87eb3d99ac4a46ca68cb4
DIFF: 
https://github.com/llvm/llvm-project/commit/057b6f5d0b3ec1c1d0a87eb3d99ac4a46ca68cb4.diff

LOG: clang: Update libstdc++ issue workaround

Add some specificity to libstdc++ hack, perhaps we can remove it at a
later date.

Added: 


Modified: 
clang/lib/Sema/SemaDeclCXX.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaDeclCXX.cpp b/clang/lib/Sema/SemaDeclCXX.cpp
index 95eac2859b57..7a5f66d31105 100644
--- a/clang/lib/Sema/SemaDeclCXX.cpp
+++ b/clang/lib/Sema/SemaDeclCXX.cpp
@@ -12134,10 +12134,9 @@ NamedDecl *Sema::BuildUsingDeclaration(
   // invalid).
   if (R.empty() &&
   NameInfo.getName().getNameKind() != DeclarationName::CXXConstructorName) 
{
-// HACK: Work around a bug in libstdc++'s detection of ::gets. Sometimes
-// it will believe that glibc provides a ::gets in cases where it does not,
-// and will try to pull it into namespace std with a using-declaration.
-// Just ignore the using-declaration in that case.
+// HACK 2017-01-08: Work around an issue with libstdc++'s detection of
+// ::gets. Sometimes it believes that glibc provides a ::gets in cases 
where
+// it does not. The issue was fixed in libstdc++ 6.3 (2016-12-21) and 
later.
 auto *II = NameInfo.getName().getAsIdentifierInfo();
 if (getLangOpts().CPlusPlus14 && II && II->isStr("gets") &&
 CurContext->isStdNamespace() &&



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


[PATCH] D100874: [OpenMP] Use irbuilder as default for masked and master construct

2021-04-20 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert accepted this revision.
jdoerfert added a comment.
This revision is now accepted and ready to land.

LGTM, thanks


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100874

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


[PATCH] D100118: [clang] RFC Support new builtin __arithmetic_fence to control floating point optimization, and new clang option fprotect-parens

2021-04-20 Thread Melanie Blower via Phabricator via cfe-commits
mibintc added inline comments.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:2844
+  return RValue::get(
+  Builder.CreateArithmeticFence(ArgValue, ConvertType(ArgType)));
+return RValue::get(ArgValue);

mibintc wrote:
> kpn wrote:
> > Does this say that the fence will be silently dropped if any of the fast 
> > math flags are disabled? Silently dropping something used for correctness 
> > makes me nervous. Is there a case where all of these flags are required for 
> > correct behavior of the fence?
> Yes that is the idea, the clang builtin is only meaningful for float 
> operations when -ffast-math is enabled.  If fast math isn't enabled then the 
> operations should already be performed strictly.  I didn't have "isFast", 
> should rewrite with isFast to make it easier to understand 
Oops I'm wrong. @kbsmith1 tells me only the reassoc bit is interesting. i'll 
need to fix this in the documentation etc. Thanks for your careful reading. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100118

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


[PATCH] D100567: BPF: emit debuginfo for Function of DeclRefExpr if requested

2021-04-20 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

In D100567#2702394 , @yonghong-song 
wrote:

> ping @dblaikie could you take a look of my new investigation?

Yep, it's on my list to look at.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100567

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


[PATCH] D100118: [clang] RFC Support new builtin __arithmetic_fence to control floating point optimization, and new clang option fprotect-parens

2021-04-20 Thread Melanie Blower via Phabricator via cfe-commits
mibintc added inline comments.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:2844
+  return RValue::get(
+  Builder.CreateArithmeticFence(ArgValue, ConvertType(ArgType)));
+return RValue::get(ArgValue);

kpn wrote:
> Does this say that the fence will be silently dropped if any of the fast math 
> flags are disabled? Silently dropping something used for correctness makes me 
> nervous. Is there a case where all of these flags are required for correct 
> behavior of the fence?
Yes that is the idea, the clang builtin is only meaningful for float operations 
when -ffast-math is enabled.  If fast math isn't enabled then the operations 
should already be performed strictly.  I didn't have "isFast", should rewrite 
with isFast to make it easier to understand 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100118

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


[clang] 6e77a67 - Fix clang Visual Studio build instructions

2021-04-20 Thread Adrian McCarthy via cfe-commits

Author: Alessandro Vergani
Date: 2021-04-20T11:17:29-07:00
New Revision: 6e77a67171e68d9eda811799d5b1c2530282478e

URL: 
https://github.com/llvm/llvm-project/commit/6e77a67171e68d9eda811799d5b1c2530282478e
DIFF: 
https://github.com/llvm/llvm-project/commit/6e77a67171e68d9eda811799d5b1c2530282478e.diff

LOG: Fix clang Visual Studio build instructions

Change cd ..\.. to cd llvm-project (the former is probably a leftover
of the old svn instructions)

Committer: Adrian McCarthy 

Differential Revision: https://reviews.llvm.org/D68321

Added: 


Modified: 
clang/www/get_started.html

Removed: 




diff  --git a/clang/www/get_started.html b/clang/www/get_started.html
index 4c5a3976a6ad..aacf55af8f57 100755
--- a/clang/www/get_started.html
+++ b/clang/www/get_started.html
@@ -137,7 +137,7 @@ Using Visual Studio
   
   Run CMake to generate the Visual Studio solution and project files:
   
-cd ..\..  (back to where you started)
+cd llvm-project
 mkdir build (for building without polluting the source 
dir)
 cd build
 



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


[PATCH] D68321: Fix clang Visual Studio build instructions

2021-04-20 Thread Adrian McCarthy via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG6e77a67171e6: Fix clang Visual Studio build instructions 
(authored by Loghorn, committed by amccarth).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68321

Files:
  clang/www/get_started.html


Index: clang/www/get_started.html
===
--- clang/www/get_started.html
+++ clang/www/get_started.html
@@ -137,7 +137,7 @@
   
   Run CMake to generate the Visual Studio solution and project files:
   
-cd ..\..  (back to where you started)
+cd llvm-project
 mkdir build (for building without polluting the source 
dir)
 cd build
 


Index: clang/www/get_started.html
===
--- clang/www/get_started.html
+++ clang/www/get_started.html
@@ -137,7 +137,7 @@
   
   Run CMake to generate the Visual Studio solution and project files:
   
-cd ..\..  (back to where you started)
+cd llvm-project
 mkdir build (for building without polluting the source dir)
 cd build
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D100118: [clang] RFC Support new builtin __arithmetic_fence to control floating point optimization, and new clang option fprotect-parens

2021-04-20 Thread Kevin P. Neal via Phabricator via cfe-commits
kpn added inline comments.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:2844
+  return RValue::get(
+  Builder.CreateArithmeticFence(ArgValue, ConvertType(ArgType)));
+return RValue::get(ArgValue);

Does this say that the fence will be silently dropped if any of the fast math 
flags are disabled? Silently dropping something used for correctness makes me 
nervous. Is there a case where all of these flags are required for correct 
behavior of the fence?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100118

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


[PATCH] D100567: BPF: emit debuginfo for Function of DeclRefExpr if requested

2021-04-20 Thread Yonghong Song via Phabricator via cfe-commits
yonghong-song added a comment.

ping @dblaikie could you take a look of my new investigation?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100567

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


  1   2   >