date:20200424

[PATCH] D77491: [Sema] Fix incompatible builtin redeclarations in non-global scope

2020-04-24 Thread Raul Tambre via Phabricator via cfe-commits

tambre added a reviewer: MaskRay.
tambre added a comment.

Could someone please review this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77491



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

[PATCH] D65543: [Windows] Autolink with basenames and add libdir to libpath

2020-04-24 Thread Hans Wennborg via Phabricator via cfe-commits

hans added a comment.

The docs look great, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65543



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

[PATCH] D77809: [Analyzer] Include typedef statements in CFG build.

2020-04-24 Thread Balázs Kéri via Phabricator via cfe-commits

balazske updated this revision to Diff 259820.
balazske marked an inline comment as done.
balazske added a comment.

- Separating test files, fixing alignof problem.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77809

Files:
  clang/lib/Analysis/CFG.cpp
  clang/test/Analysis/cfg.c
  clang/test/Analysis/cfg.cpp

Index: clang/test/Analysis/cfg.cpp
===
--- clang/test/Analysis/cfg.cpp
+++ clang/test/Analysis/cfg.cpp
@@ -12,42 +12,6 @@
 // off. Feel free to add tests that test only one of the CFG flavors if you're
 // not sure how the other flavor is supposed to work in your case.
 
-// CHECK-LABEL: void checkWrap(int i)
-// CHECK: ENTRY
-// CHECK-NEXT: Succs (1): B1
-// CHECK: [B1]
-// CHECK: Succs (21): B2 B3 B4 B5 B6 B7 B8 B9
-// CHECK: B10 B11 B12 B13 B14 B15 B16 B17 B18 B19
-// CHECK: B20 B21 B0
-// CHECK: [B0 (EXIT)]
-// CHECK-NEXT: Preds (21): B2 B3 B4 B5 B6 B7 B8 B9
-// CHECK-NEXT: B10 B11 B12 B13 B14 B15 B16 B17 B18 B19
-// CHECK-NEXT: B20 B21 B1
-void checkWrap(int i) {
-  switch(i) {
-case 0: break;
-case 1: break;
-case 2: break;
-case 3: break;
-case 4: break;
-case 5: break;
-case 6: break;
-case 7: break;
-case 8: break;
-case 9: break;
-case 10: break;
-case 11: break;
-case 12: break;
-case 13: break;
-case 14: break;
-case 15: break;
-case 16: break;
-case 17: break;
-case 18: break;
-case 19: break;
-  }
-}
-
 // CHECK-LABEL: void checkDeclStmts()
 // CHECK: ENTRY
 // CHECK-NEXT: Succs (1): B1
@@ -84,24 +48,6 @@
   static_assert(1, "abc");
 }
 
-
-// CHECK-LABEL: void checkGCCAsmRValueOutput()
-// CHECK: [B2 (ENTRY)]
-// CHECK-NEXT: Succs (1): B1
-// CHECK: [B1]
-// CHECK-NEXT:   1: int arg
-// CHECK-NEXT:   2: arg
-// CHECK-NEXT:   3: (int)[B1.2] (CStyleCastExpr, NoOp, int)
-// CHECK-NEXT:   4: asm ("" : "=r" ([B1.3]));
-// CHECK-NEXT:   5: arg
-// CHECK-NEXT:   6: asm ("" : "=r" ([B1.5]));
-void checkGCCAsmRValueOutput() {
-  int arg;
-  __asm__("" : "=r"((int)arg));  // rvalue output operand
-  __asm__("" : "=r"(arg));   // lvalue output operand
-}
-
-
 // CHECK-LABEL: void F(EmptyE e)
 // CHECK: ENTRY
 // CHECK-NEXT: Succs (1): B1
@@ -136,7 +82,6 @@
   (void)__builtin_object_size(dummy(), 0);
 }
 
-
 class A {
 public:
   A() {}
@@ -355,7 +300,6 @@
   return x;
 }
 
-
 // CHECK-LABEL: void test_placement_new()
 // CHECK:  [B2 (ENTRY)]
 // CHECK-NEXT:  Succs (1): B1
@@ -547,25 +491,88 @@
 }
 } // namespace statement_expression_in_return
 
-// CHECK-LABEL: int overlap_compare(int x)
-// CHECK: [B2]
-// CHECK-NEXT:   1: 1
-// CHECK-NEXT:   2: return [B2.1];
-// CHECK-NEXT:   Preds (1): B3(Unreachable)
-// CHECK-NEXT:   Succs (1): B0
-// CHECK: [B3]
+// CHECK-LABEL: void vla_simple(int x)
+// CHECK: [B1]
 // CHECK-NEXT:   1: x
-// CHECK-NEXT:   2: [B3.1] (ImplicitCastExpr, LValueToRValue, int)
-// CHECK-NEXT:   3: 5
-// CHECK-NEXT:   4: [B3.2] > [B3.3]
-// CHECK-NEXT:   T: if [B4.5] && [B3.4]
-// CHECK-NEXT:   Preds (1): B4
-// CHECK-NEXT:   Succs (2): B2(Unreachable) B1
-int overlap_compare(int x) {
-  if (x == -1 && x > 5)
-return 1;
-
-  return 2;
+// CHECK-NEXT:   2: [B1.1] (ImplicitCastExpr, LValueToRValue, int)
+// CHECK-NEXT:   3: int vla[x];
+void vla_simple(int x) {
+  int vla[x];
+}
+
+// CHECK-LABEL: void vla_typedef(int x)
+// CHECK: [B1]
+// CHECK-NEXT:   1: x
+// CHECK-NEXT:   2: [B1.1] (ImplicitCastExpr, LValueToRValue, int)
+// CHECK-NEXT:   3: typedef int VLA[x];
+void vla_typedef(int x) {
+  typedef int VLA[x];
+}
+
+// CHECK-LABEL: void vla_typealias(int x)
+// CHECK: [B1]
+// CHECK-NEXT:   1: x
+// CHECK-NEXT:   2: [B1.1] (ImplicitCastExpr, LValueToRValue, int)
+// CHECK-NEXT:   3: using VLA = int [x];
+void vla_typealias(int x) {
+  using VLA = int[x];
+}
+
+// CHECK-LABEL: void vla_typedef_multi(int x, int y)
+// CHECK:  [B1]
+// CHECK-NEXT:   1: y
+// CHECK-NEXT:   2: [B1.1] (ImplicitCastExpr, LValueToRValue, int)
+// CHECK-NEXT:   3: x
+// CHECK-NEXT:   4: [B1.3] (ImplicitCastExpr, LValueToRValue, int)
+// CHECK-NEXT:   5: typedef int VLA[x][y];
+void vla_typedef_multi(int x, int y) {
+  typedef int VLA[x][y];
+}
+
+// CHECK-LABEL: void vla_typedefname_multi(int x, int y)
+// CHECK:  [B1]
+// CHECK-NEXT:   1: x
+// CHECK-NEXT:   2: [B1.1] (ImplicitCastExpr, LValueToRValue, int)
+// CHECK-NEXT:   3: typedef int VLA[x];
+// CHECK-NEXT:   4: y
+// CHECK-NEXT:   5: [B1.4] (ImplicitCastExpr, LValueToRValue, int)
+// CHECK-NEXT:   6: typedef VLA VLA1[y];
+// CHECK-NEXT:   7: 3
+// CHECK-NEXT:   8: using VLA2 = VLA1 [3];
+// CHECK-NEXT:   9: 4
+// CHECK-NEXT:  10: VLA2 vla[4];
+void vla_typedefname_multi(int x, int y) {
+  typedef int VLA[x];
+  typedef VLA VLA1[y];
+  using VLA2 = VLA1[3];
+  VLA2 vla[4];
+}
+
+// CHECK-LABEL: int vla_evaluate(int x)
+// CHECK:  [B1]
+// CHECK-NEXT:   1: x
+// CHECK-NEXT:   2: ++[B1.1]
+// CHECK-NEXT:   3:

[clang] 8f766e3 - Update compiler extension integration into the build system

2020-04-24 Thread via cfe-commits


Author: serge-sans-paille
Date: 2020-04-24T09:40:14+02:00
New Revision: 8f766e382b77eef3102798b49e087d1e4804b984

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

LOG: Update compiler extension integration into the build system

The approach here is to create a new (empty) component, `Extensions', where all
statically compiled extensions dynamically register their dependencies. That way
we're more natively compatible with LLVMBuild and llvm-config.

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

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

Added: 
llvm/lib/Extensions/CMakeLists.txt
llvm/lib/Extensions/Extensions.cpp
llvm/lib/Extensions/LLVMBuild.txt

Modified: 
clang/lib/CodeGen/CMakeLists.txt
llvm/cmake/modules/AddLLVM.cmake
llvm/lib/CMakeLists.txt
llvm/lib/LLVMBuild.txt
llvm/lib/LTO/CMakeLists.txt
llvm/lib/LTO/LLVMBuild.txt
llvm/tools/bugpoint/CMakeLists.txt
llvm/tools/llvm-config/llvm-config.cpp
llvm/tools/opt/CMakeLists.txt

Removed: 




diff  --git a/clang/lib/CodeGen/CMakeLists.txt 
b/clang/lib/CodeGen/CMakeLists.txt
index d8b3c234a1ef..c300c1b021f3 100644
--- a/clang/lib/CodeGen/CMakeLists.txt
+++ b/clang/lib/CodeGen/CMakeLists.txt
@@ -5,6 +5,7 @@ set(LLVM_LINK_COMPONENTS
   Core
   Coroutines
   Coverage
+  Extensions
   FrontendOpenMP
   IPO
   IRReader
@@ -96,8 +97,6 @@ add_clang_library(clangCodeGen
   TargetInfo.cpp
   VarBypassDetector.cpp
 
-  ENABLE_PLUGINS
-
   DEPENDS
   ${codegen_deps}
 

diff  --git a/llvm/cmake/modules/AddLLVM.cmake 
b/llvm/cmake/modules/AddLLVM.cmake
index 7d5094eac00c..ba720d49acb9 100644
--- a/llvm/cmake/modules/AddLLVM.cmake
+++ b/llvm/cmake/modules/AddLLVM.cmake
@@ -409,7 +409,7 @@ endfunction(set_windows_version_resource_properties)
 #   )
 function(llvm_add_library name)
   cmake_parse_arguments(ARG
-
"MODULE;SHARED;STATIC;OBJECT;DISABLE_LLVM_LINK_LLVM_DYLIB;SONAME;NO_INSTALL_RPATH;COMPONENT_LIB;ENABLE_PLUGINS"
+
"MODULE;SHARED;STATIC;OBJECT;DISABLE_LLVM_LINK_LLVM_DYLIB;SONAME;NO_INSTALL_RPATH;COMPONENT_LIB"
 "OUTPUT_NAME;PLUGIN_TOOL;ENTITLEMENTS;BUNDLE_PATH"
 "ADDITIONAL_HEADERS;DEPENDS;LINK_COMPONENTS;LINK_LIBS;OBJLIBS"
 ${ARGN})
@@ -423,9 +423,6 @@ function(llvm_add_library name)
   else()
 llvm_process_sources(ALL_FILES ${ARG_UNPARSED_ARGUMENTS} 
${ARG_ADDITIONAL_HEADERS})
   endif()
-  if(ARG_ENABLE_PLUGINS)
-set_property(GLOBAL APPEND PROPERTY LLVM_PLUGIN_TARGETS ${name})
-  endif()
 
   if(ARG_MODULE)
 if(ARG_SHARED OR ARG_STATIC)
@@ -758,7 +755,7 @@ endmacro(add_llvm_library name)
 
 macro(add_llvm_executable name)
   cmake_parse_arguments(ARG
-
"DISABLE_LLVM_LINK_LLVM_DYLIB;IGNORE_EXTERNALIZE_DEBUGINFO;NO_INSTALL_RPATH;SUPPORT_PLUGINS;ENABLE_PLUGINS"
+
"DISABLE_LLVM_LINK_LLVM_DYLIB;IGNORE_EXTERNALIZE_DEBUGINFO;NO_INSTALL_RPATH;SUPPORT_PLUGINS"
 "ENTITLEMENTS;BUNDLE_PATH"
 "DEPENDS"
 ${ARGN})
@@ -845,9 +842,6 @@ macro(add_llvm_executable name)
 # API for all shared libaries loaded by this executable.
 target_link_libraries(${name} PRIVATE ${LLVM_PTHREAD_LIB})
   endif()
-  if(ARG_ENABLE_PLUGINS)
-set_property(GLOBAL APPEND PROPERTY LLVM_PLUGIN_TARGETS ${name})
-  endif()
 
   llvm_codesign(${name} ENTITLEMENTS ${ARG_ENTITLEMENTS} BUNDLE_PATH 
${ARG_BUNDLE_PATH})
 endmacro(add_llvm_executable name)
@@ -920,18 +914,18 @@ function(process_llvm_pass_plugins)
   include(LLVMConfigExtensions)
   endif()
 
-  # Add static plugins to each plugin target.
+  # Add static plugins to the Extension component
   foreach(llvm_extension ${LLVM_STATIC_EXTENSIONS})
-get_property(llvm_plugin_targets GLOBAL PROPERTY LLVM_PLUGIN_TARGETS)
-foreach(llvm_plugin_target ${llvm_plugin_targets})
-  set_property(TARGET ${llvm_plugin_target} APPEND PROPERTY LINK_LIBRARIES 
${llvm_extension})
-  set_property(TARGET ${llvm_plugin_target} APPEND PROPERTY 
INTERFACE_LINK_LIBRARIES ${llvm_extension})
-endforeach()
+  set_property(TARGET LLVMExtensions APPEND PROPERTY LINK_LIBRARIES 
${llvm_extension})
+  set_property(TARGET LLVMExtensions APPEND PROPERTY 
INTERFACE_LINK_LIBRARIES ${llvm_extension})
   endforeach()
 
-  # Eventually generate the extension header, and store config to a cmake file
+  # Eventually generate the extension headers, and store config to a cmake file
   # for usage in third-party configuration.
   if(ARG_GEN_CONFIG)
+
+  ## Part 1: Extension header to be included whenever we need extension
+  #  processing.
   set(LLVM_INSTALL_PACKAGE_DIR lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm)
   set(llvm_cmake_builddir "${LLVM_BINARY_DIR}/${LLVM_INSTALL_PACKAGE_DIR}")
   file(WRITE
@@ -954,6 +948,57 @@ function(process_llvm_pass_plugins)
   "${ExtensionDef}.tmp"
   "${E

[PATCH] D78192: Support compiler extensions as a normal component

2020-04-24 Thread serge via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG8f766e382b77: Update compiler extension integration into the 
build system (authored by serge-sans-paille).

Changed prior to commit:
  https://reviews.llvm.org/D78192?vs=259495&id=259827#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78192

Files:
  clang/lib/CodeGen/CMakeLists.txt
  llvm/cmake/modules/AddLLVM.cmake
  llvm/lib/CMakeLists.txt
  llvm/lib/Extensions/CMakeLists.txt
  llvm/lib/Extensions/Extensions.cpp
  llvm/lib/Extensions/LLVMBuild.txt
  llvm/lib/LLVMBuild.txt
  llvm/lib/LTO/CMakeLists.txt
  llvm/lib/LTO/LLVMBuild.txt
  llvm/tools/bugpoint/CMakeLists.txt
  llvm/tools/llvm-config/llvm-config.cpp
  llvm/tools/opt/CMakeLists.txt

Index: llvm/tools/opt/CMakeLists.txt
===
--- llvm/tools/opt/CMakeLists.txt
+++ llvm/tools/opt/CMakeLists.txt
@@ -9,6 +9,7 @@
   CodeGen
   Core
   Coroutines
+  Extensions
   IPO
   IRReader
   InstCombine
@@ -33,8 +34,6 @@
   PrintSCC.cpp
   opt.cpp
 
-  ENABLE_PLUGINS
-
   DEPENDS
   intrinsics_gen
   SUPPORT_PLUGINS
Index: llvm/tools/llvm-config/llvm-config.cpp
===
--- llvm/tools/llvm-config/llvm-config.cpp
+++ llvm/tools/llvm-config/llvm-config.cpp
@@ -46,6 +46,10 @@
 // create entries for pseudo groups like x86 or all-targets.
 #include "LibraryDependencies.inc"
 
+// Built-in extensions also register their dependencies, but in a separate file,
+// later in the process.
+#include "ExtensionDependencies.inc"
+
 // LinkMode determines what libraries and flags are returned by llvm-config.
 enum LinkMode {
   // LinkModeAuto will link with the default link mode for the installation,
@@ -110,6 +114,25 @@
GetComponentLibraryPath, Missing, DirSep);
   }
 
+  // Special handling for the special 'extensions' component. Its content is
+  // not populated by llvm-build, but later in the process and loaded from
+  // ExtensionDependencies.inc.
+  if (Name == "extensions") {
+for (auto const &AvailableExtension : AvailableExtensions) {
+  for (const char *const *Iter = &AvailableExtension.RequiredLibraries[0];
+   *Iter; ++Iter) {
+AvailableComponent *AC = ComponentMap.lookup(*Iter);
+if (!AC) {
+  RequiredLibs.push_back(*Iter);
+} else {
+  VisitComponent(*Iter, ComponentMap, VisitedComponents, RequiredLibs,
+ IncludeNonInstalled, GetComponentNames,
+ GetComponentLibraryPath, Missing, DirSep);
+}
+  }
+}
+  }
+
   if (GetComponentNames) {
 RequiredLibs.push_back(Name);
 return;
Index: llvm/tools/bugpoint/CMakeLists.txt
===
--- llvm/tools/bugpoint/CMakeLists.txt
+++ llvm/tools/bugpoint/CMakeLists.txt
@@ -6,6 +6,7 @@
   Analysis
   BitWriter
   CodeGen
+  Extensions
   Core
   IPO
   IRReader
@@ -32,8 +33,6 @@
   ToolRunner.cpp
   bugpoint.cpp
 
-  ENABLE_PLUGINS
-
   DEPENDS
   intrinsics_gen
   SUPPORT_PLUGINS
Index: llvm/lib/LTO/CMakeLists.txt
===
--- llvm/lib/LTO/CMakeLists.txt
+++ llvm/lib/LTO/CMakeLists.txt
@@ -10,9 +10,6 @@
 
   ADDITIONAL_HEADER_DIRS
   ${LLVM_MAIN_INCLUDE_DIR}/llvm/LTO
-
-  ENABLE_PLUGINS
-
   DEPENDS
   intrinsics_gen
   llvm_vcsrevision_h
Index: llvm/lib/LLVMBuild.txt
===
--- llvm/lib/LLVMBuild.txt
+++ llvm/lib/LLVMBuild.txt
@@ -25,6 +25,7 @@
  Demangle
  DWARFLinker
  ExecutionEngine
+ Extensions
  Frontend
  FuzzMutate
  LineEditor
Index: llvm/lib/LTO/LLVMBuild.txt
===
--- llvm/lib/LTO/LLVMBuild.txt
+++ llvm/lib/LTO/LLVMBuild.txt
@@ -26,6 +26,7 @@
  BitWriter
  CodeGen
  Core
+ Extensions
  IPO
  InstCombine
  Linker
Index: llvm/lib/Extensions/LLVMBuild.txt
===
--- llvm/lib/Extensions/LLVMBuild.txt
+++ llvm/lib/Extensions/LLVMBuild.txt
@@ -1,4 +1,4 @@
-;===- ./lib/LTO/LLVMBuild.txt --*- Conf -*--===;
+;===- ./lib/Extensions/LLVMBuild.txt ---*- Conf -*--===;
 ;
 ; Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 ; See https://llvm.org/LICENSE.txt for license information.
@@ -16,25 +16,6 @@
 
 [component_0]
 type = Library
-name = LTO
+name = Extensions
 parent = Libraries
 required_libraries =
- AggressiveInstCombine
- Analysis
- BinaryFormat
- BitReader
- BitWriter
- CodeGen
- Core
- IPO
- InstCombine
- Linker
- MC
- ObjCARC
- Object
- Passes
- Remarks
- Scalar
- Support
- Target
- TransformUtils
Index: llvm/lib/Extensions/CMakeLists.txt

[PATCH] D70416: [Driver] Make -static-libgcc imply static libunwind

2020-04-24 Thread Idar Tollefsen via Phabricator via cfe-commits

itollefsen added a comment.

I only build libunwind as a static library because it's (so far) the approach 
that gets me the furthest in avoiding all of the trouble that comes from having 
multiple libunwind (on Linux). I'm also running with the patch from D26244 
 (now abandoned unfortunately).

This approach works quite well. It doesn't solve everything tough.

I can use the (default) static version of the sanitizer runtimes as long as the 
project being built doesn't itself use another libuwnind. If it does, I can use 
the shared sanitizer runtimes since they are linked against the static LLVM 
libunwind and therefore self-contained. Obviously, this only works for 
sanitiziers that //have// shared runtimes. Those that don't can't be used in 
this case. Well, as far as I've been able to work out at least.

I planned on experimenting with merging libunwind into the shared version of 
libc++abi (i.e. the whole libunwind archive) to see if that could solve it, but 
haven't gotten around to testing it yet.

Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:1215
+else
+  CmdArgs.push_back("-l:libunwind.so");
 break;

saugustine wrote:
> itollefsen wrote:
> > If you are building with `-DLIBUNWIND_ENABLE_SHARED:OFF 
> > -DLIBUNWIND_ENABLE_STATIC:ON`, there's no shared version available. And 
> > vice versa. This doesn't account for that.
> Although true, I don't believe this is any different from the parallel libgcc 
> situation. libgcc_eh is the static version, and will never be satisfied by 
> the dynamic version. libgcc_s is the dynamic version, and can never satisfy 
> the static version. See lines 1204-1208 above.
> 
> The case where you ask for a static compiler-rt but still want a dynamic 
> unwind library is new. I'm not opposed to supporting it, but "what gcc does" 
> isn't a terrible standard.
I haven't really requested anything specific one way or the other (I think).

I'm guessing `getLibGccType()` returns `LibGccType::SharedLibGcc` because 
`CCCIsCXX()` returns true.

Even if it returned `LibGccType::UnspecifiedLibGcc`, the shared version would 
still be used though.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70416

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

[PATCH] D73845: [Gnu toolchain] Move GCC multilib/multiarch paths support from Linux to Gnu

2020-04-24 Thread Samuel Thibault via Phabricator via cfe-commits

sthibaul added a comment.

@MaskRay  : Samuel Thibault 


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

https://reviews.llvm.org/D73845



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

[PATCH] D77621: Change BitcodeWriter buffer to std::vector instead of SmallVector.

2020-04-24 Thread Nikita Popov via Phabricator via cfe-commits

nikic added a comment.

In D77621#2000237 , @nikic wrote:

> > Perhaps you could move the value computation into a constexpr variable & 
> > just return that as needed. (could be a static local constexpr, I guess - 
> > to avoid the issues around linkage of constexpr member variables)
>
> The use of a function rather than a static constexpr for SizeTypeMax() was my 
> first thought as well. It seems pretty weird to me, but maybe it's enough to 
> fall one the wrong side of some inlining heuristic.
>
> The only other thing that comes to mind is that grow_pod() moved into the 
> header, which might have negative effects. It should be possible to avoid 
> that by providing explicit template instantiations for uint32_t and uintptr_t 
> in the cpp file.
>
> I'll try to figure out what the cause is, but might take me a few days.

I've tried those two things: results 
.
 From the bottom, the first commit is a rebased version of the original change, 
the second one makes `SizeTypeMax` a constant instead of a function and the 
last one moves `grow_pod` back into the C++ file (I forgot to replace the 
UINT32_MAX references in grow_pod, but I don't think it has an impact on the 
conclusion). The first change is a `+0.75%` regression, the second is neutral 
and the last one is a `-0.70%` improvement, the remaining difference is likely 
noise. So it looks like the move of `grow_pod` into the header was the culprit.

What is rather peculiar is that the picture is similar for the max-rss numbers 
.
 I believe this is because max-rss is also influenced by the size of the clang 
binary itself, and apparently the move of grow_pod into the header increased it 
a lot. (I should probably collect clang binary size to make this easy to 
verify.) That means that there doesn't seem to be much of an increase in terms 
of actually allocated heap memory due to this change.

Taking the max-rss numbers 

 across all three commits, the only part where memory usage increases 
non-trivially is the LTO `-g` link step, by about ~1%. Possibly some debuginfo 
related stuff uses `SmallVector`.

So tl;dr looks like as long as we keep `grow_pod` outside the header file, this 
change seems to be approximately free in terms of compile-time and memory usage 
both.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77621

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

[PATCH] D78642: [clang-format] Handle C# property accessors when parsing lines

2020-04-24 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay added inline comments.



Comment at: clang/lib/Format/UnwrappedLineParser.cpp:1344
   addUnwrappedLine();
 FormatTok->Type = TT_FunctionLBrace;
 parseBlock(/*MustBeDeclaration=*/false);

jbcoe wrote:
> MyDeveloperDay wrote:
> > previously set and get would break based on the setting of AfterFunction 
> > correct? now I assume it doesn't?
> That's right. There's a bunch more work needed here and current/previous 
> behaviour is undertested and incorrect. 
> 
> I'm focusing on this for the next few days so should get everything working 
> well and configurable as we'd like.
> 
> MS examples are not very consistent so choice seems like the way forward: 
> https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/classes#properties
Sounds good



Comment at: clang/unittests/Format/FormatTestCSharp.cpp:249
+   "public string Host { set; get; }");
 
   verifyFormat("[TestMethod(\"start\", HelpText = \"Starts the server "

jbcoe wrote:
> MyDeveloperDay wrote:
> > is this just a personal choice? or based on some rule that it shouldn't 
> > break?
> > 
> > I don't like us changing tests unless we understand otherwise we just keep 
> > flip-flopping the style?
> Agreed. This was oversight and merits discussion. I'll make this configurable 
> in a follow-up patch.
> 
> Thanks for taking the time to review/comment.
I the original C# work I mentioned we'd want to add specific styling for things 
like this, I feel this is going the the right direction thank you.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78642



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

[PATCH] D78715: [clangd] Fix modernize-loop-convert "multiple diag in flight" crash.

2020-04-24 Thread Haojian Wu via Phabricator via cfe-commits

hokein added a comment.

In D78715#1999236 , @sammccall wrote:

> Ah, nice work!
>  Agree it's a hack (and how many more instances are lurking) but I don't know 
> how better to fix it and it's been reported 3 times...


this is the only place in clang-tidy calling `getTypeInfo`.




Comment at: clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp:529
+  // getTypeInfo may emit a diagnostic, we have to call it before constructing
+  // the Diag to avoid the "multiple-diagnostic in flight" crash in clangd.
+  auto TypeWidth = Context->getTypeInfo(Descriptor.ElemType).Width;

sammccall wrote:
> I'm not sure we need to mention clangd here - I'd expect standalone 
> clang-tidy to be able to hit the same condition?
> At least logically I think the bug exists either way.
yeah logically, but it doesn't trigger the assertion somehow (haven't dig into 
it). removed it.

 I realized that the code below may change `Descriptor.ElemType`, refined the 
fix (we store the fixits, and emit the diagnostic at the end of the function).



Comment at: clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp:275
 
+TEST(DiagnosticTest, NoMultipleDiagnosticInFlight) {
+  Annotations Main(R"cpp(

sammccall wrote:
> Does the bug repro with clang-tidy? If so it'd be nice to make this a 
> clang-tidy test.
unfortunately, not for standalone clang-tidy :(


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78715



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

[PATCH] D78715: [clangd] Fix modernize-loop-convert "multiple diag in flight" crash.

2020-04-24 Thread Haojian Wu via Phabricator via cfe-commits

hokein updated this revision to Diff 259832.
hokein marked 3 inline comments as done.
hokein added a comment.

refine the fix.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78715

Files:
  clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
  clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp


Index: clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
===
--- clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
+++ clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
@@ -272,6 +272,33 @@
   "use a trailing return type for this function");
 }
 
+TEST(DiagnosticTest, NoMultipleDiagnosticInFlight) {
+  Annotations Main(R"cpp(
+template  struct Foo {
+  T *begin();
+  T *end();
+};
+struct LabelInfo {
+  int a;
+  bool b;
+};
+
+void f() {
+  Foo label_info_map;
+  [[for]] (auto it = label_info_map.begin(); it != label_info_map.end(); 
++it) {
+auto S = *it;
+  }
+}
+  )cpp");
+  TestTU TU = TestTU::withCode(Main.code());
+  TU.ClangTidyChecks = "modernize-loop-convert";
+  EXPECT_THAT(
+  TU.build().getDiagnostics(),
+  UnorderedElementsAre(::testing::AllOf(
+  Diag(Main.range(), "use range-based for loop instead"),
+  DiagSource(Diag::ClangTidy), DiagName("modernize-loop-convert";
+}
+
 TEST(DiagnosticTest, ClangTidySuppressionComment) {
   Annotations Main(R"cpp(
 int main() {
Index: clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
===
--- clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
+++ clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
@@ -525,13 +525,11 @@
 const ValueDecl *MaybeContainer, const UsageResult &Usages,
 const DeclStmt *AliasDecl, bool AliasUseRequired, bool AliasFromForInit,
 const ForStmt *Loop, RangeDescriptor Descriptor) {
-  auto Diag = diag(Loop->getForLoc(), "use range-based for loop instead");
-
   std::string VarName;
   bool VarNameFromAlias = (Usages.size() == 1) && AliasDecl;
   bool AliasVarIsRef = false;
   bool CanCopy = true;
-
+  std::vector FixIts;
   if (VarNameFromAlias) {
 const auto *AliasVar = cast(AliasDecl->getSingleDecl());
 VarName = AliasVar->getName().str();
@@ -563,8 +561,8 @@
   getAliasRange(Context->getSourceManager(), ReplaceRange);
 }
 
-Diag << FixItHint::CreateReplacement(
-CharSourceRange::getTokenRange(ReplaceRange), ReplacementText);
+FixIts.push_back(FixItHint::CreateReplacement(
+CharSourceRange::getTokenRange(ReplaceRange), ReplacementText));
 // No further replacements are made to the loop, since the iterator or 
index
 // was used exactly once - in the initialization of AliasVar.
   } else {
@@ -609,8 +607,8 @@
 Usage.Kind == Usage::UK_CaptureByCopy ? "&" + VarName : VarName;
   }
   TUInfo->getReplacedVars().insert(std::make_pair(Loop, IndexVar));
-  Diag << FixItHint::CreateReplacement(
-  CharSourceRange::getTokenRange(Range), ReplaceText);
+  FixIts.push_back(FixItHint::CreateReplacement(
+  CharSourceRange::getTokenRange(Range), ReplaceText));
 }
   }
 
@@ -648,8 +646,9 @@
   std::string Range = ("(" + TypeString + " " + VarName + " : " +
MaybeDereference + Descriptor.ContainerString + ")")
   .str();
-  Diag << FixItHint::CreateReplacement(
-  CharSourceRange::getTokenRange(ParenRange), Range);
+  FixIts.push_back(FixItHint::CreateReplacement(
+  CharSourceRange::getTokenRange(ParenRange), Range));
+  diag(Loop->getForLoc(), "use range-based for loop instead") << FixIts;
   TUInfo->getGeneratedDecls().insert(make_pair(Loop, VarName));
 }
 


Index: clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
===
--- clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
+++ clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
@@ -272,6 +272,33 @@
   "use a trailing return type for this function");
 }
 
+TEST(DiagnosticTest, NoMultipleDiagnosticInFlight) {
+  Annotations Main(R"cpp(
+template  struct Foo {
+  T *begin();
+  T *end();
+};
+struct LabelInfo {
+  int a;
+  bool b;
+};
+
+void f() {
+  Foo label_info_map;
+  [[for]] (auto it = label_info_map.begin(); it != label_info_map.end(); ++it) {
+auto S = *it;
+  }
+}
+  )cpp");
+  TestTU TU = TestTU::withCode(Main.code());
+  TU.ClangTidyChecks = "modernize-loop-convert";
+  EXPECT_THAT(
+  TU.build().getDiagnostics(),
+  UnorderedElementsAre(::testing::AllOf(
+  Diag(Main.range(), "use range-based for loop instead"),
+  DiagSource(Diag::ClangTidy), DiagName("modernize-loop-convert")))

Re: [PATCH] D78192: Support compiler extensions as a normal component

2020-04-24 Thread Russell Gallop via cfe-commits

Hi Serge,

It looks like this is failing to build on Windows bots (e.g.
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/32003).
Error below.

Please could you take a look?

Thanks
Russ

FAILED: tools/llvm-config/CMakeFiles/llvm-config.dir/llvm-config.cpp.obj
C:\PROGRA~2\MIB055~1\2019\COMMUN~1\VC\Tools\MSVC\1425~1.286\bin\Hostx64\x64\cl.exe
/nologo /TP -DBUILD_EXAMPLES -DCMAKE_CFG_INTDIR=\".\" -DGTEST_HAS_RTTI=0
-DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS
-D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_HAS_EXCEPTIONS=0
-D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-Itools\llvm-config
-IC:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm-project\llvm\tools\llvm-config
-Iinclude
-IC:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm-project\llvm\include
/DWIN32 /D_WINDOWS /Zc:inline /Zc:strictStrings /Oi /Zc:rvalueCast /W4
-wd4141 -wd4146 -wd4244 -wd4267 -wd4291 -wd4351 -wd4456 -wd4457 -wd4458
-wd4459 -wd4503 -wd4624 -wd4722 -wd4100 -wd4127 -wd4512 -wd4505 -wd4610
-wd4510 -wd4702 -wd4245 -wd4706 -wd4310 -wd4701 -wd4703 -wd4389 -wd4611
-wd4805 -wd4204 -wd4577 -wd4091 -wd4592 -wd4319 -wd4709 -wd4324 -w14062
-we4238 /Gw /MD /O2 /Ob2 /EHs-c- /GR- -UNDEBUG -std:c++14 /showIncludes
/Fotools\llvm-config\CMakeFiles\llvm-config.dir\llvm-config.cpp.obj
/Fdtools\llvm-config\CMakeFiles\llvm-config.dir\ /FS -c
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm-project\llvm\tools\llvm-config\llvm-config.cpp
tools\llvm-config\ExtensionDependencies.inc(6): error C2280:
'ExtensionDescriptor::ExtensionDescriptor(void)': attempting to reference a
deleted function tools\llvm-config\ExtensionDependencies.inc(5): note:
compiler has generated 'ExtensionDescriptor::ExtensionDescriptor' here
tools\llvm-config\ExtensionDependencies.inc(5): note:
'ExtensionDescriptor::ExtensionDescriptor(void)': function was implicitly
deleted because 'ExtensionDescriptor' has an uninitialized const-qualified
data member 'ExtensionDescriptor::RequiredLibraries'
tools\llvm-config\ExtensionDependencies.inc(4): note: see declaration of
'ExtensionDescriptor::RequiredLibraries'

On Fri, 24 Apr 2020 at 09:02, serge via Phabricator via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> This revision was automatically updated to reflect the committed changes.
> Closed by commit rG8f766e382b77: Update compiler extension integration
> into the build system (authored by serge-sans-paille).
>
> Changed prior to commit:
>   https://reviews.llvm.org/D78192?vs=259495&id=259827#toc
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D78192/new/
>
> https://reviews.llvm.org/D78192
>
> Files:
>   clang/lib/CodeGen/CMakeLists.txt
>   llvm/cmake/modules/AddLLVM.cmake
>   llvm/lib/CMakeLists.txt
>   llvm/lib/Extensions/CMakeLists.txt
>   llvm/lib/Extensions/Extensions.cpp
>   llvm/lib/Extensions/LLVMBuild.txt
>   llvm/lib/LLVMBuild.txt
>   llvm/lib/LTO/CMakeLists.txt
>   llvm/lib/LTO/LLVMBuild.txt
>   llvm/tools/bugpoint/CMakeLists.txt
>   llvm/tools/llvm-config/llvm-config.cpp
>   llvm/tools/opt/CMakeLists.txt
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] a466e4b - [clangd] Fix modernize-loop-convert "multiple diag in flight" crash.

2020-04-24 Thread Haojian Wu via cfe-commits


Author: Haojian Wu
Date: 2020-04-24T11:16:36+02:00
New Revision: a466e4be3831848d7ff6ffbe4f57d99de8fb66af

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

LOG: [clangd] Fix modernize-loop-convert "multiple diag in flight" crash.

Summary:
this maybe not ideal, but it is trivial and does fix the crash.

Fixes https://github.com/clangd/clangd/issues/156.

Reviewers: sammccall

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxena95, 
cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp 
b/clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
index ee6234704ff5..011da5e8840d 100644
--- a/clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
+++ b/clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
@@ -525,13 +525,11 @@ void LoopConvertCheck::doConversion(
 const ValueDecl *MaybeContainer, const UsageResult &Usages,
 const DeclStmt *AliasDecl, bool AliasUseRequired, bool AliasFromForInit,
 const ForStmt *Loop, RangeDescriptor Descriptor) {
-  auto Diag = diag(Loop->getForLoc(), "use range-based for loop instead");
-
   std::string VarName;
   bool VarNameFromAlias = (Usages.size() == 1) && AliasDecl;
   bool AliasVarIsRef = false;
   bool CanCopy = true;
-
+  std::vector FixIts;
   if (VarNameFromAlias) {
 const auto *AliasVar = cast(AliasDecl->getSingleDecl());
 VarName = AliasVar->getName().str();
@@ -563,8 +561,8 @@ void LoopConvertCheck::doConversion(
   getAliasRange(Context->getSourceManager(), ReplaceRange);
 }
 
-Diag << FixItHint::CreateReplacement(
-CharSourceRange::getTokenRange(ReplaceRange), ReplacementText);
+FixIts.push_back(FixItHint::CreateReplacement(
+CharSourceRange::getTokenRange(ReplaceRange), ReplacementText));
 // No further replacements are made to the loop, since the iterator or 
index
 // was used exactly once - in the initialization of AliasVar.
   } else {
@@ -609,8 +607,8 @@ void LoopConvertCheck::doConversion(
 Usage.Kind == Usage::UK_CaptureByCopy ? "&" + VarName : VarName;
   }
   TUInfo->getReplacedVars().insert(std::make_pair(Loop, IndexVar));
-  Diag << FixItHint::CreateReplacement(
-  CharSourceRange::getTokenRange(Range), ReplaceText);
+  FixIts.push_back(FixItHint::CreateReplacement(
+  CharSourceRange::getTokenRange(Range), ReplaceText));
 }
   }
 
@@ -648,8 +646,9 @@ void LoopConvertCheck::doConversion(
   std::string Range = ("(" + TypeString + " " + VarName + " : " +
MaybeDereference + Descriptor.ContainerString + ")")
   .str();
-  Diag << FixItHint::CreateReplacement(
-  CharSourceRange::getTokenRange(ParenRange), Range);
+  FixIts.push_back(FixItHint::CreateReplacement(
+  CharSourceRange::getTokenRange(ParenRange), Range));
+  diag(Loop->getForLoc(), "use range-based for loop instead") << FixIts;
   TUInfo->getGeneratedDecls().insert(make_pair(Loop, VarName));
 }
 

diff  --git a/clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp 
b/clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
index 026e145ed65d..7f4cff147535 100644
--- a/clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
+++ b/clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
@@ -272,6 +272,33 @@ TEST(DiagnosticsTest, ClangTidy) {
   "use a trailing return type for this function");
 }
 
+TEST(DiagnosticTest, NoMultipleDiagnosticInFlight) {
+  Annotations Main(R"cpp(
+template  struct Foo {
+  T *begin();
+  T *end();
+};
+struct LabelInfo {
+  int a;
+  bool b;
+};
+
+void f() {
+  Foo label_info_map;
+  [[for]] (auto it = label_info_map.begin(); it != label_info_map.end(); 
++it) {
+auto S = *it;
+  }
+}
+  )cpp");
+  TestTU TU = TestTU::withCode(Main.code());
+  TU.ClangTidyChecks = "modernize-loop-convert";
+  EXPECT_THAT(
+  TU.build().getDiagnostics(),
+  UnorderedElementsAre(::testing::AllOf(
+  Diag(Main.range(), "use range-based for loop instead"),
+  DiagSource(Diag::ClangTidy), DiagName("modernize-loop-convert";
+}
+
 TEST(DiagnosticTest, ClangTidySuppressionComment) {
   Annotations Main(R"cpp(
 int main() {



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

[PATCH] D77809: [Analyzer] Include typedef statements in CFG build.

2020-04-24 Thread Balázs Kéri via Phabricator via cfe-commits

balazske added inline comments.



Comment at: clang/lib/Analysis/CFG.cpp:2855
+ VA = FindVA(VA->getElementType().getTypePtr())) {
+  if (CFGBlock *newBlock = addStmt(VA->getSizeExpr()))
+LastBlock = newBlock;

aaron.ballman wrote:
> newBlock -> NewBlock per coding standard.
Another thing is to follow the style of the source code. In the same function 
`newBlock` is used at other places, it would look even worse (or not?) to 
change just that single new occurrence to `NewBlock`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77809



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

[PATCH] D78521: [clangd] Extend dexp to support remote index

2020-04-24 Thread Kirill Bobyrev via Phabricator via cfe-commits

kbobyrev updated this revision to Diff 259836.
kbobyrev marked 6 inline comments as done.
kbobyrev added a comment.

Resolve the last comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78521

Files:
  clang-tools-extra/clangd/CMakeLists.txt
  clang-tools-extra/clangd/Features.inc.in
  clang-tools-extra/clangd/index/Serialization.h
  clang-tools-extra/clangd/index/YAMLSerialization.cpp
  clang-tools-extra/clangd/index/dex/dexp/CMakeLists.txt
  clang-tools-extra/clangd/index/dex/dexp/Dexp.cpp
  clang-tools-extra/clangd/index/remote/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/Client.cpp
  clang-tools-extra/clangd/index/remote/Client.h
  clang-tools-extra/clangd/index/remote/Index.proto
  clang-tools-extra/clangd/index/remote/client/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/client/Client.cpp
  clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/marshalling/Marshalling.cpp
  clang-tools-extra/clangd/index/remote/marshalling/Marshalling.h
  clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/server/Server.cpp
  clang-tools-extra/clangd/index/remote/unimplemented/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/unimplemented/Client.cpp

Index: clang-tools-extra/clangd/index/remote/unimplemented/Client.cpp
===
--- /dev/null
+++ clang-tools-extra/clangd/index/remote/unimplemented/Client.cpp
@@ -0,0 +1,26 @@
+//===--- Client.cpp --*- 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
+//
+//===--===//
+
+#include "index/remote/Client.h"
+#include "Logger.h"
+
+namespace clang {
+namespace clangd {
+namespace remote {
+
+std::unique_ptr getClient(llvm::StringRef Address) {
+  const auto *Message =
+  "Can't create SymbolIndex client without Remote Index support.";
+  llvm_unreachable(Message);
+  elog(Message);
+  return nullptr;
+}
+
+} // namespace remote
+} // namespace clangd
+} // namespace clang
Index: clang-tools-extra/clangd/index/remote/unimplemented/CMakeLists.txt
===
--- /dev/null
+++ clang-tools-extra/clangd/index/remote/unimplemented/CMakeLists.txt
@@ -0,0 +1,7 @@
+include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../../../)
+add_clang_library(clangdRemoteIndex
+  Client.cpp
+
+  LINK_LIBS
+  clangDaemon
+  )
Index: clang-tools-extra/clangd/index/remote/server/Server.cpp
===
--- clang-tools-extra/clangd/index/remote/server/Server.cpp
+++ clang-tools-extra/clangd/index/remote/server/Server.cpp
@@ -8,6 +8,7 @@
 
 #include "index/Index.h"
 #include "index/Serialization.h"
+#include "index/remote/marshalling/Marshalling.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/LineEditor/LineEditor.h"
@@ -16,13 +17,14 @@
 #include "llvm/Support/Path.h"
 #include "llvm/Support/Signals.h"
 
-#include "grpcpp/grpcpp.h"
-#include "grpcpp/health_check_service_interface.h"
+#include 
+#include 
 
 #include "Index.grpc.pb.h"
 
 namespace clang {
 namespace clangd {
+namespace remote {
 namespace {
 
 static const std::string Overview = R"(
@@ -33,42 +35,81 @@
 llvm::cl::opt IndexPath(llvm::cl::desc(""),
  llvm::cl::Positional, llvm::cl::Required);
 
-llvm::cl::opt ServerAddress("server-address",
- llvm::cl::init("0.0.0.0:50051"));
+llvm::cl::opt ServerAddress(
+"server-address", llvm::cl::init("0.0.0.0:50051"),
+llvm::cl::desc("Address of the invoked server. Defaults to 0.0.0.0:50051"));
 
-std::unique_ptr openIndex(llvm::StringRef Index) {
+std::unique_ptr openIndex(llvm::StringRef Index) {
   return loadIndex(Index, /*UseIndex=*/true);
 }
 
-class RemoteIndexServer final : public remote::Index::Service {
+class RemoteIndexServer final : public SymbolIndex::Service {
 public:
-  RemoteIndexServer(std::unique_ptr Index)
+  RemoteIndexServer(std::unique_ptr Index)
   : Index(std::move(Index)) {}
 
 private:
   grpc::Status Lookup(grpc::ServerContext *Context,
-  const remote::LookupRequest *Request,
-  grpc::ServerWriter *Reply) override {
-llvm::outs() << "Lookup of symbol with ID " << Request->id() << '\n';
-LookupRequest Req;
-auto SID = SymbolID::fromStr(Request->id());
-if (!SID) {
-  llvm::outs() << llvm::toString(SID.takeError()) << "\n";
-  return grpc::Status::CANCELLED;
+  const LookupRequest *Request,
+  gr

[PATCH] D78477: [profile] Don't crash when forking in several threads

2020-04-24 Thread serge via Phabricator via cfe-commits

serge-sans-paille added inline comments.



Comment at: llvm/lib/Transforms/Instrumentation/GCOVProfiling.cpp:697
+Builder.CreateCall(WriteoutF);
+if (NextInst != Parent->end()) {
+  DebugLoc Loc = E->getDebugLoc();

I'm puzzled by this test. ``F`` is a CallInst, so not a terminator, so how can 
`NextInst` be past the Terminator?



Comment at: llvm/lib/Transforms/Instrumentation/GCOVProfiling.cpp:1263
+  Type *RetTy = ResetF->getReturnType();
+  if (RetTy == Type::getVoidTy(*Ctx))
+Builder.CreateRetVoid();

[nit] could be  `if (RetTy->isVoidTy())`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78477



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

[PATCH] D75068: libclang: Add static build support for Windows

2020-04-24 Thread Cristian Adam via Phabricator via cfe-commits

cristian.adam marked an inline comment as done.
cristian.adam added a comment.

@mstorsjo can you merge (again) this on my behalf? Thank you in advance!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75068



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

[PATCH] D78457: [analyzer][Z3-refutation] Fix refutation BugReporterVisitor bug and refactor

2020-04-24 Thread Whisperity via Phabricator via cfe-commits

whisperity added a comment.

@steakhal You might want to update the patch summary before committing this to 
the upstream (it still mentions "not needing a visitor" 😄)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78457



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

[PATCH] D78715: [clangd] Fix modernize-loop-convert "multiple diag in flight" crash.

2020-04-24 Thread Haojian Wu via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGa466e4be3831: [clangd] Fix modernize-loop-convert 
"multiple diag in flight" crash. (authored by hokein).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78715

Files:
  clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
  clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp


Index: clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
===
--- clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
+++ clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
@@ -272,6 +272,33 @@
   "use a trailing return type for this function");
 }
 
+TEST(DiagnosticTest, NoMultipleDiagnosticInFlight) {
+  Annotations Main(R"cpp(
+template  struct Foo {
+  T *begin();
+  T *end();
+};
+struct LabelInfo {
+  int a;
+  bool b;
+};
+
+void f() {
+  Foo label_info_map;
+  [[for]] (auto it = label_info_map.begin(); it != label_info_map.end(); 
++it) {
+auto S = *it;
+  }
+}
+  )cpp");
+  TestTU TU = TestTU::withCode(Main.code());
+  TU.ClangTidyChecks = "modernize-loop-convert";
+  EXPECT_THAT(
+  TU.build().getDiagnostics(),
+  UnorderedElementsAre(::testing::AllOf(
+  Diag(Main.range(), "use range-based for loop instead"),
+  DiagSource(Diag::ClangTidy), DiagName("modernize-loop-convert";
+}
+
 TEST(DiagnosticTest, ClangTidySuppressionComment) {
   Annotations Main(R"cpp(
 int main() {
Index: clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
===
--- clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
+++ clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
@@ -525,13 +525,11 @@
 const ValueDecl *MaybeContainer, const UsageResult &Usages,
 const DeclStmt *AliasDecl, bool AliasUseRequired, bool AliasFromForInit,
 const ForStmt *Loop, RangeDescriptor Descriptor) {
-  auto Diag = diag(Loop->getForLoc(), "use range-based for loop instead");
-
   std::string VarName;
   bool VarNameFromAlias = (Usages.size() == 1) && AliasDecl;
   bool AliasVarIsRef = false;
   bool CanCopy = true;
-
+  std::vector FixIts;
   if (VarNameFromAlias) {
 const auto *AliasVar = cast(AliasDecl->getSingleDecl());
 VarName = AliasVar->getName().str();
@@ -563,8 +561,8 @@
   getAliasRange(Context->getSourceManager(), ReplaceRange);
 }
 
-Diag << FixItHint::CreateReplacement(
-CharSourceRange::getTokenRange(ReplaceRange), ReplacementText);
+FixIts.push_back(FixItHint::CreateReplacement(
+CharSourceRange::getTokenRange(ReplaceRange), ReplacementText));
 // No further replacements are made to the loop, since the iterator or 
index
 // was used exactly once - in the initialization of AliasVar.
   } else {
@@ -609,8 +607,8 @@
 Usage.Kind == Usage::UK_CaptureByCopy ? "&" + VarName : VarName;
   }
   TUInfo->getReplacedVars().insert(std::make_pair(Loop, IndexVar));
-  Diag << FixItHint::CreateReplacement(
-  CharSourceRange::getTokenRange(Range), ReplaceText);
+  FixIts.push_back(FixItHint::CreateReplacement(
+  CharSourceRange::getTokenRange(Range), ReplaceText));
 }
   }
 
@@ -648,8 +646,9 @@
   std::string Range = ("(" + TypeString + " " + VarName + " : " +
MaybeDereference + Descriptor.ContainerString + ")")
   .str();
-  Diag << FixItHint::CreateReplacement(
-  CharSourceRange::getTokenRange(ParenRange), Range);
+  FixIts.push_back(FixItHint::CreateReplacement(
+  CharSourceRange::getTokenRange(ParenRange), Range));
+  diag(Loop->getForLoc(), "use range-based for loop instead") << FixIts;
   TUInfo->getGeneratedDecls().insert(make_pair(Loop, VarName));
 }
 


Index: clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
===
--- clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
+++ clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
@@ -272,6 +272,33 @@
   "use a trailing return type for this function");
 }
 
+TEST(DiagnosticTest, NoMultipleDiagnosticInFlight) {
+  Annotations Main(R"cpp(
+template  struct Foo {
+  T *begin();
+  T *end();
+};
+struct LabelInfo {
+  int a;
+  bool b;
+};
+
+void f() {
+  Foo label_info_map;
+  [[for]] (auto it = label_info_map.begin(); it != label_info_map.end(); ++it) {
+auto S = *it;
+  }
+}
+  )cpp");
+  TestTU TU = TestTU::withCode(Main.code());
+  TU.ClangTidyChecks = "modernize-loop-convert";
+  EXPECT_THAT(
+  TU.build().getDiagnostics(),
+  UnorderedElementsAre(::testing::AllOf(
+  Diag(Main.range(), "use range-based for loop instead"),
+

Re: [PATCH] D78192: Support compiler extensions as a normal component

2020-04-24 Thread Serge Guelton via cfe-commits

On Fri, Apr 24, 2020 at 10:15:15AM +0100, Russell Gallop wrote:
> Hi Serge,
> 
> It looks like this is failing to build on Windows bots (e.g. [1]http://
> lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/
> builds/32003). Error below.
> 
> Please could you take a look?

Sure, thanks for reaching me!

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

Re: [PATCH] D78192: Support compiler extensions as a normal component

2020-04-24 Thread Serge Guelton via cfe-commits

On Fri, Apr 24, 2020 at 10:15:15AM +0100, Russell Gallop wrote:
> Hi Serge,
> 
> It looks like this is failing to build on Windows bots (e.g. [1]http://
> lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/
> builds/32003). Error below.
> 
> Please could you take a look?

e307eeba0137700e75893089cf0de03383d851ca should do the trick (finger crossed)

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

[clang] c84e130 - [SveEmitter] Add builtins for scatter stores

2020-04-24 Thread Sander de Smalen via cfe-commits


Author: Sander de Smalen
Date: 2020-04-24T10:57:43+01:00
New Revision: c84e1305c4faf92bb75cf265e022b39bf96da608

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

LOG: [SveEmitter] Add builtins for scatter stores

D77735 only added scatters for the non-temporal variants.

Reviewers: SjoerdMeijer, efriedma, andwar

Reviewed By: efriedma

Tags: #clang

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

Added: 


Modified: 
clang/include/clang/Basic/arm_sve.td
clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_st1.c
clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_st1b.c
clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_st1h.c
clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_st1w.c

Removed: 




diff  --git a/clang/include/clang/Basic/arm_sve.td 
b/clang/include/clang/Basic/arm_sve.td
index 692e76aff9a3..f3dfe2c8bb1d 100644
--- a/clang/include/clang/Basic/arm_sve.td
+++ b/clang/include/clang/Basic/arm_sve.td
@@ -466,6 +466,75 @@ def SVST1H_VNUM_U : MInst<"svst1h_vnum[_{d}]", "vPFld", 
"UiUl",[IsSt
 def SVST1W_VNUM_S : MInst<"svst1w_vnum[_{d}]", "vPCld", "l",   
[IsStore], MemEltTyInt32,   "aarch64_sve_st1">;
 def SVST1W_VNUM_U : MInst<"svst1w_vnum[_{d}]", "vPGld", "Ul",  
[IsStore], MemEltTyInt32,   "aarch64_sve_st1">;
 
+// Store one vector (vector base)
+def SVST1_SCATTER_BASES_U : MInst<"svst1_scatter[_{2}base_{d}]",  "vPud",  
"ilUiUlfd", [IsScatterStore], MemEltTyDefault, 
"aarch64_sve_st1_scatter_scalar_offset">;
+def SVST1B_SCATTER_BASES_U: MInst<"svst1b_scatter[_{2}base_{d}]", "vPud",  
"ilUiUl",   [IsScatterStore], MemEltTyInt8,
"aarch64_sve_st1_scatter_scalar_offset">;
+def SVST1H_SCATTER_BASES_U: MInst<"svst1h_scatter[_{2}base_{d}]", "vPud",  
"ilUiUl",   [IsScatterStore], MemEltTyInt16,   
"aarch64_sve_st1_scatter_scalar_offset">;
+def SVST1W_SCATTER_BASES_U: MInst<"svst1w_scatter[_{2}base_{d}]", "vPud",  
"lUl",  [IsScatterStore], MemEltTyInt32,   
"aarch64_sve_st1_scatter_scalar_offset">;
+
+// Store one vector (scalar base, signed vector offset in bytes)
+def SVST1_SCATTER_64B_OFFSETS_S   : MInst<"svst1_scatter_[{3}]offset[_{d}]",  
"vPpxd", "lUld", [IsScatterStore, IsByteIndexed], MemEltTyDefault, 
"aarch64_sve_st1_scatter">;
+def SVST1B_SCATTER_64B_OFFSETS_SS : MInst<"svst1b_scatter_[{3}]offset[_{d}]", 
"vPAxd", "l",[IsScatterStore, IsByteIndexed], MemEltTyInt8,
"aarch64_sve_st1_scatter">;
+def SVST1B_SCATTER_64B_OFFSETS_SU : MInst<"svst1b_scatter_[{3}]offset[_{d}]", 
"vPExd", "Ul",   [IsScatterStore, IsByteIndexed], MemEltTyInt8,
"aarch64_sve_st1_scatter">;
+def SVST1H_SCATTER_64B_OFFSETS_SS : MInst<"svst1h_scatter_[{3}]offset[_{d}]", 
"vPBxd", "l",[IsScatterStore, IsByteIndexed], MemEltTyInt16,   
"aarch64_sve_st1_scatter">;
+def SVST1H_SCATTER_64B_OFFSETS_SU : MInst<"svst1h_scatter_[{3}]offset[_{d}]", 
"vPFxd", "Ul",   [IsScatterStore, IsByteIndexed], MemEltTyInt16,   
"aarch64_sve_st1_scatter">;
+def SVST1W_SCATTER_64B_OFFSETS_SS : MInst<"svst1w_scatter_[{3}]offset[_{d}]", 
"vPCxd", "l",[IsScatterStore, IsByteIndexed], MemEltTyInt32,   
"aarch64_sve_st1_scatter">;
+def SVST1W_SCATTER_64B_OFFSETS_SU : MInst<"svst1w_scatter_[{3}]offset[_{d}]", 
"vPGxd", "Ul",   [IsScatterStore, IsByteIndexed], MemEltTyInt32,   
"aarch64_sve_st1_scatter">;
+
+def SVST1_SCATTER_32B_OFFSETS_S   : MInst<"svst1_scatter_[{3}]offset[_{d}]",  
"vPpxd", "iUif", [IsScatterStore, IsByteIndexed], MemEltTyDefault, 
"aarch64_sve_st1_scatter_sxtw">;
+def SVST1B_SCATTER_32B_OFFSETS_SS : MInst<"svst1b_scatter_[{3}]offset[_{d}]", 
"vPAxd", "i",[IsScatterStore, IsByteIndexed], MemEltTyInt8,
"aarch64_sve_st1_scatter_sxtw">;
+def SVST1B_SCATTER_32B_OFFSETS_SU : MInst<"svst1b_scatter_[{3}]offset[_{d}]", 
"vPExd", "Ui",   [IsScatterStore, IsByteIndexed], MemEltTyInt8,
"aarch64_sve_st1_scatter_sxtw">;
+def SVST1H_SCATTER_32B_OFFSETS_SS : MInst<"svst1h_scatter_[{3}]offset[_{d}]", 
"vPBxd", "i",[IsScatterStore, IsByteIndexed], MemEltTyInt16,   
"aarch64_sve_st1_scatter_sxtw">;
+def SVST1H_SCATTER_32B_OFFSETS_SU : MInst<"svst1h_scatter_[{3}]offset[_{d}]", 
"vPFxd", "Ui",   [IsScatterStore, IsByteIndexed], MemEltTyInt16,   
"aarch64_sve_st1_scatter_sxtw">;
+
+// Store one vector (scalar base, unsigned vector offset in bytes)
+def SVST1_SCATTER_64B_OFFSETS_U   : MInst<"svst1_scatter_[{3}]offset[_{d}]",  
"vPpud", "lUld", [IsScatterStore, IsByteIndexed], MemEltTyDefault, 
"aarch64_sve_st1_scatter">;
+def SVST1B_SCATTER_64B_OFFSETS_US : MInst<"svst1b_scatter_[{3}]offset[_{d}]", 
"vPAud", "l",[IsScatterStore, IsByteIndexed], MemEltTyInt8,
"aarch64_sve_st1_scatter">;
+def SVST1B_SCATTER_64B_OFFSETS_UU : MInst<"svst1b_scatter_[{3}]offset[_{d}]", 
"vPEud", "Ul",   [IsScatterStore, IsBy

[PATCH] D78704: [analyzer][NFC] Add unittest for FalsePositiveRefutationBRVisitor

2020-04-24 Thread Whisperity via Phabricator via cfe-commits

whisperity added inline comments.



Comment at: 
clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp:24
+  do   
\
+if (!LLVM_WITH_Z3) 
\
+  return;  
\

xazax.hun wrote:
> steakhal wrote:
> > xazax.hun wrote:
> > > I think this might not be the idiomatic way to skip a test. Consider 
> > > using ` GTEST_SKIP();`.
> > I agree, though that is not yet supported in the `gtest` in the repository.
> > Should we update that to benefit from this macro?
> > 
> > There are several places where we could use that like:
> > - 
> > [llvm/unittests/ExecutionEngine/MCJIT/MCJITTestAPICommon.h:29](https://github.com/llvm/llvm-project/blob/master/llvm/unittests/ExecutionEngine/MCJIT/MCJITTestAPICommon.h#L29-L33)
> >  (expanded 37 times in the codebase)
> > - 
> > [llvm/unittests/Support/ThreadPool.cpp:81](https://github.com/llvm/llvm-project/blob/master/llvm/unittests/Support/ThreadPool.cpp#L81-L85)
> >  (expanded 7 times in the file)
> > - 
> > [llvm/unittests/Support/MemoryTest.cpp:89](https://github.com/llvm/llvm-project/blob/master/llvm/unittests/Support/MemoryTest.cpp#L89-L94)
> >  (expanded 10 time in the file)
> I think you should check who updated gtest the last time and ping them what 
> is the process to update it again.
Still maybe this could warrant a `// FIXME: Update GTest and use GTEST_SKIP()` ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78704



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

[PATCH] D77597: [SveEmitter] Add IsAppendSVALL and builtins for svptrue and svcnt[bhwd]

2020-04-24 Thread Sander de Smalen via Phabricator via cfe-commits

sdesmalen added a comment.

Gentle ping :)


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

https://reviews.llvm.org/D77597



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

[PATCH] D78521: [clangd] Extend dexp to support remote index

2020-04-24 Thread Kirill Bobyrev via Phabricator via cfe-commits

kbobyrev updated this revision to Diff 259839.
kbobyrev added a comment.

Don't use callback on the last message.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78521

Files:
  clang-tools-extra/clangd/CMakeLists.txt
  clang-tools-extra/clangd/Features.inc.in
  clang-tools-extra/clangd/index/Serialization.h
  clang-tools-extra/clangd/index/YAMLSerialization.cpp
  clang-tools-extra/clangd/index/dex/dexp/CMakeLists.txt
  clang-tools-extra/clangd/index/dex/dexp/Dexp.cpp
  clang-tools-extra/clangd/index/remote/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/Client.cpp
  clang-tools-extra/clangd/index/remote/Client.h
  clang-tools-extra/clangd/index/remote/Index.proto
  clang-tools-extra/clangd/index/remote/client/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/client/Client.cpp
  clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/marshalling/Marshalling.cpp
  clang-tools-extra/clangd/index/remote/marshalling/Marshalling.h
  clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/server/Server.cpp
  clang-tools-extra/clangd/index/remote/unimplemented/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/unimplemented/Client.cpp

Index: clang-tools-extra/clangd/index/remote/unimplemented/Client.cpp
===
--- /dev/null
+++ clang-tools-extra/clangd/index/remote/unimplemented/Client.cpp
@@ -0,0 +1,26 @@
+//===--- Client.cpp --*- 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
+//
+//===--===//
+
+#include "index/remote/Client.h"
+#include "Logger.h"
+
+namespace clang {
+namespace clangd {
+namespace remote {
+
+std::unique_ptr getClient(llvm::StringRef Address) {
+  const auto *Message =
+  "Can't create SymbolIndex client without Remote Index support.";
+  llvm_unreachable(Message);
+  elog(Message);
+  return nullptr;
+}
+
+} // namespace remote
+} // namespace clangd
+} // namespace clang
Index: clang-tools-extra/clangd/index/remote/unimplemented/CMakeLists.txt
===
--- /dev/null
+++ clang-tools-extra/clangd/index/remote/unimplemented/CMakeLists.txt
@@ -0,0 +1,7 @@
+include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../../../)
+add_clang_library(clangdRemoteIndex
+  Client.cpp
+
+  LINK_LIBS
+  clangDaemon
+  )
Index: clang-tools-extra/clangd/index/remote/server/Server.cpp
===
--- clang-tools-extra/clangd/index/remote/server/Server.cpp
+++ clang-tools-extra/clangd/index/remote/server/Server.cpp
@@ -8,6 +8,7 @@
 
 #include "index/Index.h"
 #include "index/Serialization.h"
+#include "index/remote/marshalling/Marshalling.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/LineEditor/LineEditor.h"
@@ -16,13 +17,14 @@
 #include "llvm/Support/Path.h"
 #include "llvm/Support/Signals.h"
 
-#include "grpcpp/grpcpp.h"
-#include "grpcpp/health_check_service_interface.h"
+#include 
+#include 
 
 #include "Index.grpc.pb.h"
 
 namespace clang {
 namespace clangd {
+namespace remote {
 namespace {
 
 static const std::string Overview = R"(
@@ -33,42 +35,81 @@
 llvm::cl::opt IndexPath(llvm::cl::desc(""),
  llvm::cl::Positional, llvm::cl::Required);
 
-llvm::cl::opt ServerAddress("server-address",
- llvm::cl::init("0.0.0.0:50051"));
+llvm::cl::opt ServerAddress(
+"server-address", llvm::cl::init("0.0.0.0:50051"),
+llvm::cl::desc("Address of the invoked server. Defaults to 0.0.0.0:50051"));
 
-std::unique_ptr openIndex(llvm::StringRef Index) {
+std::unique_ptr openIndex(llvm::StringRef Index) {
   return loadIndex(Index, /*UseIndex=*/true);
 }
 
-class RemoteIndexServer final : public remote::Index::Service {
+class RemoteIndexServer final : public SymbolIndex::Service {
 public:
-  RemoteIndexServer(std::unique_ptr Index)
+  RemoteIndexServer(std::unique_ptr Index)
   : Index(std::move(Index)) {}
 
 private:
   grpc::Status Lookup(grpc::ServerContext *Context,
-  const remote::LookupRequest *Request,
-  grpc::ServerWriter *Reply) override {
-llvm::outs() << "Lookup of symbol with ID " << Request->id() << '\n';
-LookupRequest Req;
-auto SID = SymbolID::fromStr(Request->id());
-if (!SID) {
-  llvm::outs() << llvm::toString(SID.takeError()) << "\n";
-  return grpc::Status::CANCELLED;
+  const LookupRequest *Request,
+  grpc::ServerWriter *Reply) overr

[PATCH] D46317: [clang-tidy] New check bugprone-map-subscript-operator-lookup

2020-04-24 Thread Kalle Huttunen via Phabricator via cfe-commits

khuttun updated this revision to Diff 259843.
khuttun added a comment.

Documented the MapTypes check option.


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

https://reviews.llvm.org/D46317

Files:
  clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
  clang-tools-extra/clang-tidy/bugprone/MapSubscriptOperatorLookupCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/MapSubscriptOperatorLookupCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/docs/clang-tidy/checks/bugprone-map-subscript-operator-lookup.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-map-subscript-operator-lookup-custom.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-map-subscript-operator-lookup.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-map-subscript-operator-lookup.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-map-subscript-operator-lookup.cpp
@@ -0,0 +1,267 @@
+// RUN: %check_clang_tidy %s bugprone-map-subscript-operator-lookup %t
+
+namespace std {
+
+template 
+struct allocator {};
+
+template 
+struct equal_to {};
+
+template 
+struct hash {};
+
+template 
+struct less {};
+
+template 
+struct pair {};
+
+template ,
+  typename Allocator = std::allocator>>
+struct map {
+  T &operator[](const Key &);
+  T &operator[](Key &&);
+};
+
+// the check should be able to match std lib calls even if the functions are
+// declared inside inline namespaces
+inline namespace v1 {
+
+template ,
+  typename KeyEqual = std::equal_to,
+  typename Allocator = std::allocator>>
+struct unordered_map {
+  T &operator[](const Key &);
+  T &operator[](Key &&);
+};
+
+} // namespace v1
+} // namespace std
+
+struct Foo {
+  int getter() const;
+  void setter(int);
+  bool operator==(const Foo &) const;
+};
+
+using FooPtr = Foo *;
+
+void readInt(const int &);
+void writeInt(int &);
+void copyInt(int);
+
+void readFoo(const Foo &);
+void writeFoo(Foo &);
+void copyFoo(Foo);
+
+void copyFooPtr(Foo *);
+void copyConstFooPtr(const Foo *);
+
+std::map IntMap;
+std::map FooMap;
+std::unordered_map FooPtrMap;
+
+void copyFromMap() {
+  int A = IntMap[1];
+  // CHECK-MESSAGES: [[@LINE-1]]:11: warning: do not use operator[] for map lookup [bugprone-map-subscript-operator-lookup]
+  Foo B = FooMap[1];
+  // CHECK-MESSAGES: [[@LINE-1]]:11: warning: do not use operator[] for map lookup [bugprone-map-subscript-operator-lookup]
+  FooPtr C = FooPtrMap[1];
+  // CHECK-MESSAGES: [[@LINE-1]]:14: warning: do not use operator[] for unordered_map lookup [bugprone-map-subscript-operator-lookup]
+}
+
+void constRefFromMap() {
+  const int &A = IntMap[1];
+  // CHECK-MESSAGES: [[@LINE-1]]:18: warning: do not use operator[] for map lookup [bugprone-map-subscript-operator-lookup]
+  const Foo &B = FooMap[1];
+  // CHECK-MESSAGES: [[@LINE-1]]:18: warning: do not use operator[] for map lookup [bugprone-map-subscript-operator-lookup]
+  const FooPtr &C = FooPtrMap[1];
+  // CHECK-MESSAGES: [[@LINE-1]]:21: warning: do not use operator[] for unordered_map lookup [bugprone-map-subscript-operator-lookup]
+}
+
+void constPtrFromMap() {
+  const int *A = &IntMap[1];
+  // CHECK-MESSAGES: [[@LINE-1]]:19: warning: do not use operator[] for map lookup [bugprone-map-subscript-operator-lookup]
+  const Foo *B = &FooMap[1];
+  // CHECK-MESSAGES: [[@LINE-1]]:19: warning: do not use operator[] for map lookup [bugprone-map-subscript-operator-lookup]
+  const FooPtr *C = &FooPtrMap[1];
+  // CHECK-MESSAGES: [[@LINE-1]]:22: warning: do not use operator[] for unordered_map lookup [bugprone-map-subscript-operator-lookup]
+}
+
+int returnInt() {
+  return IntMap[1];
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: do not use operator[] for map lookup [bugprone-map-subscript-operator-lookup]
+}
+
+Foo returnFoo() {
+  return FooMap[1];
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: do not use operator[] for map lookup [bugprone-map-subscript-operator-lookup]
+}
+
+FooPtr returnFooPtr() {
+  return FooPtrMap[1];
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: do not use operator[] for unordered_map lookup [bugprone-map-subscript-operator-lookup]
+}
+
+const int &returnRefToConstInt() {
+  return IntMap[1];
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: do not use operator[] for map lookup [bugprone-map-subscript-operator-lookup]
+}
+
+const Foo &returnRefToConstFoo() {
+  return FooMap[1];
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: do not use operator[] for map lookup [bugprone-map-subscript-operator-lookup]
+}
+
+const FooPtr &returnRefToConstFooPtr() {
+  return FooPtrMap[1];
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: do not use operator[] for unordered_map lookup [bugprone-map-subscript-operator-lookup]
+}
+
+const int *returnPtrToConstInt() {
+  return &IntMap[1];
+  // CHECK-MESSAGE

[PATCH] D50078: clang-format: support aligned nested conditionals formatting

2020-04-24 Thread Francois Ferrand via Phabricator via cfe-commits

Typz added a comment.

Thanks for trying the patch, too bad it does not work...
I will see how to get the required setup/env, but it will probably take some 
time (esp. in the current situation).
Thanks again


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D50078



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

[PATCH] D78751: [SveEmitter] Add builtins for scatter stores

2020-04-24 Thread Sander de Smalen via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGc84e1305c4fa: [SveEmitter] Add builtins for scatter stores 
(authored by sdesmalen).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78751

Files:
  clang/include/clang/Basic/arm_sve.td
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_st1.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_st1b.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_st1h.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_st1w.c

Index: clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_st1w.c
===
--- clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_st1w.c
+++ clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_st1w.c
@@ -53,3 +53,145 @@
   // CHECK: ret void
   return SVE_ACLE_FUNC(svst1w_vnum,_u64,,)(pg, base, vnum, data);
 }
+
+void test_svst1w_scatter_u64base_s64(svbool_t pg, svuint64_t bases, svint64_t data)
+{
+  // CHECK-LABEL: test_svst1w_scatter_u64base_s64
+  // CHECK-DAG: %[[TRUNC:.*]] = trunc  %data to 
+  // CHECK-DAG: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv2i1( %pg)
+  // CHECK: call void @llvm.aarch64.sve.st1.scatter.scalar.offset.nxv2i32.nxv2i64( %[[TRUNC]],  %[[PG]],  %bases, i64 0)
+  // CHECK: ret void
+  return SVE_ACLE_FUNC(svst1w_scatter,_u64base,,_s64)(pg, bases, data);
+}
+
+void test_svst1w_scatter_u64base_u64(svbool_t pg, svuint64_t bases, svuint64_t data)
+{
+  // CHECK-LABEL: test_svst1w_scatter_u64base_u64
+  // CHECK-DAG: %[[TRUNC:.*]] = trunc  %data to 
+  // CHECK-DAG: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv2i1( %pg)
+  // CHECK: call void @llvm.aarch64.sve.st1.scatter.scalar.offset.nxv2i32.nxv2i64( %[[TRUNC]],  %[[PG]],  %bases, i64 0)
+  // CHECK: ret void
+  return SVE_ACLE_FUNC(svst1w_scatter,_u64base,,_u64)(pg, bases, data);
+}
+
+void test_svst1w_scatter_s64offset_s64(svbool_t pg, int32_t *base, svint64_t offsets, svint64_t data)
+{
+  // CHECK-LABEL: test_svst1w_scatter_s64offset_s64
+  // CHECK-DAG: %[[TRUNC:.*]] = trunc  %data to 
+  // CHECK-DAG: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv2i1( %pg)
+  // CHECK: call void @llvm.aarch64.sve.st1.scatter.nxv2i32( %[[TRUNC]],  %[[PG]], i32* %base,  %offsets)
+  // CHECK: ret void
+  return SVE_ACLE_FUNC(svst1w_scatter_,s64,offset,_s64)(pg, base, offsets, data);
+}
+
+void test_svst1w_scatter_s64offset_u64(svbool_t pg, uint32_t *base, svint64_t offsets, svuint64_t data)
+{
+  // CHECK-LABEL: test_svst1w_scatter_s64offset_u64
+  // CHECK-DAG: %[[TRUNC:.*]] = trunc  %data to 
+  // CHECK-DAG: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv2i1( %pg)
+  // CHECK: call void @llvm.aarch64.sve.st1.scatter.nxv2i32( %[[TRUNC]],  %[[PG]], i32* %base,  %offsets)
+  // CHECK: ret void
+  return SVE_ACLE_FUNC(svst1w_scatter_,s64,offset,_u64)(pg, base, offsets, data);
+}
+
+void test_svst1w_scatter_u64offset_s64(svbool_t pg, int32_t *base, svuint64_t offsets, svint64_t data)
+{
+  // CHECK-LABEL: test_svst1w_scatter_u64offset_s64
+  // CHECK-DAG: %[[TRUNC:.*]] = trunc  %data to 
+  // CHECK-DAG: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv2i1( %pg)
+  // CHECK: call void @llvm.aarch64.sve.st1.scatter.nxv2i32( %[[TRUNC]],  %[[PG]], i32* %base,  %offsets)
+  // CHECK: ret void
+  return SVE_ACLE_FUNC(svst1w_scatter_,u64,offset,_s64)(pg, base, offsets, data);
+}
+
+void test_svst1w_scatter_u64offset_u64(svbool_t pg, uint32_t *base, svuint64_t offsets, svuint64_t data)
+{
+  // CHECK-LABEL: test_svst1w_scatter_u64offset_u64
+  // CHECK-DAG: %[[TRUNC:.*]] = trunc  %data to 
+  // CHECK-DAG: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv2i1( %pg)
+  // CHECK: call void @llvm.aarch64.sve.st1.scatter.nxv2i32( %[[TRUNC]],  %[[PG]], i32* %base,  %offsets)
+  // CHECK: ret void
+  return SVE_ACLE_FUNC(svst1w_scatter_,u64,offset,_u64)(pg, base, offsets, data);
+}
+
+void test_svst1w_scatter_u64base_offset_s64(svbool_t pg, svuint64_t bases, int64_t offset, svint64_t data)
+{
+  // CHECK-LABEL: test_svst1w_scatter_u64base_offset_s64
+  // CHECK-DAG: %[[TRUNC:.*]] = trunc  %data to 
+  // CHECK-DAG: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv2i1( %pg)
+  // CHECK: call void @llvm.aarch64.sve.st1.scatter.scalar.offset.nxv2i32.nxv2i64( %[[TRUNC]],  %[[PG]],  %bases, i64 %offset)
+  // CHECK: ret void
+  return SVE_ACLE_FUNC(svst1w_scatter,_u64base,_offset,_s64)(pg, bases, offset, data);
+}
+
+void test_svst1w_scatter_u64base_offset_u64(svbool_t pg, svuint64_t bases, int64_t offset, svuint64_t data)
+{
+  // CHECK-LABEL: test_svst1w_scatter_u64base_offset_u64
+  // CHECK-DAG: %[[TRUNC:.*]] = trunc  %data to 
+  // CHECK-DAG: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv2i1( %pg)
+  // CHECK: call void @llvm.aarch64.sve.st1.scatter.scalar.offset.nxv2i32.nxv2i64( %[[TRUNC]],  %[[PG]],  %bases,

[clang] db79974 - [SveEmitter] Add builtins for svld1rq

2020-04-24 Thread Sander de Smalen via cfe-commits


Author: Sander de Smalen
Date: 2020-04-24T11:10:28+01:00
New Revision: db7997472bbd01645f058b23a4ca9e991d5b8144

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

LOG: [SveEmitter] Add builtins for svld1rq

Reviewed By: efriedma

Tags: #clang

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

Added: 
clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_ld1rq.c

Modified: 
clang/include/clang/Basic/arm_sve.td

Removed: 




diff  --git a/clang/include/clang/Basic/arm_sve.td 
b/clang/include/clang/Basic/arm_sve.td
index f3dfe2c8bb1d..4b69cdcb6468 100644
--- a/clang/include/clang/Basic/arm_sve.td
+++ b/clang/include/clang/Basic/arm_sve.td
@@ -444,6 +444,8 @@ def SVLDNT1 : MInst<"svldnt1[_{2}]", "dPc", 
"csilUcUsUiUlhfd", [IsLoad], MemEltT
 // Load one vector, unextended load, non-temporal (scalar base, VL 
displacement)
 def SVLDNT1_VNUM : MInst<"svldnt1_vnum[_{2}]", "dPcl", "csilUcUsUiUlhfd", 
[IsLoad], MemEltTyDefault, "aarch64_sve_ldnt1">;
 
+// Load one quadword and replicate (scalar base)
+def SVLD1RQ : SInst<"svld1rq[_{2}]", "dPc", "csilUcUsUiUlhfd", MergeNone, 
"aarch64_sve_ld1rq">;
 
 

 // Stores

diff  --git a/clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_ld1rq.c 
b/clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_ld1rq.c
new file mode 100644
index ..f0a3d5c1a62a
--- /dev/null
+++ b/clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_ld1rq.c
@@ -0,0 +1,108 @@
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -triple aarch64-none-linux-gnu 
-target-feature +sve -fallow-half-arguments-and-returns -S -O1 -Werror -Wall 
-emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -DSVE_OVERLOADED_FORMS -triple 
aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns 
-S -O1 -Werror -Wall -emit-llvm -o - %s | FileCheck %s
+
+#include 
+
+#ifdef SVE_OVERLOADED_FORMS
+// A simple used,unused... macro, long enough to represent any SVE builtin.
+#define SVE_ACLE_FUNC(A1,A2_UNUSED,A3,A4_UNUSED) A1##A3
+#else
+#define SVE_ACLE_FUNC(A1,A2,A3,A4) A1##A2##A3##A4
+#endif
+
+svint8_t test_svld1rq_s8(svbool_t pg, const int8_t *base)
+{
+  // CHECK-LABEL: test_svld1rq_s8
+  // CHECK: %[[INTRINSIC:.*]] = call  
@llvm.aarch64.sve.ld1rq.nxv16i8( %pg, i8* %base)
+  // CHECK: ret  %[[INTRINSIC]]
+  return SVE_ACLE_FUNC(svld1rq,_s8,,)(pg, base);
+}
+
+svint16_t test_svld1rq_s16(svbool_t pg, const int16_t *base)
+{
+  // CHECK-LABEL: test_svld1rq_s16
+  // CHECK: %[[PG:.*]] = call  
@llvm.aarch64.sve.convert.from.svbool.nxv8i1( %pg)
+  // CHECK: %[[INTRINSIC:.*]] = call  
@llvm.aarch64.sve.ld1rq.nxv8i16( %[[PG]], i16* %base)
+  // CHECK: ret  %[[INTRINSIC]]
+  return SVE_ACLE_FUNC(svld1rq,_s16,,)(pg, base);
+}
+
+svint32_t test_svld1rq_s32(svbool_t pg, const int32_t *base)
+{
+  // CHECK-LABEL: test_svld1rq_s32
+  // CHECK: %[[PG:.*]] = call  
@llvm.aarch64.sve.convert.from.svbool.nxv4i1( %pg)
+  // CHECK: %[[INTRINSIC:.*]] = call  
@llvm.aarch64.sve.ld1rq.nxv4i32( %[[PG]], i32* %base)
+  // CHECK: ret  %[[INTRINSIC]]
+  return SVE_ACLE_FUNC(svld1rq,_s32,,)(pg, base);
+}
+
+svint64_t test_svld1rq_s64(svbool_t pg, const int64_t *base)
+{
+  // CHECK-LABEL: test_svld1rq_s64
+  // CHECK: %[[PG:.*]] = call  
@llvm.aarch64.sve.convert.from.svbool.nxv2i1( %pg)
+  // CHECK: %[[INTRINSIC:.*]] = call  
@llvm.aarch64.sve.ld1rq.nxv2i64( %[[PG]], i64* %base)
+  // CHECK: ret  %[[INTRINSIC]]
+  return SVE_ACLE_FUNC(svld1rq,_s64,,)(pg, base);
+}
+
+svuint8_t test_svld1rq_u8(svbool_t pg, const uint8_t *base)
+{
+  // CHECK-LABEL: test_svld1rq_u8
+  // CHECK: %[[INTRINSIC:.*]] = call  
@llvm.aarch64.sve.ld1rq.nxv16i8( %pg, i8* %base)
+  // CHECK: ret  %[[INTRINSIC]]
+  return SVE_ACLE_FUNC(svld1rq,_u8,,)(pg, base);
+}
+
+svuint16_t test_svld1rq_u16(svbool_t pg, const uint16_t *base)
+{
+  // CHECK-LABEL: test_svld1rq_u16
+  // CHECK: %[[PG:.*]] = call  
@llvm.aarch64.sve.convert.from.svbool.nxv8i1( %pg)
+  // CHECK: %[[INTRINSIC:.*]] = call  
@llvm.aarch64.sve.ld1rq.nxv8i16( %[[PG]], i16* %base)
+  // CHECK: ret  %[[INTRINSIC]]
+  return SVE_ACLE_FUNC(svld1rq,_u16,,)(pg, base);
+}
+
+svuint32_t test_svld1rq_u32(svbool_t pg, const uint32_t *base)
+{
+  // CHECK-LABEL: test_svld1rq_u32
+  // CHECK: %[[PG:.*]] = call  
@llvm.aarch64.sve.convert.from.svbool.nxv4i1( %pg)
+  // CHECK: %[[INTRINSIC:.*]] = call  
@llvm.aarch64.sve.ld1rq.nxv4i32( %[[PG]], i32* %base)
+  // CHECK: ret  %[[INTRINSIC]]
+  return SVE_ACLE_FUNC(svld1rq,_u32,,)(pg, base);
+}
+
+svuint64_t test_svld1rq_u64(svbool_t pg, const uint64_t *base)
+{
+  // CHECK-LABEL: test_svld1rq_u64
+  // CHECK: %[[PG:.*]] = call  
@llvm.aarch64.sve.convert.from.svbool.nxv2i1( %pg)
+  // CHECK: %[[INTRINSIC:.*]] = call  
@llvm.aarch64.sve.

[clang] 823e2a6 - [SveEmitter] Add builtins for contiguous prefetches

2020-04-24 Thread Sander de Smalen via cfe-commits


Author: Sander de Smalen
Date: 2020-04-24T11:35:59+01:00
New Revision: 823e2a670a9da8e5cd8beed108355a168ca1a23b

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

LOG: [SveEmitter] Add builtins for contiguous prefetches

This patch also adds the enum `sv_prfop` for the prefetch operation specifier
and checks to ensure the passed enum values are valid.

Reviewers: SjoerdMeijer, efriedma, ctetreau

Reviewed By: efriedma

Tags: #clang

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

Added: 
clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfb.c
clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfd.c
clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfh.c
clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfw.c
clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_prfb.c
clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_prfd.c
clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_prfh.c
clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_prfw.c

Modified: 
clang/include/clang/Basic/TargetBuiltins.h
clang/include/clang/Basic/arm_sve.td
clang/lib/CodeGen/CGBuiltin.cpp
clang/lib/CodeGen/CodeGenFunction.h
clang/lib/Sema/SemaChecking.cpp
clang/utils/TableGen/SveEmitter.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/TargetBuiltins.h 
b/clang/include/clang/Basic/TargetBuiltins.h
index 5ef1a58fbb0f..1a9cb4cda1a4 100644
--- a/clang/include/clang/Basic/TargetBuiltins.h
+++ b/clang/include/clang/Basic/TargetBuiltins.h
@@ -238,6 +238,7 @@ namespace clang {
 bool isOverloadDefault() const { return !(Flags & OverloadKindMask); }
 bool isOverloadWhileRW() const { return Flags & IsOverloadWhileRW; }
 bool isOverloadCvt() const { return Flags & IsOverloadCvt; }
+bool isPrefetch() const { return Flags & IsPrefetch; }
 
 uint64_t getBits() const { return Flags; }
 bool isFlagSet(uint64_t Flag) const { return Flags & Flag; }

diff  --git a/clang/include/clang/Basic/arm_sve.td 
b/clang/include/clang/Basic/arm_sve.td
index 4b69cdcb6468..5709dc8b8781 100644
--- a/clang/include/clang/Basic/arm_sve.td
+++ b/clang/include/clang/Basic/arm_sve.td
@@ -58,6 +58,7 @@
 // ---
 // prototype: return (arg, arg, ...)
 //
+// v: void
 // x: vector of signed integers
 // u: vector of unsigned integers
 // d: default
@@ -82,6 +83,7 @@
 // M: svfloat32_t
 // N: svfloat64_t
 
+// J: Prefetch type (sv_prfop)
 // A: pointer to int8_t
 // B: pointer to int16_t
 // C: pointer to int32_t
@@ -176,6 +178,7 @@ def IsOverloadWhileRW : FlagType<0x0040>; // 
Use {pred(default type)
 def IsOverloadCvt : FlagType<0x0080>; // Use 
{typeof(operand0), typeof(last operand)} as overloaded types.
 def OverloadKindMask  : FlagType<0x00E0>; // When the masked 
values are all '0', the default type is used as overload type.
 def IsByteIndexed : FlagType<0x0100>;
+def IsPrefetch: FlagType<0x0800>; // Contiguous prefetches.
 
 // These must be kept in sync with the flags in 
include/clang/Basic/TargetBuiltins.h
 class ImmCheckType {
@@ -193,6 +196,7 @@ def ImmCheckLaneIndexCompRotate : ImmCheckType<8>;  // 
0..(128/(2*sizeinbits(elt
 def ImmCheckLaneIndexDot: ImmCheckType<9>;  // 
0..(128/(4*sizeinbits(elt)) - 1)
 def ImmCheckComplexRot90_270: ImmCheckType<10>; // [90,270]
 def ImmCheckComplexRotAll90 : ImmCheckType<11>; // [0, 90, 180,270]
+def ImmCheck0_13: ImmCheckType<12>; // 0..13
 
 class ImmCheck {
   int Arg = arg;
@@ -543,6 +547,21 @@ def SVSTNT1 : MInst<"svstnt1[_{d}]", "vPpd", 
"csilUcUsUiUlhfd", [IsStore], MemEl
 // Store one vector, with no truncation, non-temporal (scalar base, VL 
displacement)
 def SVSTNT1_VNUM : MInst<"svstnt1_vnum[_{d}]", "vPpld", "csilUcUsUiUlhfd", 
[IsStore], MemEltTyDefault, "aarch64_sve_stnt1">;
 
+
+// Prefetches
+
+// Prefetch (Scalar base)
+def SVPRFB : MInst<"svprfb", "vPcJ", "c", [IsPrefetch], MemEltTyInt8,  
"aarch64_sve_prf">;
+def SVPRFH : MInst<"svprfh", "vPcJ", "s", [IsPrefetch], MemEltTyInt16, 
"aarch64_sve_prf">;
+def SVPRFW : MInst<"svprfw", "vPcJ", "i", [IsPrefetch], MemEltTyInt32, 
"aarch64_sve_prf">;
+def SVPRFD : MInst<"svprfd", "vPcJ", "l", [IsPrefetch], MemEltTyInt64, 
"aarch64_sve_prf">;
+
+// Prefetch (Scalar base, VL displacement)
+def SVPRFB_VNUM : MInst<"svprfb_vnum", "vPclJ", "c", [IsPrefetch], 
MemEltTyInt8,  "aarch64_sve_prf">;
+def SVPRFH_VNUM : MInst<"svprfh_vnum", "vPclJ", "s", [IsPrefetch], 
MemEltTyInt16, "aarch64_sve_prf">;
+def SVPRFW_VNUM : MInst<"svprfw_vnum", "vPclJ", "i", [IsPrefetch], 
MemEltTyInt32, "aarch64_sve_prf">;
+def SVPRFD_VNUM : MIns

[PATCH] D78521: [clangd] Extend dexp to support remote index

2020-04-24 Thread Sam McCall via Phabricator via cfe-commits

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

LG, nits apart from the llvm_unreachable in unimplemented, let's discuss 
further if you disagree on that.

We do have to go back and add unit tests for this stuff. I'm OK with doing that 
once the marshalling is sorted out (not YAML), but we should make sure we 
remember!

Comment at: clang-tools-extra/clangd/index/YAMLSerialization.cpp:437
+  if (YAMLInput.error())
+return llvm::None;
+  YAMLInput >> Deserialized;

we should still log (or at least vlog)

(Actually personally I'd return Expected here and then log and drop to optional 
in Marshalling, but it doesn't matter)

Comment at: clang-tools-extra/clangd/index/dex/dexp/CMakeLists.txt:2
 include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../../../)
+# Include Features.inc
+include_directories(${CMAKE_CURRENT_BINARY_DIR}/../../../)

This comment is likely to get stale. I'd drop it: if we're including the clangd 
source dir, also including the clangd binary dir is appropriate and doesn't 
really require an explanation.

Comment at: clang-tools-extra/clangd/index/dex/dexp/Dexp.cpp:32
+llvm::cl::opt
+IndexLocation(llvm::cl::desc(""),
+  llvm::cl::Positional);

Dex -> index file
(dex is the in-memory implementation, not the data format)

Comment at: clang-tools-extra/clangd/index/dex/dexp/Dexp.cpp:44

+You can connect to remote index by passing remote:address to dex. Example:
+

dex -> dexp (and in the example command)

Comment at: clang-tools-extra/clangd/index/dex/dexp/Dexp.cpp:280
 std::unique_ptr openIndex(llvm::StringRef Index) {
+#ifdef CLANGD_ENABLE_REMOTE
+  return Index.startswith("remote:")

no longer needs to be ifdef'd: if the user passes remote:foo and it's not 
compiled in, they'll get an appropriate error

Comment at: clang-tools-extra/clangd/index/remote/CMakeLists.txt:26
+else()
+  add_subdirectory(unimplemented)
+endif()

Maybe "# provides a dummy implementation of clangdRemoteIndex"

Comment at: clang-tools-extra/clangd/index/remote/Client.cpp:47
+if (!Sym)
+  elog("YAML parsing error: {0}", Sym.takeError());
+Callback(*Sym);

nit: I'd suggest dropping "YAML" from this message so we don't forget later. 
Rather `"Received invalid {0}: {1}", ReplyT::descriptor()->name(), 
Sym.takeError()`

Comment at: clang-tools-extra/clangd/index/remote/Client.cpp:95
+std::unique_ptr getClient(llvm::StringRef Address) {
+  return std::unique_ptr(new IndexClient(Address));
+}

nit: for slightly cleaner separation, I'd suggest creating the channel here and 
passing it into the IndexClient constructor.

The channel is where various configuration (auth, etc) might live, and it's 
nice if the client class stays doesn't need to deal with that level of 
abstraction.
e.g. a test version that doesn't use the real network would pass in a different 
channel and the IndexClient wouldn't care. (Not sure if that's how testing is 
actually done in grpc these days, but you get the idea...)

Comment at: clang-tools-extra/clangd/index/remote/Client.cpp:29
+  bool streamRPC(ClangdRequestT Request,
+ std::function>(
+ remote::SymbolIndex::Stub *, grpc::ClientContext *,

whether this is a member pointer or a function wrapper, it should be in a 
typedef or readability.
e.g.
template 
using StreamingCall = std::function>>(Stub*, 
ClientContext*, const RspT&);

Comment at: clang-tools-extra/clangd/index/remote/Client.h:1
+//===--- Index.h -*- 
C++-*-===//
+//

Client.h - Connect to a remote index via gRPC

Comment at: clang-tools-extra/clangd/index/remote/Index.cpp:27
+llvm::StringRef SpanName, SymbolIndex::Stub *Stub, ClangdRequestT Request,
+std::function>(
+SymbolIndex::Stub *, grpc::ClientContext *, const RPCRequestT &)>

kbobyrev wrote:
> sammccall wrote:
> > Hmm, I think member pointers are totally the right thing here. And all the 
> > params should be deducible.
> > 
> > Have a look at https://godbolt.org/z/AnprJ- (simplified but self-contained 
> > and I think shows all the bits)
> > 
> > The thing I can't work out how to do is make the member pointer a template 
> > param *and* have it be deduced...
> Uh, I had the pointers but decided against it because of rather... bizarre 
> syntax :D
> 
> And yes, just like you said, the calls contained too many explicit template 
> parameters, so I decided the implementation should be more verbose than "user 
> code". I'm not against pointers, but I think the current version looks 
> simpler, WDYT?
There are advantages o

[PATCH] D78748: [SveEmitter] Add builtins for svld1rq

2020-04-24 Thread Sander de Smalen via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGdb7997472bbd: [SveEmitter] Add builtins for svld1rq 
(authored by sdesmalen).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78748

Files:
  clang/include/clang/Basic/arm_sve.td
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_ld1rq.c

Index: clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_ld1rq.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_ld1rq.c
@@ -0,0 +1,108 @@
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -S -O1 -Werror -Wall -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -DSVE_OVERLOADED_FORMS -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -S -O1 -Werror -Wall -emit-llvm -o - %s | FileCheck %s
+
+#include 
+
+#ifdef SVE_OVERLOADED_FORMS
+// A simple used,unused... macro, long enough to represent any SVE builtin.
+#define SVE_ACLE_FUNC(A1,A2_UNUSED,A3,A4_UNUSED) A1##A3
+#else
+#define SVE_ACLE_FUNC(A1,A2,A3,A4) A1##A2##A3##A4
+#endif
+
+svint8_t test_svld1rq_s8(svbool_t pg, const int8_t *base)
+{
+  // CHECK-LABEL: test_svld1rq_s8
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ld1rq.nxv16i8( %pg, i8* %base)
+  // CHECK: ret  %[[INTRINSIC]]
+  return SVE_ACLE_FUNC(svld1rq,_s8,,)(pg, base);
+}
+
+svint16_t test_svld1rq_s16(svbool_t pg, const int16_t *base)
+{
+  // CHECK-LABEL: test_svld1rq_s16
+  // CHECK: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv8i1( %pg)
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ld1rq.nxv8i16( %[[PG]], i16* %base)
+  // CHECK: ret  %[[INTRINSIC]]
+  return SVE_ACLE_FUNC(svld1rq,_s16,,)(pg, base);
+}
+
+svint32_t test_svld1rq_s32(svbool_t pg, const int32_t *base)
+{
+  // CHECK-LABEL: test_svld1rq_s32
+  // CHECK: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv4i1( %pg)
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ld1rq.nxv4i32( %[[PG]], i32* %base)
+  // CHECK: ret  %[[INTRINSIC]]
+  return SVE_ACLE_FUNC(svld1rq,_s32,,)(pg, base);
+}
+
+svint64_t test_svld1rq_s64(svbool_t pg, const int64_t *base)
+{
+  // CHECK-LABEL: test_svld1rq_s64
+  // CHECK: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv2i1( %pg)
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ld1rq.nxv2i64( %[[PG]], i64* %base)
+  // CHECK: ret  %[[INTRINSIC]]
+  return SVE_ACLE_FUNC(svld1rq,_s64,,)(pg, base);
+}
+
+svuint8_t test_svld1rq_u8(svbool_t pg, const uint8_t *base)
+{
+  // CHECK-LABEL: test_svld1rq_u8
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ld1rq.nxv16i8( %pg, i8* %base)
+  // CHECK: ret  %[[INTRINSIC]]
+  return SVE_ACLE_FUNC(svld1rq,_u8,,)(pg, base);
+}
+
+svuint16_t test_svld1rq_u16(svbool_t pg, const uint16_t *base)
+{
+  // CHECK-LABEL: test_svld1rq_u16
+  // CHECK: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv8i1( %pg)
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ld1rq.nxv8i16( %[[PG]], i16* %base)
+  // CHECK: ret  %[[INTRINSIC]]
+  return SVE_ACLE_FUNC(svld1rq,_u16,,)(pg, base);
+}
+
+svuint32_t test_svld1rq_u32(svbool_t pg, const uint32_t *base)
+{
+  // CHECK-LABEL: test_svld1rq_u32
+  // CHECK: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv4i1( %pg)
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ld1rq.nxv4i32( %[[PG]], i32* %base)
+  // CHECK: ret  %[[INTRINSIC]]
+  return SVE_ACLE_FUNC(svld1rq,_u32,,)(pg, base);
+}
+
+svuint64_t test_svld1rq_u64(svbool_t pg, const uint64_t *base)
+{
+  // CHECK-LABEL: test_svld1rq_u64
+  // CHECK: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv2i1( %pg)
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ld1rq.nxv2i64( %[[PG]], i64* %base)
+  // CHECK: ret  %[[INTRINSIC]]
+  return SVE_ACLE_FUNC(svld1rq,_u64,,)(pg, base);
+}
+
+svfloat16_t test_svld1rq_f16(svbool_t pg, const float16_t *base)
+{
+  // CHECK-LABEL: test_svld1rq_f16
+  // CHECK: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv8i1( %pg)
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ld1rq.nxv8f16( %[[PG]], half* %base)
+  // CHECK: ret  %[[INTRINSIC]]
+  return SVE_ACLE_FUNC(svld1rq,_f16,,)(pg, base);
+}
+
+svfloat32_t test_svld1rq_f32(svbool_t pg, const float32_t *base)
+{
+  // CHECK-LABEL: test_svld1rq_f32
+  // CHECK: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv4i1( %pg)
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ld1rq.nxv4f32( %[[PG]], float* %base)
+  // CHECK: ret  %[[INTRINSIC]]
+  return SVE_ACLE_FUNC(svld1rq,_f32,,)(pg, base);
+}
+
+svfloat64_t test_svld1rq_f64(svbool_t pg, const float64_t *base)
+{
+  // CHECK-LABEL: test_svld1rq_f64
+  // CHECK: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv2i1( %pg)
+  // CHECK: %[[INTRINSIC:.*]] = call

[PATCH] D78569: [SVE][CodeGen] Lower SDIV & UDIV to SVE intrinsics

2020-04-24 Thread Kerry McLaughlin via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
kmclaughlin marked an inline comment as done.
Closed by commit rG53dd72a87aeb: [SVE][CodeGen] Lower SDIV & UDIV to SVE 
intrinsics (authored by kmclaughlin).

Changed prior to commit:
  https://reviews.llvm.org/D78569?vs=259610&id=259852#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78569

Files:
  llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
  llvm/lib/Target/AArch64/AArch64ISelLowering.h
  llvm/lib/Target/AArch64/AArch64SVEInstrInfo.td
  llvm/test/CodeGen/AArch64/llvm-ir-to-intrinsic.ll

Index: llvm/test/CodeGen/AArch64/llvm-ir-to-intrinsic.ll
===
--- /dev/null
+++ llvm/test/CodeGen/AArch64/llvm-ir-to-intrinsic.ll
@@ -0,0 +1,45 @@
+; RUN: llc -mtriple=aarch64-linux-gnu -mattr=+sve < %s | FileCheck %s
+
+;
+; SDIV
+;
+
+define  @sdiv_i32( %a,  %b) {
+; CHECK-LABEL: @sdiv_i32
+; CHECK-DAG: ptrue p0.s
+; CHECK-DAG: sdiv z0.s, p0/m, z0.s, z1.s
+; CHECK-NEXT: ret
+  %div = sdiv  %a, %b
+  ret  %div
+}
+
+define  @sdiv_i64( %a,  %b) {
+; CHECK-LABEL: @sdiv_i64
+; CHECK-DAG: ptrue p0.d
+; CHECK-DAG: sdiv z0.d, p0/m, z0.d, z1.d
+; CHECK-NEXT: ret
+  %div = sdiv  %a, %b
+  ret  %div
+}
+
+;
+; UDIV
+;
+
+define  @udiv_i32( %a,  %b) {
+; CHECK-LABEL: @udiv_i32
+; CHECK-DAG: ptrue p0.s
+; CHECK-DAG: udiv z0.s, p0/m, z0.s, z1.s
+; CHECK-NEXT: ret
+  %div = udiv  %a, %b
+  ret  %div
+}
+
+define  @udiv_i64( %a,  %b) {
+; CHECK-LABEL: @udiv_i64
+; CHECK-DAG: ptrue p0.d
+; CHECK-DAG: udiv z0.d, p0/m, z0.d, z1.d
+; CHECK-NEXT: ret
+  %div = udiv  %a, %b
+  ret  %div
+}
Index: llvm/lib/Target/AArch64/AArch64SVEInstrInfo.td
===
--- llvm/lib/Target/AArch64/AArch64SVEInstrInfo.td
+++ llvm/lib/Target/AArch64/AArch64SVEInstrInfo.td
@@ -145,6 +145,14 @@
 def AArch64lasta   :  SDNode<"AArch64ISD::LASTA", SDT_AArch64Reduce>;
 def AArch64lastb   :  SDNode<"AArch64ISD::LASTB", SDT_AArch64Reduce>;
 
+def SDT_AArch64DIV : SDTypeProfile<1, 3, [
+  SDTCisVec<0>, SDTCisVec<1>, SDTCisVec<2>, SDTCisVec<3>,
+  SDTCVecEltisVT<1,i1>, SDTCisSameAs<2,3>
+]>;
+
+def AArch64sdiv_pred  :  SDNode<"AArch64ISD::SDIV_PRED", SDT_AArch64DIV>;
+def AArch64udiv_pred  :  SDNode<"AArch64ISD::UDIV_PRED", SDT_AArch64DIV>;
+
 def SDT_AArch64ReduceWithInit : SDTypeProfile<1, 3, [SDTCisVec<1>, SDTCisVec<3>]>;
 def AArch64clasta_n   : SDNode<"AArch64ISD::CLASTA_N",   SDT_AArch64ReduceWithInit>;
 def AArch64clastb_n   : SDNode<"AArch64ISD::CLASTB_N",   SDT_AArch64ReduceWithInit>;
@@ -239,8 +247,8 @@
   def : Pat<(mul nxv2i64:$Op1, nxv2i64:$Op2),
 (MUL_ZPmZ_D (PTRUE_D 31), $Op1, $Op2)>;
 
-  defm SDIV_ZPmZ  : sve_int_bin_pred_arit_2_div<0b100, "sdiv", int_aarch64_sve_sdiv>;
-  defm UDIV_ZPmZ  : sve_int_bin_pred_arit_2_div<0b101, "udiv", int_aarch64_sve_udiv>;
+  defm SDIV_ZPmZ  : sve_int_bin_pred_arit_2_div<0b100, "sdiv",  AArch64sdiv_pred>;
+  defm UDIV_ZPmZ  : sve_int_bin_pred_arit_2_div<0b101, "udiv",  AArch64udiv_pred>;
   defm SDIVR_ZPmZ : sve_int_bin_pred_arit_2_div<0b110, "sdivr", int_aarch64_sve_sdivr>;
   defm UDIVR_ZPmZ : sve_int_bin_pred_arit_2_div<0b111, "udivr", int_aarch64_sve_udivr>;
 
Index: llvm/lib/Target/AArch64/AArch64ISelLowering.h
===
--- llvm/lib/Target/AArch64/AArch64ISelLowering.h
+++ llvm/lib/Target/AArch64/AArch64ISelLowering.h
@@ -52,6 +52,10 @@
   ADC,
   SBC, // adc, sbc instructions
 
+  // Arithmetic instructions
+  SDIV_PRED,
+  UDIV_PRED,
+
   // Arithmetic instructions which write flags.
   ADDS,
   SUBS,
@@ -781,6 +785,8 @@
   SDValue LowerVECTOR_SHUFFLE(SDValue Op, SelectionDAG &DAG) const;
   SDValue LowerSPLAT_VECTOR(SDValue Op, SelectionDAG &DAG) const;
   SDValue LowerDUPQLane(SDValue Op, SelectionDAG &DAG) const;
+  SDValue LowerDIV(SDValue Op, SelectionDAG &DAG,
+   unsigned NewOp) const;
   SDValue LowerEXTRACT_SUBVECTOR(SDValue Op, SelectionDAG &DAG) const;
   SDValue LowerVectorSRA_SRL_SHL(SDValue Op, SelectionDAG &DAG) const;
   SDValue LowerShiftLeftParts(SDValue Op, SelectionDAG &DAG) const;
Index: llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
===
--- llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
+++ llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
@@ -883,8 +883,11 @@
 // splat of 0 or undef) once vector selects supported in SVE codegen. See
 // D68877 for more details.
 for (MVT VT : MVT::integer_scalable_vector_valuetypes()) {
-  if (isTypeLegal(VT))
+  if (isTypeLegal(VT)) {
 setOperationAction(ISD::SPLAT_VECTOR, VT, Custom);
+setOperationAction(ISD::SDIV, VT, Custom);
+setOperationAction(ISD::UDIV, VT, Custom);
+  }
 }
 setOperationAction(ISD::INTRINSIC_WO_CHAIN, MVT::i8, Custom

[PATCH] D78674: [SveEmitter] Add builtins for contiguous prefetches

2020-04-24 Thread Sander de Smalen via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG823e2a670a9d: [SveEmitter] Add builtins for contiguous 
prefetches (authored by sdesmalen).

Changed prior to commit:
  https://reviews.llvm.org/D78674?vs=259587&id=259851#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78674

Files:
  clang/include/clang/Basic/TargetBuiltins.h
  clang/include/clang/Basic/arm_sve.td
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfb.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfd.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfh.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfw.c
  clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_prfb.c
  clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_prfd.c
  clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_prfh.c
  clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_prfw.c
  clang/utils/TableGen/SveEmitter.cpp

Index: clang/utils/TableGen/SveEmitter.cpp
===
--- clang/utils/TableGen/SveEmitter.cpp
+++ clang/utils/TableGen/SveEmitter.cpp
@@ -536,6 +536,15 @@
 Immediate = true;
 PredicatePattern = true;
 break;
+  case 'J':
+Predicate = false;
+Float = false;
+ElementBitwidth = Bitwidth = 32;
+NumVectors = 0;
+Signed = true;
+Immediate = true;
+PrefetchOp = true;
+break;
   case 'k':
 Predicate = false;
 Signed = true;
@@ -703,6 +712,9 @@
   if (T.isPredicatePattern())
 ImmChecks.emplace_back(
 I - 1, Emitter.getEnumValueForImmCheck("ImmCheck0_31"));
+  else if (T.isPrefetchOp())
+ImmChecks.emplace_back(
+I - 1, Emitter.getEnumValueForImmCheck("ImmCheck0_13"));
 }
   }
 
@@ -1005,6 +1017,22 @@
   OS << "  SV_ALL = 31\n";
   OS << "} sv_pattern;\n\n";
 
+  OS << "typedef enum\n";
+  OS << "{\n";
+  OS << "  SV_PLDL1KEEP = 0,\n";
+  OS << "  SV_PLDL1STRM = 1,\n";
+  OS << "  SV_PLDL2KEEP = 2,\n";
+  OS << "  SV_PLDL2STRM = 3,\n";
+  OS << "  SV_PLDL3KEEP = 4,\n";
+  OS << "  SV_PLDL3STRM = 5,\n";
+  OS << "  SV_PSTL1KEEP = 8,\n";
+  OS << "  SV_PSTL1STRM = 9,\n";
+  OS << "  SV_PSTL2KEEP = 10,\n";
+  OS << "  SV_PSTL2STRM = 11,\n";
+  OS << "  SV_PSTL3KEEP = 12,\n";
+  OS << "  SV_PSTL3STRM = 13\n";
+  OS << "} sv_prfop;\n\n";
+
   OS << "/* Function attributes */\n";
   OS << "#define __aio static inline __attribute__((__always_inline__, "
 "__nodebug__, __overloadable__))\n\n";
Index: clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_prfw.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_prfw.c
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -fsyntax-only -verify %s
+
+#include 
+
+void test_svprfw(svbool_t pg, const void *base)
+{
+  // expected-error@+1 {{argument value 14 is outside the valid range [0, 13]}}
+  return svprfw(pg, base, 14);
+}
+
+void test_svprfw_1(svbool_t pg, const void *base)
+{
+  // expected-error@+1 {{argument value -1 is outside the valid range [0, 13]}}
+  return svprfw(pg, base, -1);
+}
+
+void test_svprfw_vnum(svbool_t pg, const void *base)
+{
+  // expected-error@+1 {{argument value 14 is outside the valid range [0, 13]}}
+  return svprfw_vnum(pg, base, 0, 14);
+}
+
+void test_svprfw_vnum_1(svbool_t pg, const void *base)
+{
+  // expected-error@+1 {{argument value -1 is outside the valid range [0, 13]}}
+  return svprfw_vnum(pg, base, 0, -1);
+}
Index: clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_prfh.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_prfh.c
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -fsyntax-only -verify %s
+
+#include 
+
+void test_svprfh(svbool_t pg, const void *base)
+{
+  // expected-error@+1 {{argument value 14 is outside the valid range [0, 13]}}
+  return svprfh(pg, base, 14);
+}
+
+void test_svprfh_1(svbool_t pg, const void *base)
+{
+  // expected-error@+1 {{argument value -1 is outside the valid range [0, 13]}}
+  return svprfh(pg, base, -1);
+}
+
+void test_svprfh_vnum(svbool_t pg, const void *base)
+{
+  // expected-error@+1 {{argument value 14 is outside the valid range [0, 13]}}
+  return svprfh_vnum(pg, base, 0, 14);
+}
+
+void test_svprfh_vnum_1(svbool_t pg, const void *base)
+{
+  // expected-error@+1 {{argument value -1 is outside the valid range [0, 13]}}
+  return svprfh_vnum(pg, base, 0, -1);
+}
Index: clang/test/CodeGen/aarch64-

[PATCH] D78569: [SVE][CodeGen] Lower SDIV & UDIV to SVE intrinsics

2020-04-24 Thread Kerry McLaughlin via Phabricator via cfe-commits

kmclaughlin added a comment.

Thank you both for your comments on this patch, @efriedma & @sdesmalen!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78569



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

[PATCH] D78477: [profile] Don't crash when forking in several threads

2020-04-24 Thread calixte via Phabricator via cfe-commits

calixte updated this revision to Diff 259854.
calixte added a comment.

Fix nits.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78477

Files:
  clang/lib/Driver/ToolChains/Darwin.cpp
  compiler-rt/lib/profile/GCDAProfiling.c
  compiler-rt/test/profile/Inputs/instrprof-gcov-multithread_fork.cpp
  compiler-rt/test/profile/instrprof-gcov-multithread_fork.test
  llvm/lib/Transforms/Instrumentation/GCOVProfiling.cpp

Index: llvm/lib/Transforms/Instrumentation/GCOVProfiling.cpp
===
--- llvm/lib/Transforms/Instrumentation/GCOVProfiling.cpp
+++ llvm/lib/Transforms/Instrumentation/GCOVProfiling.cpp
@@ -115,7 +115,8 @@
   // list.
   Function *
   insertCounterWriteout(ArrayRef>);
-  Function *insertFlush(ArrayRef>);
+  Function *insertReset(ArrayRef>);
+  Function *insertFlush(Function *ResetF);
 
   void AddFlushBeforeForkAndExec();
 
@@ -631,35 +632,76 @@
 }
 
 void GCOVProfiler::AddFlushBeforeForkAndExec() {
-  SmallVector ForkAndExecs;
+  SmallVector Forks;
+  SmallVector Execs;
   for (auto &F : M->functions()) {
 auto *TLI = &GetTLI(F);
 for (auto &I : instructions(F)) {
   if (CallInst *CI = dyn_cast(&I)) {
 if (Function *Callee = CI->getCalledFunction()) {
   LibFunc LF;
-  if (TLI->getLibFunc(*Callee, LF) &&
-  (LF == LibFunc_fork || LF == LibFunc_execl ||
-   LF == LibFunc_execle || LF == LibFunc_execlp ||
-   LF == LibFunc_execv || LF == LibFunc_execvp ||
-   LF == LibFunc_execve || LF == LibFunc_execvpe ||
-   LF == LibFunc_execvP)) {
-ForkAndExecs.push_back(&I);
+  if (TLI->getLibFunc(*Callee, LF)) {
+if (LF == LibFunc_fork) {
+#if !defined(_WIN32)
+  Forks.push_back(CI);
+#endif
+} else if (LF == LibFunc_execl || LF == LibFunc_execle ||
+   LF == LibFunc_execlp || LF == LibFunc_execv ||
+   LF == LibFunc_execvp || LF == LibFunc_execve ||
+   LF == LibFunc_execvpe || LF == LibFunc_execvP) {
+  Execs.push_back(CI);
+}
   }
 }
   }
 }
   }
 
-  // We need to split the block after the fork/exec call
-  // because else the counters for the lines after will be
-  // the same as before the call.
-  for (auto I : ForkAndExecs) {
-IRBuilder<> Builder(I);
+  for (auto F : Forks) {
+IRBuilder<> Builder(F);
+BasicBlock *Parent = F->getParent();
+auto NextInst = ++F->getIterator();
+
+// We've a fork so just reset the counters in the child process
+FunctionType *FTy = FunctionType::get(Builder.getInt32Ty(), {}, false);
+FunctionCallee GCOVFork = M->getOrInsertFunction("__gcov_fork", FTy);
+F->setCalledFunction(GCOVFork);
+
+// We split just after the fork to have a counter for the lines after
+// Anyway there's a bug:
+// void foo() { fork(); }
+// void bar() { foo(); blah(); }
+// then "blah();" will be called 2 times but showed as 1
+// because "blah()" belongs to the same block as "foo();"
+Parent->splitBasicBlock(NextInst);
+
+// back() is a br instruction with a debug location
+// equals to the one from NextAfterFork
+// So to avoid to have two debug locs on two blocks just change it
+DebugLoc Loc = F->getDebugLoc();
+Parent->back().setDebugLoc(Loc);
+  }
+
+  for (auto E : Execs) {
+IRBuilder<> Builder(E);
+BasicBlock *Parent = E->getParent();
+auto NextInst = ++E->getIterator();
+
+// Since the process is replaced by a new one we need to write out gcdas
+// No need to reset the counters since they'll be lost after the exec**
 FunctionType *FTy = FunctionType::get(Builder.getVoidTy(), {}, false);
-FunctionCallee GCOVFlush = M->getOrInsertFunction("__gcov_flush", FTy);
-Builder.CreateCall(GCOVFlush);
-I->getParent()->splitBasicBlock(I);
+FunctionCallee WriteoutF =
+M->getOrInsertFunction("llvm_writeout_files", FTy);
+Builder.CreateCall(WriteoutF);
+
+DebugLoc Loc = E->getDebugLoc();
+Builder.SetInsertPoint(&*NextInst);
+// If the exec** fails we must reset the counters since they've been
+// dumped
+FunctionCallee ResetF = M->getOrInsertFunction("llvm_reset_counters", FTy);
+Builder.CreateCall(ResetF)->setDebugLoc(Loc);
+Parent->splitBasicBlock(NextInst);
+Parent->back().setDebugLoc(Loc);
   }
 }
 
@@ -851,7 +893,8 @@
 }
 
 Function *WriteoutF = insertCounterWriteout(CountersBySP);
-Function *FlushF = insertFlush(CountersBySP);
+Function *ResetF = insertReset(CountersBySP);
+Function *FlushF = insertFlush(ResetF);
 
 // Create a small bit of code that registers the "__llvm_gcov_writeout" to
 // be executed at exit and the "__llvm_gcov_flush" function to be executed
@@ -869,16 +912,14 @@
 IRBuilder<> Builder(BB);

[PATCH] D78648: [CMake] Bump CMake minimum version to 3.13.4

2020-04-24 Thread Shoaib Meenai via Phabricator via cfe-commits

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

With the newer minimum CMake version, we can eliminate a bunch of the policy 
settings as well, but that can be a follow-up (especially given this isn't 
gonna ship for a few months).

(Another followup would be to add a `max` version to our 
`cmake_minimum_required`, to streamline policy settings even further. See 
https://cmake.org/cmake/help/latest/command/cmake_policy.html for details.)




Comment at: llvm/docs/CMakePrimer.rst:57
 
-   cmake_minimum_required(VERSION 3.2)
+   cmake_minimum_required(VERSION 3.15)
project(HelloWorld)

Is the higher minimum here for future-proofing?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78648



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

[PATCH] D77809: [Analyzer] Include typedef statements in CFG build.

2020-04-24 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added inline comments.



Comment at: clang/lib/Analysis/CFG.cpp:2855
+ VA = FindVA(VA->getElementType().getTypePtr())) {
+  if (CFGBlock *newBlock = addStmt(VA->getSizeExpr()))
+LastBlock = newBlock;

balazske wrote:
> aaron.ballman wrote:
> > newBlock -> NewBlock per coding standard.
> Another thing is to follow the style of the source code. In the same function 
> `newBlock` is used at other places, it would look even worse (or not?) to 
> change just that single new occurrence to `NewBlock`.
I don't insist on the change, but when the local code is already inconsistent 
with its naming conventions like this is, I think new code should follow the 
coding standard unless there's a strong reason to deviate. This way, over time, 
the file converges more and more on following the coding standard instead of 
getting more and more inconsistent.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77809



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

[PATCH] D75453: [Driver][ARM] fix undefined behaviour when checking architecture version

2020-04-24 Thread Jan Ole Hüser via Phabricator via cfe-commits

j0le added a comment.

I would like to ask, whether I could "Accept the Revision" myself, or is this 
only allowed to be done by code owners or other reviewers?
And when the revision is accepted, do I have to commit this, or can this only 
be done by people who have commit access or is this done automatically?

Many thanks in advance,
Ole


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

https://reviews.llvm.org/D75453



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

[PATCH] D78521: [clangd] Extend dexp to support remote index

2020-04-24 Thread Kirill Bobyrev via Phabricator via cfe-commits

kbobyrev updated this revision to Diff 259859.
kbobyrev marked 16 inline comments as done.
kbobyrev added a comment.

Address the last round of comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78521

Files:
  clang-tools-extra/clangd/CMakeLists.txt
  clang-tools-extra/clangd/Features.inc.in
  clang-tools-extra/clangd/index/Serialization.h
  clang-tools-extra/clangd/index/YAMLSerialization.cpp
  clang-tools-extra/clangd/index/dex/dexp/CMakeLists.txt
  clang-tools-extra/clangd/index/dex/dexp/Dexp.cpp
  clang-tools-extra/clangd/index/remote/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/Client.cpp
  clang-tools-extra/clangd/index/remote/Client.h
  clang-tools-extra/clangd/index/remote/Index.proto
  clang-tools-extra/clangd/index/remote/client/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/client/Client.cpp
  clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/marshalling/Marshalling.cpp
  clang-tools-extra/clangd/index/remote/marshalling/Marshalling.h
  clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/server/Server.cpp
  clang-tools-extra/clangd/index/remote/unimplemented/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/unimplemented/UnimplementedClient.cpp

Index: clang-tools-extra/clangd/index/remote/unimplemented/UnimplementedClient.cpp
===
--- /dev/null
+++ clang-tools-extra/clangd/index/remote/unimplemented/UnimplementedClient.cpp
@@ -0,0 +1,23 @@
+//===--- UnimplementedClient.cpp -*- 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
+//
+//===--===//
+
+#include "Logger.h"
+#include "index/remote/Client.h"
+
+namespace clang {
+namespace clangd {
+namespace remote {
+
+std::unique_ptr getClient(llvm::StringRef Address) {
+  elog("Can't create SymbolIndex client without Remote Index support.");
+  return nullptr;
+}
+
+} // namespace remote
+} // namespace clangd
+} // namespace clang
Index: clang-tools-extra/clangd/index/remote/unimplemented/CMakeLists.txt
===
--- /dev/null
+++ clang-tools-extra/clangd/index/remote/unimplemented/CMakeLists.txt
@@ -0,0 +1,10 @@
+include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../../../)
+# When compiled without Remote Index support, the real implementation index
+# client is not present. Users will get a notification about this when trying
+# to connect to remote index server instance.
+add_clang_library(clangdRemoteIndex
+  UnimplementedClient.cpp
+
+  LINK_LIBS
+  clangDaemon
+  )
Index: clang-tools-extra/clangd/index/remote/server/Server.cpp
===
--- clang-tools-extra/clangd/index/remote/server/Server.cpp
+++ clang-tools-extra/clangd/index/remote/server/Server.cpp
@@ -8,6 +8,7 @@
 
 #include "index/Index.h"
 #include "index/Serialization.h"
+#include "index/remote/marshalling/Marshalling.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/LineEditor/LineEditor.h"
@@ -16,13 +17,14 @@
 #include "llvm/Support/Path.h"
 #include "llvm/Support/Signals.h"
 
-#include "grpcpp/grpcpp.h"
-#include "grpcpp/health_check_service_interface.h"
+#include 
+#include 
 
 #include "Index.grpc.pb.h"
 
 namespace clang {
 namespace clangd {
+namespace remote {
 namespace {
 
 static const std::string Overview = R"(
@@ -33,42 +35,80 @@
 llvm::cl::opt IndexPath(llvm::cl::desc(""),
  llvm::cl::Positional, llvm::cl::Required);
 
-llvm::cl::opt ServerAddress("server-address",
- llvm::cl::init("0.0.0.0:50051"));
+llvm::cl::opt ServerAddress(
+"server-address", llvm::cl::init("0.0.0.0:50051"),
+llvm::cl::desc("Address of the invoked server. Defaults to 0.0.0.0:50051"));
 
-std::unique_ptr openIndex(llvm::StringRef Index) {
+std::unique_ptr openIndex(llvm::StringRef Index) {
   return loadIndex(Index, /*UseIndex=*/true);
 }
 
-class RemoteIndexServer final : public remote::Index::Service {
+class RemoteIndexServer final : public SymbolIndex::Service {
 public:
-  RemoteIndexServer(std::unique_ptr Index)
+  RemoteIndexServer(std::unique_ptr Index)
   : Index(std::move(Index)) {}
 
 private:
   grpc::Status Lookup(grpc::ServerContext *Context,
-  const remote::LookupRequest *Request,
-  grpc::ServerWriter *Reply) override {
-llvm::outs() << "Lookup of symbol with ID " << Request->id() << '\n';
-LookupRequest Req;
-auto SID = SymbolID::fromStr(Request->id());
-

[clang-tools-extra] 67b2dbd - [clangd] Extend dexp to support remote index

2020-04-24 Thread Kirill Bobyrev via cfe-commits


Author: Kirill Bobyrev
Date: 2020-04-24T13:59:21+02:00
New Revision: 67b2dbd5a33583fe148fd12f141e15301cfe99d1

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

LOG: [clangd] Extend dexp to support remote index

Summary:
* Merge clangd-remote-client into dexp
* Implement `clangd::remote::IndexClient` that is derived from `SymbolIndex`
* Upgrade remote mode-related CMake infrastructure

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: mgorny, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, 
usaxena95, cfe-commits

Tags: #clang

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

Added: 
clang-tools-extra/clangd/index/remote/Client.cpp
clang-tools-extra/clangd/index/remote/Client.h
clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
clang-tools-extra/clangd/index/remote/marshalling/Marshalling.cpp
clang-tools-extra/clangd/index/remote/marshalling/Marshalling.h
clang-tools-extra/clangd/index/remote/unimplemented/CMakeLists.txt
clang-tools-extra/clangd/index/remote/unimplemented/UnimplementedClient.cpp

Modified: 
clang-tools-extra/clangd/CMakeLists.txt
clang-tools-extra/clangd/Features.inc.in
clang-tools-extra/clangd/index/Serialization.h
clang-tools-extra/clangd/index/YAMLSerialization.cpp
clang-tools-extra/clangd/index/dex/dexp/CMakeLists.txt
clang-tools-extra/clangd/index/dex/dexp/Dexp.cpp
clang-tools-extra/clangd/index/remote/CMakeLists.txt
clang-tools-extra/clangd/index/remote/Index.proto
clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
clang-tools-extra/clangd/index/remote/server/Server.cpp

Removed: 
clang-tools-extra/clangd/index/remote/client/CMakeLists.txt
clang-tools-extra/clangd/index/remote/client/Client.cpp



diff  --git a/clang-tools-extra/clangd/CMakeLists.txt 
b/clang-tools-extra/clangd/CMakeLists.txt
index 1c2cbf398b77..124f087589d6 100644
--- a/clang-tools-extra/clangd/CMakeLists.txt
+++ b/clang-tools-extra/clangd/CMakeLists.txt
@@ -140,7 +140,6 @@ if (${CMAKE_SYSTEM_NAME} STREQUAL "Linux")
 endif()
 add_subdirectory(tool)
 add_subdirectory(indexer)
-add_subdirectory(index/dex/dexp)
 
 if (LLVM_INCLUDE_BENCHMARKS)
   add_subdirectory(benchmarks)
@@ -160,5 +159,6 @@ set(GRPC_INSTALL_PATH "" CACHE PATH "Path to gRPC library 
manual installation.")
 
 if (CLANGD_ENABLE_REMOTE)
   include(FindGRPC)
-  add_subdirectory(index/remote)
 endif()
+add_subdirectory(index/remote)
+add_subdirectory(index/dex/dexp)

diff  --git a/clang-tools-extra/clangd/Features.inc.in 
b/clang-tools-extra/clangd/Features.inc.in
index da75aa67a65b..6797232ddac7 100644
--- a/clang-tools-extra/clangd/Features.inc.in
+++ b/clang-tools-extra/clangd/Features.inc.in
@@ -1 +1,2 @@
 #define CLANGD_BUILD_XPC @CLANGD_BUILD_XPC@
+#define CLANGD_ENABLE_REMOTE @CLANGD_ENABLE_REMOTE@

diff  --git a/clang-tools-extra/clangd/index/Serialization.h 
b/clang-tools-extra/clangd/index/Serialization.h
index 47317c0401fc..99510630f1ca 100644
--- a/clang-tools-extra/clangd/index/Serialization.h
+++ b/clang-tools-extra/clangd/index/Serialization.h
@@ -77,6 +77,13 @@ llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, const 
IndexFileOut &O);
 std::string toYAML(const Symbol &);
 std::string toYAML(const std::pair> &);
 std::string toYAML(const Relation &);
+std::string toYAML(const Ref &);
+
+// Deserialize a single symbol from YAML.
+llvm::Expected symbolFromYAML(StringRef YAML,
+  llvm::UniqueStringSaver 
*Strings);
+llvm::Expected refFromYAML(StringRef YAML,
+llvm::UniqueStringSaver *Strings);
 
 // Build an in-memory static index from an index file.
 // The size should be relatively small, so data can be managed in memory.

diff  --git a/clang-tools-extra/clangd/index/YAMLSerialization.cpp 
b/clang-tools-extra/clangd/index/YAMLSerialization.cpp
index 79965ceb1634..fc515a17d100 100644
--- a/clang-tools-extra/clangd/index/YAMLSerialization.cpp
+++ b/clang-tools-extra/clangd/index/YAMLSerialization.cpp
@@ -517,5 +517,40 @@ std::string toYAML(const Relation &R) {
   return Buf;
 }
 
+std::string toYAML(const Ref &R) {
+  std::string Buf;
+  {
+llvm::raw_string_ostream OS(Buf);
+llvm::yaml::Output Yout(OS);
+Ref Reference = R; // copy: Yout<< requires mutability.
+Yout << Reference;
+  }
+  return Buf;
+}
+
+llvm::Expected
+symbolFromYAML(StringRef YAML, llvm::UniqueStringSaver *Strings) {
+  clangd::Symbol Deserialized;
+  llvm::yaml::Input YAMLInput(YAML, Strings);
+  if (YAMLInput.error())
+return llvm::make_error(
+llvm::formatv("Unable to deserialize Symbol from YAML: {0}", YAML),
+llvm::inconvertibleErrorCode());
+  YAMLInput >> Deserialized;
+  return Deserialized;
+}
+
+llvm::Expected

[PATCH] D78521: [clangd] Extend dexp to support remote index

2020-04-24 Thread Sam McCall via Phabricator via cfe-commits

sammccall accepted this revision.
sammccall added inline comments.



Comment at: clang-tools-extra/clangd/index/remote/Client.cpp:64
+  llvm::function_ref Callback) const 
{
+streamRPC(
+Request, &remote::SymbolIndex::Stub::Lookup, Callback);

nit: LookupRequest and LookupReply should be deducible now I think


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78521



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

[PATCH] D78521: [clangd] Extend dexp to support remote index

2020-04-24 Thread Kirill Bobyrev via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG67b2dbd5a335: [clangd] Extend dexp to support remote index 
(authored by kbobyrev).

Changed prior to commit:
  https://reviews.llvm.org/D78521?vs=259859&id=259869#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78521

Files:
  clang-tools-extra/clangd/CMakeLists.txt
  clang-tools-extra/clangd/Features.inc.in
  clang-tools-extra/clangd/index/Serialization.h
  clang-tools-extra/clangd/index/YAMLSerialization.cpp
  clang-tools-extra/clangd/index/dex/dexp/CMakeLists.txt
  clang-tools-extra/clangd/index/dex/dexp/Dexp.cpp
  clang-tools-extra/clangd/index/remote/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/Client.cpp
  clang-tools-extra/clangd/index/remote/Client.h
  clang-tools-extra/clangd/index/remote/Index.proto
  clang-tools-extra/clangd/index/remote/client/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/client/Client.cpp
  clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/marshalling/Marshalling.cpp
  clang-tools-extra/clangd/index/remote/marshalling/Marshalling.h
  clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/server/Server.cpp
  clang-tools-extra/clangd/index/remote/unimplemented/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/unimplemented/UnimplementedClient.cpp

Index: clang-tools-extra/clangd/index/remote/unimplemented/UnimplementedClient.cpp
===
--- /dev/null
+++ clang-tools-extra/clangd/index/remote/unimplemented/UnimplementedClient.cpp
@@ -0,0 +1,23 @@
+//===--- UnimplementedClient.cpp -*- 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
+//
+//===--===//
+
+#include "Logger.h"
+#include "index/remote/Client.h"
+
+namespace clang {
+namespace clangd {
+namespace remote {
+
+std::unique_ptr getClient(llvm::StringRef Address) {
+  elog("Can't create SymbolIndex client without Remote Index support.");
+  return nullptr;
+}
+
+} // namespace remote
+} // namespace clangd
+} // namespace clang
Index: clang-tools-extra/clangd/index/remote/unimplemented/CMakeLists.txt
===
--- /dev/null
+++ clang-tools-extra/clangd/index/remote/unimplemented/CMakeLists.txt
@@ -0,0 +1,10 @@
+include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../../../)
+# When compiled without Remote Index support, the real implementation index
+# client is not present. Users will get a notification about this when trying
+# to connect to remote index server instance.
+add_clang_library(clangdRemoteIndex
+  UnimplementedClient.cpp
+
+  LINK_LIBS
+  clangDaemon
+  )
Index: clang-tools-extra/clangd/index/remote/server/Server.cpp
===
--- clang-tools-extra/clangd/index/remote/server/Server.cpp
+++ clang-tools-extra/clangd/index/remote/server/Server.cpp
@@ -8,6 +8,7 @@
 
 #include "index/Index.h"
 #include "index/Serialization.h"
+#include "index/remote/marshalling/Marshalling.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/LineEditor/LineEditor.h"
@@ -16,13 +17,14 @@
 #include "llvm/Support/Path.h"
 #include "llvm/Support/Signals.h"
 
-#include "grpcpp/grpcpp.h"
-#include "grpcpp/health_check_service_interface.h"
+#include 
+#include 
 
 #include "Index.grpc.pb.h"
 
 namespace clang {
 namespace clangd {
+namespace remote {
 namespace {
 
 static const std::string Overview = R"(
@@ -33,42 +35,80 @@
 llvm::cl::opt IndexPath(llvm::cl::desc(""),
  llvm::cl::Positional, llvm::cl::Required);
 
-llvm::cl::opt ServerAddress("server-address",
- llvm::cl::init("0.0.0.0:50051"));
+llvm::cl::opt ServerAddress(
+"server-address", llvm::cl::init("0.0.0.0:50051"),
+llvm::cl::desc("Address of the invoked server. Defaults to 0.0.0.0:50051"));
 
-std::unique_ptr openIndex(llvm::StringRef Index) {
+std::unique_ptr openIndex(llvm::StringRef Index) {
   return loadIndex(Index, /*UseIndex=*/true);
 }
 
-class RemoteIndexServer final : public remote::Index::Service {
+class RemoteIndexServer final : public SymbolIndex::Service {
 public:
-  RemoteIndexServer(std::unique_ptr Index)
+  RemoteIndexServer(std::unique_ptr Index)
   : Index(std::move(Index)) {}
 
 private:
   grpc::Status Lookup(grpc::ServerContext *Context,
-  const remote::LookupRequest *Request,
-  grpc::ServerWriter *Reply) override {
-llvm::outs() << "Lookup of symbol with ID

[PATCH] D78807: Fix gendered documentation

2020-04-24 Thread Pedro Gonnet via Phabricator via cfe-commits

pedro.gonnet created this revision.
pedro.gonnet added reviewers: JDevlieghere, hokein.
Herald added projects: clang, LLDB.
Herald added subscribers: lldb-commits, cfe-commits.

Changed two references to developers as "he" or "him" to the more neutral 
"they".


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D78807

Files:
  
clang-tools-extra/docs/clang-tidy/checks/google-objc-global-variable-declaration.rst
  lldb/docs/use/variable.rst


Index: lldb/docs/use/variable.rst
===
--- lldb/docs/use/variable.rst
+++ lldb/docs/use/variable.rst
@@ -993,7 +993,7 @@
 user to see.
 
 A filter will solve this issue by only letting the user see those member
-variables he cares about. Of course, the equivalent of a filter can be
+variables they care about. Of course, the equivalent of a filter can be
 implemented easily using synthetic children, but a filter lets you get the job
 done without having to write Python code.
 
Index: 
clang-tools-extra/docs/clang-tidy/checks/google-objc-global-variable-declaration.rst
===
--- 
clang-tools-extra/docs/clang-tidy/checks/google-objc-global-variable-declaration.rst
+++ 
clang-tools-extra/docs/clang-tidy/checks/google-objc-global-variable-declaration.rst
@@ -44,4 +44,4 @@
   static NSString* __anotherString = @"world";
 
 The check will give a warning message but will not be able to suggest a fix. 
The
-user need to fix it on his own.
+user needs to fix it on their own.


Index: lldb/docs/use/variable.rst
===
--- lldb/docs/use/variable.rst
+++ lldb/docs/use/variable.rst
@@ -993,7 +993,7 @@
 user to see.
 
 A filter will solve this issue by only letting the user see those member
-variables he cares about. Of course, the equivalent of a filter can be
+variables they care about. Of course, the equivalent of a filter can be
 implemented easily using synthetic children, but a filter lets you get the job
 done without having to write Python code.
 
Index: clang-tools-extra/docs/clang-tidy/checks/google-objc-global-variable-declaration.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/google-objc-global-variable-declaration.rst
+++ clang-tools-extra/docs/clang-tidy/checks/google-objc-global-variable-declaration.rst
@@ -44,4 +44,4 @@
   static NSString* __anotherString = @"world";
 
 The check will give a warning message but will not be able to suggest a fix. The
-user need to fix it on his own.
+user needs to fix it on their own.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D77954: [CUDA][HIP] Fix host/device based overload resolution

2020-04-24 Thread Yaxun Liu via Phabricator via cfe-commits

yaxunl marked 6 inline comments as done.
yaxunl added inline comments.



Comment at: clang/lib/Sema/SemaOverload.cpp:9749
+  if (isBetterMultiversionCandidate(Cand1, Cand2))
+return true;
+

rjmccall wrote:
> tra wrote:
> > rjmccall wrote:
> > > erichkeane wrote:
> > > > yaxunl wrote:
> > > > > echristo wrote:
> > > > > > rjmccall wrote:
> > > > > > > yaxunl wrote:
> > > > > > > > rjmccall wrote:
> > > > > > > > > If we move anything below this check, it needs to figure out 
> > > > > > > > > a tri-state so that it can return false if `Cand2` is a 
> > > > > > > > > better candidate than `Cand1`.  Now, that only matters if 
> > > > > > > > > multiversion functions are supported under CUDA, but if 
> > > > > > > > > you're relying on them not being supported, that should at 
> > > > > > > > > least be commented on.
> > > > > > > > multiversion host functions is orthogonal to CUDA therefore 
> > > > > > > > should be supported. multiversion in device, host device, and 
> > > > > > > > global functions are not supported. However this change does 
> > > > > > > > not make things worse, and should continue to work if they are 
> > > > > > > > supported.
> > > > > > > > 
> > > > > > > > host/device based overloading resolution is mostly for 
> > > > > > > > determining viability of a function. If two functions are both 
> > > > > > > > viable, other factors should take precedence in preference. 
> > > > > > > > This general rule has been taken for cases other than 
> > > > > > > > multiversion, I think it should also apply to multiversion.
> > > > > > > > 
> > > > > > > > I will make isBetterMultiversionCandidate three states.
> > > > > > > > This general rule has been taken for cases other than 
> > > > > > > > multiversion, I think it should also apply to multiversion.
> > > > > > > 
> > > > > > > Well, but the multiversion people could say the same: that 
> > > > > > > multiversioning is for picking an alternative among 
> > > > > > > otherwise-identical functions, and HD and H functions are not 
> > > > > > > otherwise-identical.
> > > > > > > 
> > > > > > > CC'ing @echristo for his thoughts on the right ordering here.
> > > > > > Adding @erichkeane here as well.
> > > > > > 
> > > > > > I think this makes sense, but I can see a reason to multiversion a 
> > > > > > function that will run on host and device. A version of some matrix 
> > > > > > mult that takes advantage of 3 host architectures and one cuda one? 
> > > > > > Am I missing something here?
> > > > > My understanding is that a multiversion function is for a specific 
> > > > > cpu(gpu). Let's say we want to have a function f for gfx900, gfx906, 
> > > > > sandybridge, ivybridge, shouldn't they be more like
> > > > > 
> > > > > ```
> > > > > __host__ __attribute__((cpu_specific(sandybridge))) f();
> > > > > __host__ __attribute__((cpu_specific(ivybridge))) f();
> > > > > __device__ __attribute__((cpu_specific(gfx900))) f();
> > > > > __device__ __attribute__((cpu_specific(gfx906))) f();
> > > > > ```
> > > > > instead of all `__device__ __host__` functions?
> > > > IMO, it doesn't make sense for functions to functions be BOTH host and 
> > > > device, they'd have to be just one.  Otherwise I'm not sure how the 
> > > > resolver behavior is supposed to work.  The whole idea is that the 
> > > > definition is chosen at runtime.
> > > > 
> > > > Unless __host__ __device void foo(); is TWO declaration chains (meaning 
> > > > two separate AST entries), it doesn't make sense to have multiverison 
> > > > on it (and then, how it would be spelled is awkward/confusing to me).
> > > > 
> > > > In the above case, if those 4 declarations are not 2 separate root- AST 
> > > > nodes, multiversioning won't work.
> > > There are certainly functions that ought to be usable from either host or 
> > > device context — any inline function that just does ordinary language 
> > > things should be in that category.  Also IIUC many declarations are 
> > > *inferred* to be `__host__ __device__`, or can be mass-annotated with 
> > > pragmas, and those reasons are probably the main ones this might matter — 
> > > we might include a header in CUDA mode that declares a multi-versioned 
> > > function, and we should handle it right.
> > > 
> > > My read of how CUDA programmers expect this to work is that they see the 
> > > `__host__` / `__device__` attributes as primarily a mechanism for 
> > > catching problems where you're using the wrong functions for the current 
> > > configuration.  That is, while we allow overloading by 
> > > `__host__`/`__device__`-ness, users expect those attributes to mostly be 
> > > used as a filter for what's "really there" rather than really strictly 
> > > segregating the namespace.  So I would say that CUDA programmers would 
> > > probably expect the interaction with multiversioning to be:
> > > 
> > > - Programmers can put `__host__`, `__device__`, or both on a variant 
> > > depending on where it was

[clang-tools-extra] 1ccfe47 - [clangd] Fix build when CLANGD_REMOTE is not enabled

2020-04-24 Thread Kirill Bobyrev via cfe-commits


Author: Kirill Bobyrev
Date: 2020-04-24T14:07:39+02:00
New Revision: 1ccfe475a753a93d647be78edff000b9d6667ff7

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

LOG: [clangd] Fix build when CLANGD_REMOTE is not enabled

Added: 


Modified: 
clang-tools-extra/clangd/index/dex/dexp/Dexp.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/index/dex/dexp/Dexp.cpp 
b/clang-tools-extra/clangd/index/dex/dexp/Dexp.cpp
index 101367ce7c67..8738f9cd144c 100644
--- a/clang-tools-extra/clangd/index/dex/dexp/Dexp.cpp
+++ b/clang-tools-extra/clangd/index/dex/dexp/Dexp.cpp
@@ -286,9 +286,9 @@ class Export : public Command {
   void run() {
 using namespace clang::clangd;
 // Read input file (as specified in global option)
-auto Buffer = llvm::MemoryBuffer::getFile(IndexPath);
+auto Buffer = llvm::MemoryBuffer::getFile(IndexLocation);
 if (!Buffer) {
-  llvm::errs() << llvm::formatv("Can't open {0}", IndexPath) << "\n";
+  llvm::errs() << llvm::formatv("Can't open {0}", IndexLocation) << "\n";
   return;
 }
 



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

[clang-tools-extra] 9774c34 - [clangd] NFC: Omit deduced template parameters

2020-04-24 Thread Kirill Bobyrev via cfe-commits


Author: Kirill Bobyrev
Date: 2020-04-24T14:27:39+02:00
New Revision: 9774c34a84e336968f276591c200bd955631c5be

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

LOG: [clangd] NFC: Omit deduced template parameters

Related revision: D78521

Added: 


Modified: 
clang-tools-extra/clangd/index/remote/Client.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/index/remote/Client.cpp 
b/clang-tools-extra/clangd/index/remote/Client.cpp
index 79f303978c31..0c5fe142214b 100644
--- a/clang-tools-extra/clangd/index/remote/Client.cpp
+++ b/clang-tools-extra/clangd/index/remote/Client.cpp
@@ -61,21 +61,18 @@ class IndexClient : public clangd::SymbolIndex {
 
   void lookup(const clangd::LookupRequest &Request,
   llvm::function_ref Callback) const 
{
-streamRPC(
-Request, &remote::SymbolIndex::Stub::Lookup, Callback);
+streamRPC(Request, &remote::SymbolIndex::Stub::Lookup, Callback);
   }
 
   bool
   fuzzyFind(const clangd::FuzzyFindRequest &Request,
 llvm::function_ref Callback) const {
-return streamRPC(
-Request, &remote::SymbolIndex::Stub::FuzzyFind, Callback);
+return streamRPC(Request, &remote::SymbolIndex::Stub::FuzzyFind, Callback);
   }
 
   bool refs(const clangd::RefsRequest &Request,
 llvm::function_ref Callback) const {
-return streamRPC(
-Request, &remote::SymbolIndex::Stub::Refs, Callback);
+return streamRPC(Request, &remote::SymbolIndex::Stub::Refs, Callback);
   }
 
   // FIXME(kirillbobyrev): Implement this.



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

Re: [PATCH] D78192: Support compiler extensions as a normal component

2020-04-24 Thread Russell Gallop via cfe-commits

Thanks!

On Fri, 24 Apr 2020 at 10:51, Serge Guelton  wrote:

> On Fri, Apr 24, 2020 at 10:15:15AM +0100, Russell Gallop wrote:
> > Hi Serge,
> >
> > It looks like this is failing to build on Windows bots (e.g. [1]http://
> >
> lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/
> > builds/32003). Error below.
> >
> > Please could you take a look?
>
> e307eeba0137700e75893089cf0de03383d851ca should do the trick (finger
> crossed)
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 2da89df - Fix minor bug in CommonArgs.cpp

2020-04-24 Thread Yaxun Liu via cfe-commits


Author: Yaxun (Sam) Liu
Date: 2020-04-24T08:46:33-04:00
New Revision: 2da89df4e8d240160d5f265ecac4b0c6a0705d65

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

LOG: Fix minor bug in CommonArgs.cpp

Change-Id: Ibe87b1633cc7516479bb08bf51b6860a1585a94f

Added: 


Modified: 
clang/lib/Driver/ToolChains/CommonArgs.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/CommonArgs.cpp 
b/clang/lib/Driver/ToolChains/CommonArgs.cpp
index 303ced52454c..5219f28565a4 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ b/clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -1327,7 +1327,7 @@ void tools::AddHIPLinkerScript(const ToolChain &TC, 
Compilation &C,
   llvm::raw_string_ostream LksStream(LksBuffer);
 
   // Get the HIP offload tool chain.
-  auto *HIPTC = static_cast(
+  auto *HIPTC = static_cast(
   C.getSingleOffloadToolChain());
   assert(HIPTC->getTriple().getArch() == llvm::Triple::amdgcn &&
  "Wrong platform");



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

[PATCH] D77954: [CUDA][HIP] Fix host/device based overload resolution

2020-04-24 Thread Yaxun Liu via Phabricator via cfe-commits

yaxunl updated this revision to Diff 259870.
yaxunl marked an inline comment as done.
yaxunl added a comment.

change the precedence of multiversion to be over host/device-ness.


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

https://reviews.llvm.org/D77954

Files:
  clang/lib/Sema/SemaOverload.cpp
  clang/test/SemaCUDA/function-overload.cu

Index: clang/test/SemaCUDA/function-overload.cu
===
--- clang/test/SemaCUDA/function-overload.cu
+++ clang/test/SemaCUDA/function-overload.cu
@@ -331,9 +331,6 @@
 // If we have a mix of HD and H-only or D-only candidates in the overload set,
 // normal C++ overload resolution rules apply first.
 template  TemplateReturnTy template_vs_hd_function(T arg)
-#ifdef __CUDA_ARCH__
-//expected-note@-2 {{declared here}}
-#endif
 {
   return TemplateReturnTy();
 }
@@ -342,11 +339,13 @@
 }
 
 __host__ __device__ void test_host_device_calls_hd_template() {
-  HostDeviceReturnTy ret1 = template_vs_hd_function(1.0f);
-  TemplateReturnTy ret2 = template_vs_hd_function(1);
 #ifdef __CUDA_ARCH__
-  // expected-error@-2 {{reference to __host__ function 'template_vs_hd_function' in __host__ __device__ function}}
+  typedef HostDeviceReturnTy ExpectedReturnTy;
+#else
+  typedef TemplateReturnTy ExpectedReturnTy;
 #endif
+  HostDeviceReturnTy ret1 = template_vs_hd_function(1.0f);
+  ExpectedReturnTy ret2 = template_vs_hd_function(1);
 }
 
 __host__ void test_host_calls_hd_template() {
@@ -367,14 +366,14 @@
 __device__ DeviceReturnTy device_only_function(int arg) { return DeviceReturnTy(); }
 __device__ DeviceReturnTy2 device_only_function(float arg) { return DeviceReturnTy2(); }
 #ifndef __CUDA_ARCH__
-  // expected-note@-3 {{'device_only_function' declared here}}
-  // expected-note@-3 {{'device_only_function' declared here}}
+  // expected-note@-3 2{{'device_only_function' declared here}}
+  // expected-note@-3 2{{'device_only_function' declared here}}
 #endif
 __host__ HostReturnTy host_only_function(int arg) { return HostReturnTy(); }
 __host__ HostReturnTy2 host_only_function(float arg) { return HostReturnTy2(); }
 #ifdef __CUDA_ARCH__
-  // expected-note@-3 {{'host_only_function' declared here}}
-  // expected-note@-3 {{'host_only_function' declared here}}
+  // expected-note@-3 2{{'host_only_function' declared here}}
+  // expected-note@-3 2{{'host_only_function' declared here}}
 #endif
 
 __host__ __device__ void test_host_device_single_side_overloading() {
@@ -392,6 +391,37 @@
 #endif
 }
 
+// wrong-sided overloading should not cause diagnostic unless it is emitted.
+// This inline function is not emitted.
+inline __host__ __device__ void test_host_device_wrong_side_overloading_inline_no_diag() {
+  DeviceReturnTy ret1 = device_only_function(1);
+  DeviceReturnTy2 ret2 = device_only_function(1.0f);
+  HostReturnTy ret3 = host_only_function(1);
+  HostReturnTy2 ret4 = host_only_function(1.0f);
+}
+
+// wrong-sided overloading should cause diagnostic if it is emitted.
+// This inline function is emitted since it is called by an emitted function.
+inline __host__ __device__ void test_host_device_wrong_side_overloading_inline_diag() {
+  DeviceReturnTy ret1 = device_only_function(1);
+  DeviceReturnTy2 ret2 = device_only_function(1.0f);
+#ifndef __CUDA_ARCH__
+  // expected-error@-3 {{reference to __device__ function 'device_only_function' in __host__ __device__ function}}
+  // expected-error@-3 {{reference to __device__ function 'device_only_function' in __host__ __device__ function}}
+#endif
+  HostReturnTy ret3 = host_only_function(1);
+  HostReturnTy2 ret4 = host_only_function(1.0f);
+#ifdef __CUDA_ARCH__
+  // expected-error@-3 {{reference to __host__ function 'host_only_function' in __host__ __device__ function}}
+  // expected-error@-3 {{reference to __host__ function 'host_only_function' in __host__ __device__ function}}
+#endif
+}
+
+__host__ __device__ void test_host_device_wrong_side_overloading_inline_diag_caller() {
+  test_host_device_wrong_side_overloading_inline_diag();
+  // expected-note@-1 {{called by 'test_host_device_wrong_side_overloading_inline_diag_caller'}}
+}
+
 // Verify that we allow overloading function templates.
 template  __host__ T template_overload(const T &a) { return a; };
 template  __device__ T template_overload(const T &a) { return a; };
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -9374,16 +9374,22 @@
   return Comparison::Equal;
 }
 
-static bool isBetterMultiversionCandidate(const OverloadCandidate &Cand1,
-  const OverloadCandidate &Cand2) {
+static Comparison
+isBetterMultiversionCandidate(const OverloadCandidate &Cand1,
+  const OverloadCandidate &Cand2) {
   if (!Cand1.Function || !Cand1.Function->isMultiVersion() || !Cand2.Function ||
   !Cand2.Funct

[PATCH] D78807: Fix gendered documentation

2020-04-24 Thread Sylvestre Ledru via Phabricator via cfe-commits

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

thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78807



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

[PATCH] D77229: [Analyzer][WIP] Avoid handling of LazyCompundVals in IteratorModeling

2020-04-24 Thread Balogh , Ádám via Phabricator via cfe-commits

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



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h:1044
 
+class ParamWithoutVarRegion : public TypedValueRegion {
+  friend class MemRegionManager;

NoQ wrote:
> baloghadamsoftware wrote:
> > baloghadamsoftware wrote:
> > > baloghadamsoftware wrote:
> > > > NoQ wrote:
> > > > > There should be only one way to express the parameter region. Let's 
> > > > > call this one simply `ParamRegion` or something like that, and 
> > > > > `assert(!isa(D))` in the constructor of `VarRegion`.
> > > > Do you mean that we should use `ParamRegion` in every case, thus also 
> > > > when we have the definitioan for the function? I wonder whether it 
> > > > breaks too many things.
> > > This will surely not work. The common handling of `ParamVarDecl` and 
> > > `VarDecl` is soo deeply rooted in the whole analyzer that separating them 
> > > means creation of a totally new analyzer engine from scratch.
> > More specifically: whenever a function is inlined, its parameters are used 
> > as variables via `DeclRefExpr`s. A `DeclRefExpr` refers to a `Decl` which 
> > is a `ParamVarDecl` but that has reference neither for the `CallExpr` 
> > (since it is not related to the call, but to the `FunctionDecl` or 
> > `ObjCMethodDecl`) nore for its `Index` in the call. The former is the real 
> > problem that cannot be solved even on theoretical level: a function which 
> > is inlined cannot depend on the different `CallExpr`s where it is called. 
> > Even worse, if the function is analyzed top-level it has not `CallExpr` at 
> > all so using `ParamRegion` for its parameters is completely impossible.
> > A `DeclRefExpr` refers to a `Decl` which is a `ParamVarDecl` but that has 
> > reference neither for the `CallExpr` (since it is not related to the call, 
> > but to the `FunctionDecl` or `ObjCMethodDecl`)
> 
> The call site is available as part of the current location context.
> 
> > nore for its Index in the call
> 
> It's available as part of `ParmVarDecl`.
> 
> > The former is the real problem that cannot be solved even on theoretical 
> > level: a function which is inlined cannot depend on the different 
> > `CallExpr`s where it is called
> 
> It already depends on the `CallExpr`. `ParmVarDecl`-based `VarRegion`s are 
> different for different call sites even if `ParmVarDecl` is the same; 
> moreover, they reside in non-overlapping memory spaces.
> 
> > Even worse, if the function is analyzed top-level it has not `CallExpr` at 
> > all so using `ParamRegion` for its parameters is completely impossible.
> 
> Ok, let's make an exception for this case and either use the old `VarRegion` 
> (given that there's no redecl confusion in this case) or allow the `CallExpr` 
> to be null (it's still trivially easy to extract all the necessary 
> information).
> 
> > The common handling of `ParamVarDecl` and `VarDecl` is soo deeply rooted in 
> > the whole analyzer that separating them means creation of a totally new 
> > analyzer engine from scratch.
> 
> I don't see any indication of that yet.
> or allow the `CallExpr` to be `null`

How do we calculate the type then? Or should we store it explicitly?


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

https://reviews.llvm.org/D77229



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

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

2020-04-24 Thread Florian Hahn via Phabricator via cfe-commits

fhahn added a comment.

ping.

@rjmccall & @SjoerdMeijer thanks for all the comments. I hope they are no 
addressed adequately.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76612



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

[PATCH] D76451: [clangd] Enable textual fallback for go-to-definition on dependent names

2020-04-24 Thread Sam McCall via Phabricator via cfe-commits

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

Great, thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76451



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

[PATCH] D78785: Fix x86/x86_64 calling convention for _ExtInt

2020-04-24 Thread Erich Keane via Phabricator via cfe-commits

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



Comment at: clang/lib/CodeGen/TargetInfo.cpp:2804
+return;
+  }
+

Quuxplusone wrote:
> Asking silly questions because I don't stand a chance of understanding either 
> the code or the tests...
> 
> In the x86-64 ABI, an ordinary 16-byte `struct` would be passed in `rdi/rsi` 
> and returned in `rdx/rax`. An ordinary 17-byte `struct` would be passed by 
> hidden reference and returned by hidden reference.
> 
> Is your intent here that `_ExtInt` will follow the same convention, i.e., 
> `_ExtInt(128)` will be passed in `rdi/rsi` and returned in `rdx/rax`? and 
> `_ExtInt(129)` will be passed and returned by hidden reference?
> 
> Clang trunk currently passes `_ExtInt(256)` in `rdi/rsi/rdx/rcx/r8/r9/stack` 
> as if it were a series of `uint64_t`s. (I hadn't noticed until now.) That's 
> kind of cute. Is the current PR motivated by performance concerns with the 
> multi-`uint64_t` approach, or just trying to be consistent with the `struct` 
> rules?
Yes, that is my intent.  The bug you filed apparently showed why putting it in 
registers is perhaps a bad idea (for something that large), AND gets us more 
consistent with structs.

As there is no official ABI for any of the 3 platforms, this seems more 
consistent and gives performance benefit.  @craig.topper can explain this part 
better than me.


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

https://reviews.llvm.org/D78785



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

[PATCH] D78784: [clangd] Add some logging to explain why textual fallback navigation failed

2020-04-24 Thread Sam McCall via Phabricator via cfe-commits

sammccall added a comment.

This seems fine-grained even for `vlog`. Is this for debugging, can it be 
`dlog()`? (i.e. available in asserts-enabled builds behind `-debug` or 
`-debug-only=XRefs.cpp`)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78784



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

[PATCH] D46317: [clang-tidy] New check bugprone-map-subscript-operator-lookup

2020-04-24 Thread Eugene Zelenko via Phabricator via cfe-commits

Eugene.Zelenko added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/MapSubscriptOperatorLookupCheck.cpp:31
+void MapSubscriptOperatorLookupCheck::registerMatchers(MatchFinder *Finder) {
+  if (!getLangOpts().CPlusPlus)
+return;

Should be in isLanguageVersionSupported() method.



Comment at: clang-tools-extra/docs/ReleaseNotes.rst:78
 ^^
+- New :doc:`bugprone-map-subscript-operator-lookup
+  ` check.

Please separate with empty line.



Comment at: clang-tools-extra/docs/ReleaseNotes.rst:81
+
+  Detects map lookups done with operator[].
+

Please synchronize with first statement in documentation.


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

https://reviews.llvm.org/D46317



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

[PATCH] D78785: Fix x86/x86_64 calling convention for _ExtInt

2020-04-24 Thread Erich Keane via Phabricator via cfe-commits

erichkeane updated this revision to Diff 259875.
erichkeane added a comment.

Handle indirect return as well.  @craig.topper : Anything else you can think of?


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

https://reviews.llvm.org/D78785

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/ext-int-sanitizer.cpp
  clang/test/CodeGen/ext-int.c
  clang/test/CodeGenCXX/ext-int.cpp

Index: clang/test/CodeGenCXX/ext-int.cpp
===
--- clang/test/CodeGenCXX/ext-int.cpp
+++ clang/test/CodeGenCXX/ext-int.cpp
@@ -98,7 +98,7 @@
 };
 
 void UnderlyingTypeUsage(AsEnumUnderlyingType Param) {
-  // LIN: define void @_Z19UnderlyingTypeUsage20AsEnumUnderlyingType(i9 %
+  // LIN: define void @_Z19UnderlyingTypeUsage20AsEnumUnderlyingType(i16 %
   // WIN: define dso_local void @"?UnderlyingTypeUsage@@YAXW4AsEnumUnderlyingType@@@Z"(i9 %
   AsEnumUnderlyingType Var;
   // CHECK: alloca i9, align 2
@@ -106,13 +106,13 @@
 }
 
 unsigned _ExtInt(33) ManglingTestRetParam(unsigned _ExtInt(33) Param) {
-// LIN: define i33 @_Z20ManglingTestRetParamU7_ExtIntILi33EEj(i33 %
+// LIN: define i64 @_Z20ManglingTestRetParamU7_ExtIntILi33EEj(i64 %
 // WIN: define dso_local i33 @"?ManglingTestRetParam@@YAU?$_UExtInt@$0CB@@__clang@@U12@@Z"(i33
   return 0;
 }
 
 _ExtInt(33) ManglingTestRetParam(_ExtInt(33) Param) {
-// LIN: define i33 @_Z20ManglingTestRetParamU7_ExtIntILi33EEi(i33 %
+// LIN: define i64 @_Z20ManglingTestRetParamU7_ExtIntILi33EEi(i64 %
 // WIN: define dso_local i33 @"?ManglingTestRetParam@@YAU?$_ExtInt@$0CB@@__clang@@U12@@Z"(i33
   return 0;
 }
@@ -155,13 +155,14 @@
 
   _ExtInt(92) A = __builtin_va_arg(args, _ExtInt(92));
   // LIN: %[[AD1:.+]] = getelementptr inbounds [1 x %struct.__va_list_tag], [1 x %struct.__va_list_tag]* %[[ARGS]]
-  // LIN: %[[OFA_P1:.+]] = getelementptr inbounds %struct.__va_list_tag, %struct.__va_list_tag* %[[AD1]], i32 0, i32 2
-  // LIN: %[[OFA1:.+]] = load i8*, i8** %[[OFA_P1]]
-  // LIN: %[[BC1:.+]] = bitcast i8* %[[OFA1]] to i92*
-  // LIN: %[[OFANEXT1:.+]] = getelementptr i8, i8* %[[OFA1]], i32 16
-  // LIN: store i8* %[[OFANEXT1]], i8** %[[OFA_P1]]
+  // LIN: %[[OFA_P1:.+]] = getelementptr inbounds %struct.__va_list_tag, %struct.__va_list_tag* %[[AD1]], i32 0, i32 0
+  // LIN: %[[GPOFFSET:.+]] = load i32, i32* %[[OFA_P1]]
+  // LIN: %[[FITSINGP:.+]] = icmp ule i32 %[[GPOFFSET]], 32
+  // LIN: br i1 %[[FITSINGP]]
+  // LIN: %[[BC1:.+]] = phi i92*
   // LIN: %[[LOAD1:.+]] = load i92, i92* %[[BC1]]
   // LIN: store i92 %[[LOAD1]], i92*
+
   // WIN: %[[CUR1:.+]] = load i8*, i8** %[[ARGS]]
   // WIN: %[[NEXT1:.+]] = getelementptr inbounds i8, i8* %[[CUR1]], i64 16
   // WIN: store i8* %[[NEXT1]], i8** %[[ARGS]]
@@ -171,15 +172,16 @@
 
   _ExtInt(31) B = __builtin_va_arg(args, _ExtInt(31));
   // LIN: %[[AD2:.+]] = getelementptr inbounds [1 x %struct.__va_list_tag], [1 x %struct.__va_list_tag]* %[[ARGS]]
-  // LIN: %[[OFA_P2:.+]] = getelementptr inbounds %struct.__va_list_tag, %struct.__va_list_tag* %[[AD2]], i32 0, i32 2
-  // LIN: %[[OFA2:.+]] = load i8*, i8** %[[OFA_P2]]
-  // LIN: %[[BC2:.+]] = bitcast i8* %[[OFA2]] to i31*
-  // LIN: %[[OFANEXT2:.+]] = getelementptr i8, i8* %[[OFA2]], i32 8
-  // LIN: store i8* %[[OFANEXT2]], i8** %[[OFA_P2]]
-  // LIN: %[[LOAD2:.+]] = load i31, i31* %[[BC2]]
-  // LIN: store i31 %[[LOAD2]], i31*
+  // LIN: %[[OFA_P2:.+]] = getelementptr inbounds %struct.__va_list_tag, %struct.__va_list_tag* %[[AD2]], i32 0, i32 0
+  // LIN: %[[GPOFFSET:.+]] = load i32, i32* %[[OFA_P2]]
+  // LIN: %[[FITSINGP:.+]] = icmp ule i32 %[[GPOFFSET]], 40
+  // LIN: br i1 %[[FITSINGP]]
+  // LIN: %[[BC1:.+]] = phi i31*
+  // LIN: %[[LOAD1:.+]] = load i31, i31* %[[BC1]]
+  // LIN: store i31 %[[LOAD1]], i31*
+
   // WIN: %[[CUR2:.+]] = load i8*, i8** %[[ARGS]]
-  // WIN: %[[NEXT2:.+]] = getelementptr inbounds i8, i8* %[[CUR2]], i64 8 
+  // WIN: %[[NEXT2:.+]] = getelementptr inbounds i8, i8* %[[CUR2]], i64 8
   // WIN: store i8* %[[NEXT2]], i8** %[[ARGS]]
   // WIN: %[[BC2:.+]] = bitcast i8* %[[CUR2]] to i31*
   // WIN: %[[LOADV2:.+]] = load i31, i31* %[[BC2]]
@@ -187,13 +189,14 @@
 
   _ExtInt(16) C = __builtin_va_arg(args, _ExtInt(16));
   // LIN: %[[AD3:.+]] = getelementptr inbounds [1 x %struct.__va_list_tag], [1 x %struct.__va_list_tag]* %[[ARGS]]
-  // LIN: %[[OFA_P3:.+]] = getelementptr inbounds %struct.__va_list_tag, %struct.__va_list_tag* %[[AD3]], i32 0, i32 2
-  // LIN: %[[OFA3:.+]] = load i8*, i8** %[[OFA_P3]]
-  // LIN: %[[BC3:.+]] = bitcast i8* %[[OFA3]] to i16*
-  // LIN: %[[OFANEXT3:.+]] = getelementptr i8, i8* %[[OFA3]], i32 8
-  // LIN: store i8* %[[OFANEXT3]], i8** %[[OFA_P3]]
-  // LIN: %[[LOAD3:.+]] = load i16, i16* %[[BC3]]
-  // LIN: store i16 %[[LOAD3]], i16*
+  // LIN: %[[OFA_P3:.+]] = getelementptr inbounds %struct.__va_list_tag, %struct.__va_list_tag* %[[AD3]], i32 0, i32 0
+  // LIN: %[[GPOFFSET:.+]] = load i32, i32* %[[OFA_P3]]
+  // LIN: %[[FITSINGP:.+]] = icmp ule i32 %[[

[clang] 832cd74 - [AArch64] Armv8.6-a Matrix Mult Assembly + Intrinsics

2020-04-24 Thread Luke Geeson via cfe-commits


Author: Luke Geeson
Date: 2020-04-24T15:54:06+01:00
New Revision: 832cd749131b1fa59d12486325f19e16eb392a42

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

LOG: [AArch64] Armv8.6-a Matrix Mult Assembly + Intrinsics

This patch upstreams support for the Armv8.6-a Matrix Multiplication
Extension. A summary of the features can be found here:

https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a

This patch includes:

- Assembly support for AArch64 only (no SVE or Neon)
- Intrinsics Support for AArch64 Armv8.6a Matrix Multiplication Instructions 
(No bfloat16 matrix multiplication)

No IR types or C Types are needed for this extension.

This is part of a patch series, starting with BFloat16 support and
the other components in the armv8.6a extension (in previous patches
linked in phabricator)

Based on work by:
- Luke Geeson
- Oliver Stannard
- Luke Cheeseman

Reviewers: ostannard, t.p.northover, rengolin, kmclaughlin

Reviewed By: kmclaughlin

Subscribers: kmclaughlin, kristof.beyls, hiraditya, danielkiss,
cfe-commits

Tags: #clang

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

Added: 
clang/test/CodeGen/aarch64-matmul.cpp
clang/test/CodeGen/aarch64-v8.6a-neon-intrinsics.c
llvm/test/CodeGen/AArch64/aarch64-matmul.ll
llvm/test/MC/AArch64/armv8.6a-simd-matmul-error.s
llvm/test/MC/AArch64/armv8.6a-simd-matmul.s
llvm/test/MC/Disassembler/AArch64/armv8.6a-simd-matmul.txt

Modified: 
clang/include/clang/Basic/arm_neon.td
clang/lib/Basic/Targets/AArch64.cpp
clang/lib/Basic/Targets/AArch64.h
clang/lib/CodeGen/CGBuiltin.cpp
llvm/include/llvm/IR/IntrinsicsAArch64.td
llvm/lib/Target/AArch64/AArch64.td
llvm/lib/Target/AArch64/AArch64InstrFormats.td
llvm/lib/Target/AArch64/AArch64InstrInfo.td
llvm/lib/Target/AArch64/AArch64Subtarget.h

Removed: 




diff  --git a/clang/include/clang/Basic/arm_neon.td 
b/clang/include/clang/Basic/arm_neon.td
index f949edc378fc..82e44aaec69b 100644
--- a/clang/include/clang/Basic/arm_neon.td
+++ b/clang/include/clang/Basic/arm_neon.td
@@ -221,6 +221,21 @@ def OP_FMLAL_LN_Hi  : Op<(call "vfmlal_high", $p0, $p1,
 def OP_FMLSL_LN_Hi  : Op<(call "vfmlsl_high", $p0, $p1,
(dup_typed $p1, (call "vget_lane", $p2, $p3)))>;
 
+def OP_USDOT_LN
+: Op<(call "vusdot", $p0, $p1,
+  (cast "8", "S", (call_mangled "splat_lane", (bitcast "int32x2_t", 
$p2), $p3)))>;
+def OP_USDOT_LNQ
+: Op<(call "vusdot", $p0, $p1,
+  (cast "8", "S", (call_mangled "splat_lane", (bitcast "int32x4_t", 
$p2), $p3)))>;
+
+// sudot splats the second vector and then calls vusdot
+def OP_SUDOT_LN
+: Op<(call "vusdot", $p0,
+  (cast "8", "U", (call_mangled "splat_lane", (bitcast "int32x2_t", 
$p2), $p3)), $p1)>;
+def OP_SUDOT_LNQ
+: Op<(call "vusdot", $p0,
+  (cast "8", "U", (call_mangled "splat_lane", (bitcast "int32x4_t", 
$p2), $p3)), $p1)>;
+
 
//===--===//
 // Auxiliary Instructions
 
//===--===//
@@ -1792,6 +1807,23 @@ let ArchGuard = "defined(__ARM_FEATURE_FP16FML) && 
defined(__aarch64__)" in {
   }
 }
 
+let ArchGuard = "defined(__ARM_FEATURE_MATMUL_INT8)" in {
+  def VMMLA   : SInst<"vmmla", "..(<<)(<<)", "QUiQi">;
+  def VUSMMLA : SInst<"vusmmla", "..(<;
+
+  def VUSDOT  : SInst<"vusdot", "..(<;
+
+  def VUSDOT_LANE  : SOpInst<"vusdot_lane", "..(<;
+  def VSUDOT_LANE  : SOpInst<"vsudot_lane", "..(<<)(<;
+
+  let ArchGuard = "defined(__aarch64__)" in {
+let isLaneQ = 1 in {
+  def VUSDOT_LANEQ  : SOpInst<"vusdot_laneq", "..(<;
+  def VSUDOT_LANEQ  : SOpInst<"vsudot_laneq", "..(<<)(<;
+}
+  }
+}
+
 // v8.3-A Vector complex addition intrinsics
 let ArchGuard = "defined(__ARM_FEATURE_COMPLEX) && 
defined(__ARM_FEATURE_FP16_VECTOR_ARITHMETIC)" in {
   def VCADD_ROT90_FP16   : SInst<"vcadd_rot90", "...", "h">;
@@ -1808,4 +1840,4 @@ let ArchGuard = "defined(__ARM_FEATURE_COMPLEX)" in {
 let ArchGuard = "defined(__ARM_FEATURE_COMPLEX) && defined(__aarch64__)" in {
   def VCADDQ_ROT90_FP64  : SInst<"vcaddq_rot90", "QQQ", "d">;
   def VCADDQ_ROT270_FP64 : SInst<"vcaddq_rot270", "QQQ", "d">;
-}
\ No newline at end of file
+}

diff  --git a/clang/lib/Basic/Targets/AArch64.cpp 
b/clang/lib/Basic/Targets/AArch64.cpp
index 8ceb7f2b515e..5357d31ee64c 100644
--- a/clang/lib/Basic/Targets/AArch64.cpp
+++ b/clang/lib/Basic/Targets/AArch64.cpp
@@ -280,6 +280,9 @@ void AArch64TargetInfo::getTargetDefines(const LangOptions 
&Opts,
   if (HasTME)
 Builder.defineMacro("__ARM_FEATURE_TME", "1");
 
+  if (HasMatMul)
+Builder.defineMacro("__ARM_FEATURE_MATM

[clang] 740a1dd - [ARM] Armv8.6-a Matrix Mul cmd line support

2020-04-24 Thread Luke Geeson via cfe-commits


Author: Luke Geeson
Date: 2020-04-24T15:54:06+01:00
New Revision: 740a1dd050eea93a875ec86780ad6ed4b0310113

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

LOG: [ARM] Armv8.6-a Matrix Mul cmd line support

This patch upstreams support for the Armv8.6-a Matrix Multiplication
Extension. A summary of the features can be found here:

https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a

This patch includes:

- Command line options to enable these features with +i8mm, +f32mm, or f64mm

Note: +f32mm and +f64mm are optional and so are not enabled by default

This is part of a patch series, starting with BFloat16 support and
the other components in the armv8.6a extension (in previous patches
linked in phabricator)

Based on work by:
- Luke Geeson
- Oliver Stannard
- Luke Cheeseman

Reviewers: t.p.northover, DavidSpickett

Reviewed By: DavidSpickett

Subscribers: DavidSpickett, ostannard, kristof.beyls, danielkiss,
cfe-commits

Tags: #clang

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

Added: 
clang/test/Driver/arm-matrix-multiply.c

Modified: 
clang/lib/Driver/ToolChains/Arch/AArch64.cpp
clang/test/Driver/aarch64-cpus.c
llvm/include/llvm/Support/AArch64TargetParser.def
llvm/include/llvm/Support/AArch64TargetParser.h
llvm/include/llvm/Support/ARMTargetParser.def
llvm/include/llvm/Support/ARMTargetParser.h
llvm/unittests/Support/TargetParserTest.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Arch/AArch64.cpp 
b/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
index b21cfac6e7ed..4c034d40aaf4 100644
--- a/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
@@ -54,7 +54,8 @@ std::string aarch64::getAArch64TargetCPU(const ArgList &Args,
 
 // Decode AArch64 features from string like +[no]featureA+[no]featureB+...
 static bool DecodeAArch64Features(const Driver &D, StringRef text,
-  std::vector &Features) {
+  std::vector &Features,
+  llvm::AArch64::ArchKind ArchKind) {
   SmallVector Split;
   text.split(Split, StringRef("+"), -1, false);
 
@@ -66,6 +67,11 @@ static bool DecodeAArch64Features(const Driver &D, StringRef 
text,
   D.Diag(clang::diag::err_drv_no_neon_modifier);
 else
   return false;
+
+// +sve implies +f32mm if the base architecture is v8.6A
+// it isn't the case in general that sve implies both f64mm and f32mm
+if ((ArchKind == llvm::AArch64::ArchKind::ARMV8_6A) && Feature == "sve")
+  Features.push_back("+f32mm");
   }
   return true;
 }
@@ -76,6 +82,7 @@ static bool DecodeAArch64Mcpu(const Driver &D, StringRef 
Mcpu, StringRef &CPU,
   std::vector &Features) {
   std::pair Split = Mcpu.split("+");
   CPU = Split.first;
+  llvm::AArch64::ArchKind ArchKind = llvm::AArch64::ArchKind::ARMV8A;
 
   if (CPU == "native")
 CPU = llvm::sys::getHostCPUName();
@@ -83,7 +90,7 @@ static bool DecodeAArch64Mcpu(const Driver &D, StringRef 
Mcpu, StringRef &CPU,
   if (CPU == "generic") {
 Features.push_back("+neon");
   } else {
-llvm::AArch64::ArchKind ArchKind = llvm::AArch64::parseCPUArch(CPU);
+ArchKind = llvm::AArch64::parseCPUArch(CPU);
 if (!llvm::AArch64::getArchFeatures(ArchKind, Features))
   return false;
 
@@ -92,10 +99,11 @@ static bool DecodeAArch64Mcpu(const Driver &D, StringRef 
Mcpu, StringRef &CPU,
   return false;
}
 
-  if (Split.second.size() && !DecodeAArch64Features(D, Split.second, Features))
-return false;
+   if (Split.second.size() &&
+   !DecodeAArch64Features(D, Split.second, Features, ArchKind))
+ return false;
 
-  return true;
+   return true;
 }
 
 static bool
@@ -108,7 +116,8 @@ getAArch64ArchFeaturesFromMarch(const Driver &D, StringRef 
March,
   llvm::AArch64::ArchKind ArchKind = llvm::AArch64::parseArch(Split.first);
   if (ArchKind == llvm::AArch64::ArchKind::INVALID ||
   !llvm::AArch64::getArchFeatures(ArchKind, Features) ||
-  (Split.second.size() && !DecodeAArch64Features(D, Split.second, 
Features)))
+  (Split.second.size() &&
+   !DecodeAArch64Features(D, Split.second, Features, ArchKind)))
 return false;
 
   return true;

diff  --git a/clang/test/Driver/aarch64-cpus.c 
b/clang/test/Driver/aarch64-cpus.c
index 971f3cd83521..cf12a5155689 100644
--- a/clang/test/Driver/aarch64-cpus.c
+++ b/clang/test/Driver/aarch64-cpus.c
@@ -636,6 +636,34 @@
 // RUN: %clang -target aarch64 -march=armv8.5a+bf16+sve -### -c %s 2>&1 | 
FileCheck -check-prefixes=GENERICV85A-BF16-SVE %s
 // GENERICV85A-BF16-SVE: "-target-feature" "+bf16" "-target-feature" "+sve"
 
+// The 8-bit integer matrix

[clang] 7da1905 - [AArch32] Armv8.6-a Matrix Mult Assembly + Intrinsics

2020-04-24 Thread Luke Geeson via cfe-commits


Author: Luke Geeson
Date: 2020-04-24T15:54:06+01:00
New Revision: 7da19051253219d4bee2c50fe13f250201f1f7ec

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

LOG: [AArch32] Armv8.6-a Matrix Mult Assembly + Intrinsics

This patch upstreams support for the Armv8.6-a Matrix Multiplication
Extension. A summary of the features can be found here:

https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a

This patch includes:

- Assembly support for AArch32
- Intrinsics Support for AArch32 Neon Intrinsics for Matrix
  Multiplication

Note: these extensions are optional in the 8.6a architecture and so have
to be enabled by default

No additional IR types or C Types are needed for this extension.

This is part of a patch series, starting with BFloat16 support and
the other components in the armv8.6a extension (in previous patches
linked in phabricator)

Based on work by:
- Luke Geeson
- Oliver Stannard
- Luke Cheeseman

Reviewers: t.p.northover, miyuki

Reviewed By: miyuki

Subscribers: miyuki, ostannard, kristof.beyls, hiraditya, danielkiss,
cfe-commits

Tags: #clang

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

Added: 
clang/test/CodeGen/arm-v8.6a-neon-intrinsics.c
llvm/test/CodeGen/ARM/arm-matmul.ll

Modified: 
clang/lib/Basic/Targets/ARM.cpp
clang/lib/Basic/Targets/ARM.h
clang/lib/CodeGen/CGBuiltin.cpp
llvm/include/llvm/IR/IntrinsicsARM.td
llvm/lib/Target/ARM/ARM.td
llvm/lib/Target/ARM/ARMInstrNEON.td
llvm/lib/Target/ARM/ARMPredicates.td
llvm/lib/Target/ARM/ARMSubtarget.h

Removed: 




diff  --git a/clang/lib/Basic/Targets/ARM.cpp b/clang/lib/Basic/Targets/ARM.cpp
index 881516181538..f02a9d373609 100644
--- a/clang/lib/Basic/Targets/ARM.cpp
+++ b/clang/lib/Basic/Targets/ARM.cpp
@@ -425,6 +425,7 @@ bool 
ARMTargetInfo::handleTargetFeatures(std::vector &Features,
   // Note that SoftFloatABI is initialized in our constructor.
   HWDiv = 0;
   DotProd = 0;
+  HasMatMul = 0;
   HasFloat16 = true;
   ARMCDECoprocMask = 0;
 
@@ -491,6 +492,8 @@ bool 
ARMTargetInfo::handleTargetFeatures(std::vector &Features,
   FPU |= FPARMV8;
   MVE |= MVE_INT | MVE_FP;
   HW_FP |= HW_FP_SP | HW_FP_HP;
+} else if (Feature == "+i8mm") {
+  HasMatMul = 1;
 } else if (Feature.size() == strlen("+cdecp0") && Feature >= "+cdecp0" &&
Feature <= "+cdecp7") {
   unsigned Coproc = Feature.back() - '0';
@@ -820,6 +823,9 @@ void ARMTargetInfo::getTargetDefines(const LangOptions 
&Opts,
   if (DotProd)
 Builder.defineMacro("__ARM_FEATURE_DOTPROD", "1");
 
+  if (HasMatMul)
+Builder.defineMacro("__ARM_FEATURE_MATMUL_INT8", "1");
+
   switch (ArchKind) {
   default:
 break;

diff  --git a/clang/lib/Basic/Targets/ARM.h b/clang/lib/Basic/Targets/ARM.h
index 725954038602..48d9db2ba166 100644
--- a/clang/lib/Basic/Targets/ARM.h
+++ b/clang/lib/Basic/Targets/ARM.h
@@ -75,6 +75,7 @@ class LLVM_LIBRARY_VISIBILITY ARMTargetInfo : public 
TargetInfo {
   unsigned DSP : 1;
   unsigned Unaligned : 1;
   unsigned DotProd : 1;
+  unsigned HasMatMul : 1;
 
   enum {
 LDREX_B = (1 << 0), /// byte (8-bit)

diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index 80b27b629d1e..3a66583e20e8 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -4807,6 +4807,7 @@ static const ARMVectorIntrinsicInfo ARMSIMDIntrinsicMap 
[] = {
   NEONMAP1(vminnm_v, arm_neon_vminnm, Add1ArgType),
   NEONMAP1(vminnmq_v, arm_neon_vminnm, Add1ArgType),
   NEONMAP2(vminq_v, arm_neon_vminu, arm_neon_vmins, Add1ArgType | 
UnsignedAlts),
+  NEONMAP2(vmmlaq_v, arm_neon_ummla, arm_neon_smmla, 0),
   NEONMAP0(vmovl_v),
   NEONMAP0(vmovn_v),
   NEONMAP1(vmul_v, arm_neon_vmulp, Add1ArgType),
@@ -4914,6 +4915,9 @@ static const ARMVectorIntrinsicInfo ARMSIMDIntrinsicMap 
[] = {
   NEONMAP0(vtrnq_v),
   NEONMAP0(vtst_v),
   NEONMAP0(vtstq_v),
+  NEONMAP1(vusdot_v, arm_neon_usdot, 0),
+  NEONMAP1(vusdotq_v, arm_neon_usdot, 0),
+  NEONMAP1(vusmmlaq_v, arm_neon_usmmla, 0),
   NEONMAP0(vuzp_v),
   NEONMAP0(vuzpq_v),
   NEONMAP0(vzip_v),

diff  --git a/clang/test/CodeGen/arm-v8.6a-neon-intrinsics.c 
b/clang/test/CodeGen/arm-v8.6a-neon-intrinsics.c
new file mode 100644
index ..a641197b118a
--- /dev/null
+++ b/clang/test/CodeGen/arm-v8.6a-neon-intrinsics.c
@@ -0,0 +1,87 @@
+// RUN: %clang_cc1 -triple armv8.6a-arm-none-eabi -target-feature +neon 
-target-feature +fullfp16 -target-feature +i8mm \
+// RUN: -fallow-half-arguments-and-returns -S -disable-O0-optnone -emit-llvm 
-o - %s \
+// RUN: | opt -S -mem2reg -sroa \
+// RUN: | FileCheck %s
+
+// REQUIRES: arm-registered-target
+
+#include 
+
+// CHECK-LABEL: test_vmmlaq_s32
+// CHECK: [[

[PATCH] D78704: [analyzer][NFC] Add unittest for FalsePositiveRefutationBRVisitor

2020-04-24 Thread Gabor Marton via Phabricator via cfe-commits

martong accepted this revision.
martong added a comment.

Other than Whispy's nits, LGTM!




Comment at: 
clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp:24
+  do   
\
+if (!LLVM_WITH_Z3) 
\
+  return;  
\

whisperity wrote:
> xazax.hun wrote:
> > steakhal wrote:
> > > xazax.hun wrote:
> > > > I think this might not be the idiomatic way to skip a test. Consider 
> > > > using ` GTEST_SKIP();`.
> > > I agree, though that is not yet supported in the `gtest` in the 
> > > repository.
> > > Should we update that to benefit from this macro?
> > > 
> > > There are several places where we could use that like:
> > > - 
> > > [llvm/unittests/ExecutionEngine/MCJIT/MCJITTestAPICommon.h:29](https://github.com/llvm/llvm-project/blob/master/llvm/unittests/ExecutionEngine/MCJIT/MCJITTestAPICommon.h#L29-L33)
> > >  (expanded 37 times in the codebase)
> > > - 
> > > [llvm/unittests/Support/ThreadPool.cpp:81](https://github.com/llvm/llvm-project/blob/master/llvm/unittests/Support/ThreadPool.cpp#L81-L85)
> > >  (expanded 7 times in the file)
> > > - 
> > > [llvm/unittests/Support/MemoryTest.cpp:89](https://github.com/llvm/llvm-project/blob/master/llvm/unittests/Support/MemoryTest.cpp#L89-L94)
> > >  (expanded 10 time in the file)
> > I think you should check who updated gtest the last time and ping them what 
> > is the process to update it again.
> Still maybe this could warrant a `// FIXME: Update GTest and use 
> GTEST_SKIP()` ?
+1


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78704



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

[PATCH] D77229: [Analyzer][WIP] Avoid handling of LazyCompundVals in IteratorModeling

2020-04-24 Thread Balogh , Ádám via Phabricator via cfe-commits

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



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h:1044
 
+class ParamWithoutVarRegion : public TypedValueRegion {
+  friend class MemRegionManager;

baloghadamsoftware wrote:
> NoQ wrote:
> > baloghadamsoftware wrote:
> > > baloghadamsoftware wrote:
> > > > baloghadamsoftware wrote:
> > > > > NoQ wrote:
> > > > > > There should be only one way to express the parameter region. Let's 
> > > > > > call this one simply `ParamRegion` or something like that, and 
> > > > > > `assert(!isa(D))` in the constructor of `VarRegion`.
> > > > > Do you mean that we should use `ParamRegion` in every case, thus also 
> > > > > when we have the definitioan for the function? I wonder whether it 
> > > > > breaks too many things.
> > > > This will surely not work. The common handling of `ParamVarDecl` and 
> > > > `VarDecl` is soo deeply rooted in the whole analyzer that separating 
> > > > them means creation of a totally new analyzer engine from scratch.
> > > More specifically: whenever a function is inlined, its parameters are 
> > > used as variables via `DeclRefExpr`s. A `DeclRefExpr` refers to a `Decl` 
> > > which is a `ParamVarDecl` but that has reference neither for the 
> > > `CallExpr` (since it is not related to the call, but to the 
> > > `FunctionDecl` or `ObjCMethodDecl`) nore for its `Index` in the call. The 
> > > former is the real problem that cannot be solved even on theoretical 
> > > level: a function which is inlined cannot depend on the different 
> > > `CallExpr`s where it is called. Even worse, if the function is analyzed 
> > > top-level it has not `CallExpr` at all so using `ParamRegion` for its 
> > > parameters is completely impossible.
> > > A `DeclRefExpr` refers to a `Decl` which is a `ParamVarDecl` but that has 
> > > reference neither for the `CallExpr` (since it is not related to the 
> > > call, but to the `FunctionDecl` or `ObjCMethodDecl`)
> > 
> > The call site is available as part of the current location context.
> > 
> > > nore for its Index in the call
> > 
> > It's available as part of `ParmVarDecl`.
> > 
> > > The former is the real problem that cannot be solved even on theoretical 
> > > level: a function which is inlined cannot depend on the different 
> > > `CallExpr`s where it is called
> > 
> > It already depends on the `CallExpr`. `ParmVarDecl`-based `VarRegion`s are 
> > different for different call sites even if `ParmVarDecl` is the same; 
> > moreover, they reside in non-overlapping memory spaces.
> > 
> > > Even worse, if the function is analyzed top-level it has not `CallExpr` 
> > > at all so using `ParamRegion` for its parameters is completely impossible.
> > 
> > Ok, let's make an exception for this case and either use the old 
> > `VarRegion` (given that there's no redecl confusion in this case) or allow 
> > the `CallExpr` to be null (it's still trivially easy to extract all the 
> > necessary information).
> > 
> > > The common handling of `ParamVarDecl` and `VarDecl` is soo deeply rooted 
> > > in the whole analyzer that separating them means creation of a totally 
> > > new analyzer engine from scratch.
> > 
> > I don't see any indication of that yet.
> > or allow the `CallExpr` to be `null`
> 
> How do we calculate the type then? Or should we store it explicitly?
> I don't see any indication of that yet.

But I do. Even if I fix most of the crashes almost all the tests fail for 
different reasons.

But I also have crashes: what to do with functions called through pointers? 
These calls do not have direct callee, thus determining the type of the 
parameter based on the call is difficult. If the function has no prototype, 
then it is impossible. Maybe we should store the type explicitely indeed?



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

https://reviews.llvm.org/D77229



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

[PATCH] D78457: [analyzer][Z3-refutation] Fix refutation BugReporterVisitor bug and refactor

2020-04-24 Thread Gabor Marton via Phabricator via cfe-commits

martong added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:2869
+  Constraints = CF.add(Constraints, Sym, C.second);
+} else if (!OnlyForNewSymbols) {
+  // Overwrite the associated constraint of the Symbol.

If there is really no other way (see my comments below) then perhaps 
`OverwriteConstraintsOnExistingSyms` would be a better naming than 
`OnlyForNewSymbols` because it expresses what exactly is happening.
In either case, could you add some documentation (comments) to 
`addConstraints`? What it does, and what is the exact meaning of the param?



Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:2871
+  // Overwrite the associated constraint of the Symbol.
+  Constraints = CF.remove(Constraints, Sym);
   Constraints = CF.add(Constraints, Sym, C.second);

martong wrote:
> martong wrote:
> > steakhal wrote:
> > > How can we simplify this?
> > Could we change the visitation logic to start with the `EndPathNode`? I 
> > mean could we exercise `FalsePositiveRefutationBRVisitor` to start the 
> > visitation from `EndPathNode`? If that was possible then this whole patch 
> > would be way simpler.
> > In BugReporter.cpp:
> > ```
> >   // Run visitors on all nodes starting from the node *before* the last one.
> >   // The last node is reserved for notes generated with {@code getEndPath}.
> >   const ExplodedNode *NextNode = ErrorNode->getFirstPred();
> >   while (NextNode) {
> > ```
> > Why can't we have a different visitation order implemented specifically for 
> > the refutation visitor? (@NoQ, @xazax.hun)
> Hmm, to answer my own question, then we would visit the ErrorNode twice. So 
> then perhaps we should not allow any constraints in the ErrorNodes, right? 
> What if we'd split all such ErrorNodes into a PrevNode with the constraints 
> and a simple ErrorNode without the constraints?
@xazax.hun, and others: Any thoughts on my comments above? What do you think, 
would it be possible to split the error node into two nodes? A PrevNode with 
the constraints and a simple ErrorNode without the constraints?



Comment at: 
clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp:194
+  // This assumption is false!
+  // 'y' can not be 5 if the maximal value of both x and y is 2.
+  // This bugreport must be caught by the visitor, since the 
constraints

martong wrote:
> `x and y` -> `x and n`.
It's not done. It is still `x and y` but should be `x and n`, isn't it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78457



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

[PATCH] D77871: [AArch64] Armv8.6-a Matrix Mult Assembly + Intrinsics

2020-04-24 Thread Luke Geeson via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG832cd749131b: [AArch64] Armv8.6-a Matrix Mult Assembly + 
Intrinsics (authored by LukeGeeson).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77871

Files:
  clang/include/clang/Basic/arm_neon.td
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/AArch64.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/aarch64-matmul.cpp
  clang/test/CodeGen/aarch64-v8.6a-neon-intrinsics.c
  llvm/include/llvm/IR/IntrinsicsAArch64.td
  llvm/lib/Target/AArch64/AArch64.td
  llvm/lib/Target/AArch64/AArch64InstrFormats.td
  llvm/lib/Target/AArch64/AArch64InstrInfo.td
  llvm/lib/Target/AArch64/AArch64Subtarget.h
  llvm/test/CodeGen/AArch64/aarch64-matmul.ll
  llvm/test/MC/AArch64/armv8.6a-simd-matmul-error.s
  llvm/test/MC/AArch64/armv8.6a-simd-matmul.s
  llvm/test/MC/Disassembler/AArch64/armv8.6a-simd-matmul.txt

Index: llvm/test/MC/Disassembler/AArch64/armv8.6a-simd-matmul.txt
===
--- /dev/null
+++ llvm/test/MC/Disassembler/AArch64/armv8.6a-simd-matmul.txt
@@ -0,0 +1,34 @@
+# RUN: llvm-mc -triple=aarch64  -mattr=+i8mm -disassemble < %s   | FileCheck %s
+# RUN: llvm-mc -triple=aarch64  -mattr=+v8.6a -disassemble < %s  | FileCheck %s
+# RUN: not llvm-mc -triple=aarch64  -mattr=+v8.5a -disassemble < %s 2>&1 | FileCheck %s --check-prefix=NOI8MM
+
+[0x01,0xa6,0x9f,0x4e]
+[0x01,0xa6,0x9f,0x6e]
+[0x01,0xae,0x9f,0x4e]
+# CHECK: smmla   v1.4s, v16.16b, v31.16b
+# CHECK: ummla   v1.4s, v16.16b, v31.16b
+# CHECK: usmmla  v1.4s, v16.16b, v31.16b
+# NOI8MM: [[@LINE-6]]:{{[0-9]+}}: warning: invalid instruction encoding
+# NOI8MM: [[@LINE-6]]:{{[0-9]+}}: warning: invalid instruction encoding
+# NOI8MM: [[@LINE-6]]:{{[0-9]+}}: warning: invalid instruction encoding
+
+[0xe3,0x9d,0x9e,0x0e]
+[0xe3,0x9d,0x9e,0x4e]
+# CHECK: usdot   v3.2s, v15.8b, v30.8b
+# CHECK: usdot   v3.4s, v15.16b, v30.16b
+# NOI8MM: [[@LINE-4]]:{{[0-9]+}}: warning: invalid instruction encoding
+# NOI8MM: [[@LINE-4]]:{{[0-9]+}}: warning: invalid instruction encoding
+
+[0x3f,0xf8,0xa2,0x0f]
+[0x3f,0xf8,0xa2,0x4f]
+# CHECK: usdot   v31.2s, v1.8b, v2.4b[3]
+# CHECK: usdot   v31.4s, v1.16b, v2.4b[3]
+# NOI8MM: [[@LINE-4]]:{{[0-9]+}}: warning: invalid instruction encoding
+# NOI8MM: [[@LINE-4]]:{{[0-9]+}}: warning: invalid instruction encoding
+
+[0x3f,0xf8,0x22,0x0f]
+[0x3f,0xf8,0x22,0x4f]
+# CHECK: sudot   v31.2s, v1.8b, v2.4b[3]
+# CHECK: sudot   v31.4s, v1.16b, v2.4b[3]
+# NOI8MM: [[@LINE-4]]:{{[0-9]+}}: warning: invalid instruction encoding
+# NOI8MM: [[@LINE-4]]:{{[0-9]+}}: warning: invalid instruction encoding
Index: llvm/test/MC/AArch64/armv8.6a-simd-matmul.s
===
--- /dev/null
+++ llvm/test/MC/AArch64/armv8.6a-simd-matmul.s
@@ -0,0 +1,43 @@
+// RUN: llvm-mc -triple aarch64 -show-encoding -mattr=+i8mm   < %s  | FileCheck %s
+// RUN: llvm-mc -triple aarch64 -show-encoding -mattr=+v8.6a  < %s  | FileCheck %s
+// RUN: not llvm-mc -triple aarch64 -show-encoding -mattr=+v8.6a-i8mm < %s 2>&1 | FileCheck %s --check-prefix=NOMATMUL
+
+smmla  v1.4s, v16.16b, v31.16b
+ummla  v1.4s, v16.16b, v31.16b
+usmmla v1.4s, v16.16b, v31.16b
+// CHECK: smmla   v1.4s, v16.16b, v31.16b // encoding: [0x01,0xa6,0x9f,0x4e]
+// CHECK: ummla   v1.4s, v16.16b, v31.16b // encoding: [0x01,0xa6,0x9f,0x6e]
+// CHECK: usmmla  v1.4s, v16.16b, v31.16b // encoding: [0x01,0xae,0x9f,0x4e]
+// NOMATMUL: instruction requires: i8mm
+// NOMATMUL-NEXT: smmla  v1.4s, v16.16b, v31.16b
+// NOMATMUL: instruction requires: i8mm
+// NOMATMUL-NEXT: ummla  v1.4s, v16.16b, v31.16b
+// NOMATMUL: instruction requires: i8mm
+// NOMATMUL-NEXT: usmmla  v1.4s, v16.16b, v31.16b
+
+usdot v3.2s, v15.8b, v30.8b
+usdot v3.4s, v15.16b, v30.16b
+// CHECK: usdot   v3.2s, v15.8b, v30.8b   // encoding: [0xe3,0x9d,0x9e,0x0e]
+// CHECK: usdot   v3.4s, v15.16b, v30.16b // encoding: [0xe3,0x9d,0x9e,0x4e]
+// NOMATMUL: instruction requires: i8mm
+// NOMATMUL-NEXT: usdot v3.2s, v15.8b, v30.8b
+// NOMATMUL: instruction requires: i8mm
+// NOMATMUL-NEXT: usdot v3.4s, v15.16b, v30.16b
+
+usdot v31.2s, v1.8b,  v2.4b[3]
+usdot v31.4s, v1.16b, v2.4b[3]
+// CHECK: usdot   v31.2s, v1.8b, v2.4b[3] // encoding: [0x3f,0xf8,0xa2,0x0f]
+// CHECK: usdot   v31.4s, v1.16b, v2.4b[3] // encoding: [0x3f,0xf8,0xa2,0x4f]
+// NOMATMUL: instruction requires: i8mm
+// NOMATMUL-NEXT: usdot   v31.2s, v1.8b, v2.4b[3]
+// NOMATMUL: instruction requires: i8mm
+// NOMATMUL-NEXT: usdot   v31.4s, v1.16b, v2.4b[3]
+
+sudot v31.2s, v1.8b,  v2.4b[3]
+sudot v31.4s, v1.16b, v2.4b[3]
+// CHECK: sudot   v31.2s, v1.8b, v2.4b[3] // encoding: [0x3f,0xf8,0x22,0x0f]
+// CHECK: sudot   v31.4s, v1.16b, v2.4b[3] // encoding: [0x3f,0xf8,0x22,0x4f]
+// NOMATMUL: instruction requires: i8mm
+// NOMATMUL-NEXT: sudot   v31.2s, v1.8b, v2.4

[PATCH] D77872: [AArch32] Armv8.6-a Matrix Mult Assembly + Intrinsics

2020-04-24 Thread Luke Geeson via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
LukeGeeson marked an inline comment as done.
Closed by commit rG7da190512532: [AArch32] Armv8.6-a Matrix Mult Assembly + 
Intrinsics (authored by LukeGeeson).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77872

Files:
  clang/lib/Basic/Targets/ARM.cpp
  clang/lib/Basic/Targets/ARM.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/arm-v8.6a-neon-intrinsics.c
  llvm/include/llvm/IR/IntrinsicsARM.td
  llvm/lib/Target/ARM/ARM.td
  llvm/lib/Target/ARM/ARMInstrNEON.td
  llvm/lib/Target/ARM/ARMPredicates.td
  llvm/lib/Target/ARM/ARMSubtarget.h
  llvm/test/CodeGen/ARM/arm-matmul.ll

Index: llvm/test/CodeGen/ARM/arm-matmul.ll
===
--- /dev/null
+++ llvm/test/CodeGen/ARM/arm-matmul.ll
@@ -0,0 +1,83 @@
+; RUN: llc -mtriple=arm-none-linux-gnu -mattr=+neon,+i8mm -float-abi=hard < %s -o -| FileCheck %s
+
+define <4 x i32> @smmla.v4i32.v16i8(<4 x i32> %r, <16 x i8> %a, <16 x i8> %b) {
+entry:
+; CHECK-LABEL: smmla.v4i32.v16i8
+; CHECK:vsmmla.s8   q0, q1, q2
+  %vmmla1.i = tail call <4 x i32> @llvm.arm.neon.smmla.v4i32.v16i8(<4 x i32> %r, <16 x i8> %a, <16 x i8> %b) #3
+  ret <4 x i32> %vmmla1.i
+}
+
+define <4 x i32> @ummla.v4i32.v16i8(<4 x i32> %r, <16 x i8> %a, <16 x i8> %b) {
+entry:
+; CHECK-LABEL: ummla.v4i32.v16i8
+; CHECK:vummla.u8   q0, q1, q2
+  %vmmla1.i = tail call <4 x i32> @llvm.arm.neon.ummla.v4i32.v16i8(<4 x i32> %r, <16 x i8> %a, <16 x i8> %b) #3
+  ret <4 x i32> %vmmla1.i
+}
+
+define <4 x i32> @usmmla.v4i32.v16i8(<4 x i32> %r, <16 x i8> %a, <16 x i8> %b) {
+entry:
+; CHECK-LABEL: usmmla.v4i32.v16i8
+; CHECK:vusmmla.s8   q0, q1, q2
+  %vusmmla1.i = tail call <4 x i32> @llvm.arm.neon.usmmla.v4i32.v16i8(<4 x i32> %r, <16 x i8> %a, <16 x i8> %b) #3
+  ret <4 x i32> %vusmmla1.i
+}
+
+define <2 x i32> @usdot.v2i32.v8i8(<2 x i32> %r, <8 x i8> %a, <8 x i8> %b) {
+entry:
+; CHECK-LABEL: usdot.v2i32.v8i8
+; CHECK:vusdot.s8   d0, d1, d2
+  %vusdot1.i = tail call <2 x i32> @llvm.arm.neon.usdot.v2i32.v8i8(<2 x i32> %r, <8 x i8> %a, <8 x i8> %b) #3
+  ret <2 x i32> %vusdot1.i
+}
+
+define <2 x i32> @usdot_lane.v2i32.v8i8(<2 x i32> %r, <8 x i8> %a, <8 x i8> %b) {
+entry:
+; CHECK-LABEL: usdot_lane.v2i32.v8i8
+; CHECK:vusdot.s8   d0, d1, d2[0]
+  %0 = bitcast <8 x i8> %b to <2 x i32>
+  %shuffle = shufflevector <2 x i32> %0, <2 x i32> undef, <2 x i32> zeroinitializer
+  %1 = bitcast <2 x i32> %shuffle to <8 x i8>
+  %vusdot1.i = tail call <2 x i32> @llvm.arm.neon.usdot.v2i32.v8i8(<2 x i32> %r, <8 x i8> %a, <8 x i8> %1) #3
+  ret <2 x i32> %vusdot1.i
+}
+
+define <2 x i32> @sudot_lane.v2i32.v8i8(<2 x i32> %r, <8 x i8> %a, <8 x i8> %b) {
+entry:
+; CHECK-LABEL: sudot_lane.v2i32.v8i8
+; CHECK:vsudot.u8   d0, d1, d2[0]
+  %0 = bitcast <8 x i8> %b to <2 x i32>
+  %shuffle = shufflevector <2 x i32> %0, <2 x i32> undef, <2 x i32> zeroinitializer
+  %1 = bitcast <2 x i32> %shuffle to <8 x i8>
+  %vusdot1.i = tail call <2 x i32> @llvm.arm.neon.usdot.v2i32.v8i8(<2 x i32> %r, <8 x i8> %1, <8 x i8> %a) #3
+  ret <2 x i32> %vusdot1.i
+}
+
+define <4 x i32> @usdotq_lane.v4i32.v16i8(<4 x i32> %r, <16 x i8> %a, <8 x i8> %b) {
+entry:
+; CHECK-LABEL: usdotq_lane.v4i32.v16i8
+; CHECK:vusdot.s8   q0, q1, d4[0]
+  %0 = bitcast <8 x i8> %b to <2 x i32>
+  %shuffle = shufflevector <2 x i32> %0, <2 x i32> undef, <4 x i32> zeroinitializer
+  %1 = bitcast <4 x i32> %shuffle to <16 x i8>
+  %vusdot1.i = tail call <4 x i32> @llvm.arm.neon.usdot.v4i32.v16i8(<4 x i32> %r, <16 x i8> %a, <16 x i8> %1) #3
+  ret <4 x i32> %vusdot1.i
+}
+
+define <4 x i32> @sudotq_lane.v4i32.v16i8(<4 x i32> %r, <16 x i8> %a, <8 x i8> %b) {
+entry:
+; CHECK-LABEL: sudotq_lane.v4i32.v16i8
+; CHECK:vsudot.u8   q0, q1, d4[0]
+  %0 = bitcast <8 x i8> %b to <2 x i32>
+  %shuffle = shufflevector <2 x i32> %0, <2 x i32> undef, <4 x i32> zeroinitializer
+  %1 = bitcast <4 x i32> %shuffle to <16 x i8>
+  %vusdot1.i = tail call <4 x i32> @llvm.arm.neon.usdot.v4i32.v16i8(<4 x i32> %r, <16 x i8> %1, <16 x i8> %a) #3
+  ret <4 x i32> %vusdot1.i
+}
+
+declare <4 x i32> @llvm.arm.neon.smmla.v4i32.v16i8(<4 x i32>, <16 x i8>, <16 x i8>) #2
+declare <4 x i32> @llvm.arm.neon.ummla.v4i32.v16i8(<4 x i32>, <16 x i8>, <16 x i8>) #2
+declare <4 x i32> @llvm.arm.neon.usmmla.v4i32.v16i8(<4 x i32>, <16 x i8>, <16 x i8>) #2
+declare <2 x i32> @llvm.arm.neon.usdot.v2i32.v8i8(<2 x i32>, <8 x i8>, <8 x i8>) #2
+declare <4 x i32> @llvm.arm.neon.usdot.v4i32.v16i8(<4 x i32>, <16 x i8>, <16 x i8>) #2
Index: llvm/lib/Target/ARM/ARMSubtarget.h
===
--- llvm/lib/Target/ARM/ARMSubtarget.h
+++ llvm/lib/Target/ARM/ARMSubtarget.h
@@ -260,6 +260,9 @@
   /// HasBF16 - True if subtarget supports BFloat16 floating point operations

[PATCH] D77875: [ARM] Armv8.6-a Matrix Mul cmd line support

2020-04-24 Thread Luke Geeson via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG740a1dd050ee: [ARM] Armv8.6-a Matrix Mul cmd line support 
(authored by LukeGeeson).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77875

Files:
  clang/lib/Driver/ToolChains/Arch/AArch64.cpp
  clang/test/Driver/aarch64-cpus.c
  clang/test/Driver/arm-matrix-multiply.c
  llvm/include/llvm/Support/AArch64TargetParser.def
  llvm/include/llvm/Support/AArch64TargetParser.h
  llvm/include/llvm/Support/ARMTargetParser.def
  llvm/include/llvm/Support/ARMTargetParser.h
  llvm/unittests/Support/TargetParserTest.cpp

Index: llvm/unittests/Support/TargetParserTest.cpp
===
--- llvm/unittests/Support/TargetParserTest.cpp
+++ llvm/unittests/Support/TargetParserTest.cpp
@@ -636,6 +636,7 @@
   {"maverick", "maverick", nullptr, nullptr},
   {"xscale", "noxscale", nullptr, nullptr},
   {"sb", "nosb", "+sb", "-sb"},
+  {"i8mm", "noi8mm", "+i8mm", "-i8mm"},
   {"mve", "nomve", "+mve", "-mve"},
   {"mve.fp", "nomve.fp", "+mve.fp", "-mve.fp"}};
 
@@ -1230,7 +1231,10 @@
   {"tme", "notme", "+tme", "-tme"},
   {"ssbs", "nossbs", "+ssbs", "-ssbs"},
   {"sb", "nosb", "+sb", "-sb"},
-  {"predres", "nopredres", "+predres", "-predres"}
+  {"predres", "nopredres", "+predres", "-predres"},
+  {"i8mm", "noi8mm", "+i8mm", "-i8mm"},
+  {"f32mm", "nof32mm", "+f32mm", "-f32mm"},
+  {"f64mm", "nof64mm", "+f64mm", "-f64mm"},
 };
 
   for (unsigned i = 0; i < array_lengthof(ArchExt); i++) {
Index: llvm/include/llvm/Support/ARMTargetParser.h
===
--- llvm/include/llvm/Support/ARMTargetParser.h
+++ llvm/include/llvm/Support/ARMTargetParser.h
@@ -47,14 +47,15 @@
   AEK_FP_DP   = 1 << 18,
   AEK_LOB = 1 << 19,
   AEK_BF16= 1 << 20,
-  AEK_CDECP0 =  1 << 21,
-  AEK_CDECP1 =  1 << 22,
-  AEK_CDECP2 =  1 << 23,
-  AEK_CDECP3 =  1 << 24,
-  AEK_CDECP4 =  1 << 25,
-  AEK_CDECP5 =  1 << 26,
-  AEK_CDECP6 =  1 << 27,
-  AEK_CDECP7 =  1 << 28,
+  AEK_I8MM= 1 << 21,
+  AEK_CDECP0 =  1 << 22,
+  AEK_CDECP1 =  1 << 23,
+  AEK_CDECP2 =  1 << 24,
+  AEK_CDECP3 =  1 << 25,
+  AEK_CDECP4 =  1 << 26,
+  AEK_CDECP5 =  1 << 27,
+  AEK_CDECP6 =  1 << 28,
+  AEK_CDECP7 =  1 << 29,
 
   // Unsupported extensions.
   AEK_OS   =1ULL << 59,
Index: llvm/include/llvm/Support/ARMTargetParser.def
===
--- llvm/include/llvm/Support/ARMTargetParser.def
+++ llvm/include/llvm/Support/ARMTargetParser.def
@@ -116,7 +116,8 @@
  ARMBuildAttrs::CPUArch::v8_A, FK_CRYPTO_NEON_FP_ARMV8,
  (ARM::AEK_SEC| ARM::AEK_MP   | ARM::AEK_VIRT | ARM::AEK_HWDIVARM |
   ARM::AEK_HWDIVTHUMB | ARM::AEK_DSP  | ARM::AEK_CRC  | ARM::AEK_RAS |
-  ARM::AEK_DOTPROD| ARM::AEK_BF16 | ARM::AEK_SHA2 | ARM::AEK_AES))
+  ARM::AEK_DOTPROD| ARM::AEK_BF16 | ARM::AEK_SHA2 | ARM::AEK_AES |
+  ARM::AEK_I8MM))
 ARM_ARCH("armv8-r", ARMV8R, "8-R", "v8r", ARMBuildAttrs::CPUArch::v8_R,
   FK_NEON_FP_ARMV8,
   (ARM::AEK_MP | ARM::AEK_VIRT | ARM::AEK_HWDIVARM | ARM::AEK_HWDIVTHUMB |
@@ -171,6 +172,7 @@
 ARM_ARCH_EXT_NAME("fp16fml",  ARM::AEK_FP16FML,  "+fp16fml", "-fp16fml")
 ARM_ARCH_EXT_NAME("bf16", ARM::AEK_BF16, "+bf16","-bf16")
 ARM_ARCH_EXT_NAME("sb",   ARM::AEK_SB,   "+sb",  "-sb")
+ARM_ARCH_EXT_NAME("i8mm", ARM::AEK_I8MM, "+i8mm","-i8mm")
 ARM_ARCH_EXT_NAME("lob",  ARM::AEK_LOB,  "+lob",   "-lob")
 ARM_ARCH_EXT_NAME("cdecp0",   ARM::AEK_CDECP0,   "+cdecp0",  "-cdecp0")
 ARM_ARCH_EXT_NAME("cdecp1",   ARM::AEK_CDECP1,   "+cdecp1",  "-cdecp1")
Index: llvm/include/llvm/Support/AArch64TargetParser.h
===
--- llvm/include/llvm/Support/AArch64TargetParser.h
+++ llvm/include/llvm/Support/AArch64TargetParser.h
@@ -24,7 +24,7 @@
 namespace AArch64 {
 
 // Arch extension modifiers for CPUs.
-enum ArchExtKind : unsigned {
+enum ArchExtKind : uint64_t {
   AEK_INVALID = 0,
   AEK_NONE =1,
   AEK_CRC = 1 << 1,
@@ -57,6 +57,8 @@
   AEK_TME = 1 << 28,
   AEK_BF16 =1 << 29,
   AEK_I8MM =1 << 30,
+  AEK_F32MM =   1ULL << 31,
+  AEK_F64MM =   1ULL << 32,
 };
 
 enum class ArchKind {
Index: llvm/include/llvm/Support/AArch64TargetParser.def
=

[PATCH] D78457: [analyzer][Z3-refutation] Fix refutation BugReporterVisitor bug and refactor

2020-04-24 Thread Gábor Horváth via Phabricator via cfe-commits

xazax.hun added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:2871
+  // Overwrite the associated constraint of the Symbol.
+  Constraints = CF.remove(Constraints, Sym);
   Constraints = CF.add(Constraints, Sym, C.second);

martong wrote:
> martong wrote:
> > martong wrote:
> > > steakhal wrote:
> > > > How can we simplify this?
> > > Could we change the visitation logic to start with the `EndPathNode`? I 
> > > mean could we exercise `FalsePositiveRefutationBRVisitor` to start the 
> > > visitation from `EndPathNode`? If that was possible then this whole patch 
> > > would be way simpler.
> > > In BugReporter.cpp:
> > > ```
> > >   // Run visitors on all nodes starting from the node *before* the last 
> > > one.
> > >   // The last node is reserved for notes generated with {@code 
> > > getEndPath}.
> > >   const ExplodedNode *NextNode = ErrorNode->getFirstPred();
> > >   while (NextNode) {
> > > ```
> > > Why can't we have a different visitation order implemented specifically 
> > > for the refutation visitor? (@NoQ, @xazax.hun)
> > Hmm, to answer my own question, then we would visit the ErrorNode twice. So 
> > then perhaps we should not allow any constraints in the ErrorNodes, right? 
> > What if we'd split all such ErrorNodes into a PrevNode with the constraints 
> > and a simple ErrorNode without the constraints?
> @xazax.hun, and others: Any thoughts on my comments above? What do you think, 
> would it be possible to split the error node into two nodes? A PrevNode with 
> the constraints and a simple ErrorNode without the constraints?
I think this would make a lot of sense in the context of this visitor. But we 
would need to check if it also makes sense in the context of the other parts of 
the analyzer (other visitors and mechanisms like bug report generation). I'd 
prefer such a change to be a separate patch so we can assess it easier whether 
it makes things easier or more complicated. I think it might be worth to 
experiment with.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78457



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

[PATCH] D78129: Add Marvell ThunderX3T110 support

2020-04-24 Thread Kyrill Tkachov via Phabricator via cfe-commits

ktkachov added inline comments.



Comment at: llvm/lib/Target/AArch64/AArch64InstrInfo.td:849-857
+// These pointer authentication instructions require armv8.3a
+let Predicates = [HasV8_3a, HasPA] in {
 let Uses = [LR], Defs = [LR] in {
   def PACIAZ   : SystemNoOperands<0b000, "hint\t#24">;
   def PACIBZ   : SystemNoOperands<0b010, "hint\t#26">;
   let isAuthenticated = 1 in {
 def AUTIAZ   : SystemNoOperands<0b100, "hint\t#28">;

IIRC these instructions are deliberately allowed in pre-armv8.3 targets because 
they are encoded in the NOP-space and can be deployed on pre-armv8.3 targets 



Comment at: llvm/lib/Target/AArch64/AArch64SchedThunderX3T110.td:9
+//
+// This file defines the scheduling model for Marvell ThunderX3T101
+// family of processors.

Typo in the processor name?


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

https://reviews.llvm.org/D78129



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

[PATCH] D78129: Add Marvell ThunderX3T110 support

2020-04-24 Thread Wei Zhao via Phabricator via cfe-commits

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



Comment at: llvm/lib/Target/AArch64/AArch64InstrInfo.td:849-857
+// These pointer authentication instructions require armv8.3a
+let Predicates = [HasV8_3a, HasPA] in {
 let Uses = [LR], Defs = [LR] in {
   def PACIAZ   : SystemNoOperands<0b000, "hint\t#24">;
   def PACIBZ   : SystemNoOperands<0b010, "hint\t#26">;
   let isAuthenticated = 1 in {
 def AUTIAZ   : SystemNoOperands<0b100, "hint\t#28">;

ktkachov wrote:
> IIRC these instructions are deliberately allowed in pre-armv8.3 targets 
> because they are encoded in the NOP-space and can be deployed on pre-armv8.3 
> targets 
I will do some research on this.



Comment at: llvm/lib/Target/AArch64/AArch64SchedThunderX3T110.td:9
+//
+// This file defines the scheduling model for Marvell ThunderX3T101
+// family of processors.

ktkachov wrote:
> Typo in the processor name?
Sure, thanks for spotting it. I will have it fixed.


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

https://reviews.llvm.org/D78129



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

[PATCH] D78374: [Analyzer][StreamChecker] Added evaluation of fread and fwrite.

2020-04-24 Thread Kristóf Umann via Phabricator via cfe-commits

Szelethus added a comment.

I gave a lot of thought to the high level logic, but I need some time to really 
internalize whats happening here.

In D78374#1993858 , @balazske wrote:

> Finally I had to make the decision to remove the `ErrorKindTy` enum and use 
> boolean flags instead for every possible error (including no error). This is 
> needed because we do not know always what error is possible if it is 
> "unknown". It could be determined from the last operation but now not any 
> more. The documentation for `fread` says that if 0 is passed as the size or 
> count argument the function returns zero and does not change the state. So 
> the error state before `fread` remains active. The new design is to have bool 
> values for every error kind (**feof** and **ferror** and a no-error state) so 
> multiple can be active in a state to indicate that more than one error state 
> is possible. If no-error or **feof** is possible these flags are turned on. 
> If we need to know in such a state if the stream is in **EOF** a state split 
> is needed to handle both cases (one with **EOF** and one with no-error). This 
> split must be done in the pre-call handler, for example if we want a warning 
> that the operation is not safe to use in **EOF** state. (But in this case 
> really no split is needed, only clear the EOF flag and make a warning.)


I guess one solution would be to have a history of last operations on the 
stream, but overall, it makes sense to have a make a shift to calculate the 
possible errors as we're evaluating the functions. Great idea!

> We can have another approach if we do not set return values of the functions 
> at all, instead save the symbol of the function and determine the returned 
> value later from the constraints actually applied on it. This may save state 
> splits, but only until a condition is encountered that checks for the 
> function's return value.

Or any stream modifying operation. If we don't have branches for the return 
value, that is almost a bug in itself. Also, digging the return value out of a 
branch condition may be difficult (see `ReturnValueChecker`). Lets stick with 
the state splits at the function call for now.




Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:222
 {StreamState::FEof, StreamState::FError, StreamState::NoError}}},
-  {{"ftell", 1}, {&StreamChecker::preDefault, nullptr, 0, {}}},
+  // Note: ftell sets errno only.
+  {{"ftell", 1},

balazske wrote:
> Szelethus wrote:
> > Szelethus wrote:
> > > C'99 standard [[ 
> > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf | 
> > > §7.19.9.4.3]], about the `ftell function`:
> > > 
> > > > If successful, the `ftell` function returns the current value of the 
> > > > file position indicator for the stream. On failure, the `ftell` 
> > > > function returns `-1L` and stores an implementation-defined positive 
> > > > value in `errno`.
> > > 
> > > So we need an evalCall for this.
> > I mean, this function can only fail if the stream itself is an erroneous or 
> > closed state, right? So we can associate the -1 return value with the 
> > stream being in that, and the other with the stream being opened.
> The `ftell` is part of a later patch that is adding `ftell` (and probably 
> other functions). Only the "PossibleErrors" was updated in this patch because 
> its meaning was changed (it contains value even if only one error kind is 
> possible, before it was used only if at least two errors are possible).
> It is not sure how the file operations work, maybe the `ftell` needs access 
> to some data that is not available at the moment (and can fail even if the 
> stream was not OK). If the stream is already in failed state the question is: 
> Do ftell fail (then the we can make it return -1) or it does not fail but 
> gives an unusable value (then generate a checker warning and stop the 
> analysis).
In any case, this should be removed from the patch, because adding it seems to 
be an orthogonal change to this one.



Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:37
+/// Note: A stream has either FEOF or FERROR set but not both at the same time.
+struct StreamErrorState {
+  /// There is an execution path with none of the error flags set.

We're not describing the error state of a stream here, but rather //possible// 
error states, so the name should reflect that.



Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:207-210
+  {{"fread", 4},
+   {&StreamChecker::preFread,
+std::bind(&StreamChecker::evalFreadFwrite, _1, _2, _3, _4,
+  ErrorFEof | ErrorFError),

What does this mean? I guess not the possible states after an fread call, but 
rather the possible states after a **failed** fread call, but then...



Comment at: clang/lib/StaticAnalyzer/Ch

[PATCH] D77540: [PATCH] [ARM]: Armv8.6-a Matrix Mul Asm and Intrinsics Support

2020-04-24 Thread Luke Geeson via Phabricator via cfe-commits

LukeGeeson abandoned this revision.
LukeGeeson added a comment.

Sub-issues all closed


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

https://reviews.llvm.org/D77540



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

[clang] 6395980 - [Driver] Move GCC multilib/multiarch paths support from Linux.cpp to Gnu.cpp

2020-04-24 Thread Fangrui Song via cfe-commits


Author: Samuel Thibault
Date: 2020-04-24T09:33:19-07:00
New Revision: 63959803702c66cbd72f6526f43914039c1a027b

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

LOG: [Driver] Move GCC multilib/multiarch paths support from Linux.cpp to 
Gnu.cpp

The current code for GNU/Linux is actually completely generic, and can be moved 
to ToolChains/Gnu.cpp,
so that it can benefit GNU/Hurd and GNU/kFreeBSD.

Reviewed By: MaskRay, phosek

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/Gnu.cpp
clang/lib/Driver/ToolChains/Gnu.h
clang/lib/Driver/ToolChains/Linux.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Gnu.cpp 
b/clang/lib/Driver/ToolChains/Gnu.cpp
index 0ea33fc20e86..315988faf40a 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -35,6 +35,7 @@ using namespace clang;
 using namespace llvm::opt;
 
 using tools::addMultilibFlag;
+using tools::addPathIfExists;
 
 void tools::GnuTool::anchor() {}
 
@@ -2670,6 +2671,140 @@ bool Generic_GCC::IsIntegratedAssemblerDefault() const {
   }
 }
 
+static void addMultilibsFilePaths(const Driver &D, const MultilibSet 
&Multilibs,
+  const Multilib &Multilib,
+  StringRef InstallPath,
+  ToolChain::path_list &Paths) {
+  if (const auto &PathsCallback = Multilibs.filePathsCallback())
+for (const auto &Path : PathsCallback(Multilib))
+  addPathIfExists(D, InstallPath + Path, Paths);
+}
+
+void Generic_GCC::PushPPaths(ToolChain::path_list &PPaths) {
+  // Cross-compiling binutils and GCC installations (vanilla and openSUSE at
+  // least) put various tools in a triple-prefixed directory off of the parent
+  // of the GCC installation. We use the GCC triple here to ensure that we end
+  // up with tools that support the same amount of cross compiling as the
+  // detected GCC installation. For example, if we find a GCC installation
+  // targeting x86_64, but it is a bi-arch GCC installation, it can also be
+  // used to target i386.
+  if (GCCInstallation.isValid()) {
+PPaths.push_back(Twine(GCCInstallation.getParentLibPath() + "/../" +
+   GCCInstallation.getTriple().str() + "/bin")
+ .str());
+  }
+}
+
+void Generic_GCC::AddMultilibPaths(const Driver &D,
+   const std::string &SysRoot,
+   const std::string &OSLibDir,
+   const std::string &MultiarchTriple,
+   path_list &Paths) {
+  // Add the multilib suffixed paths where they are available.
+  if (GCCInstallation.isValid()) {
+const llvm::Triple &GCCTriple = GCCInstallation.getTriple();
+const std::string &LibPath =
+std::string(GCCInstallation.getParentLibPath());
+
+// Add toolchain / multilib specific file paths.
+addMultilibsFilePaths(D, Multilibs, SelectedMultilib,
+  GCCInstallation.getInstallPath(), Paths);
+
+// Sourcery CodeBench MIPS toolchain holds some libraries under
+// a biarch-like suffix of the GCC installation.
+addPathIfExists(
+D, GCCInstallation.getInstallPath() + SelectedMultilib.gccSuffix(),
+Paths);
+
+// GCC cross compiling toolchains will install target libraries which ship
+// as part of the toolchain under // rather than as
+// any part of the GCC installation in
+// //gcc//. This decision is somewhat
+// debatable, but is the reality today. We need to search this tree even
+// when we have a sysroot somewhere else. It is the responsibility of
+// whomever is doing the cross build targeting a sysroot using a GCC
+// installation that is *not* within the system root to ensure two things:
+//
+//  1) Any DSOs that are linked in from this tree or from the install path
+// above must be present on the system root and found via an
+// appropriate rpath.
+//  2) There must not be libraries installed into
+// // unless they should be preferred over
+// those within the system root.
+//
+// Note that this matches the GCC behavior. See the below comment for where
+// Clang diverges from GCC's behavior.
+addPathIfExists(D,
+LibPath + "/../" + GCCTriple.str() + "/lib/../" + OSLibDir 
+
+SelectedMultilib.osSuffix(),
+Paths);
+
+// If the GCC installation we found is inside of the sysroot, we want to
+// prefer libraries installed in the parent prefix of the GCC installation.
+// It is important to *not* use these paths when the GCC installation i

[PATCH] D78812: [SVE][CodeGen] Fix legalisation for scalable types

2020-04-24 Thread Kerry McLaughlin via Phabricator via cfe-commits

kmclaughlin created this revision.
kmclaughlin added reviewers: sdesmalen, efriedma, huntergr.
Herald added subscribers: psnobl, rkruppe, hiraditya, tschuett.
Herald added a project: LLVM.

This patch handles illegal scalable types when lowering IR operations,
addressing several places where the value of isScalableVector() is
ignored.

For types such as , this means splitting the
operations. In this example, we would split it into two
operations of type  for the low and high halves.

In cases such as , the elements in the vector
will be promoted. In this case they will be promoted to
i64 (with a vector of type )


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D78812

Files:
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
  llvm/lib/CodeGen/TargetLoweringBase.cpp
  llvm/test/CodeGen/AArch64/llvm-ir-to-intrinsic.ll

Index: llvm/test/CodeGen/AArch64/llvm-ir-to-intrinsic.ll
===
--- llvm/test/CodeGen/AArch64/llvm-ir-to-intrinsic.ll
+++ llvm/test/CodeGen/AArch64/llvm-ir-to-intrinsic.ll
@@ -22,6 +22,37 @@
   ret  %div
 }
 
+define  @sdiv_split_i32( %a,  %b) {
+; CHECK-LABEL: @sdiv_split_i32
+; CHECK-DAG: ptrue p0.s
+; CHECK-DAG: sdiv z0.s, p0/m, z0.s, z2.s
+; CHECK-DAG: sdiv z1.s, p0/m, z1.s, z3.s
+; CHECK-NEXT: ret
+  %div = sdiv  %a, %b
+  ret  %div
+}
+
+define  @sdiv_widen_i32( %a,  %b) {
+; CHECK-LABEL: @sdiv_widen_i32
+; CHECK-DAG: ptrue p0.d
+; CHECK-DAG: sxtw z1.d, p0/m, z1.d
+; CHECK-DAG: sxtw z0.d, p0/m, z0.d
+; CHECK-DAG: sdiv z0.d, p0/m, z0.d, z1.d
+; CHECK-NEXT: ret
+  %div = sdiv  %a, %b
+  ret  %div
+}
+
+define  @sdiv_split_i64( %a,  %b) {
+; CHECK-LABEL: @sdiv_split_i64
+; CHECK-DAG: ptrue p0.d
+; CHECK-DAG: sdiv z0.d, p0/m, z0.d, z2.d
+; CHECK-DAG: sdiv z1.d, p0/m, z1.d, z3.d
+; CHECK-NEXT: ret
+  %div = sdiv  %a, %b
+  ret  %div
+}
+
 ;
 ; UDIV
 ;
@@ -43,3 +74,34 @@
   %div = udiv  %a, %b
   ret  %div
 }
+
+define  @udiv_split_i32( %a,  %b) {
+; CHECK-LABEL: @udiv_split_i32
+; CHECK-DAG: ptrue p0.s
+; CHECK-DAG: udiv z0.s, p0/m, z0.s, z2.s
+; CHECK-DAG: udiv z1.s, p0/m, z1.s, z3.s
+; CHECK-NEXT: ret
+  %div = udiv  %a, %b
+  ret  %div
+}
+
+define  @udiv_widen_i32( %a,  %b) {
+; CHECK-LABEL: @udiv_widen_i32
+; CHECK-DAG: ptrue p0.d
+; CHECK-DAG: and z1.d, z1.d, #0x
+; CHECK-DAG: and z0.d, z0.d, #0x
+; CHECK-DAG: udiv z0.d, p0/m, z0.d, z1.d
+; CHECK-NEXT: ret
+  %div = udiv  %a, %b
+  ret  %div
+}
+
+define  @udiv_split_i64( %a,  %b) {
+; CHECK-LABEL: @udiv_split_i64
+; CHECK-DAG: ptrue p0.d
+; CHECK-DAG: udiv z0.d, p0/m, z0.d, z2.d
+; CHECK-DAG: udiv z1.d, p0/m, z1.d, z3.d
+; CHECK-NEXT: ret
+  %div = udiv  %a, %b
+  ret  %div
+}
Index: llvm/lib/CodeGen/TargetLoweringBase.cpp
===
--- llvm/lib/CodeGen/TargetLoweringBase.cpp
+++ llvm/lib/CodeGen/TargetLoweringBase.cpp
@@ -1393,6 +1393,7 @@
 unsigned &NumIntermediates,
 MVT &RegisterVT) const {
   unsigned NumElts = VT.getVectorNumElements();
+  bool IsScalable = VT.isScalableVector();
 
   // If there is a wider vector type with the same element type as this one,
   // or a promoted vector type that has the same number of elements which
@@ -1424,15 +1425,15 @@
 
   // Divide the input until we get to a supported size.  This will always
   // end with a scalar if the target doesn't support vectors.
-  while (NumElts > 1 && !isTypeLegal(
-   EVT::getVectorVT(Context, EltTy, NumElts))) {
+  while (NumElts > 1 &&
+ !isTypeLegal(EVT::getVectorVT(Context, EltTy, NumElts, IsScalable))) {
 NumElts >>= 1;
 NumVectorRegs <<= 1;
   }
 
   NumIntermediates = NumVectorRegs;
 
-  EVT NewVT = EVT::getVectorVT(Context, EltTy, NumElts);
+  EVT NewVT = EVT::getVectorVT(Context, EltTy, NumElts, IsScalable);
   if (!isTypeLegal(NewVT))
 NewVT = EltTy;
   IntermediateVT = NewVT;
Index: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
===
--- llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
+++ llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
@@ -734,7 +734,8 @@
   unsigned DestVectorNoElts = NumIntermediates * IntermediateNumElts;
 
   EVT BuiltVectorTy = EVT::getVectorVT(
-  *DAG.getContext(), IntermediateVT.getScalarType(), DestVectorNoElts);
+  *DAG.getContext(), IntermediateVT.getScalarType(), DestVectorNoElts,
+  ValueVT.isScalableVector());
   if (ValueVT != BuiltVectorTy) {
 if (SDValue Widened = widenVectorToPartType(DAG, Val, DL, BuiltVectorTy))
   Val = Widened;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D78807: Fix gendered documentation

2020-04-24 Thread Jonas Devlieghere via Phabricator via cfe-commits

JDevlieghere accepted this revision.
JDevlieghere added a comment.

Thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78807



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

[PATCH] D73845: [Gnu toolchain] Move GCC multilib/multiarch paths support from Linux to Gnu

2020-04-24 Thread Fangrui Song via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG63959803702c: [Driver] Move GCC multilib/multiarch paths 
support from Linux.cpp to Gnu.cpp (authored by sthibaul, committed by MaskRay).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73845

Files:
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/Gnu.h
  clang/lib/Driver/ToolChains/Linux.cpp

Index: clang/lib/Driver/ToolChains/Linux.cpp
===
--- clang/lib/Driver/ToolChains/Linux.cpp
+++ clang/lib/Driver/ToolChains/Linux.cpp
@@ -208,15 +208,6 @@
   return Triple.isArch32Bit() ? "lib" : "lib64";
 }
 
-static void addMultilibsFilePaths(const Driver &D, const MultilibSet &Multilibs,
-  const Multilib &Multilib,
-  StringRef InstallPath,
-  ToolChain::path_list &Paths) {
-  if (const auto &PathsCallback = Multilibs.filePathsCallback())
-for (const auto &Path : PathsCallback(Multilib))
-  addPathIfExists(D, InstallPath + Path, Paths);
-}
-
 Linux::Linux(const Driver &D, const llvm::Triple &Triple, const ArgList &Args)
 : Generic_ELF(D, Triple, Args) {
   GCCInstallation.init(Triple, Args);
@@ -224,21 +215,9 @@
   SelectedMultilib = GCCInstallation.getMultilib();
   llvm::Triple::ArchType Arch = Triple.getArch();
   std::string SysRoot = computeSysRoot();
-
-  // Cross-compiling binutils and GCC installations (vanilla and openSUSE at
-  // least) put various tools in a triple-prefixed directory off of the parent
-  // of the GCC installation. We use the GCC triple here to ensure that we end
-  // up with tools that support the same amount of cross compiling as the
-  // detected GCC installation. For example, if we find a GCC installation
-  // targeting x86_64, but it is a bi-arch GCC installation, it can also be
-  // used to target i386.
-  // FIXME: This seems unlikely to be Linux-specific.
   ToolChain::path_list &PPaths = getProgramPaths();
-  if (GCCInstallation.isValid()) {
-PPaths.push_back(Twine(GCCInstallation.getParentLibPath() + "/../" +
-   GCCInstallation.getTriple().str() + "/bin")
- .str());
-  }
+
+  Generic_GCC::PushPPaths(PPaths);
 
   Distro Distro(D.getVFS(), Triple);
 
@@ -316,58 +295,7 @@
   const std::string OSLibDir = std::string(getOSLibDir(Triple, Args));
   const std::string MultiarchTriple = getMultiarchTriple(D, Triple, SysRoot);
 
-  // Add the multilib suffixed paths where they are available.
-  if (GCCInstallation.isValid()) {
-const llvm::Triple &GCCTriple = GCCInstallation.getTriple();
-const std::string &LibPath =
-std::string(GCCInstallation.getParentLibPath());
-
-// Add toolchain / multilib specific file paths.
-addMultilibsFilePaths(D, Multilibs, SelectedMultilib,
-  GCCInstallation.getInstallPath(), Paths);
-
-// Sourcery CodeBench MIPS toolchain holds some libraries under
-// a biarch-like suffix of the GCC installation.
-addPathIfExists(
-D, GCCInstallation.getInstallPath() + SelectedMultilib.gccSuffix(),
-Paths);
-
-// GCC cross compiling toolchains will install target libraries which ship
-// as part of the toolchain under // rather than as
-// any part of the GCC installation in
-// //gcc//. This decision is somewhat
-// debatable, but is the reality today. We need to search this tree even
-// when we have a sysroot somewhere else. It is the responsibility of
-// whomever is doing the cross build targeting a sysroot using a GCC
-// installation that is *not* within the system root to ensure two things:
-//
-//  1) Any DSOs that are linked in from this tree or from the install path
-// above must be present on the system root and found via an
-// appropriate rpath.
-//  2) There must not be libraries installed into
-// // unless they should be preferred over
-// those within the system root.
-//
-// Note that this matches the GCC behavior. See the below comment for where
-// Clang diverges from GCC's behavior.
-addPathIfExists(D, LibPath + "/../" + GCCTriple.str() + "/lib/../" +
-   OSLibDir + SelectedMultilib.osSuffix(),
-Paths);
-
-// If the GCC installation we found is inside of the sysroot, we want to
-// prefer libraries installed in the parent prefix of the GCC installation.
-// It is important to *not* use these paths when the GCC installation is
-// outside of the system root as that can pick up unintended libraries.
-// This usually happens when there is an external cross compiler on the
-// host system, and a more minimal sysroot available that is the target of
-// the cross. Note that GCC does include some of

Re: [Lldb-commits] [PATCH] D78807: Fix gendered documentation

2020-04-24 Thread Jim Ingham via cfe-commits

A lot of our comments and documentation was written a while ago when the “good” 
practice was to be careful to use “he” and “she” in equal measure when 
referring to our users.  The consensus has shifted to using “they” instead, so 
there are probably a bunch of other places using he and she.  Please feel free 
to fix this wherever you see it!

Thanks!

Jim

> On Apr 24, 2020, at 9:43 AM, Jonas Devlieghere via Phabricator via 
> lldb-commits  wrote:
> 
> JDevlieghere accepted this revision.
> JDevlieghere added a comment.
> 
> Thank you!
> 
> 
> Repository:
>  rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D78807/new/
> 
> https://reviews.llvm.org/D78807
> 
> 
> 
> ___
> lldb-commits mailing list
> lldb-comm...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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

[PATCH] D77954: [CUDA][HIP] Fix host/device based overload resolution

2020-04-24 Thread Artem Belevich via Phabricator via cfe-commits

tra added inline comments.



Comment at: clang/lib/Sema/SemaOverload.cpp:9749
+  if (isBetterMultiversionCandidate(Cand1, Cand2))
+return true;
+

yaxunl wrote:
> rjmccall wrote:
> > tra wrote:
> > > rjmccall wrote:
> > > > erichkeane wrote:
> > > > > yaxunl wrote:
> > > > > > echristo wrote:
> > > > > > > rjmccall wrote:
> > > > > > > > yaxunl wrote:
> > > > > > > > > rjmccall wrote:
> > > > > > > > > > If we move anything below this check, it needs to figure 
> > > > > > > > > > out a tri-state so that it can return false if `Cand2` is a 
> > > > > > > > > > better candidate than `Cand1`.  Now, that only matters if 
> > > > > > > > > > multiversion functions are supported under CUDA, but if 
> > > > > > > > > > you're relying on them not being supported, that should at 
> > > > > > > > > > least be commented on.
> > > > > > > > > multiversion host functions is orthogonal to CUDA therefore 
> > > > > > > > > should be supported. multiversion in device, host device, and 
> > > > > > > > > global functions are not supported. However this change does 
> > > > > > > > > not make things worse, and should continue to work if they 
> > > > > > > > > are supported.
> > > > > > > > > 
> > > > > > > > > host/device based overloading resolution is mostly for 
> > > > > > > > > determining viability of a function. If two functions are 
> > > > > > > > > both viable, other factors should take precedence in 
> > > > > > > > > preference. This general rule has been taken for cases other 
> > > > > > > > > than multiversion, I think it should also apply to 
> > > > > > > > > multiversion.
> > > > > > > > > 
> > > > > > > > > I will make isBetterMultiversionCandidate three states.
> > > > > > > > > This general rule has been taken for cases other than 
> > > > > > > > > multiversion, I think it should also apply to multiversion.
> > > > > > > > 
> > > > > > > > Well, but the multiversion people could say the same: that 
> > > > > > > > multiversioning is for picking an alternative among 
> > > > > > > > otherwise-identical functions, and HD and H functions are not 
> > > > > > > > otherwise-identical.
> > > > > > > > 
> > > > > > > > CC'ing @echristo for his thoughts on the right ordering here.
> > > > > > > Adding @erichkeane here as well.
> > > > > > > 
> > > > > > > I think this makes sense, but I can see a reason to multiversion 
> > > > > > > a function that will run on host and device. A version of some 
> > > > > > > matrix mult that takes advantage of 3 host architectures and one 
> > > > > > > cuda one? Am I missing something here?
> > > > > > My understanding is that a multiversion function is for a specific 
> > > > > > cpu(gpu). Let's say we want to have a function f for gfx900, 
> > > > > > gfx906, sandybridge, ivybridge, shouldn't they be more like
> > > > > > 
> > > > > > ```
> > > > > > __host__ __attribute__((cpu_specific(sandybridge))) f();
> > > > > > __host__ __attribute__((cpu_specific(ivybridge))) f();
> > > > > > __device__ __attribute__((cpu_specific(gfx900))) f();
> > > > > > __device__ __attribute__((cpu_specific(gfx906))) f();
> > > > > > ```
> > > > > > instead of all `__device__ __host__` functions?
> > > > > IMO, it doesn't make sense for functions to functions be BOTH host 
> > > > > and device, they'd have to be just one.  Otherwise I'm not sure how 
> > > > > the resolver behavior is supposed to work.  The whole idea is that 
> > > > > the definition is chosen at runtime.
> > > > > 
> > > > > Unless __host__ __device void foo(); is TWO declaration chains 
> > > > > (meaning two separate AST entries), it doesn't make sense to have 
> > > > > multiverison on it (and then, how it would be spelled is 
> > > > > awkward/confusing to me).
> > > > > 
> > > > > In the above case, if those 4 declarations are not 2 separate root- 
> > > > > AST nodes, multiversioning won't work.
> > > > There are certainly functions that ought to be usable from either host 
> > > > or device context — any inline function that just does ordinary 
> > > > language things should be in that category.  Also IIUC many 
> > > > declarations are *inferred* to be `__host__ __device__`, or can be 
> > > > mass-annotated with pragmas, and those reasons are probably the main 
> > > > ones this might matter — we might include a header in CUDA mode that 
> > > > declares a multi-versioned function, and we should handle it right.
> > > > 
> > > > My read of how CUDA programmers expect this to work is that they see 
> > > > the `__host__` / `__device__` attributes as primarily a mechanism for 
> > > > catching problems where you're using the wrong functions for the 
> > > > current configuration.  That is, while we allow overloading by 
> > > > `__host__`/`__device__`-ness, users expect those attributes to mostly 
> > > > be used as a filter for what's "really there" rather than really 
> > > > strictly segregating the namespace.  So I would say that CUDA 
> > > > programmers would probably expe

[PATCH] D77954: [CUDA][HIP] Fix host/device based overload resolution

2020-04-24 Thread John McCall via Phabricator via cfe-commits

rjmccall accepted this revision.
rjmccall added a comment.

Thanks, Yaxun.  LGTM.


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

https://reviews.llvm.org/D77954



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

[PATCH] D78817: clang: Allow backend unsupported warnings

2020-04-24 Thread Matt Arsenault via Phabricator via cfe-commits

arsenm created this revision.
arsenm added reviewers: yaxunl, Anastasia, olista01, ostannard, xur.
Herald added subscribers: tpr, wdng.

Currently this asserts on anything other than errors. In one
workaround scenario, AMDGPU emits DiagnosticInfoUnsupported as a
warning for functions that can't be correctly codegened, but should
never be executed.


https://reviews.llvm.org/D78817

Files:
  clang/include/clang/Basic/DiagnosticFrontendKinds.td
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/test/CodeGenOpenCL/backend-unsupported-warning.ll


Index: clang/test/CodeGenOpenCL/backend-unsupported-warning.ll
===
--- /dev/null
+++ clang/test/CodeGenOpenCL/backend-unsupported-warning.ll
@@ -0,0 +1,30 @@
+; RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -S -o - %s 2>&1 | FileCheck %s
+
+; Check that a DiagnosticUnsupported reported as a warning works
+; correctly, and is not emitted as an error.
+
+; CHECK: warning: test.c:2:20: in function use_lds_global_in_func i32 (): 
local memory global used by non-kernel function
+
+target triple = "amdgcn-amd-amdhsa"
+
+@lds = external addrspace(3) global i32, align 4
+
+define i32 @use_lds_global_in_func() !dbg !5 {
+  %load = load i32, i32 addrspace(3)* @lds, !dbg !9
+  ret i32 %load, !dbg !10
+}
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "clang 
version 3.9.0", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, 
enums: !2)
+!1 = !DIFile(filename: "test.c", directory: "")
+!2 = !{}
+!3 = !{i32 2, !"Dwarf Version", i32 4}
+!4 = !{i32 2, !"Debug Info Version", i32 3}
+!5 = distinct !DISubprogram(name: "bar", scope: !1, file: !1, line: 2, type: 
!6, scopeLine: 2, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !2)
+!6 = !DISubroutineType(types: !7)
+!7 = !{!8}
+!8 = !DIBasicType(name: "int", size: 32, align: 32, encoding: DW_ATE_signed)
+!9 = !DILocation(line: 2, column: 20, scope: !5)
+!10 = !DILocation(line: 2, column: 13, scope: !5)
Index: clang/lib/CodeGen/CodeGenAction.cpp
===
--- clang/lib/CodeGen/CodeGenAction.cpp
+++ clang/lib/CodeGen/CodeGenAction.cpp
@@ -633,8 +633,9 @@
 
 void BackendConsumer::UnsupportedDiagHandler(
 const llvm::DiagnosticInfoUnsupported &D) {
-  // We only support errors.
-  assert(D.getSeverity() == llvm::DS_Error);
+  // We only support warnings or errors.
+  assert(D.getSeverity() == llvm::DS_Error ||
+ D.getSeverity() == llvm::DS_Warning);
 
   StringRef Filename;
   unsigned Line, Column;
@@ -652,7 +653,11 @@
 DiagnosticPrinterRawOStream DP(MsgStream);
 D.print(DP);
   }
-  Diags.Report(Loc, diag::err_fe_backend_unsupported) << MsgStream.str();
+
+  auto DiagType = D.getSeverity() == llvm::DS_Error
+  ? diag::err_fe_backend_unsupported
+  : diag::warn_fe_backend_unsupported;
+  Diags.Report(Loc, DiagType) << MsgStream.str();
 
   if (BadDebugInfo)
 // If we were not able to translate the file:line:col information
Index: clang/include/clang/Basic/DiagnosticFrontendKinds.td
===
--- clang/include/clang/Basic/DiagnosticFrontendKinds.td
+++ clang/include/clang/Basic/DiagnosticFrontendKinds.td
@@ -61,6 +61,7 @@
   "not determine the original source location for %0:%1:%2">, BackendInfo;
 
 def err_fe_backend_unsupported : Error<"%0">, BackendInfo;
+def warn_fe_backend_unsupported : Warning<"%0">, BackendInfo;
 
 def err_fe_invalid_code_complete_file : Error<
 "cannot locate code-completion file %0">, DefaultFatal;


Index: clang/test/CodeGenOpenCL/backend-unsupported-warning.ll
===
--- /dev/null
+++ clang/test/CodeGenOpenCL/backend-unsupported-warning.ll
@@ -0,0 +1,30 @@
+; RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -S -o - %s 2>&1 | FileCheck %s
+
+; Check that a DiagnosticUnsupported reported as a warning works
+; correctly, and is not emitted as an error.
+
+; CHECK: warning: test.c:2:20: in function use_lds_global_in_func i32 (): local memory global used by non-kernel function
+
+target triple = "amdgcn-amd-amdhsa"
+
+@lds = external addrspace(3) global i32, align 4
+
+define i32 @use_lds_global_in_func() !dbg !5 {
+  %load = load i32, i32 addrspace(3)* @lds, !dbg !9
+  ret i32 %load, !dbg !10
+}
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "clang version 3.9.0", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !2)
+!1 = !DIFile(filename: "test.c", directory: "")
+!2 = !{}
+!3 = !{i32 2, !"Dwarf Version", i32 4}
+!4 = !{i32 2, !"Debug Info Version", i32 3}
+!5 = distinct !DISubprogram(name: "bar", scope: !1, file: !1, line: 2, type: !6, scopeLine: 2, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !2)
+!6 = !DISubrout

[PATCH] D78767: [Sema] Teach -Wcast-align to compute a more accurate alignment when the source expression has array subscript or pointer arithmetic operators

2020-04-24 Thread John McCall via Phabricator via cfe-commits

rjmccall added inline comments.



Comment at: clang/include/clang/AST/Expr.h:710
+  /// possible to compute the alignment, return zero.
+  CharUnits getAlignmentFromDecl(ASTContext &Ctx) const;
+

Nothing about the name here suggests that it only works on expressions of 
pointer type.  Maybe call it `getPresumedAlignmentOfPointer` or something and 
then make it also consider the type alignment?



Comment at: clang/lib/AST/ExprConstant.cpp:14844
+  if (auto *VD = Result.Base.dyn_cast())
+return Ctx.getDeclAlign(VD).alignmentAtOffset(Result.Offset);
+

Does this do the right thing if `getDeclAlign` returns 0, or can that never 
happen?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78767



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

[PATCH] D78655: [HIP] Let lambda be host device by default

2020-04-24 Thread John McCall via Phabricator via cfe-commits

rjmccall added a comment.

Seems reasonable




Comment at: clang/test/CodeGenCUDA/lambda.cu:29
+
+// Check lambda is emitted in device compilation and accessind device variable.
+// DEV-LABEL: define internal void @_ZZ4mainENKUlvE_clEv

Typo


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

https://reviews.llvm.org/D78655



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

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

2020-04-24 Thread John McCall via Phabricator via cfe-commits

rjmccall added a comment.

LGTM with one very minor fix.




Comment at: clang/docs/LanguageExtensions.rst:511
+*r = *a +  (*b * *c);
+  }
+

fhahn wrote:
> rjmccall wrote:
> > This is kindof an unnecessarily unreadable example.  I know you haven't 
> > decided on calling convention treatment yet, but maybe the leading example 
> > could be just a little ahead of the implementation and just take the 
> > matrices as arguments and then return the result.
> I wasn't sure if that would be fine, but it indeed makes things much more 
> readable. Updated.
Extra space after the `+`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76612



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

[PATCH] D78785: Fix x86/x86_64 calling convention for _ExtInt

2020-04-24 Thread John McCall via Phabricator via cfe-commits

rjmccall added a comment.

Is there something currently restricting these types to just x86, or do you 
need to do a much broader audit?




Comment at: clang/lib/CodeGen/TargetInfo.cpp:2980
 
-return (Ty->isPromotableIntegerType() ? ABIArgInfo::getExtend(Ty)
-  : ABIArgInfo::getDirect());
+if (!Ty->isExtIntType())
+  return (Ty->isPromotableIntegerType() ? ABIArgInfo::getExtend(Ty)

Presumably *some* `ExtInt` types should be returned directly.


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

https://reviews.llvm.org/D78785



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

[PATCH] D77592: [NFC][CodeGen] Add enum for selecting the layout of components in the vtable

2020-04-24 Thread John McCall via Phabricator via cfe-commits

rjmccall added a comment.

Okay.  The plan sounds good to me.  So you want to roll out this enum in this 
patch, but not really use it for much until the follow-up?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77592



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

[PATCH] D78785: Fix x86/x86_64 calling convention for _ExtInt

2020-04-24 Thread Erich Keane via Phabricator via cfe-commits

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



Comment at: clang/lib/CodeGen/TargetInfo.cpp:2980
 
-return (Ty->isPromotableIntegerType() ? ABIArgInfo::getExtend(Ty)
-  : ABIArgInfo::getDirect());
+if (!Ty->isExtIntType())
+  return (Ty->isPromotableIntegerType() ? ABIArgInfo::getExtend(Ty)

rjmccall wrote:
> Presumably *some* `ExtInt` types should be returned directly.
Right, and they are.  This is only for cases where we request an 'indirect 
result', so cases where we've already decided that it cannot be passed direct.

At this point, the 'classify' step has already been done, which would have 
decided that <=128 bit values are passed 'direct', and we've requested an 
indirect.  At least as far as I can tell from this code/debugging.


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

https://reviews.llvm.org/D78785



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

[PATCH] D72959: Relative VTables ABI on Fuchsia

2020-04-24 Thread John McCall via Phabricator via cfe-commits

rjmccall added inline comments.



Comment at: clang/lib/CodeGen/CGVTables.cpp:623
+llvm::Constant *C, llvm::GlobalVariable *VTable, unsigned vtableIdx,
+unsigned lastAddrPoint) const {
+  // No need to get the offset of a nullptr.

There's already an `addRelativeOffset` on `ConstantArrayBuilder`; is that 
insufficient for some reason?  I think that, if v-table building were 
refactored so that the places that build components also add them to the 
v-table, we'd end up with a lot more flexibility for the ABIs.  We needed a 
similar sort of change for pointer authentication, which we haven't upstreamed 
to LLVM yet, but which you can see here:

https://github.com/apple/llvm-project/blob/apple/master/clang/lib/CodeGen/CGVTables.cpp




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72959



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

[PATCH] D78762: build: use `find_package(Python3)` if available

2020-04-24 Thread Saleem Abdulrasool via Phabricator via cfe-commits

compnerd updated this revision to Diff 259923.
compnerd added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Include clang as some of the CI uses the unified build which fails without the 
update.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78762

Files:
  clang/CMakeLists.txt
  clang/bindings/python/tests/CMakeLists.txt
  clang/test/lit.site.cfg.py.in
  clang/utils/perf-training/CMakeLists.txt
  clang/utils/perf-training/lit.site.cfg.in
  clang/utils/perf-training/order-files.lit.site.cfg.in
  llvm/CMakeLists.txt
  llvm/cmake/config-ix.cmake
  llvm/cmake/modules/AddLLVM.cmake
  llvm/test/lit.site.cfg.py.in

Index: llvm/test/lit.site.cfg.py.in
===
--- llvm/test/lit.site.cfg.py.in
+++ llvm/test/lit.site.cfg.py.in
@@ -12,7 +12,7 @@
 config.llvm_shlib_ext = "@SHLIBEXT@"
 config.llvm_exe_ext = "@EXEEXT@"
 config.lit_tools_dir = path(r"@LLVM_LIT_TOOLS_DIR@")
-config.python_executable = "@PYTHON_EXECUTABLE@"
+config.python_executable = "@Python3_EXECUTABLE@"
 config.gold_executable = "@GOLD_EXECUTABLE@"
 config.ld64_executable = "@LD64_EXECUTABLE@"
 config.ocamlfind_executable = "@OCAMLFIND@"
Index: llvm/cmake/modules/AddLLVM.cmake
===
--- llvm/cmake/modules/AddLLVM.cmake
+++ llvm/cmake/modules/AddLLVM.cmake
@@ -117,7 +117,7 @@
 set(native_export_file "${target_name}.def")
 
 add_custom_command(OUTPUT ${native_export_file}
-  COMMAND ${PYTHON_EXECUTABLE} -c "import sys;print(''.join(['EXPORTS\\n']+sys.stdin.readlines(),))"
+  COMMAND "${Python3_EXECUTABLE}" -c "import sys;print(''.join(['EXPORTS\\n']+sys.stdin.readlines(),))"
 < ${export_file} > ${native_export_file}
   DEPENDS ${export_file}
   VERBATIM
@@ -1001,7 +1001,7 @@
   set(mangling itanium)
 endif()
 add_custom_command(OUTPUT ${exported_symbol_file}
-   COMMAND ${PYTHON_EXECUTABLE} ${LLVM_MAIN_SRC_DIR}/utils/extract_symbols.py --mangling=${mangling} ${static_libs} -o ${exported_symbol_file}
+   COMMAND "${Python3_EXECUTABLE}" ${LLVM_MAIN_SRC_DIR}/utils/extract_symbols.py --mangling=${mangling} ${static_libs} -o ${exported_symbol_file}
WORKING_DIRECTORY ${LLVM_LIBRARY_OUTPUT_INTDIR}
DEPENDS ${LLVM_MAIN_SRC_DIR}/utils/extract_symbols.py ${static_libs}
VERBATIM
@@ -1402,7 +1402,7 @@
   # empty list entries. So escape the ;s in the list and do the splitting
   # ourselves. cmake has no relpath function, so use Python for that.
   string(REPLACE ";" "\\;" pathlist_escaped "${pathlist}")
-  execute_process(COMMAND "${PYTHON_EXECUTABLE}" "-c" "\n
+  execute_process(COMMAND "${Python3_EXECUTABLE}" "-c" "\n
 import os, sys\n
 base = sys.argv[1]
 def haslink(p):\n
@@ -1477,7 +1477,6 @@
   # SHLIBDIR points the build tree.
   string(REPLACE "${CMAKE_CFG_INTDIR}" "${LLVM_BUILD_MODE}" SHLIBDIR "${LLVM_SHLIB_OUTPUT_INTDIR}")
 
-  set(PYTHON_EXECUTABLE ${PYTHON_EXECUTABLE})
   # FIXME: "ENABLE_SHARED" doesn't make sense, since it is used just for
   # plugins. We may rename it.
   if(LLVM_ENABLE_PLUGINS)
@@ -1635,7 +1634,7 @@
 ALLOW_EXTERNAL
 )
 
-  set(LIT_COMMAND "${PYTHON_EXECUTABLE};${lit_base_dir}/${lit_file_name}")
+  set(LIT_COMMAND "${Python3_EXECUTABLE};${lit_base_dir}/${lit_file_name}")
   list(APPEND LIT_COMMAND ${LIT_ARGS})
   foreach(param ${ARG_PARAMS})
 list(APPEND LIT_COMMAND --param ${param})
Index: llvm/cmake/config-ix.cmake
===
--- llvm/cmake/config-ix.cmake
+++ llvm/cmake/config-ix.cmake
@@ -639,7 +639,7 @@
 return()
   endif()
 
-  execute_process(COMMAND "${PYTHON_EXECUTABLE}" "-c" "import ${module}"
+  execute_process(COMMAND "${Python3_EXECUTABLE}" "-c" "import ${module}"
 RESULT_VARIABLE status
 ERROR_QUIET)
 
Index: llvm/CMakeLists.txt
===
--- llvm/CMakeLists.txt
+++ llvm/CMakeLists.txt
@@ -672,16 +672,38 @@
 
 include(HandleLLVMOptions)
 
-include(FindPythonInterp)
-if( NOT PYTHONINTERP_FOUND )
-  message(FATAL_ERROR
-"Unable to find Python interpreter, required for builds and testing.
+if(CMAKE_VERSION VERSION_LESS 3.12)
+  include(FindPythonInterp)
+  if( NOT PYTHONINTERP_FOUND )
+message(FATAL_ERROR
+  "Unable to find Python interpreter, required for builds and testing.
 
-Please install Python or specify the PYTHON_EXECUTABLE CMake variable.")
-endif()
+  Please install Python or specify the PYTHON_EXECUTABLE CMake variable.")
+  endif()
+
+  if( ${PYTHON_VERSION_STRING} VERSION_LESS 2.7 )
+message(FATAL_ERROR "Python 2.7 or newer is required")
+  endif()
 
-if( ${PYTHON_VERSION_STRING} VERSION_LESS 2.7 )
-  message(FATAL_ERROR "Python 2.7 or newer is required")
+  add_executabl

[PATCH] D77592: [NFC][CodeGen] Add enum for selecting the layout of components in the vtable

2020-04-24 Thread Leonard Chan via Phabricator via cfe-commits

leonardchan added a comment.

In D77592#2002148 , @rjmccall wrote:

> Okay.  The plan sounds good to me.  So you want to roll out this enum in this 
> patch, but not really use it for much until the follow-up?

That was the plan, but I can also add include the cc1 flag for selecting the 
`Relative` layout and some initial vtable changes in this patch so it can be 
tested. The first patch after this that would be using it will be large 
regardless.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77592

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

[clang] 0ed5b0d - [X86] Don't use types when getting the intrinsic declaration for x86_avx512_mask_vcvtph2ps_512.

2020-04-24 Thread Craig Topper via cfe-commits


Author: Craig Topper
Date: 2020-04-24T11:01:22-07:00
New Revision: 0ed5b0d517cb781d4949cc4bfa9854bc276ee13a

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

LOG: [X86] Don't use types when getting the intrinsic declaration for 
x86_avx512_mask_vcvtph2ps_512.

This intrinsic isn't overloaded so we should query with types.
Doing so causes the backend to miss the intrinsic and not codegen it.
This eventually leads to a linker error.

Added: 


Modified: 
clang/lib/CodeGen/CGBuiltin.cpp
clang/test/CodeGen/avx512f-builtins.c

Removed: 




diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index 3a66583e20e8..18ad1664aa56 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -10961,10 +10961,8 @@ static Value *EmitX86CvtF16ToFloatExpr(CodeGenFunction 
&CGF,
 
   // If the SAE intrinsic doesn't use default rounding then we can't upgrade.
   if (Ops.size() == 4 && cast(Ops[3])->getZExtValue() != 4) 
{
-Intrinsic::ID IID = Intrinsic::x86_avx512_mask_vcvtph2ps_512;
 Function *F =
-CGF.CGM.getIntrinsic(IID, {DstTy, Ops[0]->getType(), Ops[1]->getType(),
-   Ops[2]->getType(), Ops[3]->getType()});
+CGF.CGM.getIntrinsic(Intrinsic::x86_avx512_mask_vcvtph2ps_512);
 return CGF.Builder.CreateCall(F, {Ops[0], Ops[1], Ops[2], Ops[3]});
   }
 

diff  --git a/clang/test/CodeGen/avx512f-builtins.c 
b/clang/test/CodeGen/avx512f-builtins.c
index c193e7d3a477..7be73ecbd1cd 100644
--- a/clang/test/CodeGen/avx512f-builtins.c
+++ b/clang/test/CodeGen/avx512f-builtins.c
@@ -4976,21 +4976,21 @@ __m256i test_mm512_maskz_cvt_roundps_ph(__mmask16 __U, 
__m512  __A)
 __m512 test_mm512_cvt_roundph_ps(__m256i __A)
 {
 // CHECK-LABEL: @test_mm512_cvt_roundph_ps
-// CHECK: @llvm.x86.avx512.mask.vcvtph2ps.512
+// CHECK: @llvm.x86.avx512.mask.vcvtph2ps.512(
 return _mm512_cvt_roundph_ps(__A, _MM_FROUND_NO_EXC);
 }
 
 __m512 test_mm512_mask_cvt_roundph_ps(__m512 __W, __mmask16 __U, __m256i __A)
 {
 // CHECK-LABEL: @test_mm512_mask_cvt_roundph_ps
-// CHECK: @llvm.x86.avx512.mask.vcvtph2ps.512
+// CHECK: @llvm.x86.avx512.mask.vcvtph2ps.512(
 return _mm512_mask_cvt_roundph_ps(__W, __U, __A, _MM_FROUND_NO_EXC);
 }
 
 __m512 test_mm512_maskz_cvt_roundph_ps(__mmask16 __U, __m256i __A)
 {
 // CHECK-LABEL: @test_mm512_maskz_cvt_roundph_ps
-// CHECK: @llvm.x86.avx512.mask.vcvtph2ps.512
+// CHECK: @llvm.x86.avx512.mask.vcvtph2ps.512(
 return _mm512_maskz_cvt_roundph_ps(__U, __A, _MM_FROUND_NO_EXC);
 }
 



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

[PATCH] D77621: Change BitcodeWriter buffer to std::vector instead of SmallVector.

2020-04-24 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits

dexonsmith added a comment.

@nikic, great news!  Thanks for doing the detailed analysis.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77621



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

[PATCH] D78659: Add nomerge function attribute to supress tail merge optimization in simplifyCFG

2020-04-24 Thread Zequan Wu via Phabricator via cfe-commits

zequanwu updated this revision to Diff 259938.
Herald added subscribers: dexonsmith, steven_wu.

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

https://reviews.llvm.org/D78659

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/attr-nomerge.c
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  llvm/include/llvm/IR/Attributes.td
  llvm/include/llvm/IR/InstrTypes.h
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/AsmParser/LLToken.h
  llvm/lib/IR/Attributes.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Transforms/Utils/SimplifyCFG.cpp

Index: llvm/lib/Transforms/Utils/SimplifyCFG.cpp
===
--- llvm/lib/Transforms/Utils/SimplifyCFG.cpp
+++ llvm/lib/Transforms/Utils/SimplifyCFG.cpp
@@ -1287,6 +1287,14 @@
 if (!TTI.isProfitableToHoist(I1) || !TTI.isProfitableToHoist(I2))
   return Changed;
 
+// If any of the two call sites has nomerge attribute, stop hoisting.
+if (const auto *CB1 = dyn_cast(I1))
+  if (CB1->cannotMerge())
+return Changed;
+if (const auto *CB2 = dyn_cast(I2))
+  if (CB2->cannotMerge())
+return Changed;
+
 if (isa(I1) || isa(I2)) {
   assert (isa(I1) && isa(I2));
   // The debug location is an integral part of a debug info intrinsic
@@ -1472,8 +1480,9 @@
 // Conservatively return false if I is an inline-asm instruction. Sinking
 // and merging inline-asm instructions can potentially create arguments
 // that cannot satisfy the inline-asm constraints.
+// If the instruction has nomerge attribute, return false.
 if (const auto *C = dyn_cast(I))
-  if (C->isInlineAsm())
+  if (C->isInlineAsm() || C->cannotMerge())
 return false;
 
 // Each instruction must have zero or one use.
Index: llvm/lib/IR/Verifier.cpp
===
--- llvm/lib/IR/Verifier.cpp
+++ llvm/lib/IR/Verifier.cpp
@@ -1509,6 +1509,7 @@
 /// Return true if this attribute kind only applies to functions.
 static bool isFuncOnlyAttr(Attribute::AttrKind Kind) {
   switch (Kind) {
+  case Attribute::NoMerge:
   case Attribute::NoReturn:
   case Attribute::NoSync:
   case Attribute::WillReturn:
Index: llvm/lib/IR/Attributes.cpp
===
--- llvm/lib/IR/Attributes.cpp
+++ llvm/lib/IR/Attributes.cpp
@@ -368,6 +368,8 @@
 return "noinline";
   if (hasAttribute(Attribute::NonLazyBind))
 return "nonlazybind";
+  if (hasAttribute(Attribute::NoMerge))
+return "nomerge";
   if (hasAttribute(Attribute::NonNull))
 return "nonnull";
   if (hasAttribute(Attribute::NoRedZone))
Index: llvm/lib/AsmParser/LLToken.h
===
--- llvm/lib/AsmParser/LLToken.h
+++ llvm/lib/AsmParser/LLToken.h
@@ -204,6 +204,7 @@
   kw_noinline,
   kw_norecurse,
   kw_nonlazybind,
+  kw_nomerge,
   kw_nonnull,
   kw_noredzone,
   kw_noreturn,
Index: llvm/lib/AsmParser/LLParser.cpp
===
--- llvm/lib/AsmParser/LLParser.cpp
+++ llvm/lib/AsmParser/LLParser.cpp
@@ -1306,6 +1306,7 @@
   B.addAttribute(Attribute::NoImplicitFloat); break;
 case lltok::kw_noinline: B.addAttribute(Attribute::NoInline); break;
 case lltok::kw_nonlazybind: B.addAttribute(Attribute::NonLazyBind); break;
+case lltok::kw_nomerge: B.addAttribute(Attribute::NoMerge); break;
 case lltok::kw_noredzone: B.addAttribute(Attribute::NoRedZone); break;
 case lltok::kw_noreturn: B.addAttribute(Attribute::NoReturn); break;
 case lltok::kw_nosync: B.addAttribute(Attribute::NoSync); break;
@@ -1682,6 +1683,7 @@
 case lltok::kw_noimplicitfloat:
 case lltok::kw_noinline:
 case lltok::kw_nonlazybind:
+case lltok::kw_nomerge:
 case lltok::kw_noredzone:
 case lltok::kw_noreturn:
 case lltok::kw_nocf_check:
@@ -1781,6 +1783,7 @@
 case lltok::kw_noimplicitfloat:
 case lltok::kw_noinline:
 case lltok::kw_nonlazybind:
+case lltok::kw_nomerge:
 case lltok::kw_noredzone:
 case lltok::kw_noreturn:
 case lltok::kw_nocf_check:
Index: llvm/lib/AsmParser/LLLexer.cpp
===
--- llvm/lib/AsmParser/LLLexer.cpp
+++ llvm/lib/AsmParser/LLLexer.cpp
@@ -658,6 +658,7 @@
   KEYWORD(noinline);
   KEYWORD(norecurse);
   KEYWORD(nonlazybind);
+  KEYWORD(nomerge);
   KEYWORD(nonnull);
   KEYWORD(noredzone);
   KEYWORD(noreturn);
Index: llvm/include/llvm/IR/InstrTypes.h
===
--- llvm/include/llvm/IR/InstrTypes.h
+++ llvm/include/llvm/IR/InstrTypes.h
@@ -1717,6 +1717,9 @@
 addAttribute(AttributeList::FunctionIndex, Attribute::NoDuplicate);
   }
 
+  /// Determine if the invoke cannot be tail merged.
+

[PATCH] D78817: clang: Allow backend unsupported warnings

2020-04-24 Thread Yaxun Liu via Phabricator via cfe-commits

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

LGTM. Thanks.


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

https://reviews.llvm.org/D78817



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

[PATCH] D78192: Support compiler extensions as a normal component

2020-04-24 Thread serge via Phabricator via cfe-commits

serge-sans-paille added a comment.

The patch landed without much errors, only added the patchset 
e307eeba0137700e75893089cf0de03383d851ca 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78192



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

[PATCH] D72959: Relative VTables ABI on Fuchsia

2020-04-24 Thread Leonard Chan via Phabricator via cfe-commits

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



Comment at: clang/lib/CodeGen/CGVTables.cpp:623
+llvm::Constant *C, llvm::GlobalVariable *VTable, unsigned vtableIdx,
+unsigned lastAddrPoint) const {
+  // No need to get the offset of a nullptr.

rjmccall wrote:
> There's already an `addRelativeOffset` on `ConstantArrayBuilder`; is that 
> insufficient for some reason?  I think that, if v-table building were 
> refactored so that the places that build components also add them to the 
> v-table, we'd end up with a lot more flexibility for the ABIs.  We needed a 
> similar sort of change for pointer authentication, which we haven't 
> upstreamed to LLVM yet, but which you can see here:
> 
> https://github.com/apple/llvm-project/blob/apple/master/clang/lib/CodeGen/CGVTables.cpp
> 
> 
I actually did not know about this method, but it does seem to boil down to the 
same arithmetic used here. Will update to see if I can use the existing 
builders instead.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72959



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

[PATCH] D78762: build: use `find_package(Python3)` if available

2020-04-24 Thread Jonas Devlieghere via Phabricator via cfe-commits

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

I would strongly prefer to do this differently. While we hope to drop Python 2 
support in LLDB as soon as possible, we are not there yet. This patch as it 
stands will make it really hard for us to keep doing so (even internally) if 
upstream decides to drop support. I have looked into this change myself a while 
ago with these limitations in mind, and believe we can achieve the same in a 
way that would make this easier.

My suggestion is to have 4 new CMake variable that abstract over this: 
`LLVM_PYTHON_EXECUTABLE`, `LLVM_PYTHON_LIBRARIES`, `LLVM_PYTHON_INCLUDE_DIRS` 
and finally `LLVM_PYTHON_HINT`.  We can then populate the first three depending 
on what machinery we want to use, i.e. the old CMake way of finding Python 
(until we bump the requirement across llvm), as well as the new `FindPython3` 
and `FindPython2`. Similarly for the `HINT` variable, having our own 
abstraction means we don't clobber any of the variables used internally by 
CMake.

What do you think?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78762



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

[PATCH] D78777: [AST] Use PrintingPolicy for format string diagnosis

2020-04-24 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman accepted this revision.
aaron.ballman 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/D78777/new/

https://reviews.llvm.org/D78777



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

[PATCH] D77954: [CUDA][HIP] Fix host/device based overload resolution

2020-04-24 Thread Yaxun Liu via Phabricator via cfe-commits

yaxunl added a comment.

@tra Is it OK I commit it now? Or better wait next Monday morning? Thanks.


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

https://reviews.llvm.org/D77954



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

[PATCH] D77979: [clang-tidy] modernize-use-using: Fix broken fixit with InjectedClassName

2020-04-24 Thread Aaron Ballman via Phabricator via cfe-commits

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

LGTM aside from a commenting nit.




Comment at: clang/include/clang/AST/PrettyPrinter.h:248
+  /// Whether to print an InjectedClassNameType with template arguments or as
+  /// written. When a template arguments are unnamed, printing them results in
+  /// invalid C++ code.

When a template arguments are... -> When a template argument is unnamed, 
printing it results in invalid C++ code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77979



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

[clang] c77a407 - [CUDA][HIP] Fix host/device based overload resolution

2020-04-24 Thread Yaxun Liu via cfe-commits


Author: Yaxun (Sam) Liu
Date: 2020-04-24T14:55:18-04:00
New Revision: c77a4078e01033aa2206c31a579d217c8a07569b

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

LOG: [CUDA][HIP] Fix host/device based overload resolution

Currently clang fails to compile the following CUDA program in device 
compilation:

__host__ int foo(int x) {
 return 1;
}

template
__device__ __host__ int foo(T x) {
return 2;
}

__device__ __host__ int bar() {
return foo(1);
}

__global__ void test(int *a) {
*a = bar();
}

This is due to foo is resolved to the __host__ foo instead of __device__ 
__host__ foo.
This seems to be a bug since __device__ __host__ foo is a viable callee for foo 
whereas
clang is unable to choose it.

This patch fixes that.

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

Added: 


Modified: 
clang/lib/Sema/SemaOverload.cpp
clang/test/SemaCUDA/function-overload.cu

Removed: 




diff  --git a/clang/lib/Sema/SemaOverload.cpp b/clang/lib/Sema/SemaOverload.cpp
index a32bc0c84c70..ecc4e7ee19fb 100644
--- a/clang/lib/Sema/SemaOverload.cpp
+++ b/clang/lib/Sema/SemaOverload.cpp
@@ -9374,16 +9374,22 @@ static Comparison compareEnableIfAttrs(const Sema &S, 
const FunctionDecl *Cand1,
   return Comparison::Equal;
 }
 
-static bool isBetterMultiversionCandidate(const OverloadCandidate &Cand1,
-  const OverloadCandidate &Cand2) {
+static Comparison
+isBetterMultiversionCandidate(const OverloadCandidate &Cand1,
+  const OverloadCandidate &Cand2) {
   if (!Cand1.Function || !Cand1.Function->isMultiVersion() || !Cand2.Function 
||
   !Cand2.Function->isMultiVersion())
-return false;
+return Comparison::Equal;
 
-  // If Cand1 is invalid, it cannot be a better match, if Cand2 is invalid, 
this
-  // is obviously better.
-  if (Cand1.Function->isInvalidDecl()) return false;
-  if (Cand2.Function->isInvalidDecl()) return true;
+  // If both are invalid, they are equal. If one of them is invalid, the other
+  // is better.
+  if (Cand1.Function->isInvalidDecl()) {
+if (Cand2.Function->isInvalidDecl())
+  return Comparison::Equal;
+return Comparison::Worse;
+  }
+  if (Cand2.Function->isInvalidDecl())
+return Comparison::Better;
 
   // If this is a cpu_dispatch/cpu_specific multiversion situation, prefer
   // cpu_dispatch, else arbitrarily based on the identifiers.
@@ -9393,16 +9399,18 @@ static bool isBetterMultiversionCandidate(const 
OverloadCandidate &Cand1,
   const auto *Cand2CPUSpec = Cand2.Function->getAttr();
 
   if (!Cand1CPUDisp && !Cand2CPUDisp && !Cand1CPUSpec && !Cand2CPUSpec)
-return false;
+return Comparison::Equal;
 
   if (Cand1CPUDisp && !Cand2CPUDisp)
-return true;
+return Comparison::Better;
   if (Cand2CPUDisp && !Cand1CPUDisp)
-return false;
+return Comparison::Worse;
 
   if (Cand1CPUSpec && Cand2CPUSpec) {
 if (Cand1CPUSpec->cpus_size() != Cand2CPUSpec->cpus_size())
-  return Cand1CPUSpec->cpus_size() < Cand2CPUSpec->cpus_size();
+  return Cand1CPUSpec->cpus_size() < Cand2CPUSpec->cpus_size()
+ ? Comparison::Better
+ : Comparison::Worse;
 
 std::pair
 FirstDiff = std::mismatch(
@@ -9415,7 +9423,9 @@ static bool isBetterMultiversionCandidate(const 
OverloadCandidate &Cand1,
 assert(FirstDiff.first != Cand1CPUSpec->cpus_end() &&
"Two 
diff erent cpu-specific versions should not have the same "
"identifier list, otherwise they'd be the same decl!");
-return (*FirstDiff.first)->getName() < (*FirstDiff.second)->getName();
+return (*FirstDiff.first)->getName() < (*FirstDiff.second)->getName()
+   ? Comparison::Better
+   : Comparison::Worse;
   }
   llvm_unreachable("No way to get here unless both had cpu_dispatch");
 }
@@ -9475,6 +9485,50 @@ bool clang::isBetterOverloadCandidate(
   else if (!Cand1.Viable)
 return false;
 
+  // [CUDA] A function with 'never' preference is marked not viable, therefore
+  // is never shown up here. The worst preference shown up here is 'wrong 
side',
+  // e.g. a host function called by a device host function in device
+  // compilation. This is valid AST as long as the host device function is not
+  // emitted, e.g. it is an inline function which is called only by a host
+  // function. A deferred diagnostic will be triggered if it is emitted.
+  // However a wrong-sided function is still a viable candidate here.
+  //
+  // If Cand1 can be emitted and Cand2 cannot be emitted in the current
+  // context, Cand1 is better than Cand2. If Cand1 can not be emitted and Cand2
+  // can be emitted, Cand1 is not better than Cand2. This rule should have
+  // precedence over other rules.
+

1 2 >

1 - 100 of 164 matches

Mail list logo