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

2020-04-27 Thread Saleem Abdulrasool via Phabricator via cfe-commits
compnerd closed this revision.
compnerd added a comment.

rGcd84bfb8142bc7ff3a07a188ffb809f1d86d1fd7 
 (with the 
Python2 fixes)


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] D78979: OpenCL: Include builtin header by default

2020-04-27 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added a comment.

I'm also wondering if using -nogpulib for the corresponding linker purpose was 
correct, since in the OpenCL case it's not really an offload target. Maybe this 
should switch to -nostdlib?


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

https://reviews.llvm.org/D78979



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


[PATCH] D78979: OpenCL: Include builtin header by default

2020-04-27 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

In D78979#2006847 , @arsenm wrote:

> I'm also wondering if using -nogpulib for the corresponding linker purpose 
> was correct, since in the OpenCL case it's not really an offload target. 
> Maybe this should switch to -nostdlib?


-nogpulib is fine since opencl compiler is in parallel with the device compiler 
of CUDA/HIP. The library it uses is the device library.




Comment at: clang/lib/Frontend/CompilerInvocation.cpp:2548
 
-  Opts.IncludeDefaultHeader = Args.hasArg(OPT_finclude_default_header);
+  Opts.IncludeDefaultHeader = !Args.hasArg(OPT_fno_include_default_header);
   Opts.DeclareOpenCLBuiltins = Args.hasArg(OPT_fdeclare_opencl_builtins);

should use hasFlag in case there are multiple occurrences of both options. 


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

https://reviews.llvm.org/D78979



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


[PATCH] D78853: [Analysis] Fix null pointer dereference warnings [1/n]

2020-04-27 Thread Mandeep Singh Grang via Phabricator via cfe-commits
mgrang updated this revision to Diff 260517.
mgrang retitled this revision from "[Sema] Fix null pointer dereference 
warnings [1/n]" to "[Analysis] Fix null pointer dereference warnings [1/n]".

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

https://reviews.llvm.org/D78853

Files:
  clang/lib/Analysis/ThreadSafety.cpp


Index: clang/lib/Analysis/ThreadSafety.cpp
===
--- clang/lib/Analysis/ThreadSafety.cpp
+++ clang/lib/Analysis/ThreadSafety.cpp
@@ -1935,6 +1935,10 @@
   CapDiagKind);
 
   if (isScopedVar) {
+// The default value for the argument VD to the current function is
+// nullptr. So we assert that VD is non null because we deref VD here.
+assert(VD && "!VD");
+
 // Add the managing object as a dummy mutex, mapped to the underlying 
mutex.
 SourceLocation MLoc = VD->getLocation();
 DeclRefExpr DRE(VD->getASTContext(), VD, false, VD->getType(), VK_LValue,


Index: clang/lib/Analysis/ThreadSafety.cpp
===
--- clang/lib/Analysis/ThreadSafety.cpp
+++ clang/lib/Analysis/ThreadSafety.cpp
@@ -1935,6 +1935,10 @@
   CapDiagKind);
 
   if (isScopedVar) {
+// The default value for the argument VD to the current function is
+// nullptr. So we assert that VD is non null because we deref VD here.
+assert(VD && "!VD");
+
 // Add the managing object as a dummy mutex, mapped to the underlying mutex.
 SourceLocation MLoc = VD->getLocation();
 DeclRefExpr DRE(VD->getASTContext(), VD, false, VD->getType(), VK_LValue,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D78980: Elaborate more on --rocm-path flag.

2020-04-27 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added inline comments.



Comment at: clang/include/clang/Driver/Options.td:612
 def rocm_path_EQ : Joined<["--"], "rocm-path=">, Group,
-  HelpText<"ROCm installation path">;
+  HelpText<"ROCm installation path, used for finding and automatically linking 
required bitcode libraries.">;
 def hip_device_lib_path_EQ : Joined<["--"], "hip-device-lib-path=">, 
Group,

we also want to use this for adding include and library path for HIP.


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

https://reviews.llvm.org/D78980



___
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-27 Thread Zequan Wu via Phabricator via cfe-commits
zequanwu updated this revision to Diff 260529.
zequanwu added a comment.

Split the the original differential to 2 smaller ones. This one add nomerge 
function attribute in IR level. Another one will add the attribute to let 
frontend recognize it.


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

https://reviews.llvm.org/D78659

Files:
  llvm/docs/LangRef.rst
  llvm/include/llvm/Bitcode/LLVMBitCodes.h
  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/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/Attributes.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Transforms/Utils/SimplifyCFG.cpp
  llvm/test/Transforms/SimplifyCFG/nomerge.ll

Index: llvm/test/Transforms/SimplifyCFG/nomerge.ll
===
--- /dev/null
+++ llvm/test/Transforms/SimplifyCFG/nomerge.ll
@@ -0,0 +1,30 @@
+; RUN: opt < %s -simplifycfg -S | FileCheck %s
+
+; The attribute nomerge prevents the 3 bar() calls from being merged into 
+; one inside foo. Check that there are still 3 tail calls.
+
+; CHECK-LABEL: define void @foo
+; CHECK: tail call void @bar()
+; CHECK: tail call void @bar()
+; CHECK: tail call void @bar()
+define void @foo(i32 %i) {
+entry:
+  switch i32 %i, label %if.end3 [
+i32 5, label %if.then
+i32 7, label %if.then2
+  ]
+
+if.then:
+  tail call void @bar() nomerge
+  br label %if.end3
+
+if.then2:
+  tail call void @bar() nomerge
+  br label %if.end3
+
+if.end3:
+  tail call void @bar() nomerge
+  ret void
+}
+
+declare void @bar()
\ No newline at end of file
Index: llvm/lib/Transforms/Utils/SimplifyCFG.cpp
===
--- llvm/lib/Transforms/Utils/SimplifyCFG.cpp
+++ llvm/lib/Transforms/Utils/SimplifyCFG.cpp
@@ -1300,6 +1300,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
@@ -1485,8 +1493,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
@@ -372,6 +372,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/Bitcode/Writer/BitcodeWriter.cpp
===
--- llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
+++ llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
@@ -647,6 +647,8 @@
 return bitc::ATTR_KIND_NO_INLINE;
   case Attribute::NoRecurse:
 return bitc::ATTR_KIND_NO_RECURSE;
+  case Attribute::NoMerge:
+return bitc::ATTR_KIND_NO_MERGE;
   case Attribute::NonLazyBind:
 return bitc::ATTR_KIND_NON_LAZY_BIND;
   case Attribute::NonNull:
Index: llvm/lib/Bitcode/Reader/BitcodeReader.cpp
===
--- llvm/lib/Bitcode/Reader/BitcodeReader.cpp
+++ llvm/lib/Bitcode/Reader/BitcodeReader.cpp
@@ -1306,6 +1306,9 @@
   case Attribute::Preallocated:
 llvm_unreachable("preallocated attribute not supported in raw format");
 break;
+  case Attribute::NoMerge:
+llvm_unreachable("nomerge attribute not supported in raw format");
+break;
   }
   llvm_unreachable("Unsupported attribute type");
 }
@@ -1318,7 +1321,7 @@
 if (I == Attribute::SanitizeMemTag || I == Attribute::Dereferenceable ||
 I == 

[PATCH] D78982: [clang-format] Fix Microsoft style for enums

2020-04-27 Thread Aaron Smith via Phabricator via cfe-commits
asmith added a comment.

This change tries to fix this bug.
https://bugs.llvm.org/show_bug.cgi?id=32810


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78982



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


[PATCH] D78982: [clang-format] Fix Microsoft style for enums

2020-04-27 Thread Aaron Smith via Phabricator via cfe-commits
asmith created this revision.
asmith added reviewers: jbcoe, MyDeveloperDay.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
asmith added a reviewer: thakis.

Before this change enums were formatted incorrectly for the Microsoft style.

  

[Original Source]

  
  enum {
one,
two
  } three, four;


[Incorrectly Formatted]

  
  enum blah
  {
one,
two
  } three,
  four;


[Correct Format with Patch]

  
  enum blah
  {
one,
two
  } three, four;


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D78982

Files:
  clang/lib/Format/UnwrappedLineParser.cpp


Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -2280,9 +2280,18 @@
 return true;
   }
 
+  if (Style.BraceWrapping.AfterEnum)
+addUnwrappedLine();
   // Parse enum body.
   nextToken();
+  if (Style.BraceWrapping.AfterEnum) {
+addUnwrappedLine();
+Line->Level += 1;
+  }
   bool HasError = !parseBracedList(/*ContinueOnSemicolons=*/true);
+  if (Style.BraceWrapping.AfterEnum)
+Line->Level -= 1;
+  
   if (HasError) {
 if (FormatTok->is(tok::semi))
   nextToken();


Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -2280,9 +2280,18 @@
 return true;
   }
 
+  if (Style.BraceWrapping.AfterEnum)
+addUnwrappedLine();
   // Parse enum body.
   nextToken();
+  if (Style.BraceWrapping.AfterEnum) {
+addUnwrappedLine();
+Line->Level += 1;
+  }
   bool HasError = !parseBracedList(/*ContinueOnSemicolons=*/true);
+  if (Style.BraceWrapping.AfterEnum)
+Line->Level -= 1;
+  
   if (HasError) {
 if (FormatTok->is(tok::semi))
   nextToken();
___
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-27 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.

leonardchan wrote:
> leonardchan wrote:
> > 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.
> Ah, so it seems `addRelativeOffset` operates differently than I thought. 
> Initially I thought it just took the offset relative to the start of the 
> array being built, but it actually seems to be relative to the component that 
> would be added to the builder. This is slightly different from the current 
> implementation where the offset is instead taken relative to the address 
> point of the current vtable.
> 
> We could technically still achieve the desired effect of offsets in the 
> vtable if we were to use `addTaggedRelativeOffset` and subtract a constantaly 
> increasing offset as more virtual function components are added, although I'm 
> not sure how much more benefit that would offer.
> 
> An alternative approach could also be to just use `addRelativeOffset` for 
> offsets relative to the component slot and update instances we access the 
> vtable to adjust for this new arithmetic. I think this would just transform 
> instances of `llvm.load.relative(%vtable, %func_offset)` to 
> `llvm.load.relative(%vtable + %func_offset , 0)`, which seems differerent 
> from how it was intended to be used, but technically might work.
Interesting.  Yeah, it should be relatively straightforward to add a method 
that adds a pointer subtraction starting from a different base, and there's 
already a function for getting a constant that represents the address of the 
current position in the struct.

I take it you've taught LLVM that it can emit that subtraction with a normal 
relative-offset relocation by using an addend?  That must've been exciting.  
Or, yeah, we can add in that addend in the frontend.

I think I see the expected benefit: it should generally save an instruction 
from the call sequence, at least on targets like x86 that lack pre-incrementing 
addressing modes.  It does mean that the v-table entries can't be independently 
described — e.g. there's really no way you could write a C++ type that behaves 
like a v-table entry — but that's not too much of a loss.


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] D72959: Relative VTables ABI on Fuchsia

2020-04-27 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.

leonardchan wrote:
> 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.
Ah, so it seems `addRelativeOffset` operates differently than I thought. 
Initially I thought it just took the offset relative to the start of the array 
being built, but it actually seems to be relative to the component that would 
be added to the builder. This is slightly different from the current 
implementation where the offset is instead taken relative to the address point 
of the current vtable.

We could technically still achieve the desired effect of offsets in the vtable 
if we were to use `addTaggedRelativeOffset` and subtract a constantaly 
increasing offset as more virtual function components are added, although I'm 
not sure how much more benefit that would offer.

An alternative approach could also be to just use `addRelativeOffset` for 
offsets relative to the component slot and update instances we access the 
vtable to adjust for this new arithmetic. I think this would just transform 
instances of `llvm.load.relative(%vtable, %func_offset)` to 
`llvm.load.relative(%vtable + %func_offset , 0)`, which seems differerent from 
how it was intended to be used, but technically might work.


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] D78853: [Analysis] Fix null pointer dereference warnings [1/n]

2020-04-27 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added inline comments.



Comment at: clang/lib/Analysis/ThreadSafety.cpp:1938-1940
+// The default value for the argument VD to the current function is
+// nullptr. So we assert that VD is non null because we deref VD here.
+assert(VD && "!VD");

Doesn't seem like the most informative comment or assertion string - the 
invariant  "isScopedVar implies VD is non-null" is established earlier in the 
function, where isScopedVar only becomes true under the "VD is non-null" 
condition at 1809.

Would it be better to improve whatever static analysis you're using to be able 
to track that correlation, rather than adding lots of extra assertions to LLVM? 
(can the Clang Static Analyzer understand this code and avoid warning on it, 
for instance - that'd be a good existence proof for such "smarts" being 
reasonably possible for static analysis)


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

https://reviews.llvm.org/D78853



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


[clang] be884b7 - Revert "build: use `find_package(Python3)` if available"

2020-04-27 Thread Saleem Abdulrasool via cfe-commits

Author: Saleem Abdulrasool
Date: 2020-04-27T20:03:32-07:00
New Revision: be884b79352de8917ad17fdb9bd70ec982ca8bdd

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

LOG: Revert "build: use `find_package(Python3)` if available"

This reverts commit cd84bfb8142bc7ff3a07a188ffb809f1d86d1fd7.  Although
this passed the CI in phabricator, some of the bots are missing python3
packages, revert it temporarily.

Added: 


Modified: 
clang-tools-extra/test/lit.site.cfg.py.in
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
llvm/tools/llvm-shlib/CMakeLists.txt

Removed: 




diff  --git a/clang-tools-extra/test/lit.site.cfg.py.in 
b/clang-tools-extra/test/lit.site.cfg.py.in
index 5dc112a56126..a970e7fafc1f 100644
--- a/clang-tools-extra/test/lit.site.cfg.py.in
+++ b/clang-tools-extra/test/lit.site.cfg.py.in
@@ -8,7 +8,7 @@ config.lit_tools_dir = "@LLVM_LIT_TOOLS_DIR@"
 config.clang_tools_binary_dir = "@CLANG_TOOLS_BINARY_DIR@"
 config.clang_tools_dir = "@CLANG_TOOLS_DIR@"
 config.clang_libs_dir = "@SHLIBDIR@"
-config.python_executable = "@Python3_EXECUTABLE@"
+config.python_executable = "@PYTHON_EXECUTABLE@"
 config.target_triple = "@TARGET_TRIPLE@"
 config.clang_staticanalyzer = @CLANG_ENABLE_STATIC_ANALYZER@
 

diff  --git a/clang/CMakeLists.txt b/clang/CMakeLists.txt
index 7dadc5f6e917..88e556fd88a0 100644
--- a/clang/CMakeLists.txt
+++ b/clang/CMakeLists.txt
@@ -130,38 +130,16 @@ if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR )
   set( CMAKE_ARCHIVE_OUTPUT_DIRECTORY 
${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX} )
 
   if(LLVM_INCLUDE_TESTS)
-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.
+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()
-
-  if( ${PYTHON_VERSION_STRING} VERSION_LESS 2.7 )
-message(FATAL_ERROR "Python 2.7 or newer is required")
-  endif()
+Please install Python or specify the PYTHON_EXECUTABLE CMake variable.")
+endif()
 
-  add_executable(Python3::Interpreter IMPORTED)
-  set_target_properties(Python3::Interpreter PROPERTIES
-IMPORTED_LOCATION ${PYTHON_EXECUTABLE})
-  set(Python3_EXECUTABLE ${PYTHON_EXECUTABLE})
-else()
-  find_package(Python3 COMPONENTS Interpreter)
-  if(NOT Python3_Interpreter_FOUND)
-message(WARNING "Python3 not found, using python2 as a fallback")
-find_package(Python2 COMPONENTS Interpreter REQUIRED)
-if(Python2_VERSION VERSION_LESS 2.7)
-  message(SEND_ERROR "Python 2.7 or newer is required")
-endif()
-
-# Treat python2 as python3
-add_executable(Python3::Interpreter IMPORTED)
-set_target_properties(Python3::Interpreter PROPERTIES
-  IMPORTED_LOCATION ${Python2_EXECUTABLE})
-set(Python3_EXECUTABLE ${Python2_EXECUTABLE})
-  endif()
+if( ${PYTHON_VERSION_STRING} VERSION_LESS 2.7 )
+  message(FATAL_ERROR "Python 2.7 or newer is required")
 endif()
 
 # Check prebuilt llvm/utils.

diff  --git a/clang/bindings/python/tests/CMakeLists.txt 
b/clang/bindings/python/tests/CMakeLists.txt
index 3f58c4bde8e7..626256af9c1b 100644
--- a/clang/bindings/python/tests/CMakeLists.txt
+++ b/clang/bindings/python/tests/CMakeLists.txt
@@ -3,7 +3,7 @@
 add_custom_target(check-clang-python
 COMMAND ${CMAKE_COMMAND} -E env
 CLANG_LIBRARY_PATH=$
-"${Python3_EXECUTABLE}" -m unittest discover
+${PYTHON_EXECUTABLE} -m unittest discover
 DEPENDS libclang
 WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/..)
 

diff  --git a/clang/test/lit.site.cfg.py.in b/clang/test/lit.site.cfg.py.in
index 4527ccadbb4a..daec694bd128 100644
--- a/clang/test/lit.site.cfg.py.in
+++ b/clang/test/lit.site.cfg.py.in
@@ -27,7 +27,7 @@ config.enable_backtrace = @ENABLE_BACKTRACES@
 config.enable_experimental_new_pass_manager = 
@ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER@
 config.enable_threads = @LLVM_ENABLE_THREADS@
 config.host_arch = "@HOST_ARCH@"
-config.python_executable = "@Python3_EXECUTABLE@"
+config.python_executable = "@PYTHON_EXECUTABLE@"
 config.use_z3_solver = lit_config.params.get('USE_Z3_SOLVER', 

[PATCH] D78982: [clang-format] Fix Microsoft style for enums

2020-04-27 Thread Aaron Smith via Phabricator via cfe-commits
asmith updated this revision to Diff 260542.

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

https://reviews.llvm.org/D78982

Files:
  clang/include/clang/Format/Format.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/UnwrappedLineParser.cpp


Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -2280,9 +2280,17 @@
 return true;
   }
 
+  if (!Style.AllowEnumsOnASingleLine)
+addUnwrappedLine();
   // Parse enum body.
   nextToken();
+  if (!Style.AllowEnumsOnASingleLine) {
+addUnwrappedLine();
+Line->Level += 1;
+  }
   bool HasError = !parseBracedList(/*ContinueOnSemicolons=*/true);
+  if (!Style.AllowEnumsOnASingleLine)
+Line->Level -= 1;
   if (HasError) {
 if (FormatTok->is(tok::semi))
   nextToken();
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -397,6 +397,8 @@
Style.AllowAllConstructorInitializersOnNextLine);
 IO.mapOptional("AllowAllParametersOfDeclarationOnNextLine",
Style.AllowAllParametersOfDeclarationOnNextLine);
+IO.mapOptional("AllowEnumsOnASingleLine",
+   Style.AllowEnumsOnASingleLine);
 IO.mapOptional("AllowShortBlocksOnASingleLine",
Style.AllowShortBlocksOnASingleLine);
 IO.mapOptional("AllowShortCaseLabelsOnASingleLine",
@@ -752,6 +754,7 @@
   LLVMStyle.AllowAllArgumentsOnNextLine = true;
   LLVMStyle.AllowAllConstructorInitializersOnNextLine = true;
   LLVMStyle.AllowAllParametersOfDeclarationOnNextLine = true;
+  LLVMStyle.AllowEnumsOnASingleLine = true;
   LLVMStyle.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_All;
   LLVMStyle.AllowShortBlocksOnASingleLine = FormatStyle::SBS_Never;
   LLVMStyle.AllowShortCaseLabelsOnASingleLine = false;
@@ -1137,6 +1140,7 @@
   Style.BraceWrapping.BeforeCatch = true;
   Style.BraceWrapping.BeforeElse = true;
   Style.PenaltyReturnTypeOnItsOwnLine = 1000;
+  Style.AllowEnumsOnASingleLine = false;
   Style.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_None;
   Style.AllowShortCaseLabelsOnASingleLine = false;
   Style.AllowShortIfStatementsOnASingleLine = FormatStyle::SIS_Never;
Index: clang/include/clang/Format/Format.h
===
--- clang/include/clang/Format/Format.h
+++ clang/include/clang/Format/Format.h
@@ -221,6 +221,20 @@
   /// \endcode
   bool AllowAllParametersOfDeclarationOnNextLine;
 
+  /// Allow enums on a single line.
+  /// \code
+  ///   true:
+  ///   enum { A, B } myEnum;
+  ///
+  ///   false:
+  ///   enum
+  ///   {
+  /// A,
+  /// B,
+  ///   } myEnum;
+  /// \endcode
+  bool AllowEnumsOnASingleLine;
+  
   /// Different styles for merging short blocks containing at most one
   /// statement.
   enum ShortBlockStyle {
@@ -2160,6 +2174,7 @@
R.AllowAllConstructorInitializersOnNextLine &&
AllowAllParametersOfDeclarationOnNextLine ==
R.AllowAllParametersOfDeclarationOnNextLine &&
+   AllowEnumsOnASingleLine == R.AllowEnumsOnASingleLine &&
AllowShortBlocksOnASingleLine == R.AllowShortBlocksOnASingleLine &&
AllowShortCaseLabelsOnASingleLine ==
R.AllowShortCaseLabelsOnASingleLine &&


Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -2280,9 +2280,17 @@
 return true;
   }
 
+  if (!Style.AllowEnumsOnASingleLine)
+addUnwrappedLine();
   // Parse enum body.
   nextToken();
+  if (!Style.AllowEnumsOnASingleLine) {
+addUnwrappedLine();
+Line->Level += 1;
+  }
   bool HasError = !parseBracedList(/*ContinueOnSemicolons=*/true);
+  if (!Style.AllowEnumsOnASingleLine)
+Line->Level -= 1;
   if (HasError) {
 if (FormatTok->is(tok::semi))
   nextToken();
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -397,6 +397,8 @@
Style.AllowAllConstructorInitializersOnNextLine);
 IO.mapOptional("AllowAllParametersOfDeclarationOnNextLine",
Style.AllowAllParametersOfDeclarationOnNextLine);
+IO.mapOptional("AllowEnumsOnASingleLine",
+   Style.AllowEnumsOnASingleLine);
 IO.mapOptional("AllowShortBlocksOnASingleLine",
Style.AllowShortBlocksOnASingleLine);
 IO.mapOptional("AllowShortCaseLabelsOnASingleLine",
@@ -752,6 +754,7 @@
   LLVMStyle.AllowAllArgumentsOnNextLine = true;
   LLVMStyle.AllowAllConstructorInitializersOnNextLine = true;
   

[PATCH] D78900: [HIP][AMDGPU] Enable structurizer workarounds

2020-04-27 Thread Sameer Sahasrabuddhe via Phabricator via cfe-commits
sameerds added inline comments.



Comment at: clang/lib/Driver/ToolChains/HIP.cpp:158
   Args.MakeArgString(Twine("-filetype=") + (OutputIsAsm ? "asm" : "obj")));
+  LlcArgs.push_back("--amdgpu-enable-structurizer-workarounds");
 

arsenm wrote:
> We should just flip this in the backend. llc flags are not intended for 
> frontends to set options
Admittedly, this is a broken workflow. I am not even sure if Clang should be 
invoking llc at all. Ideally, we would want to eliminate this flag entirely. 
But flipping it is okay too if graphics workloads are sensitive to it. The 
priority right now is to enable the workarounds officially only for HIP and 
this seems to be most concise way to do it. We can flip the flag once other 
users of the AMDGPU are on board.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78900



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


[clang] a58b62b - [IR] Replace all uses of CallBase::getCalledValue() with getCalledOperand().

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

Author: Craig Topper
Date: 2020-04-27T22:17:03-07:00
New Revision: a58b62b4a2b96c31b49338b262b609db746449e8

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

LOG: [IR] Replace all uses of CallBase::getCalledValue() with 
getCalledOperand().

This method has been commented as deprecated for a while. Remove
it and replace all uses with the equivalent getCalledOperand().

I also made a few cleanups in here. For example, to removes use
of getElementType on a pointer when we could just use getFunctionType
from the call.

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

Added: 


Modified: 
clang/lib/CodeGen/CGCall.cpp
clang/lib/CodeGen/CGObjC.cpp
clang/lib/CodeGen/CodeGenFunction.cpp
lldb/source/Expression/IRInterpreter.cpp
lldb/source/Plugins/ExpressionParser/Clang/IRDynamicChecks.cpp
lldb/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
llvm/include/llvm-c/Core.h
llvm/include/llvm/CodeGen/FastISel.h
llvm/include/llvm/IR/AbstractCallSite.h
llvm/include/llvm/IR/InstrTypes.h
llvm/lib/Analysis/AliasAnalysisEvaluator.cpp
llvm/lib/Analysis/InstructionSimplify.cpp
llvm/lib/Analysis/Lint.cpp
llvm/lib/Analysis/MemorySSA.cpp
llvm/lib/Analysis/ModuleSummaryAnalysis.cpp
llvm/lib/Analysis/StackSafetyAnalysis.cpp
llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
llvm/lib/CodeGen/CodeGenPrepare.cpp
llvm/lib/CodeGen/GlobalISel/CallLowering.cpp
llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp
llvm/lib/CodeGen/GlobalISel/InlineAsmLowering.cpp
llvm/lib/CodeGen/PreISelIntrinsicLowering.cpp
llvm/lib/CodeGen/SelectionDAG/FastISel.cpp
llvm/lib/CodeGen/SelectionDAG/FunctionLoweringInfo.cpp
llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp
llvm/lib/CodeGen/WasmEHPrepare.cpp
llvm/lib/CodeGen/WinEHPrepare.cpp
llvm/lib/ExecutionEngine/Interpreter/Execution.cpp
llvm/lib/IR/AsmWriter.cpp
llvm/lib/IR/Core.cpp
llvm/lib/IR/Instructions.cpp
llvm/lib/IR/Verifier.cpp
llvm/lib/Target/AArch64/AArch64PromoteConstant.cpp
llvm/lib/Target/AMDGPU/AMDGPUAnnotateKernelFeatures.cpp
llvm/lib/Target/AMDGPU/AMDGPUFixFunctionBitcasts.cpp
llvm/lib/Target/AMDGPU/AMDGPUTargetTransformInfo.cpp
llvm/lib/Target/AMDGPU/SIISelLowering.cpp
llvm/lib/Target/ARM/ARMFastISel.cpp
llvm/lib/Target/ARM/ARMISelLowering.cpp
llvm/lib/Target/BPF/BPFAbstractMemberAccess.cpp
llvm/lib/Target/NVPTX/NVPTXISelLowering.cpp
llvm/lib/Target/PowerPC/PPCISelLowering.cpp
llvm/lib/Target/PowerPC/PPCTargetTransformInfo.cpp
llvm/lib/Target/WebAssembly/WebAssemblyFastISel.cpp
llvm/lib/Target/WebAssembly/WebAssemblyFixFunctionBitcasts.cpp
llvm/lib/Target/WebAssembly/WebAssemblyLowerEmscriptenEHSjLj.cpp
llvm/lib/Target/X86/X86ISelLowering.cpp
llvm/lib/Target/X86/X86WinEHState.cpp
llvm/lib/Transforms/Coroutines/CoroSplit.cpp
llvm/lib/Transforms/IPO/CalledValuePropagation.cpp
llvm/lib/Transforms/IPO/GlobalOpt.cpp
llvm/lib/Transforms/IPO/PruneEH.cpp
llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp
llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp
llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp
llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
llvm/lib/Transforms/Instrumentation/ValueProfilePlugins.inc
llvm/lib/Transforms/Scalar/RewriteStatepointsForGC.cpp
llvm/lib/Transforms/Utils/CallPromotionUtils.cpp
llvm/lib/Transforms/Utils/Evaluator.cpp
llvm/lib/Transforms/Utils/InlineFunction.cpp
llvm/lib/Transforms/Utils/Local.cpp
llvm/lib/Transforms/Utils/LowerInvoke.cpp
llvm/lib/Transforms/Utils/SimplifyCFG.cpp
llvm/test/LTO/X86/type-mapping-bug3.ll
llvm/tools/llvm-diff/DiffConsumer.cpp
llvm/tools/llvm-diff/DifferenceEngine.cpp
mlir/lib/Target/LLVMIR/ConvertFromLLVMIR.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index b3fda6bd4ea3..e0e895f202c2 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -2701,10 +2701,10 @@ static llvm::Value 
*tryEmitFusedAutoreleaseOfResult(CodeGenFunction ,
 
   bool doRetainAutorelease;
 
-  if (call->getCalledValue() == CGF.CGM.getObjCEntrypoints().objc_retain) {
+  if (call->getCalledOperand() == CGF.CGM.getObjCEntrypoints().objc_retain) {
 doRetainAutorelease = true;
-  } else if (call->getCalledValue() == CGF.CGM.getObjCEntrypoints()
-  .objc_retainAutoreleasedReturnValue) 
{
+  } else if (call->getCalledOperand() ==
+ 

[PATCH] D78890: [clang-tidy] Add check callee-namespace.

2020-04-27 Thread Paula Toth via Phabricator via cfe-commits
PaulkaToast updated this revision to Diff 260218.
PaulkaToast marked 2 inline comments as done.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78890

Files:
  clang-tools-extra/clang-tidy/llvmlibc/CMakeLists.txt
  clang-tools-extra/clang-tidy/llvmlibc/CalleeNamespaceCheck.cpp
  clang-tools-extra/clang-tidy/llvmlibc/CalleeNamespaceCheck.h
  clang-tools-extra/clang-tidy/llvmlibc/LLVMLibcTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/docs/clang-tidy/checks/llvmlibc-callee-namespace.rst
  clang-tools-extra/test/clang-tidy/checkers/llvmlibc-callee-namespace.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/llvmlibc-callee-namespace.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/llvmlibc-callee-namespace.cpp
@@ -0,0 +1,32 @@
+// RUN: %check_clang_tidy %s llvmlibc-callee-namespace %t
+
+namespace __llvm_libc {
+namespace nested {
+void nested_func() {}
+} // namespace nested
+void libc_api_func() {}
+} // namespace __llvm_libc
+
+// Emulate a function from the public headers like string.h
+void libc_api_func() {}
+
+namespace __llvm_libc {
+void Test() {
+  // Allow calls with the fully qualified name.
+  __llvm_libc::libc_api_func();
+  __llvm_libc::nested::nested_func();
+
+  // Should not trigger on compiler provided function calls.
+  (void)__builtin_abs(-1);
+
+  // Bare calls are allowed as long as they resolve to the correct namespace.
+  libc_api_func();
+  nested::nested_func();
+
+  // Disallow calling into global namespace for implemented entrypoints.
+  ::libc_api_func();
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: function 'libc_api_func' must call to internal implementation in `__llvm_libc` namespace
+  // CHECK-MESSAGES: :11:6: note: currently resolves to:
+}
+
+} // namespace __llvm_libc
Index: clang-tools-extra/docs/clang-tidy/checks/llvmlibc-callee-namespace.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/llvmlibc-callee-namespace.rst
@@ -0,0 +1,24 @@
+.. title:: clang-tidy - llvmlibc-callee-namespace
+
+llvmlibc-callee-namespace
+
+
+Checks all calls resolve to functions within ``__llvm_libc`` namespace.
+
+.. code-block:: c++
+
+namespace __llvm_libc {
+
+// Allow calls with the fully qualified name.
+__llvm_libc::strlen("hello");
+
+// Allow calls to compiler provided functions.
+(void)__builtin_abs(-1);
+
+// Bare calls are allowed as long as they resolve to the correct namespace.
+strlen("world");
+
+// Disallow calling into functions in the global namespace.
+::strlen("!");
+
+} // namespace __llvm_libc
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -188,6 +188,7 @@
`llvm-prefer-isa-or-dyn-cast-in-conditionals `_, "Yes"
`llvm-prefer-register-over-unsigned `_, "Yes"
`llvm-twine-local `_, "Yes"
+   `llvmlibc-callee-namespace `_,
`llvmlibc-implementation-in-namespace `_,
`llvmlibc-restrict-system-libc-headers `_, "Yes"
`misc-definitions-in-headers `_, "Yes"
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -113,6 +113,11 @@
   Flags use of the `C` standard library functions ``memset``, ``memcpy`` and
   ``memcmp`` and similar derivatives on non-trivial types.
 
+- New :doc:`llvmlibc-callee-namespace
+  ` check.
+
+  Checks all calls resolve to functions within ``__llvm_libc`` namespace.
+
 - New :doc:`llvmlibc-implementation-in-namespace
   ` check.
 
Index: clang-tools-extra/clang-tidy/llvmlibc/LLVMLibcTidyModule.cpp
===
--- clang-tools-extra/clang-tidy/llvmlibc/LLVMLibcTidyModule.cpp
+++ clang-tools-extra/clang-tidy/llvmlibc/LLVMLibcTidyModule.cpp
@@ -9,6 +9,7 @@
 #include "../ClangTidy.h"
 #include "../ClangTidyModule.h"
 #include "../ClangTidyModuleRegistry.h"
+#include "CalleeNamespaceCheck.h"
 #include "ImplementationInNamespaceCheck.h"
 #include "RestrictSystemLibcHeadersCheck.h"
 
@@ -19,6 +20,8 @@
 class LLVMLibcModule : public ClangTidyModule {
 public:
   void addCheckFactories(ClangTidyCheckFactories ) override {
+CheckFactories.registerCheck(
+"llvmlibc-callee-namespace");
 CheckFactories.registerCheck(
 "llvmlibc-implementation-in-namespace");
 CheckFactories.registerCheck(
Index: clang-tools-extra/clang-tidy/llvmlibc/CalleeNamespaceCheck.h
===

<    1   2   3