date:20210408

[PATCH] D100085: [X86] Support -march=rocketlake

2021-04-08 Thread Freddy, Ye via Phabricator via cfe-commits

FreddyYe added a comment.

In D100085#2675965 , @MaskRay wrote:

> In D100085#2675919 , @FreddyYe 
> wrote:
>
>> Hi @MaskRay, I tried to refactor, but met some difficulties. Since these 
>> defines are dictionary ordered, a new #define may insert into a common 
>> CHECK. So it is difficult to let different RUN share common CHECKs.
>
> Check prefixes of the same kind do not need to be contiguous.
>
>   // A:
>   // B:
>   // A:

I see. And It works. And I'll update. And thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100085

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

[PATCH] D99037: [Matrix] Implement C-style explicit type conversions for matrix types

2021-04-08 Thread Saurabh Jha via Phabricator via cfe-commits

SaurabhJha updated this revision to Diff 336022.
SaurabhJha added a comment.

Address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99037

Files:
  clang/include/clang/AST/OperationKinds.def
  clang/include/clang/AST/Stmt.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Expr.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGExprAgg.cpp
  clang/lib/CodeGen/CGExprComplex.cpp
  clang/lib/CodeGen/CGExprConstant.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/Edit/RewriteObjCFoundationAPI.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
  clang/test/CodeGen/matrix-cast.c
  clang/test/Sema/matrix-cast.c
  clang/test/SemaCXX/matrix-casts.cpp

Index: clang/test/SemaCXX/matrix-casts.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/matrix-casts.cpp
@@ -0,0 +1,67 @@
+// RUN: %clang_cc1 -std=c++11 -fenable-matrix -fsyntax-only -verify %s
+
+template 
+
+using matrix_4_4 = X __attribute__((matrix_type(4, 4)));
+
+template 
+
+using matrix_5_5 = Y __attribute__((matrix_type(5, 5)));
+
+typedef struct test_struct {
+} test_struct;
+
+typedef int vec __attribute__((vector_size(4)));
+
+void f1() {
+  // TODO: Update this test once the support of C-style casts for C++ is implemented.
+  matrix_4_4 m1;
+  matrix_4_4 m2;
+  matrix_4_4 m3;
+  matrix_5_5 m4;
+  int i;
+  vec v;
+  test_struct *s;
+
+  (matrix_4_4)m1;   // expected-error {{C-style cast from 'matrix_4_4' (aka 'char __attribute__((matrix_type(4, \
+4)))') to 'matrix_4_4' (aka 'int __attribute__((matrix_type(4, 4)))') is not allowed}}
+  (matrix_4_4)m2; // expected-error {{C-style cast from 'matrix_4_4' (aka 'int __attribute__((matrix_type(4, \
+4)))') to 'matrix_4_4' (aka 'short __attribute__((matrix_type(4, 4)))') is not allowed}}
+  (matrix_5_5)m3;   // expected-error {{C-style cast from 'matrix_4_4' (aka 'short __attribute__((matrix_type(4, \
+4)))') to 'matrix_5_5' (aka 'int __attribute__((matrix_type(5, 5)))') is not allowed}}
+
+  (int)m3;// expected-error {{C-style cast from 'matrix_4_4' (aka 'short __attribute__((matrix_type(4, \
+4)))') to 'int'}}
+  (matrix_4_4)i; // expected-error {{C-style cast from 'int' to 'matrix_4_4' (aka 'int __attribute__((\
+matrix_type(4, 4)))') is not allowed}}
+
+  (vec) m2;// expected-error {{C-style cast from 'matrix_4_4' (aka 'int __attribute__((matrix_type(4, 4)))') \
+to 'vec' (vector of 1 'int' value) is not allowed}}
+  (matrix_4_4)v; // expected-error {{C-style cast from 'vec' (vector of 1 'int' value) to 'matrix_4_4' \
+(aka 'char __attribute__((matrix_type(4, 4)))') is not allowed}}
+
+  (test_struct *)m1;// expected-error {{cannot cast from type 'matrix_4_4' (aka 'char __attribute__\
+((matrix_type(4, 4)))') to pointer type 'test_struct *}}'
+  (matrix_5_5)s; // expected-error {{C-style cast from 'test_struct *' to 'matrix_5_5' (aka 'float __attribute__\
+((matrix_type(5, 5)))') is not allowed}}'
+}
+
+void f2() {
+  // TODO: Update this test once the support of C-style casts for C++ is implemented.
+  matrix_4_4 m1;
+  matrix_5_5 m2;
+  matrix_5_5 m3;
+  matrix_4_4 m4;
+  float f;
+
+  (matrix_4_4)m1;   // expected-error {{C-style cast from 'matrix_4_4' (aka 'float __attribute__\
+((matrix_type(4, 4)))') to 'matrix_4_4' (aka 'double __attribute__((matrix_type(4, 4)))') is not allowed}}
+  (matrix_5_5)m2;// expected-error {{C-style cast from 'matrix_5_5' (aka 'double __attribute__\
+((matrix_type(5, 5)))') to 'matrix_5_5' (aka 'float __attribute__((matrix_type(5, 5)))') is not allowed}}
+  (matrix_5_5)m3; // expected-error {{C-style cast from 'matrix_5_5' (aka 'int __attribute__\
+((matrix_type(5, 5)))') to 'matrix_5_5' (aka 'unsigned int __attribute__((matrix_type(5, 5)))') \
+is not allowed}}
+  (matrix_4_4)m4;  // expected-error {{C-style cast from 'matrix_4_4' (aka 'unsigned int \
+__attribute__((matrix_type(4, 4)))') to 'matrix_4_4' (aka 'int __attribute__((matrix_type(4, 4)))') is not \
+allowed}}
+}
Index: clang/test/Sema/matrix-cast.c
===
--- /dev/null
+++ clang/test/Sema/matrix-cast.c
@@ -0,0 +1,75 @@
+// RUN: %clang_cc1 -fenable-matrix -fsyntax-only %s -verify
+
+typedef char cx4x4 __attribute__((matrix_type(4, 4)));
+typedef int ix4x4 __attribute__((matrix_type(4, 4)));
+typedef short sx4x4 __attribute__((matrix_type(4, 4)));
+typedef int ix5x5 __attribute__((matrix_type(5, 5)));
+typedef float fx5x5 __attribute__((matrix_type(5, 5)));
+typedef int vec __attribute__((vector_size(4)));
+typedef struct test_struct {
+} test_struct;
+
+void f1() {
+  cx4x4 m1;
+  ix4x4 m2;
+  sx4x4 m3;
+  ix5x5 m4;
+  fx5x5 m5;
+  int i;
+  vec v;
+  test_struct *s;
+
+  m2 = (ix4x4)m1;
+  m3 = (sx4x4

[PATCH] D99037: [Matrix] Implement C-style explicit type conversions for matrix types

2021-04-08 Thread Saurabh Jha via Phabricator via cfe-commits

SaurabhJha added inline comments.



Comment at: clang/lib/CodeGen/CGExprScalar.cpp:1219
+  } else {
+SrcElementTy = SrcTy;
+DstElementTy = DstTy;

fhahn wrote:
> We should be able to assert here that both types are not matrix types, I 
> think?
I did `!SrcType->isMatrixType() && !DstType->isMatrixType()` instead of 
`!SrcType->isMatrixType() || !DstType->isMatrixType()` which I hope was the 
correct thing to do.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99037

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

[PATCH] D96090: [analyzer] Replace StoreManager::CastRetrievedVal with SValBuilder::evalCast

2021-04-08 Thread Artem Dergachev via Phabricator via cfe-commits

NoQ added a comment.

This looks amazing, thanks a lot.

I have one final question: can we already remove `dispatchCast()`&Co.? I don't 
see any other call sites anymore. Looks like it becomes dead code after your 
patch.

Which is fairly shocking and mind blowing that we've organically developed two 
independent implementations of casting, one for RegionStore and one for 
everything else. I'm super happy that we're cleaning this up.

Comment at: clang/lib/StaticAnalyzer/Core/SValBuilder.cpp:564-565
   }
-
-  llvm_unreachable("Unknown SVal kind");
 }

ASDenysPetrov wrote:
> steakhal wrote:
> > You probably don't want to remove this. The same applies to similar ones.
> Yep. I'd keep it here, beacuse of compiler warnings of no-return function.
> compiler warnings of no-return function.

Aha ok, in this case it's much better to keep `llvm_unreachable` outside the 
switch, like here and unlike the one in `evalCastKind` functions. This way 
we're getting compile-time warnings for unhandled enum cases.

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

https://reviews.llvm.org/D96090

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

[PATCH] D88905: [Clang] Allow "ext_vector_type" applied to Booleans

2021-04-08 Thread Simon Moll via Phabricator via cfe-commits

simoll added a comment.

ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88905

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

[PATCH] D100092: [clang-tidy] cppcoreguidelines-declare-loop-variable-in-the-initializer: a new check

2021-04-08 Thread Fabian Thurnheer via Phabricator via cfe-commits

DNS320 created this revision.
DNS320 added reviewers: aaron.ballman, njames93, alexfh.
DNS320 added a project: clang-tools-extra.
Herald added subscribers: shchenz, kbarton, xazax.hun, mgorny, nemanjai.
DNS320 requested review of this revision.

This check implements the ES.74 
 
rule of the C++ Core Guidelines.

The goal of this check is to find for-statements which do not declare their 
loop variable in the initializer part.
This limits the loop variables visibility to the scope of the loop and prevents 
using the loop variable for other purposes after the loop.

Thank you for the review.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100092

Files:
  clang-tools-extra/clang-tidy/cppcoreguidelines/CMakeLists.txt
  clang-tools-extra/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
  
clang-tools-extra/clang-tidy/cppcoreguidelines/DeclareLoopVariableInTheInitializerCheck.cpp
  
clang-tools-extra/clang-tidy/cppcoreguidelines/DeclareLoopVariableInTheInitializerCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-declare-loop-variable-in-the-initializer.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-declare-loop-variable-in-the-initializer.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-declare-loop-variable-in-the-initializer.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-declare-loop-variable-in-the-initializer.cpp
@@ -0,0 +1,17 @@
+// RUN: %check_clang_tidy %s cppcoreguidelines-declare-loop-variable-in-the-initializer %t
+
+void forLoopFunction() {
+  const int Limit{10};
+  int I{0};
+
+  // CHECK-MESSAGES: :[[@LINE+1]]:3: warning: Prefer to declare a loop variable in the initializer part of a for-statement [cppcoreguidelines-declare-loop-variable-in-the-initializer]
+  for (; I < Limit; I++) {
+  }
+
+  // CHECK-MESSAGES: :[[@LINE+1]]:3: warning: Prefer to declare a loop variable in the initializer part of a for-statement [cppcoreguidelines-declare-loop-variable-in-the-initializer]
+  for (I = 0; I < Limit; I++) {
+  }
+
+  for (int I{0}; I < Limit; I++) { // OK
+  }
+}
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
@@ -143,6 +143,7 @@
`concurrency-thread-canceltype-asynchronous `_,
`cppcoreguidelines-avoid-goto `_,
`cppcoreguidelines-avoid-non-const-global-variables `_,
+   `cppcoreguidelines-declare-loop-variable-in-the-initializer `_,
`cppcoreguidelines-init-variables `_, "Yes"
`cppcoreguidelines-interfaces-global-init `_,
`cppcoreguidelines-macro-usage `_,
Index: clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-declare-loop-variable-in-the-initializer.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-declare-loop-variable-in-the-initializer.rst
@@ -0,0 +1,33 @@
+.. title:: clang-tidy - cppcoreguidelines-declare-loop-variable-in-the-initializer
+
+cppcoreguidelines-declare-loop-variable-in-the-initializer
+==
+
+Checks if a loop variable is declared in the initializer part of a for-statement.
+
+This check implements the rule `ES.74 `_ of the C++ Core Guidelines.
+
+It does also cover parts of:
+- `ES.26 `_
+- `ES.5 `_
+- `ES.6 `_
+
+
+.. code-block:: c++
+
+void forLoopFunction() {
+const int Limit{10};
+int I{0};
+
+// Should print a warning
+for (; I < Limit; I++) {
+}
+
+// Should print a warning
+for (I = 0; I < Limit; I++) {
+}
+
+// Good
+for (int I{0}; I < Limit; I++) {
+}
+}
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -89,6 +89,11 @@
   Finds inner loops that have not been unrolled, as well as fully unrolled
   loops with unknown loops bounds or a large number of

[clang] 20105b6 - [clang] Speedup line offset mapping computation

2021-04-08 Thread via cfe-commits


Author: serge-sans-paille
Date: 2021-04-08T10:11:56+02:00
New Revision: 20105b6b4874a85813f7a4a3d8ad2a0f023dda14

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

LOG: [clang] Speedup line offset mapping computation

Clang spends a decent amount of time in the LineOffsetMapping::get(...)
function. This function used to be vectorized (through SSE2) then the
optimization got dropped because the sequential version was on-par performance
wise.

This provides an optimization of the sequential version that works on a word at
a time, using (documented) bithacks to provide a portable vectorization.

When preprocessing the sqlite amalgamation, this yields a sweet 3% speedup.

This is a recommit of 6951b72334bbe4c189c71751edc1e361d7b5632c with endianness
and unsigned long vs uint64_t issues fixed (hopefully).

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

Added: 


Modified: 
clang/lib/Basic/SourceManager.cpp

Removed: 




diff  --git a/clang/lib/Basic/SourceManager.cpp 
b/clang/lib/Basic/SourceManager.cpp
index cc275d4e8dc4..f0c4f88fde57 100644
--- a/clang/lib/Basic/SourceManager.cpp
+++ b/clang/lib/Basic/SourceManager.cpp
@@ -26,6 +26,7 @@
 #include "llvm/Support/Allocator.h"
 #include "llvm/Support/Capacity.h"
 #include "llvm/Support/Compiler.h"
+#include "llvm/Support/Endian.h"
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/MathExtras.h"
@@ -1252,12 +1253,22 @@ unsigned 
SourceManager::getPresumedColumnNumber(SourceLocation Loc,
   return PLoc.getColumn();
 }
 
-#ifdef __SSE2__
-#include 
-#endif
+// Check if mutli-byte word x has bytes between m and n, included. This may 
also
+// catch bytes equal to n + 1.
+// The returned value holds a 0x80 at each byte position that holds a match.
+// see http://graphics.stanford.edu/~seander/bithacks.html#HasBetweenInWord
+template 
+static constexpr inline T likelyhasbetween(T x, unsigned char m,
+   unsigned char n) {
+  return ((x - ~static_cast(0) / 255 * (n + 1)) & ~x &
+  (x & ~static_cast(0) / 255 * 127) +
+  ~static_cast(0) / 255 * (127 - (m - 1))) &
+ ~static_cast(0) / 255 * 128;
+}
 
 LineOffsetMapping LineOffsetMapping::get(llvm::MemoryBufferRef Buffer,
  llvm::BumpPtrAllocator &Alloc) {
+
   // Find the file offsets of all of the *physical* source lines.  This does
   // not look at trigraphs, escaped newlines, or anything else tricky.
   SmallVector LineOffsets;
@@ -1268,18 +1279,51 @@ LineOffsetMapping 
LineOffsetMapping::get(llvm::MemoryBufferRef Buffer,
   const unsigned char *Buf = (const unsigned char *)Buffer.getBufferStart();
   const unsigned char *End = (const unsigned char *)Buffer.getBufferEnd();
   const std::size_t BufLen = End - Buf;
+
   unsigned I = 0;
-  while (I < BufLen) {
-// Use a fast check to catch both newlines
-if (LLVM_UNLIKELY(Buf[I] <= std::max('\n', '\r'))) {
-  if (Buf[I] == '\n') {
-LineOffsets.push_back(I + 1);
-  } else if (Buf[I] == '\r') {
+  uint64_t Word;
+
+  // scan sizeof(Word) bytes at a time for new lines.
+  // This is much faster than scanning each byte independently.
+  if (BufLen > sizeof(Word)) {
+do {
+  Word = llvm::support::endian::read64(Buf + I, llvm::support::little);
+  // no new line => jump over sizeof(Word) bytes.
+  auto Mask = likelyhasbetween(Word, '\n', '\r');
+  if (!Mask) {
+I += sizeof(Word);
+continue;
+  }
+
+  // At that point, Mask contains 0x80 set at each byte that holds a value
+  // in [\n, \r + 1 [
+
+  // Scan for the next newline - it's very likely there's one.
+  unsigned N =
+  llvm::countTrailingZeros(Mask) - 7; // -7 because 0x80 is the marker
+  Word >>= N;
+  I += N / 8 + 1;
+  unsigned char Byte = Word;
+  if (Byte == '\n') {
+LineOffsets.push_back(I);
+  } else if (Byte == '\r') {
 // If this is \r\n, skip both characters.
-if (I + 1 < BufLen && Buf[I + 1] == '\n')
+if (Buf[I] == '\n')
   ++I;
-LineOffsets.push_back(I + 1);
+LineOffsets.push_back(I);
   }
+} while (I < BufLen - sizeof(Word) - 1);
+  }
+
+  // Handle tail using a regular check.
+  while (I < BufLen) {
+if (Buf[I] == '\n') {
+  LineOffsets.push_back(I + 1);
+} else if (Buf[I] == '\r') {
+  // If this is \r\n, skip both characters.
+  if (I + 1 < BufLen && Buf[I + 1] == '\n')
+++I;
+  LineOffsets.push_back(I + 1);
 }
 ++I;
   }



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

[PATCH] D99984: [RISCV] Prevent __builtin_riscv_orc_b_64 from being compiled RV32 target.

2021-04-08 Thread Fraser Cormack via Phabricator via cfe-commits

frasercrmck added inline comments.



Comment at: clang/lib/Basic/Targets/RISCV.cpp:259
   .Case("riscv64", Is64Bit)
+  .Case("64bit", Is64Bit)
   .Case("m", HasM)

What's the difference between this new feature and `riscv64` above?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99984

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

[PATCH] D80344: [Windows SEH]: HARDWARE EXCEPTION HANDLING (MSVC -EHa) - Part 1

2021-04-08 Thread Ten Tzen via Phabricator via cfe-commits

tentzen updated this revision to Diff 336033.
tentzen added a comment.

fixed command option typos in two test cases


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80344

Files:
  clang/include/clang/AST/Stmt.h
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/AST/JSONNodeDumper.cpp
  clang/lib/AST/TextNodeDumper.cpp
  clang/lib/CodeGen/CGCleanup.cpp
  clang/lib/CodeGen/CGException.cpp
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/EHScopeStack.h
  clang/lib/CodeGen/MicrosoftCXXABI.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/JumpDiagnostics.cpp
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp
  clang/test/CodeGen/windows-seh-EHa-CppCatchDotDotDot.cpp
  clang/test/CodeGen/windows-seh-EHa-CppCondiTemps.cpp
  clang/test/CodeGen/windows-seh-EHa-CppDtors01.cpp
  clang/test/CodeGen/windows-seh-EHa-TryInFinally.cpp
  llvm/docs/LangRef.rst
  llvm/include/llvm/IR/Intrinsics.td
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
  llvm/lib/IR/Verifier.cpp

Index: llvm/lib/IR/Verifier.cpp
===
--- llvm/lib/IR/Verifier.cpp
+++ llvm/lib/IR/Verifier.cpp
@@ -4415,6 +4415,10 @@
   Assert(
   !F->isIntrinsic() || isa(I) ||
   F->getIntrinsicID() == Intrinsic::donothing ||
+  F->getIntrinsicID() == Intrinsic::seh_try_begin ||
+  F->getIntrinsicID() == Intrinsic::seh_try_end ||
+  F->getIntrinsicID() == Intrinsic::seh_scope_begin ||
+  F->getIntrinsicID() == Intrinsic::seh_scope_end ||
   F->getIntrinsicID() == Intrinsic::coro_resume ||
   F->getIntrinsicID() == Intrinsic::coro_destroy ||
   F->getIntrinsicID() == Intrinsic::experimental_patchpoint_void ||
Index: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
===
--- llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
+++ llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
@@ -2871,6 +2871,10 @@
   llvm_unreachable("Cannot invoke this intrinsic");
 case Intrinsic::donothing:
   // Ignore invokes to @llvm.donothing: jump directly to the next BB.
+case Intrinsic::seh_try_begin:
+case Intrinsic::seh_scope_begin:
+case Intrinsic::seh_try_end:
+case Intrinsic::seh_scope_end:
   break;
 case Intrinsic::experimental_patchpoint_void:
 case Intrinsic::experimental_patchpoint_i64:
@@ -6784,6 +6788,10 @@
   lowerCallToExternalSymbol(I, FunctionName);
 return;
   case Intrinsic::donothing:
+  case Intrinsic::seh_try_begin:
+  case Intrinsic::seh_scope_begin:
+  case Intrinsic::seh_try_end:
+  case Intrinsic::seh_scope_end:
 // ignore
 return;
   case Intrinsic::experimental_stackmap:
Index: llvm/include/llvm/IR/Intrinsics.td
===
--- llvm/include/llvm/IR/Intrinsics.td
+++ llvm/include/llvm/IR/Intrinsics.td
@@ -516,6 +516,16 @@
  [llvm_ptr_ty, llvm_ptr_ty],
  [IntrNoMem]>;
 
+// To mark the beginning/end of a try-scope for Windows SEH -EHa
+//  calls/invokes to these intrinsics are placed to model control flows
+//caused by HW exceptions under option -EHa.
+//  calls/invokes to these intrinsics will be discarded during a codegen pass
+//   after EH tables are generated
+def int_seh_try_begin : Intrinsic<[], [], [IntrWriteMem, IntrWillReturn]>;
+def int_seh_try_end : Intrinsic<[], [], [IntrWriteMem, IntrWillReturn]>;
+def int_seh_scope_begin : Intrinsic<[], [], [IntrNoMem]>;
+def int_seh_scope_end : Intrinsic<[], [], [IntrNoMem]>;
+
 // Note: we treat stacksave/stackrestore as writemem because we don't otherwise
 // model their dependencies on allocas.
 def int_stacksave : DefaultAttrsIntrinsic<[llvm_ptr_ty]>,
Index: llvm/docs/LangRef.rst
===
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -12252,6 +12252,68 @@
 the escaped allocas are allocated, which would break attempts to use
 '``llvm.localrecover``'.
 
+'``llvm.seh.try.begin``' and '``llvm.seh.try.end``' Intrinsics
+^^
+
+Syntax:
+"""
+
+::
+
+  declare void @llvm.seh.try.begin()
+  declare void @llvm.seh.try.end()
+
+Overview:
+"
+
+The '``llvm.seh.try.begin``' and '``llvm.seh.try.end``' intrinsics mark
+the boundary of a _try region for Windows SEH Asynchrous Exception Handling.
+
+Semantics:
+""
+
+When a C-function is compiled with Windows SEH Asynchrous Exception option,
+-feh_asynch (aka MSVC -EHa), these two intrinsics are injected to m

[clang] 8fcb114 - [OpenCL] Fix mipmap read_image return types

2021-04-08 Thread Sven van Haastregt via cfe-commits


Author: Sven van Haastregt
Date: 2021-04-08T09:51:44+01:00
New Revision: 8fcb114d002bf7cd61309af80b26af68389944d0

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

LOG: [OpenCL] Fix mipmap read_image return types

The return type did not match the function name.

Added: 


Modified: 
clang/lib/Sema/OpenCLBuiltins.td

Removed: 




diff  --git a/clang/lib/Sema/OpenCLBuiltins.td 
b/clang/lib/Sema/OpenCLBuiltins.td
index 2ea70ae3234d9..03235985ab42f 100644
--- a/clang/lib/Sema/OpenCLBuiltins.td
+++ b/clang/lib/Sema/OpenCLBuiltins.td
@@ -1444,11 +1444,11 @@ let Extension = FuncExtKhrMipmapImage in {
   }
   foreach name = ["read_imagei"] in {
 def : Builtin, ImageType, 
Sampler, VectorType, VectorType, VectorType], 
Attr.Pure>;
-def : Builtin, ImageType, 
Sampler, VectorType, Float], Attr.Pure>;
+def : Builtin, ImageType, 
Sampler, VectorType, Float], Attr.Pure>;
   }
   foreach name = ["read_imageui"] in {
 def : Builtin, ImageType, 
Sampler, VectorType, VectorType, VectorType], 
Attr.Pure>;
-def : Builtin, ImageType, 
Sampler, VectorType, Float], Attr.Pure>;
+def : Builtin, ImageType, 
Sampler, VectorType, Float], Attr.Pure>;
   }
 }
 foreach imgTy = [Image1dArray] in {
@@ -1481,8 +1481,8 @@ let Extension = FuncExtKhrMipmapImage in {
 }
 foreach imgTy = [Image2dArrayDepth] in {
   foreach name = ["read_imagef"] in {
-def : Builtin, ImageType, 
Sampler, VectorType, Float], Attr.Pure>;
-def : Builtin, ImageType, 
Sampler, VectorType, VectorType, VectorType], 
Attr.Pure>;
+def : Builtin, Sampler, 
VectorType, Float], Attr.Pure>;
+def : Builtin, Sampler, 
VectorType, VectorType, VectorType], Attr.Pure>;
   }
 }
   }



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

[PATCH] D100085: [X86] Support -march=rocketlake

2021-04-08 Thread Simon Pilgrim via Phabricator via cfe-commits

RKSimon added inline comments.



Comment at: llvm/lib/Target/X86/X86.td:790
+  FeatureFSRM];
+  list RKLTuning = ICLTuning;
+  list RKLFeatures =

Using ICLTuning suggests we should still be avoiding 512-bit ops 
(FeaturePrefer256Bit) - is this still true for RKL (or anything past CNL...)?

I posted PR48336 but never got any response, but from what others have reported 
(Travis Downs, Phoronix etc) its mainly a power issue these days, not a perf 
issue due to big freq drops.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100085

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

[PATCH] D97116: Reduce the number of attributes attached to each function

2021-04-08 Thread Wei Xiao via Phabricator via cfe-commits

wxiao3 added inline comments.



Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:496
   //function.
-  CurFn->addFnAttr("min-legal-vector-width", llvm::utostr(LargestVectorWidth));
+  if (LargestVectorWidth)
+CurFn->addFnAttr("min-legal-vector-width", 
llvm::utostr(LargestVectorWidth));

For x86 backend, "LargestVectorWidth" default value is not zero but UINT32_MAX.
Please refer to: 
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/X86/X86TargetMachine.cpp#L271
Suggest revert this patch since it changes the code generated for x86.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97116

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

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

2021-04-08 Thread Pushpinder Singh via Phabricator via cfe-commits

pdhaliwal updated this revision to Diff 336037.
pdhaliwal added a comment.
Herald added subscribers: jansvoboda11, dang.

- Addressed review comments
- Added LIT test case


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99949

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

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

[PATCH] D99037: [Matrix] Implement C-style explicit type conversions for matrix types

2021-04-08 Thread Florian Hahn via Phabricator via cfe-commits

fhahn added a comment.

Thanks for the latest update! This basically looks good to me, with a few final 
nits!




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:8584
+def err_invalid_conversion_between_matrixes : Error<
+  "conversion between matrix type%diff{ $ and $|}0,1 of different size is not 
allowed">;
+

nit: `matrix types`?



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:8586
+
+def err_invalid_conversion_between_matrix_and_type : Error<
+  "conversion between matrix type %0 and type %1 is not allowed">;

nit: `_and_incompatible_type`?



Comment at: clang/include/clang/Sema/Sema.h:11718
+  // invalid.
+  bool CheckMatrixCast(SourceRange R, QualType MatrixTy, QualType Tr,
+   CastKind &Kind);

Can the name for `Tr` be improved? Perhaps `ToTy` or `TargetTy`?



Comment at: clang/lib/CodeGen/CGExprScalar.cpp:1219
+  } else {
+assert(!SrcType->isMatrixType() && !DstType->isMatrixType());
+SrcElementTy = SrcTy;

Thanks! Can you also add a message to the assert , like `&& "cannot cast 
between matrix and non-matrix types")`



Comment at: clang/lib/Sema/SemaCast.cpp:2932
+  if (DestType->getAs() || SrcType->getAs()) {
+if (Self.CheckMatrixCast(OpRange, DestType, SrcType, Kind)) {
+  SrcExpr = ExprError();

nit: no braces.



Comment at: clang/lib/Sema/SemaExpr.cpp:7357
+
+  return (matSrcType->getNumRows() == matDestType->getNumRows() &&
+  matSrcType->getNumColumns() == matDestType->getNumColumns());

nit: No `( .. )` required here.



Comment at: clang/test/CodeGen/matrix-cast.c:82
+
+void cast_unsigned_short_int_to_unsigned_int(unsigned_short_int_5x5 s, 
unsigned_int_5x5 i) {
+  // CHECK-LABEL: define{{.*}} void 
@cast_unsigned_short_int_to_unsigned_int(<25 x i16> %s, <25 x i32> %i)

I think this is still missing a test from unsigned to signed?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99037

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

[clang] e81b340 - [flang][driver] Add debug options not requiring semantic checks

2021-04-08 Thread Andrzej Warzynski via cfe-commits


Author: Andrzej Warzynski
Date: 2021-04-08T09:44:19Z
New Revision: e81b3401177a67481605447ea5250d8345cb4341

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

LOG: [flang][driver] Add debug options not requiring semantic checks

This patch adds two debugging options in the new Flang driver
(flang-new):
  *fdebug-unparse-no-sema
  *fdebug-dump-parse-tree-no-sema
Each of these options combines two options from the "throwaway" driver
(left: f18, right: flang-new):
  * `-fdebug-uparse -fdebug-no-semantics` --> `-fdebug-unparse-no-sema`
  * `-fdebug-dump-parse-tree -fdebug-no-semantics` -->
`-fdebug-dump-parse-tree-no-sema`

There are no plans to implement `-fdebug-no-semantics` in the new
driver.  Such option would be too powerful. Also, it would only make
sense when combined with specific frontend actions (`-fdebug-unparse`
and `-fdebug-dump-parse-tree`). Instead, this patch adds 2 specialised
options listed above. Each of these is implemented through a dedicated
FrontendAction (also added).

The new frontend actions are implemented in terms of a new abstract base
action: `PrescanAndSemaAction`. This new base class was required so that
we can have finer control over what steps within the frontend are
executed:
  * `PrescanAction`: run the _prescanner_
  * `PrescanAndSemaAction`: run the _prescanner_ and the _parser_ (new
 in this patch)
  * `PrescanAndSemaAction`: run the _prescanner_, _parser_ and run the
_semantic checks_

This patch introduces `PrescanAndParseAction::BeginSourceFileAction`.
Apart from the semantic checks removed at the end, it is similar to
`PrescanAndSemaAction::BeginSourceFileAction`.

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

Added: 
flang/test/Driver/dump-parse-tree-no-sema.f90

Modified: 
clang/include/clang/Driver/Options.td
flang/include/flang/Frontend/FrontendActions.h
flang/include/flang/Frontend/FrontendOptions.h
flang/lib/Frontend/CompilerInvocation.cpp
flang/lib/Frontend/FrontendActions.cpp
flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
flang/test/Driver/driver-help.f90
flang/test/Parser/omp-allocate-unparse.f90
flang/test/Parser/omp-atomic-unparse.f90
flang/tools/f18/f18.cpp

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 240656a6e519d..24bb3b8c34c7b 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -4377,14 +4377,26 @@ let Flags = [FC1Option, FlangOnlyOption] in {
 
 def test_io : Flag<["-"], "test-io">, Group,
   HelpText<"Run the InputOuputTest action. Use for development and testing 
only.">;
+def fdebug_unparse_no_sema : Flag<["-"], "fdebug-unparse-no-sema">, 
Group,
+  HelpText<"Unparse and stop (skips the semantic checks)">,
+  DocBrief<[{Only run the parser, then unparse the parse-tree and output the
+generated Fortran source file. Semantic checks are disabled.}]>;
 def fdebug_unparse : Flag<["-"], "fdebug-unparse">, Group,
-  HelpText<"Unparse and stop.">;
+  HelpText<"Unparse and stop.">,
+  DocBrief<[{Run the parser and the semantic checks. Then unparse the
+parse-tree and output the generated Fortran source file.}]>;
 def fdebug_unparse_with_symbols : Flag<["-"], "fdebug-unparse-with-symbols">, 
Group,
   HelpText<"Unparse and stop.">;
 def fdebug_dump_symbols : Flag<["-"], "fdebug-dump-symbols">, 
Group,
   HelpText<"Dump symbols after the semantic analysis">;
 def fdebug_dump_parse_tree : Flag<["-"], "fdebug-dump-parse-tree">, 
Group,
-  HelpText<"Dump the parse tree">;
+  HelpText<"Dump the parse tree">,
+  DocBrief<[{Run the Parser and the semantic checks, and then output the
+parse tree.}]>;
+def fdebug_dump_parse_tree_no_sema : Flag<["-"], 
"fdebug-dump-parse-tree-no-sema">, Group,
+  HelpText<"Dump the parse tree (skips the semantic checks)">,
+  DocBrief<[{Run the Parser and then output the parse tree. Semantic
+checks are disabled.}]>;
 def fdebug_dump_provenance : Flag<["-"], "fdebug-dump-provenance">, 
Group,
   HelpText<"Dump provenance">;
 def fdebug_dump_parsing_log : Flag<["-"], "fdebug-dump-parsing-log">, 
Group,

diff  --git a/flang/include/flang/Frontend/FrontendActions.h 
b/flang/include/flang/Frontend/FrontendActions.h
index f49f9f4714b53..83e9652153ae3 100644
--- a/flang/include/flang/Frontend/FrontendActions.h
+++ b/flang/include/flang/Frontend/FrontendActions.h
@@ -62,6 +62,22 @@ class DebugMeasureParseTreeAction : public PrescanAction {
   void ExecuteAction() override;
 };
 
+//===--===//
+// PrescanAndParse Actions
+//===--===//
+class PrescanAndParseAction : public FrontendAction {
+  void ExecuteAc

[PATCH] D99645: [flang][driver] Add debug options not requiring semantic checks

2021-04-08 Thread Andrzej Warzynski via Phabricator via cfe-commits

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGe81b3401177a: [flang][driver] Add debug options not 
requiring semantic checks (authored by awarzynski).

Changed prior to commit:
  https://reviews.llvm.org/D99645?vs=335820&id=336043#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99645

Files:
  clang/include/clang/Driver/Options.td
  flang/include/flang/Frontend/FrontendActions.h
  flang/include/flang/Frontend/FrontendOptions.h
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Frontend/FrontendActions.cpp
  flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
  flang/test/Driver/driver-help.f90
  flang/test/Driver/dump-parse-tree-no-sema.f90
  flang/test/Parser/omp-allocate-unparse.f90
  flang/test/Parser/omp-atomic-unparse.f90
  flang/tools/f18/f18.cpp

Index: flang/tools/f18/f18.cpp
===
--- flang/tools/f18/f18.cpp
+++ flang/tools/f18/f18.cpp
@@ -564,6 +564,13 @@
   options.instrumentedParse = true;
 } else if (arg == "-fdebug-no-semantics") {
   driver.debugNoSemantics = true;
+} else if (arg == "-fdebug-unparse-no-sema") {
+  driver.debugNoSemantics = true;
+  driver.dumpUnparse = true;
+} else if (arg == "-fdebug-dump-parse-tree-no-sema") {
+  driver.debugNoSemantics = true;
+  driver.dumpParseTree = true;
+  driver.syntaxOnly = true;
 } else if (arg == "-funparse" || arg == "-fdebug-unparse") {
   driver.dumpUnparse = true;
 } else if (arg == "-funparse-with-symbols" ||
Index: flang/test/Parser/omp-atomic-unparse.f90
===
--- flang/test/Parser/omp-atomic-unparse.f90
+++ flang/test/Parser/omp-atomic-unparse.f90
@@ -1,4 +1,4 @@
-! RUN: %f18 -fdebug-no-semantics -funparse -fopenmp %s | FileCheck %s
+! RUN: %flang_fc1 -fdebug-unparse-no-sema -fopenmp %s | FileCheck %s
 
 program main
implicit none
Index: flang/test/Parser/omp-allocate-unparse.f90
===
--- flang/test/Parser/omp-allocate-unparse.f90
+++ flang/test/Parser/omp-allocate-unparse.f90
@@ -1,4 +1,4 @@
-! RUN: %f18 -fdebug-no-semantics -funparse -fopenmp %s | FileCheck %s
+! RUN: %flang_fc1 -fdebug-unparse-no-sema -fopenmp %s | FileCheck %s
 ! Check Unparsing of OpenMP Allocate directive
 
 program allocate_unparse
Index: flang/test/Driver/dump-parse-tree-no-sema.f90
===
--- /dev/null
+++ flang/test/Driver/dump-parse-tree-no-sema.f90
@@ -0,0 +1,22 @@
+!--
+! RUN lines
+!--
+! RUN: %flang_fc1 -fdebug-dump-parse-tree %s 2>&1 | FileCheck %s --check-prefix=SEMA_ON
+! RUN: %flang_fc1 -fdebug-dump-parse-tree-no-sema %s 2>&1 | FileCheck %s --check-prefix=SEMA_OFF
+
+!-
+! EXPECTEED OUTPUT
+!-
+! SEMA_ON: | | | NamedConstant -> Name = 'i'
+! SEMA_ON-NEXT: | | | Constant -> Expr = '1_4'
+! SEMA_ON-NEXT: | | | | LiteralConstant -> IntLiteralConstant = '1'
+
+! SEMA_OFF: | | | NamedConstant -> Name = 'i'
+! SEMA_OFF-NEXT: | | | Constant -> Expr -> LiteralConstant -> IntLiteralConstant = '1'
+
+!---
+! INPUT
+!---
+parameter(i=1)
+integer :: j
+end program
Index: flang/test/Driver/driver-help.f90
===
--- flang/test/Driver/driver-help.f90
+++ flang/test/Driver/driver-help.f90
@@ -69,6 +69,8 @@
 ! HELP-FC1-NEXT: -falternative-parameter-statement
 ! HELP-FC1-NEXT: Enable the old style PARAMETER statement
 ! HELP-FC1-NEXT: -fbackslashSpecify that backslash in string introduces an escape character
+! HELP-FC1-NEXT: -fdebug-dump-parse-tree-no-sema
+! HELP-FC1-NEXT:Dump the parse tree (skips the semantic checks)
 ! HELP-FC1-NEXT: -fdebug-dump-parse-tree Dump the parse tree
 ! HELP-FC1-NEXT: -fdebug-dump-parsing-log
 ! HELP-FC1-NEXT:   Run instrumented parse and dump the parsing log
@@ -78,6 +80,7 @@
 ! HELP-FC1-NEXT: Measure the parse tree
 ! HELP-FC1-NEXT: -fdebug-module-writer   Enable debug messages while writing module files
 ! HELP-FC1-NEXT: -fdebug-pre-fir-treeDump the pre-FIR tree
+! HELP-FC1-NEXT: -fdebug-unparse-no-sema Unparse and stop (skips the semantic checks)
 ! HELP-FC1-NEXT: -fdebug-unparse-with-symbols
 ! HELP-FC1-NEXT:Unparse and stop.
 ! HELP-FC1-NEXT: -fdebug-unparseUnparse and stop.
Index: flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
===
--- flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
+++ flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
@@ -40,6 +40,9 @@
   case DebugUnparse:
 return std::make_unique();
 break;
+  case DebugUnparse

[PATCH] D99645: [flang][driver] Add debug options not requiring semantic checks

2021-04-08 Thread Andrzej Warzynski via Phabricator via cfe-commits

awarzynski added a comment.

In D99645#2674496 , @kiranchandramohan 
wrote:

> LGTM.
>
> Might be good to have a test for fdebug-dump-parse-tree-no-sema.

Good point, added before merging into main! Thank you for reviewing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99645

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

[PATCH] D99501: ignore -flto= options recognized by GCC

2021-04-08 Thread Florian Hahn via Phabricator via cfe-commits

fhahn added a comment.

In D99501#2668774 , @lebedev.ri wrote:

> Tests missing.
> This somehow wasn't sent to cfe-commits list

@doko could you add a test? e.g. in `clang/test/Driver/clang_f_opts.c`, which 
already contains a check for `-ffat-lto-objects`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99501

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

[PATCH] D97116: Reduce the number of attributes attached to each function

2021-04-08 Thread Roman Lebedev via Phabricator via cfe-commits

lebedev.ri added inline comments.



Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:496
   //function.
-  CurFn->addFnAttr("min-legal-vector-width", llvm::utostr(LargestVectorWidth));
+  if (LargestVectorWidth)
+CurFn->addFnAttr("min-legal-vector-width", 
llvm::utostr(LargestVectorWidth));

wxiao3 wrote:
> For x86 backend, "LargestVectorWidth" default value is not zero but 
> UINT32_MAX.
> Please refer to: 
> https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/X86/X86TargetMachine.cpp#L271
> Suggest revert this patch since it changes the code generated for x86.
Reproducer please?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97116

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

[clang] 6e8601f - [OpenCL][Docs] Fix typo in section label

2021-04-08 Thread Anastasia Stulova via cfe-commits


Author: Anastasia Stulova
Date: 2021-04-08T10:59:44+01:00
New Revision: 6e8601ff4ae1154e6f7963c70453b4818d7453e0

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

LOG: [OpenCL][Docs] Fix typo in section label

Added: 


Modified: 
clang/docs/OpenCLSupport.rst

Removed: 




diff  --git a/clang/docs/OpenCLSupport.rst b/clang/docs/OpenCLSupport.rst
index 71200364c7466..5b5ab2b1bec04 100644
--- a/clang/docs/OpenCLSupport.rst
+++ b/clang/docs/OpenCLSupport.rst
@@ -398,7 +398,7 @@ Feel free to contact us on `cfe-dev
 `_ or via `Bugzilla
 `__.
 
-.. _opencl_experimenal_cxxlibs:
+.. _opencl_experimental_cxxlibs:
 
 C++ libraries for OpenCL
 



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

[PATCH] D82317: [Clang/Test]: Update tests where `noundef` attribute is necessary

2021-04-08 Thread Juneyoung Lee via Phabricator via cfe-commits

aqjune added a comment.

Thank you all! Incremental change makes sense to me as well. It will help 
smooth landing without buildbot failures.
I'll start writing patches soon.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82317

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

[PATCH] D99580: [CLANG] [DebugInfo] Convert File name to native format

2021-04-08 Thread kamlesh kumar via Phabricator via cfe-commits

kamleshbhalui updated this revision to Diff 336057.
kamleshbhalui added a comment.

Making changes effective only for windows


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99580

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGen/debug-info-preprocessed-file.i
  clang/test/CodeGen/debug-prefix-map.c
  clang/test/CodeGenCXX/debug-info-mingw.cpp
  clang/test/CodeGenCXX/linetable-fnbegin.cpp
  clang/test/Frontend/optimization-remark-line-directive.c
  clang/test/Frontend/stdin-input.c
  clang/test/Modules/module-debuginfo-prefix.m
  clang/test/PCH/debug-info-pch-container-path.c

Index: clang/test/PCH/debug-info-pch-container-path.c
===
--- clang/test/PCH/debug-info-pch-container-path.c
+++ clang/test/PCH/debug-info-pch-container-path.c
@@ -1,3 +1,4 @@
+// UNSUPPORTED: system-windows
 // REQUIRES: asserts
 
 // Modules:
Index: clang/test/Modules/module-debuginfo-prefix.m
===
--- clang/test/Modules/module-debuginfo-prefix.m
+++ clang/test/Modules/module-debuginfo-prefix.m
@@ -1,3 +1,4 @@
+// UNSUPPORTED: system-windows
 // REQUIRES: asserts
 
 // Modules:
Index: clang/test/Frontend/stdin-input.c
===
--- clang/test/Frontend/stdin-input.c
+++ clang/test/Frontend/stdin-input.c
@@ -1,3 +1,4 @@
+// UNSUPPORTED: system-windows
 // RUN: cat %s | %clang -emit-llvm -g -S \
 // RUN: -Xclang -main-file-name -Xclang test/foo.c -x c - -o - | FileCheck %s
 // CHECK: ; ModuleID = 'test/foo.c'
Index: clang/test/Frontend/optimization-remark-line-directive.c
===
--- clang/test/Frontend/optimization-remark-line-directive.c
+++ clang/test/Frontend/optimization-remark-line-directive.c
@@ -1,3 +1,4 @@
+// UNSUPPORTED: system-windows
 // This file tests -Rpass diagnostics together with #line
 // directives. We cannot map #line directives back to
 // a SourceLocation.
Index: clang/test/CodeGenCXX/linetable-fnbegin.cpp
===
--- clang/test/CodeGenCXX/linetable-fnbegin.cpp
+++ clang/test/CodeGenCXX/linetable-fnbegin.cpp
@@ -1,3 +1,4 @@
+// UNSUPPORTED: system-windows
 // RUN: %clang_cc1 -emit-llvm -debug-info-kind=limited %s -o - | FileCheck %s
 // Test that the line table info for Foo::bar() is pointing to the
 // right header file.
@@ -11,7 +12,6 @@
 // We shouldn't need a lexical block for this function.
 // CHECK: [[DBG]] = !DILocation(line: 23, column: 3, scope: [[SP]])
 
-
 # 1 "./template.h" 1
 template 
 class Foo {
Index: clang/test/CodeGenCXX/debug-info-mingw.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/debug-info-mingw.cpp
@@ -0,0 +1,9 @@
+// UNSUPPORTED: !system-windows
+// RUN: rm -rf %t/UNIQUE_DIR && mkdir -p %t/UNIQUE_DIR
+// RUN: cp %s %t/UNIQUE_DIR/debug-info-mingw.cpp
+// RUN: %clang_cc1 -triple x86_64-w64-windows-gnu -debug-info-kind=limited \
+// RUN: -main-file-name debug-info-mingw.cpp %t/UNIQUE_DIR/debug-info-mingw.cpp \
+// RUN: -emit-llvm -o - | FileCheck %s
+int main() {
+}
+// CHECK: !DIFile(filename: "{{.+}}\\UNIQUE_DIR\\debug-info-mingw.cpp",
Index: clang/test/CodeGen/debug-prefix-map.c
===
--- clang/test/CodeGen/debug-prefix-map.c
+++ clang/test/CodeGen/debug-prefix-map.c
@@ -1,3 +1,4 @@
+// UNSUPPORTED: system-windows
 // RUN: %clang_cc1 -debug-info-kind=standalone -fdebug-prefix-map=%p=/UNLIKELY_PATH/empty %s -emit-llvm -o - | FileCheck %s -check-prefix CHECK-NO-MAIN-FILE-NAME
 // RUN: %clang_cc1 -debug-info-kind=standalone -fdebug-prefix-map=%p=/UNLIKELY_PATH=empty %s -emit-llvm -o - | FileCheck %s -check-prefix CHECK-EVIL
 // RUN: %clang_cc1 -debug-info-kind=standalone -fdebug-prefix-map=%p=/UNLIKELY_PATH/empty %s -emit-llvm -o - -main-file-name debug-prefix-map.c | FileCheck %s
Index: clang/test/CodeGen/debug-info-preprocessed-file.i
===
--- clang/test/CodeGen/debug-info-preprocessed-file.i
+++ clang/test/CodeGen/debug-info-preprocessed-file.i
@@ -1,3 +1,4 @@
+// UNSUPPORTED: system-windows
 # 1 "/foo/bar/preprocessed-input.c"
 # 1 "" 1
 # 1 "" 3
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -444,6 +444,12 @@
   StringRef Dir;
   StringRef File;
   std::string RemappedFile = remapDIPath(FileName);
+#ifdef _WIN32
+  // Convert RemappedFile to native style when Windows
+  SmallString<128> NativeFileName = StringRef(RemappedFile);
+  llvm::sys::path::native(NativeFileName);
+  RemappedFile = (std::string)NativeFileName.str();
+#endif
   std::string CurDir = remapD

[PATCH] D96418: [clang] Refactor mustprogress handling, add it to all loops in c++11+.

2021-04-08 Thread Florian Hahn via Phabricator via cfe-commits

fhahn updated this revision to Diff 336058.
fhahn added a comment.

Change names of loopMustProgress to checkIfLoopMustProgress. Same for 
functionMustProgress.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96418

Files:
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGen/attr-mustprogress.c
  clang/test/CodeGenCXX/attr-mustprogress.cpp

Index: clang/test/CodeGenCXX/attr-mustprogress.cpp
===
--- clang/test/CodeGenCXX/attr-mustprogress.cpp
+++ clang/test/CodeGenCXX/attr-mustprogress.cpp
@@ -23,20 +23,22 @@
 
 // CHECK: datalayout
 
-// CXX98-NOT: mustprogress
-// CXX11-NOT: mustprogress
-// FINITE-NOT: mustprogress
+// CXX98-NOT:  mustprogress
+// CXX11:  mustprogress
+// FINITE-NOT: mustprogress
 // CHECK-LABEL: @_Z2f0v(
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:br label %for.cond
 // CHECK:   for.cond:
-// CHECK-NOT:br {{.*}} llvm.loop
+// CXX98-NOT:br {{.*}} llvm.loop
+// CXX11-NEXT:   br label %for.cond, !llvm.loop [[LOOP1:!.*]]
+// FINITE-NEXT:  br label %for.cond, !llvm.loop [[LOOP1:!.*]]
 void f0() {
   for (; ;) ;
 }
 
-// CXX98-NOT: mustprogress
-// CXX11-NOT: mustprogress
+// CXX98-NOT:  mustprogress
+// CXX11:  mustprogress
 // FINITE-NOT: mustprogress
 // CHECK-LABEL: @_Z2f1v(
 // CHECK-NEXT:  entry:
@@ -44,7 +46,9 @@
 // CHECK:   for.cond:
 // CHECK-NEXT:br i1 true, label %for.body, label %for.end
 // CHECK:   for.body:
-// CHECK-NOT:br {{.*}}, !llvm.loop
+// CXX98-NOT: br {{.*}}, !llvm.loop
+// CXX11-NEXT:br label %for.cond, !llvm.loop [[LOOP2:!.*]]
+// FINITE-NEXT:  br label %for.cond, !llvm.loop [[LOOP2:!.*]]
 // CHECK:   for.end:
 // CHECK-NEXT:ret void
 //
@@ -53,8 +57,8 @@
 ;
 }
 
-// CXX98-NOT: mustprogress
-// CXX11: mustprogress
+// CXX98-NOT:  mustprogress
+// CXX11:  mustprogress
 // FINITE-NOT: mustprogress
 // CHECK-LABEL: @_Z2f2v(
 // CHECK-NEXT:  entry:
@@ -66,8 +70,8 @@
 // CHECK-NEXT:br i1 [[CMP]], label %for.body, label %for.end
 // CHECK:   for.body:
 // CXX98-NOT:br {{.*}}, !llvm.loop
-// CXX11:br label %for.cond, !llvm.loop [[LOOP1:!.*]]
-// FINITE-NEXT:   br label %for.cond, !llvm.loop [[LOOP1:!.*]]
+// CXX11:br label %for.cond, !llvm.loop [[LOOP3:!.*]]
+// FINITE-NEXT:  br label %for.cond, !llvm.loop [[LOOP3:!.*]]
 // CHECK:   for.end:
 // CHECK-NEXT:ret void
 //
@@ -76,8 +80,8 @@
 ;
 }
 
-// CXX98-NOT: mustprogress
-// CXX11-NOT: mustprogress
+// CXX98-NOT:  mustprogress
+// CXX11:  mustprogress
 // FINITE-NOT: mustprogress
 // CHECK-LABEL: @_Z1Fv(
 // CHECK-NEXT:  entry:
@@ -85,7 +89,9 @@
 // CHECK:   for.cond:
 // CHECK-NEXT:br i1 true, label %for.body, label %for.end
 // CHECK:   for.body:
-// CHECK-NOT: br {{.*}}, !llvm.loop
+// CXX98-NOT: br {{.*}}, !llvm.loop
+// CXX11-NEXT:br label %for.cond, !llvm.loop [[LOOP4:!.*]]
+// FINITE-NEXT:   br label %for.cond, !llvm.loop [[LOOP4:!.*]]
 // CHECK:   for.end:
 // CHECK-NEXT:br label %for.cond1
 // CHECK:   for.cond1:
@@ -95,8 +101,8 @@
 // CHECK-NEXT:br i1 [[CMP]], label %for.body2, label %for.end3
 // CHECK:   for.body2:
 // CXX98-NOT: br {{.*}}, !llvm.loop
-// CXX11-NEXT:br label %for.cond1, !llvm.loop [[LOOP2:!.*]]
-// FINITE-NEXT:   br label %for.cond1, !llvm.loop [[LOOP2:!.*]]
+// CXX11-NEXT:br label %for.cond1, !llvm.loop [[LOOP5:!.*]]
+// FINITE-NEXT:   br label %for.cond1, !llvm.loop [[LOOP5:!.*]]
 // CHECK:   for.end3:
 // CHECK-NEXT:ret void
 //
@@ -107,8 +113,8 @@
 ;
 }
 
-// CXX98-NOT: mustprogress
-// CXX11-NOT: mustprogress
+// CXX98-NOT:  mustprogress
+// CXX11:  mustprogress
 // FINITE-NOT: mustprogress
 // CHECK-LABEL: @_Z2F2v(
 // CHECK-NEXT:  entry:
@@ -120,14 +126,16 @@
 // CHECK-NEXT:br i1 [[CMP]], label %for.body, label %for.end
 // CHECK:   for.body:
 // CXX98_NOT: br {{.*}} !llvm.loop
-// CXX11-NEXT:br label %for.cond, !llvm.loop [[LOOP3:!.*]]
-// FINITE-NEXT:br label %for.cond, !llvm.loop [[LOOP3:!.*]]
+// CXX11-NEXT:br label %for.cond, !llvm.loop [[LOOP6:!.*]]
+// FINITE-NEXT:   br label %for.cond, !llvm.loop [[LOOP6:!.*]]
 // CHECK:   for.end:
 // CHECK-NEXT:br label %for.cond1
 // CHECK:   for.cond1:
 // CHECK-NEXT:br i1 true, label %for.body2, label %for.end3
 // CHECK:   for.body2:
-// CHECK-NOT: br {{.*}}, !llvm.loop
+// CXX98-NOT: br {{.*}}, !llvm.loop
+// CXX11-NEXT:br label %for.cond1, !llvm.loop [[LOOP7:!.*]]
+// FINITE-NEXT:   br label %for.cond1, !llvm.loop [[LOOP7:!.*]]
 // CHECK:   for.end3:
 // CHECK-NEXT:ret void
 //
@@ -138,22 +146,24 @@
 ;
 }
 
-// CXX98-NOT: mustprogress
-// CXX11-NOT: mustprogress
-// FINITE-NOT: mustprogress
+// CXX98-NOT:  mustprogress
+// CXX11:  mustprogress
+// FINITE-NOT: mu

[PATCH] D99797: [analyzer] Implemented RangeSet::Factory::unite function to handle intersections and adjacency

2021-04-08 Thread Valeriy Savchenko via Phabricator via cfe-commits

vsavchenko added a comment.

Well, that is a nice exercise for "two pointer" problems, but can we please 
talk about the actual use case for it?




Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:136
+
+RangeSet RangeSet::Factory::unite(RangeSet LHS, RangeSet RHS) {
+  if (LHS.isEmpty())

I'd prefer `merge`



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:217
+
+  while (BIt1 || BIt2) {
+

This algorithm is indeed `O(N +M)`, good job!
But let me get picky again 😅

It looks like we do too many comparisons in this loop.  As I said earlier, 
constant factor is the key here and while this iterator idea is good it is a 
tradeoff. There is a piece of knowledge that would've been obvious with regular 
iterators, now is a run-time unknown that we constantly need to check (`isTo` 
and `isFrom`).

What we are trying to achieve here is not harder than what we do in `intersect` 
and there it is way less comparisons.  While iterating through sets we can keep 
a set of invariants, so we don't need to re-check something that we already 
know.

Here is a sketch for the algorithm:

```
{
  assert(First != FirstEnd && Second != SecondEnd);
  // We have && here because one of them reaches its end,
  // we should not check for it again and simply add the rest
  // of the other set.
  while (true) {
// We need to find the beginning of the next range to add
// First should be the iterator which To is a candidate to be
// an and for the merged range.
if (First.From() > Second.From()) {
  swap();
}

auto From = First.From();

// That's it, we found our start, and we need to go through
// other ranges and look for the end.
// After this point, First.From() shouldn'y be accessed.

while (true) {
  // We can compress all the checks into just one.
  // This essentially means that Second should not get merged with First.
  if (Second.From() > First.To() + 1) {
break;
  }

  if (Second.From() > First.From()) {
// First is maintained as a candidate for the end.
swap();
  }

  // At this point we know that Second lives fully inside
  // of the new range and we can skip it.
  ++Second;

  // If we have nothing else in the second set...
  if (Second == SecondEnd) {
// ...let's finish the current range first...
Result.emplace_back(From, First.To());
while (++First != FirstEnd) {
  // ...and copy the rest of the ranges
  Result.push_back(*First);
}
// The range is ready.
return makePersistent(Result);
  }
};

// Second is outside of the range, and we can
// safely add a new range.
Result.emplace_back(From, First.To());
++First;

// First set can be over at this point and we should...
if (First == FirstEnd) {
  // ...copy the rest if the second set's ranges.
  while (Second != SecondEnd) {
Result.push_back(*(Second++));
  }
  // Nothing left to do.
  return makePersistent(Result);
}
  };

  // No way for us to get here!
  llvm_unreachable("...");
}
```

It's trickier in the way we end things than the intersection because we still 
need to add the rest of the other set.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:279-293
+  auto It = std::lower_bound(
+  B, E, Range(Point), [&Max, &One](const Range &OrigR, const Range &R) {
+return OrigR.To() != Max && (OrigR.To() + One) < R.From();
+  });
+
+  if (It != E && It->Includes(Point))
+return Original;

I don't see any practical reasons to keep this version over the more generic 
`RangeSet` + `RangeSet`



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:321-335
+
+  const APSInt &F = (It == E) ? R.From() : std::min(R.From(), It->From());
+
+  // Find a right part of disjoint ranges from the new range.
+  It = std::lower_bound(
+  It, E, R, [&One, &Max](const Range &OrigR, const Range &R) {
+return OrigR.From() == Max || (OrigR.From() - One) <= R.To();

Same here, it is just way more code to maintain.


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

https://reviews.llvm.org/D99797

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

[PATCH] D96418: [clang] Refactor mustprogress handling, add it to all loops in c++11+.

2021-04-08 Thread Florian Hahn via Phabricator via cfe-commits

fhahn added inline comments.



Comment at: clang/lib/CodeGen/CGStmt.cpp:801
+ SourceLocToDebugLoc(R.getEnd()),
+ loopMustProgress(CondIsConst));
 

lebedev.ri wrote:
> fhahn wrote:
> > lebedev.ri wrote:
> > > Now this doesn't make sense. Why must loop progress if it's condition is 
> > > a constant?
> > > I think this should be renamed?
> > I'm not sure I follow here. Whether the condition is constant or not is 
> > important for C11 and later. Something like ` while(true) {}` does not have 
> > to make progress, but `while (Foo) {}` must make progress. I am not sure 
> > what it should be renamed to?
> Right.
> But now this says that "if the condition is a constant integer 1 or 0, the 
> loop must make progress".
> Isn't that the opposite what this should say, as per your comment?
> Shouldn't it be "loop must progress unless the condition is a constant 
> integer 1"?
Ok, so with 'saying' do you mean `loopMustProgress` is a bad name? I changed 
the name as suggested below, but if you meant something else, please let me 
know.



Comment at: clang/lib/CodeGen/CodeGenFunction.h:535-536
+// Hence each function is 'mustprogress' in C++11 or later.
 return getLangOpts().CPlusPlus11 || getLangOpts().CPlusPlus14 ||
getLangOpts().CPlusPlus17 || getLangOpts().CPlusPlus20;
   }

lebedev.ri wrote:
> Since every new standard version will have to be added here,
> can we invert this and just check for the know fixed set
> of the versions where this doesn't apply?
I tried, but it appears as if there's no LangOpt for `C++98`. (this also seems 
not directly related to the patch, so I guess we could do that as follow-up as 
well?)



Comment at: clang/lib/CodeGen/CodeGenFunction.h:542
+  /// condition is a known constant.
+  bool loopMustProgress(bool HasConstantCond) {
 if (CGM.getCodeGenOpts().getFiniteLoops() ==

lebedev.ri wrote:
> Ah, i see.
> My problem is that it's impossible to tell whether `loopMustProgress` is a 
> member variable
> that gets assigned `CondIsConstInt` value, or a "filter" function.
> 
> Maybe this (and it's `function` friend) should be something like 
> `checkIfLoopMustProgress` or something..
Oh right, the name was confusing. I updated the name



Comment at: clang/lib/CodeGen/CodeGenFunction.h:562
+// Loops with non-constant conditions must make progress in C11 and later.
+return getLangOpts().C11 || getLangOpts().C17 || getLangOpts().C2x;
   }

lebedev.ri wrote:
> Since every new standard version will have to be added here,
> can we invert this and just check for the know fixed set
> of the versions where this doesn't apply?
I tried but I am not sure how to best do that, given there's no explicit C89 
lang opt.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96418

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

[PATCH] D96418: [clang] Refactor mustprogress handling, add it to all loops in c++11+.

2021-04-08 Thread Roman Lebedev via Phabricator via cfe-commits

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

Seems fine to me.
Might be good for someone else (@aaron.ballman ?) to also take a look, not sure.

Thank you.




Comment at: clang/lib/CodeGen/CGStmt.cpp:801
+ SourceLocToDebugLoc(R.getEnd()),
+ loopMustProgress(CondIsConst));
 

fhahn wrote:
> lebedev.ri wrote:
> > fhahn wrote:
> > > lebedev.ri wrote:
> > > > Now this doesn't make sense. Why must loop progress if it's condition 
> > > > is a constant?
> > > > I think this should be renamed?
> > > I'm not sure I follow here. Whether the condition is constant or not is 
> > > important for C11 and later. Something like ` while(true) {}` does not 
> > > have to make progress, but `while (Foo) {}` must make progress. I am not 
> > > sure what it should be renamed to?
> > Right.
> > But now this says that "if the condition is a constant integer 1 or 0, the 
> > loop must make progress".
> > Isn't that the opposite what this should say, as per your comment?
> > Shouldn't it be "loop must progress unless the condition is a constant 
> > integer 1"?
> Ok, so with 'saying' do you mean `loopMustProgress` is a bad name? I changed 
> the name as suggested below, but if you meant something else, please let me 
> know.
I'm saying that i was completely misreading this code because i thought 
`CondIsConstInt` was being stored into `loopMustProgress`, not that 
`loopMustProgress()` was being called with `CondIsConstInt` arg.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96418

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

[PATCH] D100054: Handle flags such as -m32 when computing the prefix for programs/runtime libs

2021-04-08 Thread Alexander Richardson via Phabricator via cfe-commits

arichardson updated this revision to Diff 336059.
arichardson added a comment.

Add the raw triple prefix for programs (but prefer the adjusted triple) and 
always use the adjusted triple for libraries.
Should hopefully address the feedback from @joerg.

Also improve tests to check that we don't insert additional empty/"-unknown" 
triple components.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100054

Files:
  clang/include/clang/Driver/Driver.h
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/RISCVToolchain.cpp
  
clang/test/Driver/Inputs/basic_freebsd64_tree/usr/bin/i386-unknown-freebsd12.2-ld
  clang/test/Driver/Inputs/basic_freebsd64_tree/usr/bin/x86_64-freebsd12.2-ld
  
clang/test/Driver/Inputs/basic_freebsd64_tree/usr/bin/x86_64-unknown-freebsd12.2-ld
  clang/test/Driver/freebsd-m32.c
  clang/test/Driver/linux-per-target-runtime-dir.c

Index: clang/test/Driver/linux-per-target-runtime-dir.c
===
--- clang/test/Driver/linux-per-target-runtime-dir.c
+++ clang/test/Driver/linux-per-target-runtime-dir.c
@@ -25,3 +25,18 @@
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
 // RUN:   | FileCheck --check-prefix=CHECK-FILE-NAME-X8664 %s
 // CHECK-FILE-NAME-X8664: lib{{/|\\}}x86_64-linux-gnu{{/|\\}}libclang_rt.builtins.a
+
+/// Check that we handle flags such as -m32 when searching for the builtins:
+/// Previously clang would use the raw triple passed to -target to find builtins
+/// and sanitizer libraries, but this will result in build errors when compiling
+/// with flags such as -m32. Check that we use the adjusted triple instead:
+// RUN: %clang -rtlib=compiler-rt -print-file-name=libclang_rt.builtins.a 2>&1 \
+// RUN: --target=i386-linux-gnu \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN:   | FileCheck --check-prefix=CHECK-FILE-NAME-I386 %s
+// CHECK-FILE-NAME-I386: resource_dir_with_per_target_subdir{{/|\\}}lib{{/|\\}}i386-linux-gnu{{/|\\}}libclang_rt.builtins.a
+// RUN: %clang -rtlib=compiler-rt -print-file-name=libclang_rt.builtins.a 2>&1 \
+// RUN: --target=x86_64-linux-gnu -m32 \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN:   | FileCheck --check-prefix=CHECK-FILE-NAME-X8664-M32 %s
+// CHECK-FILE-NAME-X8664-M32: resource_dir_with_per_target_subdir{{/|\\}}lib{{/|\\}}i386-linux-gnu{{/|\\}}libclang_rt.builtins.a
Index: clang/test/Driver/freebsd-m32.c
===
--- /dev/null
+++ clang/test/Driver/freebsd-m32.c
@@ -0,0 +1,76 @@
+/// Check that building with -m32 links with i386-freebsd12.2-ld/ instead of
+/// x86_64-freebsd12.2-ld and that we select the right sanitizer runtime.
+
+/// We should select x86_64-unknown-freebsd12.2-ld since it matches the triple argument
+/// Note: The paths specified by -B are not searched for triple-prefixed tools, so
+/// we also have to set $PATH.
+// RUN: env PATH=%S/Inputs/basic_freebsd64_tree/usr/bin %clang -no-canonical-prefixes \
+// RUN:   -target x86_64-unknown-freebsd12.2 %s \
+// RUN:   -B%S/Inputs/basic_freebsd64_tree/usr/bin -### 2>&1 | FileCheck %s --check-prefix=PREFIXED-64
+// PREFIXED-64: "-cc1" "-triple" "x86_64-unknown-freebsd12.2"
+// PREFIXED-64-NEXT: "{{.+}}Inputs{{/|\\}}basic_freebsd64_tree{{/|\\}}usr{{/|\\}}bin{{/|\\}}x86_64-unknown-freebsd12.2-ld" "--eh-frame-hdr"
+// Should not be passing an explicit linker emulation for the 64-bit case
+// PREFIXED-64-NOT: "-m"
+// RUN: env PATH=/this/path/does/not/exist %clang -no-canonical-prefixes \
+// RUN:   -target x86_64-unknown-freebsd12.2 %s \
+// RUN:   -B%S/Inputs/basic_freebsd64_tree/usr/bin -### 2>&1 | FileCheck %s --check-prefix=MINUS-B-NO-TRIPLE-PREFIX
+// MINUS-B-NO-TRIPLE-PREFIX: "-cc1" "-triple" "x86_64-unknown-freebsd12.2"
+// MINUS-B-NO-TRIPLE-PREFIX-NEXT: "ld" "--eh-frame-hdr"
+// MINUS-B-NO-TRIPLE-PREFIX-NOT: "-m"
+
+/// The triple passed to clang -cc1 should be normalized, but the prefix when searching
+/// for ld should not be normalized. Since there is no x86_64--freebsd12.2-ld, passing
+/// -target x86_64--freebsd12.2 should not find a a valid linker:
+// RUN: env PATH=%S/Inputs/basic_freebsd64_tree/usr/bin %clang -no-canonical-prefixes \
+// RUN:   -target x86_64--freebsd12.2 %s \
+// RUN:   -B%S/Inputs/basic_freebsd64_tree/usr/bin -### 2>&1 | FileCheck %s --check-prefix=NO-NORMALIZE-LD-PREFIX-64
+// NO-NORMALIZE-LD-PREFIX-64: "-cc1" "-triple" "x86_64-unknown-freebsd12.2"
+// NO-NORMALIZE-LD-PREFIX-64-NEXT: "ld" "--eh-frame-hdr"
+// NO-NORMALIZE-LD-PREFIX-NOT: "-m"
+
+/// We should search for i386-unknown-freebsd12.2-ld when -m32 is passed (and also pass -m elf_i386_fbsd):
+// RUN: env PATH=%S/Inputs/basic_freebsd64_tree/usr/bin %clang -no-canonical-prefixes \
+// RUN:   -target x86_64-unknown-freebsd12.2 %s -m32 \
+// RUN:   -B

[PATCH] D100054: Handle flags such as -m32 when computing the prefix for programs/runtime libs

2021-04-08 Thread Alexander Richardson via Phabricator via cfe-commits

arichardson updated this revision to Diff 336061.
arichardson added a comment.

Drop chunk that is no longer necessary


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100054

Files:
  clang/include/clang/Driver/Driver.h
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/RISCVToolchain.cpp
  
clang/test/Driver/Inputs/basic_freebsd64_tree/usr/bin/i386-unknown-freebsd12.2-ld
  clang/test/Driver/Inputs/basic_freebsd64_tree/usr/bin/x86_64-freebsd12.2-ld
  
clang/test/Driver/Inputs/basic_freebsd64_tree/usr/bin/x86_64-unknown-freebsd12.2-ld
  clang/test/Driver/freebsd-m32.c
  clang/test/Driver/linux-per-target-runtime-dir.c

Index: clang/test/Driver/linux-per-target-runtime-dir.c
===
--- clang/test/Driver/linux-per-target-runtime-dir.c
+++ clang/test/Driver/linux-per-target-runtime-dir.c
@@ -25,3 +25,18 @@
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
 // RUN:   | FileCheck --check-prefix=CHECK-FILE-NAME-X8664 %s
 // CHECK-FILE-NAME-X8664: lib{{/|\\}}x86_64-linux-gnu{{/|\\}}libclang_rt.builtins.a
+
+/// Check that we handle flags such as -m32 when searching for the builtins:
+/// Previously clang would use the raw triple passed to -target to find builtins
+/// and sanitizer libraries, but this will result in build errors when compiling
+/// with flags such as -m32. Check that we use the adjusted triple instead:
+// RUN: %clang -rtlib=compiler-rt -print-file-name=libclang_rt.builtins.a 2>&1 \
+// RUN: --target=i386-linux-gnu \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN:   | FileCheck --check-prefix=CHECK-FILE-NAME-I386 %s
+// CHECK-FILE-NAME-I386: resource_dir_with_per_target_subdir{{/|\\}}lib{{/|\\}}i386-linux-gnu{{/|\\}}libclang_rt.builtins.a
+// RUN: %clang -rtlib=compiler-rt -print-file-name=libclang_rt.builtins.a 2>&1 \
+// RUN: --target=x86_64-linux-gnu -m32 \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN:   | FileCheck --check-prefix=CHECK-FILE-NAME-X8664-M32 %s
+// CHECK-FILE-NAME-X8664-M32: resource_dir_with_per_target_subdir{{/|\\}}lib{{/|\\}}i386-linux-gnu{{/|\\}}libclang_rt.builtins.a
Index: clang/test/Driver/freebsd-m32.c
===
--- /dev/null
+++ clang/test/Driver/freebsd-m32.c
@@ -0,0 +1,76 @@
+/// Check that building with -m32 links with i386-freebsd12.2-ld/ instead of
+/// x86_64-freebsd12.2-ld and that we select the right sanitizer runtime.
+
+/// We should select x86_64-unknown-freebsd12.2-ld since it matches the triple argument
+/// Note: The paths specified by -B are not searched for triple-prefixed tools, so
+/// we also have to set $PATH.
+// RUN: env PATH=%S/Inputs/basic_freebsd64_tree/usr/bin %clang -no-canonical-prefixes \
+// RUN:   -target x86_64-unknown-freebsd12.2 %s \
+// RUN:   -B%S/Inputs/basic_freebsd64_tree/usr/bin -### 2>&1 | FileCheck %s --check-prefix=PREFIXED-64
+// PREFIXED-64: "-cc1" "-triple" "x86_64-unknown-freebsd12.2"
+// PREFIXED-64-NEXT: "{{.+}}Inputs{{/|\\}}basic_freebsd64_tree{{/|\\}}usr{{/|\\}}bin{{/|\\}}x86_64-unknown-freebsd12.2-ld" "--eh-frame-hdr"
+// Should not be passing an explicit linker emulation for the 64-bit case
+// PREFIXED-64-NOT: "-m"
+// RUN: env PATH=/this/path/does/not/exist %clang -no-canonical-prefixes \
+// RUN:   -target x86_64-unknown-freebsd12.2 %s \
+// RUN:   -B%S/Inputs/basic_freebsd64_tree/usr/bin -### 2>&1 | FileCheck %s --check-prefix=MINUS-B-NO-TRIPLE-PREFIX
+// MINUS-B-NO-TRIPLE-PREFIX: "-cc1" "-triple" "x86_64-unknown-freebsd12.2"
+// MINUS-B-NO-TRIPLE-PREFIX-NEXT: "ld" "--eh-frame-hdr"
+// MINUS-B-NO-TRIPLE-PREFIX-NOT: "-m"
+
+/// The triple passed to clang -cc1 should be normalized, but the prefix when searching
+/// for ld should not be normalized. Since there is no x86_64--freebsd12.2-ld, passing
+/// -target x86_64--freebsd12.2 should not find a a valid linker:
+// RUN: env PATH=%S/Inputs/basic_freebsd64_tree/usr/bin %clang -no-canonical-prefixes \
+// RUN:   -target x86_64--freebsd12.2 %s \
+// RUN:   -B%S/Inputs/basic_freebsd64_tree/usr/bin -### 2>&1 | FileCheck %s --check-prefix=NO-NORMALIZE-LD-PREFIX-64
+// NO-NORMALIZE-LD-PREFIX-64: "-cc1" "-triple" "x86_64-unknown-freebsd12.2"
+// NO-NORMALIZE-LD-PREFIX-64-NEXT: "ld" "--eh-frame-hdr"
+// NO-NORMALIZE-LD-PREFIX-NOT: "-m"
+
+/// We should search for i386-unknown-freebsd12.2-ld when -m32 is passed (and also pass -m elf_i386_fbsd):
+// RUN: env PATH=%S/Inputs/basic_freebsd64_tree/usr/bin %clang -no-canonical-prefixes \
+// RUN:   -target x86_64-unknown-freebsd12.2 %s -m32 \
+// RUN:   -B%S/Inputs/basic_freebsd64_tree/usr/bin -### 2>&1  | FileCheck %s --check-prefix=PREFIXED-M32
+// PREFIXED-M32: "-cc1" "-triple" "i386-unknown-freebsd12.2"
+// PREFIXED-M32-NEXT: "{{.+}}Inputs{{/|\\}}basic_freebsd64_tree{{/|\\}}usr{{/

[PATCH] D99797: [analyzer] Implemented RangeSet::Factory::unite function to handle intersections and adjacency

2021-04-08 Thread Valeriy Savchenko via Phabricator via cfe-commits

vsavchenko added inline comments.



Comment at: clang/unittests/StaticAnalyzer/RangeSetTest.cpp:471
+
+  // RHS adjacent to LHS in between.
+  // RHS => ___

I guess I also want to have more cases where ranges from RHS are in between 
ranges from LHS, also it should be a case with LHS being a set of ranges.



Comment at: clang/unittests/StaticAnalyzer/RangeSetTest.cpp:497
+  this->checkUnite({{MIN, B}, {C, MAX}}, {{A, D}}, {{MIN, MAX}});
+}

Also I'd like to see cases when there are ranges to merge from two sets but 
then one set has a bunch of other ranges that should be added as is.  We can 
automatically think of two possibilities here: when these additional ranges are 
before and after the common part.
And I guess I want at least one check with two sets with a good amount of 
ranges in both covering all possible situations and overlappings.


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

https://reviews.llvm.org/D99797

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

[PATCH] D98499: [clangd] Introduce ASTHooks to FeatureModules

2021-04-08 Thread Sam McCall via Phabricator via cfe-commits

sammccall added inline comments.



Comment at: clang-tools-extra/clangd/ClangdServer.cpp:237
+  if (auto Hook = Mod.astHooks()) {
+Inputs.PreambleHooks.emplace_back(std::move(Hook));
+Inputs.MainFileHooks.emplace_back(Mod.astHooks());

Now we're creating two ASTListeners for each version of the file seen, but most 
won't be parsed twice (and some won't even be parsed once).

This seems like it's going to be a weird wart for e.g. hooks that expect to do 
something interesting when a file finishes, or those that allocate something 
heavyweight.

I'd suggest sinking the ModuleSet into ParsedAST::build etc, or at least moving 
the astHooks() calls into TUScheduler. (And documenting that astHooks() should 
be threadsafe)

Otherwise, need to document that sometimes hooks are created and then never 
used.



Comment at: clang-tools-extra/clangd/Compiler.h:60
   TidyProviderRef ClangTidyProvider = {};
+  // Using shared_ptr since ParseInputs are copied between threads. But none of
+  // these hooks are accessed simultaneously.

I think having these in ParseInputs is conceptually confusing and shared_ptr is 
risky.
For example we copy inputs into ASTWorker::FileInputs, which extends the 
lifetime of the listeners in a way that seems undesirable.

I think these listeners should be clearly either:
 - bound to the lifetime of the ParsedAST (and therefore owned by it)
 - bound to the *creation* of the ParsedAST (and therefore strictly scoped 
within ParsedAST::build)

You could consider the **ModuleSet** to be part of ParseInputs, though...



Comment at: clang-tools-extra/clangd/Diagnostics.h:147
   void setLevelAdjuster(LevelAdjuster Adjuster) { this->Adjuster = Adjuster; }
+  void setASTHooks(
+  llvm::ArrayRef> Hooks) {

ArrayRef> seems like we're leaking a lot. And even 
mentioning AST hooks seems dubious layering-wise.
Can we use a std::function like LevelAdjuster?



Comment at: clang-tools-extra/clangd/FeatureModule.h:101
 
+  /// Various hooks that can be invoked by ASTWorker thread while building an
+  /// AST. These hooks are always called from a single thread, so

nit: this describes the interaction more but not what it's for.
Maybe 
```
/// Extension point that allows modules to observe and modify an AST build.
/// One instance is created each time clangd produces a ParsedAST or 
PrecompiledPreamble.
/// For a given instance, lifecycle methods are always called on a single 
thread.
```



Comment at: clang-tools-extra/clangd/FeatureModule.h:113
+  /// Can be called asynchronously before building an AST.
+  virtual std::unique_ptr astHooks() { return nullptr; }
+

the "hooks" name is still used here and throughout


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98499

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

[PATCH] D99995: [OpenMP51] Initial support for masked directive and filter clause

2021-04-08 Thread Alexey Bataev via Phabricator via cfe-commits

ABataev added inline comments.



Comment at: clang/lib/Parse/ParseOpenMP.cpp:2814
 }
 
 if (CKind == OMPC_ordered && PP.LookAhead(/*N=*/0).isNot(tok::l_paren))

This can be simplified like this:
```
if (!FirstClause) {
  Diag(Tok, diag::err_omp_more_one_clause)
  << getOpenMPDirectiveName(DKind) << getOpenMPClauseName(CKind) << 0;
  ErrorFound = true;
}
LLVM_FALLTHROUGH;
case OMPC_filter:
```
Plus, I think, you should not exclude OMPC_filter from the check, I think only 
single clause is allowed by the spec.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D5

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

[PATCH] D99353: [driver] Make `clang` warn rather then error on `flang` options

2021-04-08 Thread Andrzej Warzynski via Phabricator via cfe-commits

awarzynski updated this revision to Diff 336075.
awarzynski added a comment.

Refine comments, remove code for aliases (which didn't work anyway)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99353

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/flang-only-option-diags.c
  clang/test/Driver/flang-only-options.c

Index: clang/test/Driver/flang-only-options.c
===
--- /dev/null
+++ clang/test/Driver/flang-only-options.c
@@ -0,0 +1,70 @@
+// Verifies that Flang options marked as `FlangOnlyOption` are corectly recognised and warned about by Clang.
+//
+// TODO: Add aliases (once working)
+
+// RUN: %clang -fsyntax-only \
+// SKIP:  -Xflang \ This option is currently parsed by Clang as OPT_X_Flang (i.e. `-X flang` rather than `-Xflang`)
+// RUN:   -ffree-form \
+// RUN:   -ffixed-form \
+// RUN:   -module-dir \
+// RUN:   -ffixed-line-length=1 \
+// RUN:   -fopenacc \
+// RUN:   -fdefault-double-8 \
+// RUN:   -fdefault-integer-8 \
+// RUN:   -fdefault-real-8 \
+// RUN:   -flarge-sizes \
+// RUN:   -fbackslash \
+// RUN:   -fno-backslash \
+// RUN:   -fxor-operator \
+// RUN:   -fno-xor-operator \
+// RUN:   -flogical-abbreviations \
+// RUN:   -fno-logical-abbreviations \
+// RUN:   -fimplicit-none \
+// RUN:   -fno-implicit-none \
+// RUN:   -falternative-parameter-statement \
+// RUN:   -fintrinsic-modules-path \
+// RUN:   -test-io \
+// RUN:   -fdebug-unparse \
+// RUN:   -fdebug-unparse-with-symbols \
+// RUN:   -fdebug-dump-symbols \
+// RUN:   -fdebug-dump-parse-tree \
+// RUN:   -fdebug-dump-provenance \
+// RUN:   -fdebug-dump-parsing-log \
+// RUN:   -fdebug-measure-parse-tree \
+// RUN:   -fdebug-pre-fir-tree \
+// RUN:   -fdebug-module-writer \
+// RUN:   -fget-symbols-sources \
+// RUN: %s 2>&1 | FileCheck %s
+
+// CHECK: clang-{{[0-9]+}}: warning: command line option '-ffree-form' is only valid in Flang mode (i.e. for Fortran input) [-Wunknown-argument]
+// CHECK: clang-{{[0-9]+}}: warning: command line option '-ffixed-form' is only valid in Flang mode (i.e. for Fortran input) [-Wunknown-argument]
+// CHECK: clang-{{[0-9]+}}: warning: command line option '-module-dir' is only valid in Flang mode (i.e. for Fortran input) [-Wunknown-argument]
+// CHECK: clang-{{[0-9]+}}: warning: command line option '-ffixed-line-length=1' is only valid in Flang mode (i.e. for Fortran input) [-Wunknown-argument]
+// CHECK: clang-{{[0-9]+}}: warning: command line option '-fopenacc' is only valid in Flang mode (i.e. for Fortran input) [-Wunknown-argument]
+// CHECK: clang-{{[0-9]+}}: warning: command line option '-fdefault-double-8' is only valid in Flang mode (i.e. for Fortran input) [-Wunknown-argument]
+// CHECK: clang-{{[0-9]+}}: warning: command line option '-fdefault-integer-8' is only valid in Flang mode (i.e. for Fortran input) [-Wunknown-argument]
+// CHECK: clang-{{[0-9]+}}: warning: command line option '-fdefault-real-8' is only valid in Flang mode (i.e. for Fortran input) [-Wunknown-argument]
+// CHECK: clang-{{[0-9]+}}: warning: command line option '-flarge-sizes' is only valid in Flang mode (i.e. for Fortran input) [-Wunknown-argument]
+// CHECK: clang-{{[0-9]+}}: warning: command line option '-fbackslash' is only valid in Flang mode (i.e. for Fortran input) [-Wunknown-argument]
+// CHECK: clang-{{[0-9]+}}: warning: command line option '-fno-backslash' is only valid in Flang mode (i.e. for Fortran input) [-Wunknown-argument]
+// CHECK: clang-{{[0-9]+}}: warning: command line option '-fxor-operator' is only valid in Flang mode (i.e. for Fortran input) [-Wunknown-argument]
+// CHECK: clang-{{[0-9]+}}: warning: command line option '-fno-xor-operator' is only valid in Flang mode (i.e. for Fortran input) [-Wunknown-argument]
+// CHECK: clang-{{[0-9]+}}: warning: command line option '-flogical-abbreviations' is only valid in Flang mode (i.e. for Fortran input) [-Wunknown-argument]
+// CHECK: clang-{{[0-9]+}}: warning: command line option '-fno-logical-abbreviations' is only valid in Flang mode (i.e. for Fortran input) [-Wunknown-argument]
+// CHECK: clang-{{[0-9]+}}: warning: command line option '-fimplicit-none' is only valid in Flang mode (i.e. for Fortran input) [-Wunknown-argument]
+// CHECK: clang-{{[0-9]+}}: warning: command line option '-fno-implicit-none' is only valid in Flang mode (i.e. for Fortran input) [-Wunknown-argument]
+// CHECK: clang-{{[0-9]+}}: warning: command line option '-falternative-parameter-statement' is only valid in Flang mode (i.e. for Fortran input) [-Wunknown-argument]
+// CHECK: clang-{{[0-9]+}}: warning: command line option '-fintrinsic-modules-path' is only valid in Flang mode (i.e. for Fortran input) [-Wunknown-argument]
+// CHECK: clang-{{[0-9]+}}: warning: command line option '-test-io' is only valid in Flang mode (i.e. for Fortran input) [-Wunknown-argument]
+//

[PATCH] D99260: [analyzer] Fix false positives in inner pointer checker (PR49628)

2021-04-08 Thread Valeriy Savchenko via Phabricator via cfe-commits

vsavchenko updated this revision to Diff 336077.
vsavchenko added a comment.

Require std::data to accept exactly 1 argument


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99260

Files:
  clang/lib/StaticAnalyzer/Checkers/InnerPointerChecker.cpp
  clang/test/Analysis/inner-pointer.cpp

Index: clang/test/Analysis/inner-pointer.cpp
===
--- clang/test/Analysis/inner-pointer.cpp
+++ clang/test/Analysis/inner-pointer.cpp
@@ -17,6 +17,11 @@
 string my_string = "default";
 void default_arg(int a = 42, string &b = my_string);
 
+template 
+T *addressof(T &arg);
+
+char *data(std::string &c);
+
 } // end namespace std
 
 void consume(const char *) {}
@@ -273,6 +278,15 @@
   // expected-note@-1 {{Inner pointer of container used after re/deallocation}}
 }
 
+void deref_after_std_data() {
+  const char *c;
+  std::string s;
+  c = std::data(s); // expected-note {{Pointer to inner buffer of 'std::string' obtained here}}
+  s.push_back('c'); // expected-note {{Inner buffer of 'std::string' reallocated by call to 'push_back'}}
+  consume(c);   // expected-warning {{Inner pointer of container used after re/deallocation}}
+  // expected-note@-1 {{Inner pointer of container used after re/deallocation}}
+}
+
 struct S {
   std::string s;
   const char *name() {
@@ -361,8 +375,24 @@
   // expected-note@-1 {{Inner pointer of container used after re/deallocation}}
 }
 
+void func_addressof() {
+  const char *c;
+  std::string s;
+  c = s.c_str();
+  addressof(s);
+  consume(c); // no-warning
+}
+
+void func_std_data() {
+  const char *c;
+  std::string s;
+  c = std::data(s);
+  consume(c); // no-warning
+}
+
 struct T {
   std::string to_string() { return s; }
+
 private:
   std::string s;
 };
Index: clang/lib/StaticAnalyzer/Checkers/InnerPointerChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/InnerPointerChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/InnerPointerChecker.cpp
@@ -34,9 +34,9 @@
 class InnerPointerChecker
 : public Checker {
 
-  CallDescription AppendFn, AssignFn, ClearFn, CStrFn, DataFn, EraseFn,
-  InsertFn, PopBackFn, PushBackFn, ReplaceFn, ReserveFn, ResizeFn,
-  ShrinkToFitFn, SwapFn;
+  CallDescription AppendFn, AssignFn, AddressofFn, ClearFn, CStrFn, DataFn,
+  DataMemberFn, EraseFn, InsertFn, PopBackFn, PushBackFn, ReplaceFn,
+  ReserveFn, ResizeFn, ShrinkToFitFn, SwapFn;
 
 public:
   class InnerPointerBRVisitor : public BugReporterVisitor {
@@ -73,9 +73,10 @@
   InnerPointerChecker()
   : AppendFn({"std", "basic_string", "append"}),
 AssignFn({"std", "basic_string", "assign"}),
+AddressofFn({"std", "addressof"}),
 ClearFn({"std", "basic_string", "clear"}),
-CStrFn({"std", "basic_string", "c_str"}),
-DataFn({"std", "basic_string", "data"}),
+CStrFn({"std", "basic_string", "c_str"}), DataFn({"std", "data"}, 1),
+DataMemberFn({"std", "basic_string", "data"}),
 EraseFn({"std", "basic_string", "erase"}),
 InsertFn({"std", "basic_string", "insert"}),
 PopBackFn({"std", "basic_string", "pop_back"}),
@@ -90,6 +91,9 @@
   /// pointers referring to the container object's inner buffer.
   bool isInvalidatingMemberFunction(const CallEvent &Call) const;
 
+  /// Check whether the called function returns a raw inner pointer.
+  bool isInnerPointerAccessFunction(const CallEvent &Call) const;
+
   /// Mark pointer symbols associated with the given memory region released
   /// in the program state.
   void markPtrSymbolsReleased(const CallEvent &Call, ProgramStateRef State,
@@ -130,6 +134,12 @@
   Call.isCalled(SwapFn));
 }
 
+bool InnerPointerChecker::isInnerPointerAccessFunction(
+const CallEvent &Call) const {
+  return (Call.isCalled(CStrFn) || Call.isCalled(DataFn) ||
+  Call.isCalled(DataMemberFn));
+}
+
 void InnerPointerChecker::markPtrSymbolsReleased(const CallEvent &Call,
  ProgramStateRef State,
  const MemRegion *MR,
@@ -172,6 +182,11 @@
   if (!ArgRegion)
 continue;
 
+  // std::addressof function accepts a non-const reference as an argument,
+  // but doesn't modify it.
+  if (Call.isCalled(AddressofFn))
+continue;
+
   markPtrSymbolsReleased(Call, State, ArgRegion, C);
 }
   }
@@ -195,36 +210,49 @@
 CheckerContext &C) const {
   ProgramStateRef State = C.getState();
 
+  // TODO: Do we need these to be typed?
+  const TypedValueRegion *ObjRegion = nullptr;
+
   if (const auto *ICall = dyn_cast(&Call)) {
-// TODO: Do we need these to be typed?
-const auto *ObjRegion = dyn_cast_or_null(
+ObjRegion = dyn_cast_or_null(
 ICall->getCXXThisVal().getAsRegion());
-if (!Obj

[clang] 9f0d8ba - [analyzer] Fix dead store checker false positive

2021-04-08 Thread Valeriy Savchenko via cfe-commits


Author: Valeriy Savchenko
Date: 2021-04-08T16:12:42+03:00
New Revision: 9f0d8bac144c8eb1ca4aff823b2e2d5a0f990072

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

LOG: [analyzer] Fix dead store checker false positive

It is common to zero-initialize not only scalar variables,
but also structs.  This is also defensive programming and
we shouldn't complain about that.

rdar://34122265

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

Added: 


Modified: 
clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
clang/test/Analysis/dead-stores.c

Removed: 




diff  --git a/clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp 
b/clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
index 8c86e83608b1e..8070d869f6785 100644
--- a/clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
@@ -11,17 +11,18 @@
 //
 
//===--===//
 
-#include "clang/Lex/Lexer.h"
-#include "clang/StaticAnalyzer/Checkers/BuiltinCheckerRegistration.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Attr.h"
 #include "clang/AST/ParentMap.h"
 #include "clang/AST/RecursiveASTVisitor.h"
 #include "clang/Analysis/Analyses/LiveVariables.h"
+#include "clang/Lex/Lexer.h"
+#include "clang/StaticAnalyzer/Checkers/BuiltinCheckerRegistration.h"
 #include "clang/StaticAnalyzer/Core/BugReporter/BugReporter.h"
 #include "clang/StaticAnalyzer/Core/Checker.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/AnalysisManager.h"
 #include "llvm/ADT/BitVector.h"
+#include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/Support/SaveAndRestore.h"
 
@@ -408,15 +409,17 @@ class DeadStoreObs : public LiveVariables::Observer {
   // Special case: check for initializations with constants.
   //
   //  e.g. : int x = 0;
+  // struct A = {0, 1};
+  // struct B = {{0}, {1, 2}};
   //
   // If x is EVER assigned a new value later, don't issue
   // a warning.  This is because such initialization can be
   // due to defensive programming.
-  if (E->isEvaluatable(Ctx))
+  if (isConstant(E))
 return;
 
   if (const DeclRefExpr *DRE =
-  dyn_cast(E->IgnoreParenCasts()))
+  dyn_cast(E->IgnoreParenCasts()))
 if (const VarDecl *VD = dyn_cast(DRE->getDecl())) {
   // Special case: check for initialization from constant
   //  variables.
@@ -444,6 +447,29 @@ class DeadStoreObs : public LiveVariables::Observer {
 }
   }
   }
+
+private:
+  /// Return true if the given init list can be interpreted as constant
+  bool isConstant(const InitListExpr *Candidate) const {
+// We consider init list to be constant if each member of the list can be
+// interpreted as constant.
+return llvm::all_of(Candidate->inits(),
+[this](const Expr *Init) { return isConstant(Init); });
+  }
+
+  /// Return true if the given expression can be interpreted as constant
+  bool isConstant(const Expr *E) const {
+// It looks like E itself is a constant
+if (E->isEvaluatable(Ctx))
+  return true;
+
+// We should also allow defensive initialization of structs, i.e. { 0 }
+if (const auto *ILE = dyn_cast(E->IgnoreParenCasts())) {
+  return isConstant(ILE);
+}
+
+return false;
+  }
 };
 
 } // end anonymous namespace

diff  --git a/clang/test/Analysis/dead-stores.c 
b/clang/test/Analysis/dead-stores.c
index a17e1692496da..145b81bd03327 100644
--- a/clang/test/Analysis/dead-stores.c
+++ b/clang/test/Analysis/dead-stores.c
@@ -635,3 +635,44 @@ void testVolatile() {
   volatile int v;
   v = 0; // no warning
 }
+
+struct Foo {
+  int x;
+  int y;
+};
+
+struct Foo rdar34122265_getFoo(void);
+
+int rdar34122265_test(int input) {
+  // This is allowed for defensive programming.
+  struct Foo foo = {0, 0};
+  if (input > 0) {
+foo = rdar34122265_getFoo();
+  } else {
+return 0;
+  }
+  return foo.x + foo.y;
+}
+
+void rdar34122265_test_cast() {
+  // This is allowed for defensive programming.
+  struct Foo foo = {0, 0};
+  (void)foo;
+}
+
+struct Bar {
+  struct Foo x, y;
+};
+
+struct Bar rdar34122265_getBar(void);
+
+int rdar34122265_test_nested(int input) {
+  // This is allowed for defensive programming.
+  struct Bar bar = {{0, 0}, {0, 0}};
+  if (input > 0) {
+bar = rdar34122265_getBar();
+  } else {
+return 0;
+  }
+  return bar.x.x + bar.y.y;
+}



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
h

[PATCH] D99262: [analyzer] Fix dead store checker false positive

2021-04-08 Thread Valeriy Savchenko via Phabricator via cfe-commits

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG9f0d8bac144c: [analyzer] Fix dead store checker false 
positive (authored by vsavchenko).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99262

Files:
  clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
  clang/test/Analysis/dead-stores.c

Index: clang/test/Analysis/dead-stores.c
===
--- clang/test/Analysis/dead-stores.c
+++ clang/test/Analysis/dead-stores.c
@@ -635,3 +635,44 @@
   volatile int v;
   v = 0; // no warning
 }
+
+struct Foo {
+  int x;
+  int y;
+};
+
+struct Foo rdar34122265_getFoo(void);
+
+int rdar34122265_test(int input) {
+  // This is allowed for defensive programming.
+  struct Foo foo = {0, 0};
+  if (input > 0) {
+foo = rdar34122265_getFoo();
+  } else {
+return 0;
+  }
+  return foo.x + foo.y;
+}
+
+void rdar34122265_test_cast() {
+  // This is allowed for defensive programming.
+  struct Foo foo = {0, 0};
+  (void)foo;
+}
+
+struct Bar {
+  struct Foo x, y;
+};
+
+struct Bar rdar34122265_getBar(void);
+
+int rdar34122265_test_nested(int input) {
+  // This is allowed for defensive programming.
+  struct Bar bar = {{0, 0}, {0, 0}};
+  if (input > 0) {
+bar = rdar34122265_getBar();
+  } else {
+return 0;
+  }
+  return bar.x.x + bar.y.y;
+}
Index: clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
@@ -11,17 +11,18 @@
 //
 //===--===//
 
-#include "clang/Lex/Lexer.h"
-#include "clang/StaticAnalyzer/Checkers/BuiltinCheckerRegistration.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Attr.h"
 #include "clang/AST/ParentMap.h"
 #include "clang/AST/RecursiveASTVisitor.h"
 #include "clang/Analysis/Analyses/LiveVariables.h"
+#include "clang/Lex/Lexer.h"
+#include "clang/StaticAnalyzer/Checkers/BuiltinCheckerRegistration.h"
 #include "clang/StaticAnalyzer/Core/BugReporter/BugReporter.h"
 #include "clang/StaticAnalyzer/Core/Checker.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/AnalysisManager.h"
 #include "llvm/ADT/BitVector.h"
+#include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/Support/SaveAndRestore.h"
 
@@ -408,15 +409,17 @@
   // Special case: check for initializations with constants.
   //
   //  e.g. : int x = 0;
+  // struct A = {0, 1};
+  // struct B = {{0}, {1, 2}};
   //
   // If x is EVER assigned a new value later, don't issue
   // a warning.  This is because such initialization can be
   // due to defensive programming.
-  if (E->isEvaluatable(Ctx))
+  if (isConstant(E))
 return;
 
   if (const DeclRefExpr *DRE =
-  dyn_cast(E->IgnoreParenCasts()))
+  dyn_cast(E->IgnoreParenCasts()))
 if (const VarDecl *VD = dyn_cast(DRE->getDecl())) {
   // Special case: check for initialization from constant
   //  variables.
@@ -444,6 +447,29 @@
 }
   }
   }
+
+private:
+  /// Return true if the given init list can be interpreted as constant
+  bool isConstant(const InitListExpr *Candidate) const {
+// We consider init list to be constant if each member of the list can be
+// interpreted as constant.
+return llvm::all_of(Candidate->inits(),
+[this](const Expr *Init) { return isConstant(Init); });
+  }
+
+  /// Return true if the given expression can be interpreted as constant
+  bool isConstant(const Expr *E) const {
+// It looks like E itself is a constant
+if (E->isEvaluatable(Ctx))
+  return true;
+
+// We should also allow defensive initialization of structs, i.e. { 0 }
+if (const auto *ILE = dyn_cast(E->IgnoreParenCasts())) {
+  return isConstant(ILE);
+}
+
+return false;
+  }
 };
 
 } // end anonymous namespace
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2021-04-08 Thread Jon Chesterfield via Phabricator via cfe-commits

JonChesterfield added inline comments.



Comment at: clang/include/clang/Driver/Options.td:921
   HelpText<"HIP runtime installation path, used for finding HIP version and 
adding HIP include path.">;
+def amdgpu_arch_tool_path_EQ : Joined<["--"], "amdgpu-arch-tool-path=">, 
Group,
+  HelpText<"Path to amdgpu_arch tool, used for detecting AMD GPU arch in the 
system.">;

I'd expect path to be the directory in which the tool is found, whereas this is 
used to name the tool itself. Perhaps 'amdgpu_arch_tool='? We might be able to 
write the default string inline as part of the argument definition, otherwise 
the current handling looks ok



Comment at: clang/test/Driver/amdgpu-openmp-system-arch.c:1
+// REQUIRES: system-linux
+// REQUIRES: x86-registered-target

This seems fairly clear. We might want to drop the fcuda-is-device from the 
regex as it doesn't matter for the test.

Failing cases (maybe driven by a separate C file) are probably:
print nothing, return 0
print nothing, return 1
print two different strings, return 0



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99949

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

[PATCH] D99291: [AIX] Support init priority attribute

2021-04-08 Thread Xiangling Liao via Phabricator via cfe-commits

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



Comment at: clang/lib/CodeGen/CGDeclCXX.cpp:663
 
+  // Create our global prioritized cleanup function.
+  if (!PrioritizedCXXStermFinalizers.empty()) {

jasonliu wrote:
> Just noting that this trunk of code have very similar logic counter part in 
> `EmitCXXGlobalInitFunc`. It seems there is no easy way to common them up 
> given the current way of implementing it. It may require a non-trivial amount 
> of refactoring for us to common up the similar logic between init and 
> cleanup. 
Yes, I thought about this as well but it looks if we'd like to common it up, we 
may need to create some template function.


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

https://reviews.llvm.org/D99291

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

[clang] 9229465 - [NFC] Fix warning introduced in 20105b6b4874a85813f7a4a3d8ad2a0f023dda14

2021-04-08 Thread via cfe-commits


Author: serge-sans-paille
Date: 2021-04-08T16:11:01+02:00
New Revision: 9229465bad8504190bdfb92be829cb6c1157fea5

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

LOG: [NFC] Fix warning introduced in 20105b6b4874a85813f7a4a3d8ad2a0f023dda14

Added: 


Modified: 
clang/lib/Basic/SourceManager.cpp

Removed: 




diff  --git a/clang/lib/Basic/SourceManager.cpp 
b/clang/lib/Basic/SourceManager.cpp
index f0c4f88fde57f..438525b1ee133 100644
--- a/clang/lib/Basic/SourceManager.cpp
+++ b/clang/lib/Basic/SourceManager.cpp
@@ -1262,7 +1262,7 @@ static constexpr inline T likelyhasbetween(T x, unsigned 
char m,
unsigned char n) {
   return ((x - ~static_cast(0) / 255 * (n + 1)) & ~x &
   (x & ~static_cast(0) / 255 * 127) +
-  ~static_cast(0) / 255 * (127 - (m - 1))) &
+  (~static_cast(0) / 255 * (127 - (m - 1 &
  ~static_cast(0) / 255 * 128;
 }
 



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

[PATCH] D100092: [clang-tidy] cppcoreguidelines-declare-loop-variable-in-the-initializer: a new check

2021-04-08 Thread Eugene Zelenko via Phabricator via cfe-commits

Eugene.Zelenko added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/cppcoreguidelines/DeclareLoopVariableInTheInitializerCheck.cpp:28
+
+  diag(MatchedForStmt->getBeginLoc(),
+   "Prefer to declare a loop variable in the initializer part of a "

It'll be reasonable to add add note with actual variable declaration.



Comment at: 
clang-tools-extra/clang-tidy/cppcoreguidelines/DeclareLoopVariableInTheInitializerCheck.cpp:30
+   "Prefer to declare a loop variable in the initializer part of a "
+   "for-statement");
+}

I think should be `for statement`.



Comment at: 
clang-tools-extra/clang-tidy/cppcoreguidelines/DeclareLoopVariableInTheInitializerCheck.h:1
+//===--- DeclareLoopVariableInTheInitializerCheck.h - clang-tidy *- C++ 
-*-===//
+//

I may be mistaken, but proper code is `-*- C++ -*-`. Please remove  dash at 
left side.



Comment at: 
clang-tools-extra/clang-tidy/cppcoreguidelines/DeclareLoopVariableInTheInitializerCheck.h:24
+class DeclareLoopVariableInTheInitializerCheck : public ClangTidyCheck {
+public:
+  DeclareLoopVariableInTheInitializerCheck(StringRef Name,

Please add `isLanguageVersionSupported`. Older versions of C doesn't support 
variable declarations inside `for` loops.



Comment at: clang-tools-extra/docs/ReleaseNotes.rst:95
+
+  Checks if a loop variable is declared in the initializer part of a 
for-statement.
+

I think should be for statement and for highlighted with double back-ticks.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-declare-loop-variable-in-the-initializer.rst:6
+
+Checks if a loop variable is declared in the initializer part of a 
for-statement.
+

Please synchronize with statement in Release Notes.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-declare-loop-variable-in-the-initializer.rst:8
+
+This check implements the rule `ES.74 
`_
 of the C++ Core Guidelines.
+

Such references are usually placed at the end. See other checks documentation 
as example.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100092

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

[PATCH] D99526: [RISCV][Clang] Add RVV Widening Integer Add/Subtract intrinsic functions.

2021-04-08 Thread Zakk Chen via Phabricator via cfe-commits

khchen updated this revision to Diff 336100.
khchen added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99526

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vwadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vwsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vwadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vwsub.c

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

[PATCH] D99517: Implemented [[clang::musttail]] attribute for guaranteed tail calls.

2021-04-08 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaStmt.cpp:561-568
+  for (const auto *A : Attrs) {
+if (A->getKind() == attr::MustTail) {
+  if (!checkMustTailAttr(SubStmt, *A)) {
+return SubStmt;
+  }
+  setFunctionHasMustTail();
+}

haberman wrote:
> aaron.ballman wrote:
> > haberman wrote:
> > > aaron.ballman wrote:
> > > > rsmith wrote:
> > > > > aaron.ballman wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > haberman wrote:
> > > > > > > > aaron.ballman wrote:
> > > > > > > > > haberman wrote:
> > > > > > > > > > haberman wrote:
> > > > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > > > haberman wrote:
> > > > > > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > > > > > This functionality belongs in SemaStmtAttr.cpp, I 
> > > > > > > > > > > > > > think.
> > > > > > > > > > > > > That is where I had originally put it, but that 
> > > > > > > > > > > > > didn't work for templates. The semantic checks can 
> > > > > > > > > > > > > only be performed at instantiation time. 
> > > > > > > > > > > > > `ActOnAttributedStmt` seems to be the right hook 
> > > > > > > > > > > > > point where I can evaluate the semantic checks for 
> > > > > > > > > > > > > both template and non-template functions (with 
> > > > > > > > > > > > > template functions getting checked at instantiation 
> > > > > > > > > > > > > time).
> > > > > > > > > > > > I disagree that `ActOnAttributedStmt()` is the correct 
> > > > > > > > > > > > place for this checking -- template checking should 
> > > > > > > > > > > > occur when the template is instantiated, same as 
> > > > > > > > > > > > happens for declaration attributes. I'd like to see 
> > > > > > > > > > > > this functionality moved to SemaStmtAttr.cpp. Keeping 
> > > > > > > > > > > > the attribute logic together and following the same 
> > > > > > > > > > > > patterns is what allows us to tablegenerate more of the 
> > > > > > > > > > > > attribute logic. Statement attributes are just starting 
> > > > > > > > > > > > to get more such automation.
> > > > > > > > > > > I tried commenting out this code and adding the following 
> > > > > > > > > > > code into `handleMustTailAttr()` in `SemaStmtAttr.cpp`:
> > > > > > > > > > > 
> > > > > > > > > > > ```
> > > > > > > > > > >   if (!S.checkMustTailAttr(St, MTA))
> > > > > > > > > > > return nullptr;
> > > > > > > > > > > ```
> > > > > > > > > > > 
> > > > > > > > > > > This caused my test cases related to templates to fail. 
> > > > > > > > > > > It also seemed to break test cases related to 
> > > > > > > > > > > `JumpDiagnostics`. My interpretation of this is that 
> > > > > > > > > > > `handleMustTailAttr()` is called during parsing only, and 
> > > > > > > > > > > cannot catch errors at template instantiation time or 
> > > > > > > > > > > that require a more complete AST.
> > > > > > > > > > > 
> > > > > > > > > > > What am I missing? Where in SemaStmtAttr.cpp are you 
> > > > > > > > > > > suggesting that I put this check?
> > > > > > > > > > Scratch the part about `JumpDiagnostics`, that was me 
> > > > > > > > > > failing to call `S.setFunctionHasMustTail()`. I added that 
> > > > > > > > > > and now the `JumpDiagnostics` tests pass.
> > > > > > > > > > 
> > > > > > > > > > But the template test cases still fail, and I can't find 
> > > > > > > > > > any hook point in `SemaStmtAttr.cpp` that will let me 
> > > > > > > > > > evaluate these checks at template instantiation time.
> > > > > > > > > I think there's a bit of an architectural mixup, but I'm 
> > > > > > > > > curious if @rsmith agrees before anyone starts doing work to 
> > > > > > > > > make changes.
> > > > > > > > > 
> > > > > > > > > When transforming declarations, `RebuildWhatever()` calls the 
> > > > > > > > > `ActOnWhatever()` function which calls 
> > > > > > > > > `ProcessDeclAttributeList()` so that attributes are 
> > > > > > > > > processed. `RebuildAttributedStmt()` similarly calls 
> > > > > > > > > `ActOnAttributedStmt()`. However, `ActOnAttributedStmt()` 
> > > > > > > > > doesn't call `ProcessStmtAttributes()` -- the logic is 
> > > > > > > > > reversed so that `ProcessStmtAttributes()` is what calls 
> > > > > > > > > `ActOnAttributedStmt()`.
> > > > > > > > > 
> > > > > > > > > I think the correct answer is to switch the logic so that 
> > > > > > > > > `ActOnAttributedStmt()` calls `ProcessStmtAttributes()`, then 
> > > > > > > > > the template logic should automatically work.
> > > > > > > > > I think the correct answer is to switch the logic so that 
> > > > > > > > > ActOnAttributedStmt() calls ProcessStmtAttributes()
> > > > > > > > 
> > > > > > > > I think this would require `ProcessStmtAttributes()` to be 
> > > > > > > > split into two separate functions. Currently that function is 
> > > > > > > > doing two separate things:
> > > > > > > > 
> > > > > > > > 1. Translation of `ParsedAttr` into various subclasses of 
> > > > > > > > `At

[PATCH] D99668: [RISCV][Clang] Add some RVV Floating-Point intrinsic functions.

2021-04-08 Thread Zakk Chen via Phabricator via cfe-commits

khchen updated this revision to Diff 336101.
khchen added a comment.

rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99668

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfdiv.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmax.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmin.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfrdiv.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfrsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfsgnj.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfdiv.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfmax.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfmin.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfrdiv.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfrsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfsgnj.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfsub.c

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

[PATCH] D97116: Reduce the number of attributes attached to each function

2021-04-08 Thread Wei Xiao via Phabricator via cfe-commits

wxiao3 added inline comments.



Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:496
   //function.
-  CurFn->addFnAttr("min-legal-vector-width", llvm::utostr(LargestVectorWidth));
+  if (LargestVectorWidth)
+CurFn->addFnAttr("min-legal-vector-width", 
llvm::utostr(LargestVectorWidth));

lebedev.ri wrote:
> wxiao3 wrote:
> > For x86 backend, "LargestVectorWidth" default value is not zero but 
> > UINT32_MAX.
> > Please refer to: 
> > https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/X86/X86TargetMachine.cpp#L271
> > Suggest revert this patch since it changes the code generated for x86.
> Reproducer please?
```
$ cat test.c
void foo(float* in, float* __restrict out, int n)
{
int i;
for (i = 0; i < n; i++) {
out[i] = i + 2*in[i];
}
}
```

Before this patch

```
$ clang -Ofast -march=skylake-avx512 -mllvm -force-vector-width=16 
-mprefer-vector-width=256 -S -o - test.c | grep ymm | wc
 57 3332687
```

After this patch

```
$ clang -Ofast -march=skylake-avx512 -mllvm -force-vector-width=16 
-mprefer-vector-width=256 -S -o - test.c | grep ymm | wc
  0   0   0
```





Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97116

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

[PATCH] D99181: [analyzer] Fix crash on spaceship operator (PR47511)

2021-04-08 Thread Valeriy Savchenko via Phabricator via cfe-commits

vsavchenko updated this revision to Diff 336108.
vsavchenko marked 4 inline comments as done.
vsavchenko added a comment.

Change produced SVal for the spaceship operator from Undefined to Unknown


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99181

Files:
  clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
  clang/test/Analysis/PR47511.cpp


Index: clang/test/Analysis/PR47511.cpp
===
--- /dev/null
+++ clang/test/Analysis/PR47511.cpp
@@ -0,0 +1,19 @@
+// RUN: %clang_analyze_cc1 -std=c++20 -w -analyzer-checker=core -verify %s
+
+// expected-no-diagnostics
+
+namespace std {
+struct strong_ordering {
+  int n;
+  constexpr operator int() const { return n; }
+  static const strong_ordering equal, greater, less;
+};
+constexpr strong_ordering strong_ordering::equal = {0};
+constexpr strong_ordering strong_ordering::greater = {1};
+constexpr strong_ordering strong_ordering::less = {-1};
+} // namespace std
+
+void test() {
+  // no crash
+  (void)(0 <=> 0);
+}
Index: clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
===
--- clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
+++ clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
@@ -423,6 +423,14 @@
 return UnknownVal();
   }
 
+  if (op == BinaryOperatorKind::BO_Cmp) {
+// We can't reason about C++20 spaceship operator yet.
+//
+// FIXME: Support C++20 spaceship operator.
+//The main problem here is that the result is not integer.
+return UnknownVal();
+  }
+
   if (Optional LV = lhs.getAs()) {
 if (Optional RV = rhs.getAs())
   return evalBinOpLL(state, op, *LV, *RV, type);


Index: clang/test/Analysis/PR47511.cpp
===
--- /dev/null
+++ clang/test/Analysis/PR47511.cpp
@@ -0,0 +1,19 @@
+// RUN: %clang_analyze_cc1 -std=c++20 -w -analyzer-checker=core -verify %s
+
+// expected-no-diagnostics
+
+namespace std {
+struct strong_ordering {
+  int n;
+  constexpr operator int() const { return n; }
+  static const strong_ordering equal, greater, less;
+};
+constexpr strong_ordering strong_ordering::equal = {0};
+constexpr strong_ordering strong_ordering::greater = {1};
+constexpr strong_ordering strong_ordering::less = {-1};
+} // namespace std
+
+void test() {
+  // no crash
+  (void)(0 <=> 0);
+}
Index: clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
===
--- clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
+++ clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
@@ -423,6 +423,14 @@
 return UnknownVal();
   }
 
+  if (op == BinaryOperatorKind::BO_Cmp) {
+// We can't reason about C++20 spaceship operator yet.
+//
+// FIXME: Support C++20 spaceship operator.
+//The main problem here is that the result is not integer.
+return UnknownVal();
+  }
+
   if (Optional LV = lhs.getAs()) {
 if (Optional RV = rhs.getAs())
   return evalBinOpLL(state, op, *LV, *RV, type);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D99353: [driver] Make `clang` warn rather then error on `flang` options

2021-04-08 Thread Andrzej Warzynski via Phabricator via cfe-commits

awarzynski added a comment.

I've just send an RFC for this change to cfe-dev: 
https://lists.llvm.org/pipermail/cfe-dev/2021-April/067981.html.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99353

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

[PATCH] D97669: [clang][AVR] Add avr-libc/include to clang system include paths

2021-04-08 Thread Anastasia Stulova via Phabricator via cfe-commits

Anastasia added a comment.

In D97669#2665865 , @benshi001 wrote:

> In D97669#2661560 , @Anastasia wrote:
>
>> Is `stdio.h`  used by anything?
>
> No. `stdio.h` is not used. But if I do `#include `, then `-I 
> /usr/lib/avr/include` must be specified in the command line option. While 
> avr-gcc does not reqiures that.
>
> I would like to keep clang & avr-gcc in the behaviour.

Ok, do you plan to use it later? Then perhaps you should be adding it in the 
subsequent patches?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97669

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

[PATCH] D99669: [RISCV][Clang] Add more RVV Floating-Point intrinsic functions.

2021-04-08 Thread Zakk Chen via Phabricator via cfe-commits

khchen updated this revision to Diff 336117.
khchen added a comment.

rebase.

I don't know why `let` cannot overide field when we change instantiate single 
multiclasses to inheritance.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99669

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfnmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfnmadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfnmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfnmsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwnmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwnmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmfeq.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmfge.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmfgt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmfle.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmflt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmfne.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfmadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfmsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfnmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfnmadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfnmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfnmsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwnmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwnmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmfeq.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmfge.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmfgt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmfle.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmflt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmfne.c

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

[PATCH] D99964: [RISCV][Clang] Add all RVV Reduction intrinsic functions.

2021-04-08 Thread Zakk Chen via Phabricator via cfe-commits

khchen updated this revision to Diff 336123.
khchen added a comment.

rebase.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99964

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfredmax.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfredmin.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfredsum.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwredsum.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vredand.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vredmax.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vredmin.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vredor.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vredsum.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vredxor.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vwredsum.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfredmax.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfredmin.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfredsum.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwredosum.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwredsum.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vredand.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vredmax.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vredmin.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vredor.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vredsum.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vredxor.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vwredsum.c

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

[PATCH] D99984: [RISCV] Prevent __builtin_riscv_orc_b_64 from being compiled RV32 target.

2021-04-08 Thread Craig Topper via Phabricator via cfe-commits

craig.topper added inline comments.



Comment at: clang/lib/Basic/Targets/RISCV.cpp:259
   .Case("riscv64", Is64Bit)
+  .Case("64bit", Is64Bit)
   .Case("m", HasM)

frasercrmck wrote:
> What's the difference between this new feature and `riscv64` above?
The name I added to initFeatureMap has to match the feature name in RISCV.td 
because it will end up in the target-features attribute in IR.

SemaChecking just calls hasFeature, but CodeGenFunction also checks builtin 
features using the feature map. We check features in SemaChecking because the 
CodeGenFunction diagnostic isn’t phrased well for RISCV.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99984

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

[PATCH] D97116: Reduce the number of attributes attached to each function

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

xbolva00 added inline comments.



Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:496
   //function.
-  CurFn->addFnAttr("min-legal-vector-width", llvm::utostr(LargestVectorWidth));
+  if (LargestVectorWidth)
+CurFn->addFnAttr("min-legal-vector-width", 
llvm::utostr(LargestVectorWidth));

wxiao3 wrote:
> lebedev.ri wrote:
> > wxiao3 wrote:
> > > For x86 backend, "LargestVectorWidth" default value is not zero but 
> > > UINT32_MAX.
> > > Please refer to: 
> > > https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/X86/X86TargetMachine.cpp#L271
> > > Suggest revert this patch since it changes the code generated for x86.
> > Reproducer please?
> ```
> $ cat test.c
> void foo(float* in, float* __restrict out, int n)
> {
> int i;
> for (i = 0; i < n; i++) {
> out[i] = i + 2*in[i];
> }
> }
> ```
> 
> Before this patch
> 
> ```
> $ clang -Ofast -march=skylake-avx512 -mllvm -force-vector-width=16 
> -mprefer-vector-width=256 -S -o - test.c | grep ymm | wc
>  57 3332687
> ```
> 
> After this patch
> 
> ```
> $ clang -Ofast -march=skylake-avx512 -mllvm -force-vector-width=16 
> -mprefer-vector-width=256 -S -o - test.c | grep ymm | wc
>   0   0   0
> ```
> 
> 
> 
Hello, reverted. 
https://reviews.llvm.org/rG2cb8c10342ee5d040725abb1166feb92a64c7df6


It would be good to somehow make a test to not regress in the future, but not 
sure how, as we have no "C -> X86 asm" tests?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97116

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

[PATCH] D99517: Implemented [[clang::musttail]] attribute for guaranteed tail calls.

2021-04-08 Thread Josh Haberman via Phabricator via cfe-commits

haberman updated this revision to Diff 336130.
haberman added a comment.

- Added FIXME for attribute refactoring.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99517

Files:
  clang/include/clang/AST/Expr.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/ScopeInfo.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Expr.cpp
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGClass.cpp
  clang/lib/CodeGen/CGDecl.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGExprCXX.cpp
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/CodeGen/EHScopeStack.h
  clang/lib/Sema/JumpDiagnostics.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaStmtAttr.cpp
  clang/test/CodeGen/attr-musttail.cpp
  clang/test/Sema/attr-musttail.c
  clang/test/Sema/attr-musttail.cpp
  clang/test/Sema/attr-musttail.m

Index: clang/test/Sema/attr-musttail.m
===
--- /dev/null
+++ clang/test/Sema/attr-musttail.m
@@ -0,0 +1,28 @@
+// RUN: %clang_cc1 -fsyntax-only -fblocks -Wno-objc-root-class -verify %s
+
+void TestObjcBlock(void) {
+  void (^x)(void) = ^(void) {
+__attribute__((musttail)) return TestObjcBlock(); // expected-error{{'musttail' attribute cannot be used from a block}}
+  };
+  __attribute__((musttail)) return x();
+}
+
+void ReturnsVoid(void);
+void TestObjcBlockVar(void) {
+  __block int i = 0;  // expected-note{{jump exits scope of __block variable}}
+  __attribute__((musttail)) return ReturnsVoid();  // expected-error{{cannot perform a tail call from this return statement}}
+}
+
+//#import 
+
+__attribute__((objc_root_class))
+@interface TestObjcClass
+@end
+
+@implementation TestObjcClass
+
+- (void)testObjCMethod {
+  __attribute__((musttail)) return ReturnsVoid(); // expected-error{{'musttail' attribute cannot be used from an Objective-C function}}
+}
+
+@end
Index: clang/test/Sema/attr-musttail.cpp
===
--- /dev/null
+++ clang/test/Sema/attr-musttail.cpp
@@ -0,0 +1,191 @@
+// RUN: %clang_cc1 -verify -fsyntax-only -fms-extensions -fcxx-exceptions -fopenmp %s
+
+int ReturnsInt1();
+int Func1() {
+  [[clang::musttail]] ReturnsInt1();   // expected-error {{'musttail' attribute only applies to return statements}}
+  [[clang::musttail(1, 2)]] return ReturnsInt1(); // expected-error {{'musttail' attribute takes no arguments}}
+  [[clang::musttail]] return 5;// expected-error {{'musttail' attribute requires that the return value is the result of a function call}}
+  [[clang::musttail]] return ReturnsInt1();
+}
+
+void NoFunctionCall() {
+  [[clang::musttail]] return;  // expected-error {{'musttail' attribute requires that the return value is the result of a function call}}
+}
+
+[[clang::musttail]] static int int_val = ReturnsInt1(); // expected-error {{'musttail' attribute cannot be applied to a declaration}}
+
+void NoParams(); // expected-note {{target function has different number of parameters (expected 1 but has 0)}}
+void TestParamArityMismatch(int x) {
+  [[clang::musttail]] return NoParams(); // expected-error {{'musttail' attribute requires that caller and callee have compatible function signatures}}
+}
+
+void LongParam(long x); // expected-note {{target function has type mismatch at 1st parameter (expected 'long' but has 'int')}}
+void TestParamTypeMismatch(int x) {
+  [[clang::musttail]] return LongParam(x); // expected-error {{'musttail' attribute requires that caller and callee have compatible function signatures}}
+}
+
+long ReturnsLong(); // expected-note {{target function has different return type ('int' expected but has 'long')}}
+int TestReturnTypeMismatch() {
+  [[clang::musttail]] return ReturnsLong(); // expected-error {{'musttail' attribute requires that caller and callee have compatible function signatures}}
+}
+
+struct Struct1 {
+  void MemberFunction(); // expected-note {{target function is a member of different class (expected 'void' but has 'Struct1')}}
+};
+void TestNonMemberToMember() {
+  Struct1 st;
+  [[clang::musttail]] return st.MemberFunction(); // expected-error {{'musttail' attribute requires that caller and callee have compatible function signatures}}
+}
+
+void ReturnsVoid(); // expected-note {{target function is a member of different class (expected 'Struct2' but has 'void')}}
+struct Struct2 {
+  void TestMemberToNonMember() {
+[[clang::musttail]] return ReturnsVoid(); // expected-error{{'musttail' attribute requires that caller and callee have compatible function signatures}}
+  }
+};
+
+class HasNonTrivialDestructor {
+public:
+  ~HasNonTrivialDestructor() {}
+  int ReturnsInt();
+};
+
+void ReturnsVoid2();
+void TestNonTrivialDestructorInScope() {
+  HasNonTrivialDestructor foo;

[PATCH] D100085: [X86] Support -march=rocketlake

2021-04-08 Thread Freddy, Ye via Phabricator via cfe-commits

FreddyYe updated this revision to Diff 336133.
FreddyYe added a comment.
Herald added a subscriber: jfb.

update lit test and clang-format


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100085

Files:
  clang/lib/Basic/Targets/X86.cpp
  clang/test/CodeGen/attr-target-mv.c
  clang/test/CodeGen/target-builtin-noerror.c
  clang/test/Driver/x86-march.c
  clang/test/Misc/target-invalid-cpu-note.c
  clang/test/Preprocessor/predefined-arch-macros.c
  compiler-rt/lib/builtins/cpu_model.c
  llvm/include/llvm/Support/X86TargetParser.def
  llvm/include/llvm/Support/X86TargetParser.h
  llvm/lib/Support/Host.cpp
  llvm/lib/Support/X86TargetParser.cpp
  llvm/lib/Target/X86/X86.td
  llvm/test/CodeGen/X86/cpus-intel.ll

Index: llvm/test/CodeGen/X86/cpus-intel.ll
===
--- llvm/test/CodeGen/X86/cpus-intel.ll
+++ llvm/test/CodeGen/X86/cpus-intel.ll
@@ -38,6 +38,7 @@
 ; RUN: llc < %s -o /dev/null -mtriple=x86_64-unknown-unknown -mcpu=cooperlake 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ERROR --allow-empty
 ; RUN: llc < %s -o /dev/null -mtriple=x86_64-unknown-unknown -mcpu=cannonlake 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ERROR --allow-empty
 ; RUN: llc < %s -o /dev/null -mtriple=x86_64-unknown-unknown -mcpu=icelake-client 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ERROR --allow-empty
+; RUN: llc < %s -o /dev/null -mtriple=x86_64-unknown-unknown -mcpu=rocketlake 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ERROR --allow-empty
 ; RUN: llc < %s -o /dev/null -mtriple=x86_64-unknown-unknown -mcpu=icelake-server 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ERROR --allow-empty
 ; RUN: llc < %s -o /dev/null -mtriple=x86_64-unknown-unknown -mcpu=tigerlake 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ERROR --allow-empty
 ; RUN: llc < %s -o /dev/null -mtriple=x86_64-unknown-unknown -mcpu=sapphirerapids 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ERROR --allow-empty
Index: llvm/lib/Target/X86/X86.td
===
--- llvm/lib/Target/X86/X86.td
+++ llvm/lib/Target/X86/X86.td
@@ -754,7 +754,7 @@
   list ICXFeatures =
 !listconcat(ICLFeatures, ICXAdditionalFeatures);
 
-  //Tigerlake
+  // Tigerlake
   list TGLAdditionalFeatures = [FeatureVP2INTERSECT,
   FeatureMOVDIRI,
   FeatureMOVDIR64B,
@@ -763,7 +763,35 @@
   list TGLFeatures =
 !listconcat(ICLFeatures, TGLAdditionalFeatures );
 
-  //Sapphirerapids
+  // Rocketlake
+  list RKLAdditionalFeatures = [FeatureAES,
+  FeatureXSAVEC,
+  FeatureXSAVES,
+  FeatureCLFLUSHOPT,
+  FeatureAVX512,
+  FeatureCDI,
+  FeatureDQI,
+  FeatureBWI,
+  FeatureVLX,
+  FeaturePKU,
+  FeatureVBMI,
+  FeatureIFMA,
+  FeatureSHA,
+  FeatureBITALG,
+  FeatureVAES,
+  FeatureVBMI2,
+  FeatureVNNI,
+  FeatureVPCLMULQDQ,
+  FeatureVPOPCNTDQ,
+  FeatureGFNI,
+  FeatureCLWB,
+  FeatureRDPID,
+  FeatureFSRM];
+  list RKLTuning = ICLTuning;
+  list RKLFeatures =
+!listconcat(BDWFeatures, RKLAdditionalFeatures);
+
+  // Sapphirerapids
   list SPRAdditionalFeatures = [FeatureAMXTILE,
   FeatureAMXINT8,
   FeatureAMXBF16,
@@ -1307,6 +1335,8 @@
 ProcessorFeatures.CNLFeatures, ProcessorFeatures.CNLTuning>;
 def : ProcModel<"icelake-client", SkylakeServerModel,
 ProcessorFeatures.ICLFeatures, ProcessorFeatures.ICLTuning>;
+def : ProcModel<"rocketlake", SkylakeServerModel,
+ProcessorFeatures.RKLFeatures, ProcessorFeatures.RKLTuning>;
 def : ProcModel<"icelake-server", SkylakeServerModel,
 ProcessorFeatures.ICXFeatures, ProcessorFeatures.ICXTuning>;
 def : ProcModel<"tigerlake", SkylakeServerModel,
Index: llvm/lib/Support/

[PATCH] D100085: [X86] Support -march=rocketlake

2021-04-08 Thread Freddy, Ye via Phabricator via cfe-commits

FreddyYe added a comment.

Hi @MaskRay , I tried to refactor the test file by assembling the common 
CHECKs. But I found it will lead to too many check-prefixes ine one RUN line. 
For example,

  // RUN: %clang -march=c3 -m32 -E -dM %s -o - 2>&1 \
  // RUN: -target i386-unknown-linux \
  // RUN:   | FileCheck -match-full-lines %s 
-check-prefixes=CHECK_I386_M32C,CHECK_I486_M32C,CHECK_I486_M32S,CHECK_PENTIUM_MMX_M32S,CHECK_WINCHIP2_M32S
  
  // CHECK_WINCHIP2_M32S: #define __3dNOW__ 1
  // CHECK_PENTIUM_MMX_M32S:#define __MMX__ 1
  // CHECK_WINCHIP_C6_M32S: #define __MMX__ 1
  // CHECK_I386_M32C: #define __i386 1
  // CHECK_I386_M32C: #define __i386__ 1
  // CHECK_I486_M32C: #define __i486 1
  // CHECK_I486_M32C: #define __i486__ 1
  // CHECK_I586_M32C: #define __i586 1
  // CHECK_I586_M32C: #define __i586__ 1
  // CHECK_I586_M32C: #define __pentium 1
  // CHECK_I586_M32C: #define __pentium__ 1
  // CHECK_PENTIUM_MMX_M32S:  #define __pentium_mmx__ 1
  // CHECK_I386_M32S: #define __tune_i386__ 1
  // CHECK_I486_M32S: #define __tune_i486__ 1
  // CHECK_PENTIUM_MMX_M32S:  #define __tune_pentium_mmx__ 1
  // CHECK_I386_M32C: #define i386 1

And that CPU is still a very old CPU. It is easy to imagine how long for 
example skylake's RUN line is. Generally speaking, X86's ISA evolution between 
different chips is not very clear. So this refactoring work is beyond my ETA. I 
uploaded a new version to reuse the most similar CHECKS. Does that look good to 
you?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100085

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

[PATCH] D100118: [clang] RFC Support new arithmetic __fence builtin to control floating point optiization

2021-04-08 Thread Melanie Blower via Phabricator via cfe-commits

mibintc created this revision.
mibintc added a reviewer: kpn.
Herald added a subscriber: jfb.
mibintc requested review of this revision.
Herald added projects: clang, LLVM.
Herald added a subscriber: llvm-commits.

This is a proposal to add a new clang builtin, __arithmetic_fence.  The purpose 
of the builtin is to provide the user fine control, at the expression level, 
over floating point optimization when -ffast-math (-ffp-model=fast) is enabled. 
 We are also proposing a new clang builtin that provides access to this 
intrinsic, as well as a new clang command line option `-fprotect-parens` that 
will be implemented using this intrinsic.

This is the clang patch corresponding to https://reviews.llvm.org/D99675 which 
proposes a new llvm intrinsic llvm.arith.fence

Note: Preliminary patch, not ready for code review, doesn't yet run end-to-end 
with the llvm patch, and the logic for the new option is not yet written.

Rationale
-

Some expression transformations that are mathematically correct, such as 
reassociation and distribution, may be incorrect when dealing with finite 
precision floating point.  For example, these two expressions,

  (a + b) + c
  a + (b + c)

are equivalent mathematically in integer arithmetic, but not in floating point. 
 In some floating point (FP) models, the compiler is allowed to make these 
value-unsafe transformations for performance reasons, even when the programmer 
uses parentheses explicitly.  But the compiler must always honor the 
parentheses implied by __arithmetic_fence, regardless of the FP model settings.

Under `–ffp-model=fast`, __arithmetic_fence provides a way to partially enforce 
ordering in an FP expression.

| Original expression   | Transformed expression | Permitted? |
| - | -- | -- |
| (a + b) + c   | a + (b + c)| Yes!   |
| __arithmetic_fence(a + b) + c | a + (b + c)| No!|
|



NOTE: The __arithmetic_fence serves no purpose in value-safe FP modes like 
`–ffp-model=precise`:  FP expressions are already strictly ordered.



Motivation:
---

- The new clang builtin provides clang compatibility with the Intel C++ 
compiler builtin `__fence` which has similar semantics, and likewise enables 
implementation of the option `-fprotect-parens`.
- The new builtin provides the clang programmer control over floating point 
optimizations at the expression level.
- The gnu fortran compiler, gfortran, likewise supports `-fprotect-parens`

Requirements for __arithmetic_fence:


- There is one operand. The operand type must be scalar floating point, complex 
floating point or vector thereof.
- The return type is the same as the operand type.
- The return value is equivalent to the operand.
- The invocation of __arithmetic_fence is not a C/C++ constant expression, even 
if the operands are constant.

New option `-fprotect-parens`
-

- Determines whether the optimizer honors parentheses when floating-point 
expressions are evaluated
- Option defaults to `fno-protect-parens`


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100118

Files:
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ExprConstant.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/arithmetic-fence-builtin.c
  clang/test/Sema/arithmetic-fence-builtin.c
  llvm/include/llvm/IR/IRBuilder.h

Index: llvm/include/llvm/IR/IRBuilder.h
===
--- llvm/include/llvm/IR/IRBuilder.h
+++ llvm/include/llvm/IR/IRBuilder.h
@@ -897,6 +897,13 @@
 return CreateBinaryIntrinsic(Intrinsic::maximum, LHS, RHS, nullptr, Name);
   }
 
+  /// Create a call to the arithmetic_fence intrinsic.
+  CallInst *CreateArithmeticFence(Value *Val, Type *DstType,
+  const Twine &Name = "") {
+return CreateIntrinsic(Intrinsic::arithmetic_fence, {DstType}, {Val}, nullptr,
+   Name);
+  }
+
   /// Create a call to the experimental.vector.extract intrinsic.
   CallInst *CreateExtractVector(Type *DstType, Value *SrcVec, Value *Idx,
 const Twine &Name = "") {
Index: clang/test/Sema/arithmetic-fence-builtin.c
===
--- /dev/null
+++ clang/test/Sema/arithmetic-fence-builtin.c
@@ -0,0 +1,33 @@
+// RUN: %clang_cc1 -triple i386-pc-linux-gnu -emit-llvm -o - -verify -x c++ %s
+int v;
+template  T addT(T a, T b) {
+  T *q = __arithmetic_fence(&a);
+  // expected-error@-1 {{operand of type 'float *' where floating, complex or a vector of such types is required ('float *' invalid)}}
+  // expected-error@-2 {{operand of type 'int *' where floating, complex or a vector of such types is required ('int *' i

[PATCH] D99984: [RISCV] Prevent __builtin_riscv_orc_b_64 from being compiled RV32 target.

2021-04-08 Thread Fraser Cormack via Phabricator via cfe-commits

frasercrmck accepted this revision.
frasercrmck added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/lib/Basic/Targets/RISCV.cpp:259
   .Case("riscv64", Is64Bit)
+  .Case("64bit", Is64Bit)
   .Case("m", HasM)

craig.topper wrote:
> frasercrmck wrote:
> > What's the difference between this new feature and `riscv64` above?
> The name I added to initFeatureMap has to match the feature name in RISCV.td 
> because it will end up in the target-features attribute in IR.
> 
> SemaChecking just calls hasFeature, but CodeGenFunction also checks builtin 
> features using the feature map. We check features in SemaChecking because the 
> CodeGenFunction diagnostic isn’t phrased well for RISCV.
Ah I see, so since it has to match our `"64bit"` `SubtargetFeature` we can't 
reuse `"riscv64"`? Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99984

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

[PATCH] D99995: [OpenMP51] Initial support for masked directive and filter clause

2021-04-08 Thread Chi Chun Chen via Phabricator via cfe-commits

cchen added inline comments.



Comment at: clang/lib/Parse/ParseOpenMP.cpp:2814
 }
 
 if (CKind == OMPC_ordered && PP.LookAhead(/*N=*/0).isNot(tok::l_paren))

ABataev wrote:
> This can be simplified like this:
> ```
> if (!FirstClause) {
>   Diag(Tok, diag::err_omp_more_one_clause)
>   << getOpenMPDirectiveName(DKind) << getOpenMPClauseName(CKind) << 0;
>   ErrorFound = true;
> }
> LLVM_FALLTHROUGH;
> case OMPC_filter:
> ```
> Plus, I think, you should not exclude OMPC_filter from the check, I think 
> only single clause is allowed by the spec.
I misunderstood the syntax and will fix this and the tests, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D5

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

[PATCH] D99517: Implemented [[clang::musttail]] attribute for guaranteed tail calls.

2021-04-08 Thread Josh Haberman via Phabricator via cfe-commits

haberman updated this revision to Diff 336141.
haberman added a comment.

- Factored duplicated code into a method on MustTailAttr.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99517

Files:
  clang/include/clang/AST/Expr.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/ScopeInfo.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/AttrImpl.cpp
  clang/lib/AST/Expr.cpp
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGClass.cpp
  clang/lib/CodeGen/CGDecl.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGExprCXX.cpp
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/CodeGen/EHScopeStack.h
  clang/lib/Sema/JumpDiagnostics.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaStmtAttr.cpp
  clang/test/CodeGen/attr-musttail.cpp
  clang/test/Sema/attr-musttail.c
  clang/test/Sema/attr-musttail.cpp
  clang/test/Sema/attr-musttail.m

Index: clang/test/Sema/attr-musttail.m
===
--- /dev/null
+++ clang/test/Sema/attr-musttail.m
@@ -0,0 +1,28 @@
+// RUN: %clang_cc1 -fsyntax-only -fblocks -Wno-objc-root-class -verify %s
+
+void TestObjcBlock(void) {
+  void (^x)(void) = ^(void) {
+__attribute__((musttail)) return TestObjcBlock(); // expected-error{{'musttail' attribute cannot be used from a block}}
+  };
+  __attribute__((musttail)) return x();
+}
+
+void ReturnsVoid(void);
+void TestObjcBlockVar(void) {
+  __block int i = 0;  // expected-note{{jump exits scope of __block variable}}
+  __attribute__((musttail)) return ReturnsVoid();  // expected-error{{cannot perform a tail call from this return statement}}
+}
+
+//#import 
+
+__attribute__((objc_root_class))
+@interface TestObjcClass
+@end
+
+@implementation TestObjcClass
+
+- (void)testObjCMethod {
+  __attribute__((musttail)) return ReturnsVoid(); // expected-error{{'musttail' attribute cannot be used from an Objective-C function}}
+}
+
+@end
Index: clang/test/Sema/attr-musttail.cpp
===
--- /dev/null
+++ clang/test/Sema/attr-musttail.cpp
@@ -0,0 +1,191 @@
+// RUN: %clang_cc1 -verify -fsyntax-only -fms-extensions -fcxx-exceptions -fopenmp %s
+
+int ReturnsInt1();
+int Func1() {
+  [[clang::musttail]] ReturnsInt1();   // expected-error {{'musttail' attribute only applies to return statements}}
+  [[clang::musttail(1, 2)]] return ReturnsInt1(); // expected-error {{'musttail' attribute takes no arguments}}
+  [[clang::musttail]] return 5;// expected-error {{'musttail' attribute requires that the return value is the result of a function call}}
+  [[clang::musttail]] return ReturnsInt1();
+}
+
+void NoFunctionCall() {
+  [[clang::musttail]] return;  // expected-error {{'musttail' attribute requires that the return value is the result of a function call}}
+}
+
+[[clang::musttail]] static int int_val = ReturnsInt1(); // expected-error {{'musttail' attribute cannot be applied to a declaration}}
+
+void NoParams(); // expected-note {{target function has different number of parameters (expected 1 but has 0)}}
+void TestParamArityMismatch(int x) {
+  [[clang::musttail]] return NoParams(); // expected-error {{'musttail' attribute requires that caller and callee have compatible function signatures}}
+}
+
+void LongParam(long x); // expected-note {{target function has type mismatch at 1st parameter (expected 'long' but has 'int')}}
+void TestParamTypeMismatch(int x) {
+  [[clang::musttail]] return LongParam(x); // expected-error {{'musttail' attribute requires that caller and callee have compatible function signatures}}
+}
+
+long ReturnsLong(); // expected-note {{target function has different return type ('int' expected but has 'long')}}
+int TestReturnTypeMismatch() {
+  [[clang::musttail]] return ReturnsLong(); // expected-error {{'musttail' attribute requires that caller and callee have compatible function signatures}}
+}
+
+struct Struct1 {
+  void MemberFunction(); // expected-note {{target function is a member of different class (expected 'void' but has 'Struct1')}}
+};
+void TestNonMemberToMember() {
+  Struct1 st;
+  [[clang::musttail]] return st.MemberFunction(); // expected-error {{'musttail' attribute requires that caller and callee have compatible function signatures}}
+}
+
+void ReturnsVoid(); // expected-note {{target function is a member of different class (expected 'Struct2' but has 'void')}}
+struct Struct2 {
+  void TestMemberToNonMember() {
+[[clang::musttail]] return ReturnsVoid(); // expected-error{{'musttail' attribute requires that caller and callee have compatible function signatures}}
+  }
+};
+
+class HasNonTrivialDestructor {
+public:
+  ~HasNonTrivialDestructor() {}
+  int ReturnsInt();
+};
+
+void ReturnsVoid2();
+void TestNonTrivialDestructorInScope()

[PATCH] D99984: [RISCV] Prevent __builtin_riscv_orc_b_64 from being compiled RV32 target.

2021-04-08 Thread Craig Topper via Phabricator via cfe-commits

craig.topper added inline comments.



Comment at: clang/lib/Basic/Targets/RISCV.cpp:259
   .Case("riscv64", Is64Bit)
+  .Case("64bit", Is64Bit)
   .Case("m", HasM)

frasercrmck wrote:
> craig.topper wrote:
> > frasercrmck wrote:
> > > What's the difference between this new feature and `riscv64` above?
> > The name I added to initFeatureMap has to match the feature name in 
> > RISCV.td because it will end up in the target-features attribute in IR.
> > 
> > SemaChecking just calls hasFeature, but CodeGenFunction also checks builtin 
> > features using the feature map. We check features in SemaChecking because 
> > the CodeGenFunction diagnostic isn’t phrased well for RISCV.
> Ah I see, so since it has to match our `"64bit"` `SubtargetFeature` we can't 
> reuse `"riscv64"`? Thanks.
Correct.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99984

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

[PATCH] D99517: Implemented [[clang::musttail]] attribute for guaranteed tail calls.

2021-04-08 Thread Josh Haberman via Phabricator via cfe-commits

haberman added inline comments.



Comment at: clang/lib/Sema/SemaStmt.cpp:561-568
+  for (const auto *A : Attrs) {
+if (A->getKind() == attr::MustTail) {
+  if (!checkMustTailAttr(SubStmt, *A)) {
+return SubStmt;
+  }
+  setFunctionHasMustTail();
+}

aaron.ballman wrote:
> haberman wrote:
> > aaron.ballman wrote:
> > > haberman wrote:
> > > > aaron.ballman wrote:
> > > > > rsmith wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > aaron.ballman wrote:
> > > > > > > > haberman wrote:
> > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > haberman wrote:
> > > > > > > > > > > haberman wrote:
> > > > > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > > > > haberman wrote:
> > > > > > > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > > > > > > This functionality belongs in SemaStmtAttr.cpp, I 
> > > > > > > > > > > > > > > think.
> > > > > > > > > > > > > > That is where I had originally put it, but that 
> > > > > > > > > > > > > > didn't work for templates. The semantic checks can 
> > > > > > > > > > > > > > only be performed at instantiation time. 
> > > > > > > > > > > > > > `ActOnAttributedStmt` seems to be the right hook 
> > > > > > > > > > > > > > point where I can evaluate the semantic checks for 
> > > > > > > > > > > > > > both template and non-template functions (with 
> > > > > > > > > > > > > > template functions getting checked at instantiation 
> > > > > > > > > > > > > > time).
> > > > > > > > > > > > > I disagree that `ActOnAttributedStmt()` is the 
> > > > > > > > > > > > > correct place for this checking -- template checking 
> > > > > > > > > > > > > should occur when the template is instantiated, same 
> > > > > > > > > > > > > as happens for declaration attributes. I'd like to 
> > > > > > > > > > > > > see this functionality moved to SemaStmtAttr.cpp. 
> > > > > > > > > > > > > Keeping the attribute logic together and following 
> > > > > > > > > > > > > the same patterns is what allows us to tablegenerate 
> > > > > > > > > > > > > more of the attribute logic. Statement attributes are 
> > > > > > > > > > > > > just starting to get more such automation.
> > > > > > > > > > > > I tried commenting out this code and adding the 
> > > > > > > > > > > > following code into `handleMustTailAttr()` in 
> > > > > > > > > > > > `SemaStmtAttr.cpp`:
> > > > > > > > > > > > 
> > > > > > > > > > > > ```
> > > > > > > > > > > >   if (!S.checkMustTailAttr(St, MTA))
> > > > > > > > > > > > return nullptr;
> > > > > > > > > > > > ```
> > > > > > > > > > > > 
> > > > > > > > > > > > This caused my test cases related to templates to fail. 
> > > > > > > > > > > > It also seemed to break test cases related to 
> > > > > > > > > > > > `JumpDiagnostics`. My interpretation of this is that 
> > > > > > > > > > > > `handleMustTailAttr()` is called during parsing only, 
> > > > > > > > > > > > and cannot catch errors at template instantiation time 
> > > > > > > > > > > > or that require a more complete AST.
> > > > > > > > > > > > 
> > > > > > > > > > > > What am I missing? Where in SemaStmtAttr.cpp are you 
> > > > > > > > > > > > suggesting that I put this check?
> > > > > > > > > > > Scratch the part about `JumpDiagnostics`, that was me 
> > > > > > > > > > > failing to call `S.setFunctionHasMustTail()`. I added 
> > > > > > > > > > > that and now the `JumpDiagnostics` tests pass.
> > > > > > > > > > > 
> > > > > > > > > > > But the template test cases still fail, and I can't find 
> > > > > > > > > > > any hook point in `SemaStmtAttr.cpp` that will let me 
> > > > > > > > > > > evaluate these checks at template instantiation time.
> > > > > > > > > > I think there's a bit of an architectural mixup, but I'm 
> > > > > > > > > > curious if @rsmith agrees before anyone starts doing work 
> > > > > > > > > > to make changes.
> > > > > > > > > > 
> > > > > > > > > > When transforming declarations, `RebuildWhatever()` calls 
> > > > > > > > > > the `ActOnWhatever()` function which calls 
> > > > > > > > > > `ProcessDeclAttributeList()` so that attributes are 
> > > > > > > > > > processed. `RebuildAttributedStmt()` similarly calls 
> > > > > > > > > > `ActOnAttributedStmt()`. However, `ActOnAttributedStmt()` 
> > > > > > > > > > doesn't call `ProcessStmtAttributes()` -- the logic is 
> > > > > > > > > > reversed so that `ProcessStmtAttributes()` is what calls 
> > > > > > > > > > `ActOnAttributedStmt()`.
> > > > > > > > > > 
> > > > > > > > > > I think the correct answer is to switch the logic so that 
> > > > > > > > > > `ActOnAttributedStmt()` calls `ProcessStmtAttributes()`, 
> > > > > > > > > > then the template logic should automatically work.
> > > > > > > > > > I think the correct answer is to switch the logic so that 
> > > > > > > > > > ActOnAttributedStmt() calls ProcessStmtAttributes()
> > > > > > > > > 
> > > > > > > > > I think this would require `ProcessStmtAttributes()` to be 
> > > > > > > > > split into two separ

[PATCH] D99181: [analyzer] Fix crash on spaceship operator (PR47511)

2021-04-08 Thread Artem Dergachev via Phabricator via cfe-commits

NoQ accepted this revision.
NoQ added a comment.

Looks great now!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99181

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

[PATCH] D99593: [Clang][RISCV] Implement vlseg builtins.

2021-04-08 Thread Zakk Chen via Phabricator via cfe-commits

khchen added inline comments.



Comment at: clang/utils/TableGen/RISCVVEmitter.cpp:594
   auto PType = Transformer.back();
+  static unsigned NFCount = 0;
   switch (PType) {

rogfer01 wrote:
> Was this meant to be `static` here?
Maybe we can create a new complex type transformer `(Tuple:Value)`,  so 
`(Tuple:3)` means `TTTv`. It can avoid to use `static` here. You could ref 
https://github.com/llvm/llvm-project/blob/main/clang/utils/TableGen/RISCVVEmitter.cpp#L638


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99593

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

[PATCH] D100124: [Clang][NVPTX] Add NVPTX intrinsics and builtins for CUDA PTX redux.sync instructions

2021-04-08 Thread Steffen Larsen via Phabricator via cfe-commits

steffenlarsen created this revision.
steffenlarsen added reviewers: jdoerfert, jholewinski.
Herald added subscribers: hiraditya, yaxunl.
steffenlarsen requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

Adds NVPTX builtins and intrinsics for the CUDA PTX `redux.sync` instructions 
for `sm_80` architecture or newer.

PTX ISA description of `redux.sync`: 
https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#parallel-synchronization-and-communication-instructions-redux-sync

Authored-by: Steffen Larsen 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100124

Files:
  clang/include/clang/Basic/BuiltinsNVPTX.def
  clang/test/CodeGenCUDA/redux-builtins.cu
  llvm/include/llvm/IR/IntrinsicsNVVM.td
  llvm/lib/Target/NVPTX/NVPTXInstrInfo.td
  llvm/lib/Target/NVPTX/NVPTXIntrinsics.td
  llvm/test/CodeGen/NVPTX/redux-sync.ll

Index: llvm/test/CodeGen/NVPTX/redux-sync.ll
===
--- /dev/null
+++ llvm/test/CodeGen/NVPTX/redux-sync.ll
@@ -0,0 +1,73 @@
+; RUN: llc < %s -march=nvptx64 -mcpu=sm_80 -mattr=+ptx70 | FileCheck %s
+
+declare i32 @llvm.nvvm.redux.sync.add.u32(i32, i32)
+; CHECK-LABEL: .func{{.*}}redux_sync_add_u32
+define i32 @redux_sync_add_u32(i32 %src, i32 %mask) {
+  ; CHECK: redux.sync.add.u32
+  %val = call i32 @llvm.nvvm.redux.sync.add.u32(i32 %src, i32 %mask)
+  ret i32 %val
+}
+
+declare i32 @llvm.nvvm.redux.sync.min.u32(i32, i32)
+; CHECK-LABEL: .func{{.*}}redux_sync_min_u32
+define i32 @redux_sync_min_u32(i32 %src, i32 %mask) {
+  ; CHECK: redux.sync.min.u32
+  %val = call i32 @llvm.nvvm.redux.sync.min.u32(i32 %src, i32 %mask)
+  ret i32 %val
+}
+
+declare i32 @llvm.nvvm.redux.sync.max.u32(i32, i32)
+; CHECK-LABEL: .func{{.*}}redux_sync_max_u32
+define i32 @redux_sync_max_u32(i32 %src, i32 %mask) {
+  ; CHECK: redux.sync.max.u32
+  %val = call i32 @llvm.nvvm.redux.sync.max.u32(i32 %src, i32 %mask)
+  ret i32 %val
+}
+
+declare i32 @llvm.nvvm.redux.sync.add.s32(i32, i32)
+; CHECK-LABEL: .func{{.*}}redux_sync_add_s32
+define i32 @redux_sync_add_s32(i32 %src, i32 %mask) {
+  ; CHECK: redux.sync.add.s32
+  %val = call i32 @llvm.nvvm.redux.sync.add.s32(i32 %src, i32 %mask)
+  ret i32 %val
+}
+
+declare i32 @llvm.nvvm.redux.sync.min.s32(i32, i32)
+; CHECK-LABEL: .func{{.*}}redux_sync_min_s32
+define i32 @redux_sync_min_s32(i32 %src, i32 %mask) {
+  ; CHECK: redux.sync.min.s32
+  %val = call i32 @llvm.nvvm.redux.sync.min.s32(i32 %src, i32 %mask)
+  ret i32 %val
+}
+
+declare i32 @llvm.nvvm.redux.sync.max.s32(i32, i32)
+; CHECK-LABEL: .func{{.*}}redux_sync_max_s32
+define i32 @redux_sync_max_s32(i32 %src, i32 %mask) {
+  ; CHECK: redux.sync.max.s32
+  %val = call i32 @llvm.nvvm.redux.sync.max.s32(i32 %src, i32 %mask)
+  ret i32 %val
+}
+
+declare i32 @llvm.nvvm.redux.sync.and.b32(i32, i32)
+; CHECK-LABEL: .func{{.*}}redux_sync_and_b32
+define i32 @redux_sync_and_b32(i32 %src, i32 %mask) {
+  ; CHECK: redux.sync.and.b32
+  %val = call i32 @llvm.nvvm.redux.sync.and.b32(i32 %src, i32 %mask)
+  ret i32 %val
+}
+
+declare i32 @llvm.nvvm.redux.sync.xor.b32(i32, i32)
+; CHECK-LABEL: .func{{.*}}redux_sync_xor_b32
+define i32 @redux_sync_xor_b32(i32 %src, i32 %mask) {
+  ; CHECK: redux.sync.xor.b32
+  %val = call i32 @llvm.nvvm.redux.sync.xor.b32(i32 %src, i32 %mask)
+  ret i32 %val
+}
+
+declare i32 @llvm.nvvm.redux.sync.or.b32(i32, i32)
+; CHECK-LABEL: .func{{.*}}redux_sync_or_b32
+define i32 @redux_sync_or_b32(i32 %src, i32 %mask) {
+  ; CHECK: redux.sync.or.b32
+  %val = call i32 @llvm.nvvm.redux.sync.or.b32(i32 %src, i32 %mask)
+  ret i32 %val
+}
Index: llvm/lib/Target/NVPTX/NVPTXIntrinsics.td
===
--- llvm/lib/Target/NVPTX/NVPTXIntrinsics.td
+++ llvm/lib/Target/NVPTX/NVPTXIntrinsics.td
@@ -274,6 +274,23 @@
 defm MATCH_ALLP_SYNC_64 : MATCH_ALLP_SYNC;
 
+multiclass REDUX_SYNC {
+  def : NVPTXInst<(outs Int32Regs:$dst), (ins Int32Regs:$src, Int32Regs:$mask),
+  "redux.sync." # BinOp # "." # PTXType # " $dst, $src, $mask;",
+  [(set Int32Regs:$dst, (Intrin Int32Regs:$src, Int32Regs:$mask))]>,
+Requires<[hasPTX70, hasSM80]>;
+}
+
+defm REDUX_SYNC_ADD_U32 : REDUX_SYNC<"add", "u32", int_nvvm_redux_sync_add_u32>;
+defm REDUX_SYNC_MIN_U32 : REDUX_SYNC<"min", "u32", int_nvvm_redux_sync_min_u32>;
+defm REDUX_SYNC_MAX_U32 : REDUX_SYNC<"max", "u32", int_nvvm_redux_sync_max_u32>;
+defm REDUX_SYNC_ADD_S32 : REDUX_SYNC<"add", "s32", int_nvvm_redux_sync_add_s32>;
+defm REDUX_SYNC_MIN_S32 : REDUX_SYNC<"min", "s32", int_nvvm_redux_sync_min_s32>;
+defm REDUX_SYNC_MAX_S32 : REDUX_SYNC<"max", "s32", int_nvvm_redux_sync_max_s32>;
+defm REDUX_SYNC_AND_B32 : REDUX_SYNC<"and", "b32", int_nvvm_redux_sync_and_b32>;
+defm REDUX_SYNC_XOR_B32 : REDUX_SYNC<"xor", "b32", int_nvvm_redux_sync_xor_b32>;
+defm REDUX_SYNC_OR_B32 : REDUX_SYNC<"or", "b32", int_nvvm_redux_sync_or_b32>;
+
 } // isConvergent

[PATCH] D97462: [clang][cli] Round-trip cc1 arguments in assert builds

2021-04-08 Thread Alexander Richardson via Phabricator via cfe-commits

arichardson added a comment.

I just merged this commit into our CHERI fork and noticed some failing tests 
due to round tripping:
We add some additional CodeGenOptions and LangOptions, but are not including 
those in the generated command line.

For example, I added an additional `std::string CHERIStatsFile;` to 
`CodeGenOptions`. This is set inside `bool 
CompilerInvocation::ParseCodeGenArgs` using `Opts.CHERIStatsFile = 
Args.getLastArgValue(OPT_cheri_stats_file).str();`.
I haven't added logic to round trip this flag (yet). If CC1 argument round 
tripping is enabled, the flag is stripped and the output goes to stderr instead 
of the defined file, causing some tests to fail.

Unfortunately this is not caught by any assertions, so I worry that there are 
other arguments that might be silently removed after this commit. Are there any 
open reviews/plans to check CodeGenOptions/etc, for equality after 
round-tripping?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97462

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

[PATCH] D98798: Produce warning for performing pointer arithmetic on a null pointer.

2021-04-08 Thread Jamie Schmeiser via Phabricator via cfe-commits

jamieschmeiser updated this revision to Diff 336148.
jamieschmeiser added a comment.

Reformat to satisfy clang-format


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

https://reviews.llvm.org/D98798

Files:
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Sema/pointer-addition.c


Index: clang/test/Sema/pointer-addition.c
===
--- clang/test/Sema/pointer-addition.c
+++ clang/test/Sema/pointer-addition.c
@@ -29,4 +29,6 @@
   // Cases that don't match the GNU inttoptr idiom get a different warning.
   f = (char*)0 - i; // expected-warning {{performing pointer arithmetic on a 
null pointer has undefined behavior}}
   int *g = (int*)0 + i; // expected-warning {{performing pointer arithmetic on 
a null pointer has undefined behavior}}
+  f = (char*)((char*)0 - f); // expected-warning {{performing pointer 
arithmetic on a null pointer has undefined behavior}}
+  f = (char*)(f - (char*)0); // expected-warning {{performing pointer 
arithmetic on a null pointer has undefined behavior}}
 }
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -10720,7 +10720,15 @@
LHS.get(), RHS.get()))
 return QualType();
 
-  // FIXME: Add warnings for nullptr - ptr.
+  // Subtracting from a null pointer should produce a warning.
+  if (LHS.get()->IgnoreParenCasts()->isNullPointerConstant(
+  Context, Expr::NPC_ValueDependentIsNotNull))
+diagnoseArithmeticOnNullPointer(*this, Loc, LHS.get(), false);
+
+  // Subtracting a null pointer should produce a warning.
+  if (RHS.get()->IgnoreParenCasts()->isNullPointerConstant(
+  Context, Expr::NPC_ValueDependentIsNotNull))
+diagnoseArithmeticOnNullPointer(*this, Loc, RHS.get(), false);
 
   // The pointee type may have zero size.  As an extension, a structure or
   // union may have zero size or an array may have zero length.  In this


Index: clang/test/Sema/pointer-addition.c
===
--- clang/test/Sema/pointer-addition.c
+++ clang/test/Sema/pointer-addition.c
@@ -29,4 +29,6 @@
   // Cases that don't match the GNU inttoptr idiom get a different warning.
   f = (char*)0 - i; // expected-warning {{performing pointer arithmetic on a null pointer has undefined behavior}}
   int *g = (int*)0 + i; // expected-warning {{performing pointer arithmetic on a null pointer has undefined behavior}}
+  f = (char*)((char*)0 - f); // expected-warning {{performing pointer arithmetic on a null pointer has undefined behavior}}
+  f = (char*)(f - (char*)0); // expected-warning {{performing pointer arithmetic on a null pointer has undefined behavior}}
 }
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -10720,7 +10720,15 @@
LHS.get(), RHS.get()))
 return QualType();
 
-  // FIXME: Add warnings for nullptr - ptr.
+  // Subtracting from a null pointer should produce a warning.
+  if (LHS.get()->IgnoreParenCasts()->isNullPointerConstant(
+  Context, Expr::NPC_ValueDependentIsNotNull))
+diagnoseArithmeticOnNullPointer(*this, Loc, LHS.get(), false);
+
+  // Subtracting a null pointer should produce a warning.
+  if (RHS.get()->IgnoreParenCasts()->isNullPointerConstant(
+  Context, Expr::NPC_ValueDependentIsNotNull))
+diagnoseArithmeticOnNullPointer(*this, Loc, RHS.get(), false);
 
   // The pointee type may have zero size.  As an extension, a structure or
   // union may have zero size or an array may have zero length.  In this
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D99517: Implemented [[clang::musttail]] attribute for guaranteed tail calls.

2021-04-08 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaStmt.cpp:561-568
+  for (const auto *A : Attrs) {
+if (A->getKind() == attr::MustTail) {
+  if (!checkMustTailAttr(SubStmt, *A)) {
+return SubStmt;
+  }
+  setFunctionHasMustTail();
+}

haberman wrote:
> aaron.ballman wrote:
> > haberman wrote:
> > > aaron.ballman wrote:
> > > > haberman wrote:
> > > > > aaron.ballman wrote:
> > > > > > rsmith wrote:
> > > > > > > aaron.ballman wrote:
> > > > > > > > aaron.ballman wrote:
> > > > > > > > > haberman wrote:
> > > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > > haberman wrote:
> > > > > > > > > > > > haberman wrote:
> > > > > > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > > > > > haberman wrote:
> > > > > > > > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > > > > > > > This functionality belongs in SemaStmtAttr.cpp, 
> > > > > > > > > > > > > > > > I think.
> > > > > > > > > > > > > > > That is where I had originally put it, but that 
> > > > > > > > > > > > > > > didn't work for templates. The semantic checks 
> > > > > > > > > > > > > > > can only be performed at instantiation time. 
> > > > > > > > > > > > > > > `ActOnAttributedStmt` seems to be the right hook 
> > > > > > > > > > > > > > > point where I can evaluate the semantic checks 
> > > > > > > > > > > > > > > for both template and non-template functions 
> > > > > > > > > > > > > > > (with template functions getting checked at 
> > > > > > > > > > > > > > > instantiation time).
> > > > > > > > > > > > > > I disagree that `ActOnAttributedStmt()` is the 
> > > > > > > > > > > > > > correct place for this checking -- template 
> > > > > > > > > > > > > > checking should occur when the template is 
> > > > > > > > > > > > > > instantiated, same as happens for declaration 
> > > > > > > > > > > > > > attributes. I'd like to see this functionality 
> > > > > > > > > > > > > > moved to SemaStmtAttr.cpp. Keeping the attribute 
> > > > > > > > > > > > > > logic together and following the same patterns is 
> > > > > > > > > > > > > > what allows us to tablegenerate more of the 
> > > > > > > > > > > > > > attribute logic. Statement attributes are just 
> > > > > > > > > > > > > > starting to get more such automation.
> > > > > > > > > > > > > I tried commenting out this code and adding the 
> > > > > > > > > > > > > following code into `handleMustTailAttr()` in 
> > > > > > > > > > > > > `SemaStmtAttr.cpp`:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > ```
> > > > > > > > > > > > >   if (!S.checkMustTailAttr(St, MTA))
> > > > > > > > > > > > > return nullptr;
> > > > > > > > > > > > > ```
> > > > > > > > > > > > > 
> > > > > > > > > > > > > This caused my test cases related to templates to 
> > > > > > > > > > > > > fail. It also seemed to break test cases related to 
> > > > > > > > > > > > > `JumpDiagnostics`. My interpretation of this is that 
> > > > > > > > > > > > > `handleMustTailAttr()` is called during parsing only, 
> > > > > > > > > > > > > and cannot catch errors at template instantiation 
> > > > > > > > > > > > > time or that require a more complete AST.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > What am I missing? Where in SemaStmtAttr.cpp are you 
> > > > > > > > > > > > > suggesting that I put this check?
> > > > > > > > > > > > Scratch the part about `JumpDiagnostics`, that was me 
> > > > > > > > > > > > failing to call `S.setFunctionHasMustTail()`. I added 
> > > > > > > > > > > > that and now the `JumpDiagnostics` tests pass.
> > > > > > > > > > > > 
> > > > > > > > > > > > But the template test cases still fail, and I can't 
> > > > > > > > > > > > find any hook point in `SemaStmtAttr.cpp` that will let 
> > > > > > > > > > > > me evaluate these checks at template instantiation time.
> > > > > > > > > > > I think there's a bit of an architectural mixup, but I'm 
> > > > > > > > > > > curious if @rsmith agrees before anyone starts doing work 
> > > > > > > > > > > to make changes.
> > > > > > > > > > > 
> > > > > > > > > > > When transforming declarations, `RebuildWhatever()` calls 
> > > > > > > > > > > the `ActOnWhatever()` function which calls 
> > > > > > > > > > > `ProcessDeclAttributeList()` so that attributes are 
> > > > > > > > > > > processed. `RebuildAttributedStmt()` similarly calls 
> > > > > > > > > > > `ActOnAttributedStmt()`. However, `ActOnAttributedStmt()` 
> > > > > > > > > > > doesn't call `ProcessStmtAttributes()` -- the logic is 
> > > > > > > > > > > reversed so that `ProcessStmtAttributes()` is what calls 
> > > > > > > > > > > `ActOnAttributedStmt()`.
> > > > > > > > > > > 
> > > > > > > > > > > I think the correct answer is to switch the logic so that 
> > > > > > > > > > > `ActOnAttributedStmt()` calls `ProcessStmtAttributes()`, 
> > > > > > > > > > > then the template logic should automatically work.
> > > > > > > > > > > I think the correct answer is to switch the logic so that 
> > >

[PATCH] D99260: [analyzer] Fix false positives in inner pointer checker (PR49628)

2021-04-08 Thread Artem Dergachev via Phabricator via cfe-commits

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

Looks great now, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99260

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

[PATCH] D99517: Implemented [[clang::musttail]] attribute for guaranteed tail calls.

2021-04-08 Thread Josh Haberman via Phabricator via cfe-commits

haberman updated this revision to Diff 336153.
haberman added a comment.

- Moved calling convention check to happen as early as possible.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99517

Files:
  clang/include/clang/AST/Expr.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/ScopeInfo.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/AttrImpl.cpp
  clang/lib/AST/Expr.cpp
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGClass.cpp
  clang/lib/CodeGen/CGDecl.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGExprCXX.cpp
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/CodeGen/EHScopeStack.h
  clang/lib/Sema/JumpDiagnostics.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaStmtAttr.cpp
  clang/test/CodeGen/attr-musttail.cpp
  clang/test/Sema/attr-musttail.c
  clang/test/Sema/attr-musttail.cpp
  clang/test/Sema/attr-musttail.m

Index: clang/test/Sema/attr-musttail.m
===
--- /dev/null
+++ clang/test/Sema/attr-musttail.m
@@ -0,0 +1,28 @@
+// RUN: %clang_cc1 -fsyntax-only -fblocks -Wno-objc-root-class -verify %s
+
+void TestObjcBlock(void) {
+  void (^x)(void) = ^(void) {
+__attribute__((musttail)) return TestObjcBlock(); // expected-error{{'musttail' attribute cannot be used from a block}}
+  };
+  __attribute__((musttail)) return x();
+}
+
+void ReturnsVoid(void);
+void TestObjcBlockVar(void) {
+  __block int i = 0;  // expected-note{{jump exits scope of __block variable}}
+  __attribute__((musttail)) return ReturnsVoid();  // expected-error{{cannot perform a tail call from this return statement}}
+}
+
+//#import 
+
+__attribute__((objc_root_class))
+@interface TestObjcClass
+@end
+
+@implementation TestObjcClass
+
+- (void)testObjCMethod {
+  __attribute__((musttail)) return ReturnsVoid(); // expected-error{{'musttail' attribute cannot be used from an Objective-C function}}
+}
+
+@end
Index: clang/test/Sema/attr-musttail.cpp
===
--- /dev/null
+++ clang/test/Sema/attr-musttail.cpp
@@ -0,0 +1,191 @@
+// RUN: %clang_cc1 -verify -fsyntax-only -fms-extensions -fcxx-exceptions -fopenmp %s
+
+int ReturnsInt1();
+int Func1() {
+  [[clang::musttail]] ReturnsInt1();   // expected-error {{'musttail' attribute only applies to return statements}}
+  [[clang::musttail(1, 2)]] return ReturnsInt1(); // expected-error {{'musttail' attribute takes no arguments}}
+  [[clang::musttail]] return 5;// expected-error {{'musttail' attribute requires that the return value is the result of a function call}}
+  [[clang::musttail]] return ReturnsInt1();
+}
+
+void NoFunctionCall() {
+  [[clang::musttail]] return;  // expected-error {{'musttail' attribute requires that the return value is the result of a function call}}
+}
+
+[[clang::musttail]] static int int_val = ReturnsInt1(); // expected-error {{'musttail' attribute cannot be applied to a declaration}}
+
+void NoParams(); // expected-note {{target function has different number of parameters (expected 1 but has 0)}}
+void TestParamArityMismatch(int x) {
+  [[clang::musttail]] return NoParams(); // expected-error {{'musttail' attribute requires that caller and callee have compatible function signatures}}
+}
+
+void LongParam(long x); // expected-note {{target function has type mismatch at 1st parameter (expected 'long' but has 'int')}}
+void TestParamTypeMismatch(int x) {
+  [[clang::musttail]] return LongParam(x); // expected-error {{'musttail' attribute requires that caller and callee have compatible function signatures}}
+}
+
+long ReturnsLong(); // expected-note {{target function has different return type ('int' expected but has 'long')}}
+int TestReturnTypeMismatch() {
+  [[clang::musttail]] return ReturnsLong(); // expected-error {{'musttail' attribute requires that caller and callee have compatible function signatures}}
+}
+
+struct Struct1 {
+  void MemberFunction(); // expected-note {{target function is a member of different class (expected 'void' but has 'Struct1')}}
+};
+void TestNonMemberToMember() {
+  Struct1 st;
+  [[clang::musttail]] return st.MemberFunction(); // expected-error {{'musttail' attribute requires that caller and callee have compatible function signatures}}
+}
+
+void ReturnsVoid(); // expected-note {{target function is a member of different class (expected 'Struct2' but has 'void')}}
+struct Struct2 {
+  void TestMemberToNonMember() {
+[[clang::musttail]] return ReturnsVoid(); // expected-error{{'musttail' attribute requires that caller and callee have compatible function signatures}}
+  }
+};
+
+class HasNonTrivialDestructor {
+public:
+  ~HasNonTrivialDestructor() {}
+  int ReturnsInt();
+};
+
+void ReturnsVoid2();
+void TestNonTrivialDestructorInS

[PATCH] D99037: [Matrix] Implement C-style explicit type conversions for matrix types

2021-04-08 Thread Saurabh Jha via Phabricator via cfe-commits

SaurabhJha updated this revision to Diff 336154.
SaurabhJha added a comment.

Addressed latest round of comments.
Also rebased with latest main as the windows build failed for some reason


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99037

Files:
  clang/include/clang/AST/OperationKinds.def
  clang/include/clang/AST/Stmt.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Expr.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGExprAgg.cpp
  clang/lib/CodeGen/CGExprComplex.cpp
  clang/lib/CodeGen/CGExprConstant.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/Edit/RewriteObjCFoundationAPI.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
  clang/test/CodeGen/matrix-cast.c
  clang/test/Sema/matrix-cast.c
  clang/test/SemaCXX/matrix-casts.cpp

Index: clang/test/SemaCXX/matrix-casts.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/matrix-casts.cpp
@@ -0,0 +1,67 @@
+// RUN: %clang_cc1 -std=c++11 -fenable-matrix -fsyntax-only -verify %s
+
+template 
+
+using matrix_4_4 = X __attribute__((matrix_type(4, 4)));
+
+template 
+
+using matrix_5_5 = Y __attribute__((matrix_type(5, 5)));
+
+typedef struct test_struct {
+} test_struct;
+
+typedef int vec __attribute__((vector_size(4)));
+
+void f1() {
+  // TODO: Update this test once the support of C-style casts for C++ is implemented.
+  matrix_4_4 m1;
+  matrix_4_4 m2;
+  matrix_4_4 m3;
+  matrix_5_5 m4;
+  int i;
+  vec v;
+  test_struct *s;
+
+  (matrix_4_4)m1;   // expected-error {{C-style cast from 'matrix_4_4' (aka 'char __attribute__((matrix_type(4, \
+4)))') to 'matrix_4_4' (aka 'int __attribute__((matrix_type(4, 4)))') is not allowed}}
+  (matrix_4_4)m2; // expected-error {{C-style cast from 'matrix_4_4' (aka 'int __attribute__((matrix_type(4, \
+4)))') to 'matrix_4_4' (aka 'short __attribute__((matrix_type(4, 4)))') is not allowed}}
+  (matrix_5_5)m3;   // expected-error {{C-style cast from 'matrix_4_4' (aka 'short __attribute__((matrix_type(4, \
+4)))') to 'matrix_5_5' (aka 'int __attribute__((matrix_type(5, 5)))') is not allowed}}
+
+  (int)m3;// expected-error {{C-style cast from 'matrix_4_4' (aka 'short __attribute__((matrix_type(4, \
+4)))') to 'int'}}
+  (matrix_4_4)i; // expected-error {{C-style cast from 'int' to 'matrix_4_4' (aka 'int __attribute__((\
+matrix_type(4, 4)))') is not allowed}}
+
+  (vec) m2;// expected-error {{C-style cast from 'matrix_4_4' (aka 'int __attribute__((matrix_type(4, 4)))') \
+to 'vec' (vector of 1 'int' value) is not allowed}}
+  (matrix_4_4)v; // expected-error {{C-style cast from 'vec' (vector of 1 'int' value) to 'matrix_4_4' \
+(aka 'char __attribute__((matrix_type(4, 4)))') is not allowed}}
+
+  (test_struct *)m1;// expected-error {{cannot cast from type 'matrix_4_4' (aka 'char __attribute__\
+((matrix_type(4, 4)))') to pointer type 'test_struct *}}'
+  (matrix_5_5)s; // expected-error {{C-style cast from 'test_struct *' to 'matrix_5_5' (aka 'float __attribute__\
+((matrix_type(5, 5)))') is not allowed}}'
+}
+
+void f2() {
+  // TODO: Update this test once the support of C-style casts for C++ is implemented.
+  matrix_4_4 m1;
+  matrix_5_5 m2;
+  matrix_5_5 m3;
+  matrix_4_4 m4;
+  float f;
+
+  (matrix_4_4)m1;   // expected-error {{C-style cast from 'matrix_4_4' (aka 'float __attribute__\
+((matrix_type(4, 4)))') to 'matrix_4_4' (aka 'double __attribute__((matrix_type(4, 4)))') is not allowed}}
+  (matrix_5_5)m2;// expected-error {{C-style cast from 'matrix_5_5' (aka 'double __attribute__\
+((matrix_type(5, 5)))') to 'matrix_5_5' (aka 'float __attribute__((matrix_type(5, 5)))') is not allowed}}
+  (matrix_5_5)m3; // expected-error {{C-style cast from 'matrix_5_5' (aka 'int __attribute__\
+((matrix_type(5, 5)))') to 'matrix_5_5' (aka 'unsigned int __attribute__((matrix_type(5, 5)))') \
+is not allowed}}
+  (matrix_4_4)m4;  // expected-error {{C-style cast from 'matrix_4_4' (aka 'unsigned int \
+__attribute__((matrix_type(4, 4)))') to 'matrix_4_4' (aka 'int __attribute__((matrix_type(4, 4)))') is not \
+allowed}}
+}
Index: clang/test/Sema/matrix-cast.c
===
--- /dev/null
+++ clang/test/Sema/matrix-cast.c
@@ -0,0 +1,75 @@
+// RUN: %clang_cc1 -fenable-matrix -fsyntax-only %s -verify
+
+typedef char cx4x4 __attribute__((matrix_type(4, 4)));
+typedef int ix4x4 __attribute__((matrix_type(4, 4)));
+typedef short sx4x4 __attribute__((matrix_type(4, 4)));
+typedef int ix5x5 __attribute__((matrix_type(5, 5)));
+typedef float fx5x5 __attribute__((matrix_type(5, 5)));
+typedef int vec __attribute__((vector_size(4)));
+typedef struct test_struct {
+} test_struct;
+
+void f1() {
+  cx4x4 m1;
+  ix4x4 m2;
+  sx4x4 m3;
+  ix5x

[PATCH] D99517: Implemented [[clang::musttail]] attribute for guaranteed tail calls.

2021-04-08 Thread Josh Haberman via Phabricator via cfe-commits

haberman added a comment.

In D99517#2667025 , @rjmccall wrote:

> You should structure this code so it's easy to add exceptions for certain 
> calling conventions that can support tail calls with weaker restrictions 
> (principally, callee-pop conventions).  Mostly that probably means checking 
> the calling convention first, or extracting the type restriction checks into 
> a different function that you can skip.  For example, I believe x86's 
> `fastcall` convention can logically support any combination of prototypes as 
> `musttail` as long as the return types are vaguely compatible.

I moved the calling convention check to be as early as possible.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99517

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

[PATCH] D99037: [Matrix] Implement C-style explicit type conversions for matrix types

2021-04-08 Thread Saurabh Jha via Phabricator via cfe-commits

SaurabhJha added inline comments.



Comment at: clang/test/CodeGen/matrix-cast.c:82
+
+void cast_unsigned_short_int_to_unsigned_int(unsigned_short_int_5x5 s, 
unsigned_int_5x5 i) {
+  // CHECK-LABEL: define{{.*}} void 
@cast_unsigned_short_int_to_unsigned_int(<25 x i16> %s, <25 x i32> %i)

fhahn wrote:
> I think this is still missing a test from unsigned to signed?
I added a new `cast_unsigned_long_int_matrix_to_short`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99037

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

[PATCH] D99260: [analyzer] Fix false positives in inner pointer checker (PR49628)

2021-04-08 Thread Balázs Benics via Phabricator via cfe-commits

steakhal added a comment.

I'm still not satisfied with the `addressof`, but I won't block this either.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99260

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

[PATCH] D100120: [RISCV][Clang] Add all RVV Mask intrinsic functions.

2021-04-08 Thread Craig Topper via Phabricator via cfe-commits

craig.topper added a comment.

LGTM other than that inheritance question




Comment at: clang/include/clang/Basic/riscv_vector.td:247
+list> suffixes_prototypes> {
+  defm "" : RVVBuiltinSet;
+}

Can we use inheritance here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100120

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

[PATCH] D100127: [RISCV][Clang] Add some RVV Permutation intrinsic functions.

2021-04-08 Thread Zakk Chen via Phabricator via cfe-commits

khchen created this revision.
khchen added reviewers: craig.topper, rogfer01, HsiangKai, evandro, liaolucy, 
jrtc27.
Herald added subscribers: vkmr, frasercrmck, dexonsmith, luismarques, apazos, 
sameer.abuasal, s.egerton, Jim, benna, psnobl, jocewei, PkmX, the_o, 
brucehoult, MartinMosbeck, edward-jones, zzheng, shiva0217, kito-cheng, niosHD, 
sabuasal, simoncook, johnrusso, rbar, asb.
khchen requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

Support the following instructions.

1. Vector Slide Instructions
2. Vector Register Gather Instructions
3. Vector Compress Instruction

Authored-by: Roger Ferrer Ibanez 
Co-Authored-by: Zakk Chen 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100127

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfslide1down.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfslide1up.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vrgather.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vslide1down.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vslide1up.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vslidedown.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vslideup.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfslide1down.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfslide1up.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vrgather.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vslide1down.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vslide1up.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vslidedown.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vslideup.c

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

[PATCH] D100085: [X86] Support -march=rocketlake

2021-04-08 Thread Craig Topper via Phabricator via cfe-commits

craig.topper added inline comments.



Comment at: llvm/lib/Target/X86/X86.td:767
+  // Rocketlake
+  list RKLAdditionalFeatures = [FeatureAES,
+  FeatureXSAVEC,

FreddyYe wrote:
> craig.topper wrote:
> > Is this list this long because SKL includes SGX but RKL doesn't?
> Yes. And I don't know any simple ways to exclude SGX here, any suggestions?
Nothing pretty. Guess it depends on if SGX is going to not appear in more 
future CPUs or if this is a one off case. If it's going to continue then we 
could remove it from the inheritance and just give it to SKL, ICL, CNL, etc. 
individually.

Or we could just not default SGX on for any CPU. It's probably not all that 
useful in the backend anyway. Clang will put it in the target-feature attribute 
anyway. Having it in the backend feature lists doesn't really do anything since 
I don't think we have any IR intrinsics for SGX.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100085

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

[PATCH] D99877: [Clang] Allow processing of attributes on statements by plugins

2021-04-08 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added a comment.

Thank you for the patch! Btw, can you add more context to the patch when you 
generate it (I usually use `-U 999` when making patches)?

The changes look good so far, but I think `docs\ClangPlugins.rst` should be 
updated to document the new functionality and it would be nice to add example 
usage (in lieu of tests) to `examples\Attribute`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99877

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

[PATCH] D99995: [OpenMP51] Initial support for masked directive and filter clause

2021-04-08 Thread Alexey Bataev via Phabricator via cfe-commits

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

LG


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D5

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

[clang] 4b958dd - [analyzer] Fix crash on spaceship operator (PR47511)

2021-04-08 Thread Valeriy Savchenko via cfe-commits


Author: Valeriy Savchenko
Date: 2021-04-08T20:28:05+03:00
New Revision: 4b958dd6bccab386be432cac99332b867ab9ee22

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

LOG: [analyzer] Fix crash on spaceship operator (PR47511)

rdar://68954187

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

Added: 
clang/test/Analysis/PR47511.cpp

Modified: 
clang/lib/StaticAnalyzer/Core/SValBuilder.cpp

Removed: 




diff  --git a/clang/lib/StaticAnalyzer/Core/SValBuilder.cpp 
b/clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
index a47a28e1e866..9942b7e1423c 100644
--- a/clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
+++ b/clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
@@ -423,6 +423,14 @@ SVal SValBuilder::evalBinOp(ProgramStateRef state, 
BinaryOperator::Opcode op,
 return UnknownVal();
   }
 
+  if (op == BinaryOperatorKind::BO_Cmp) {
+// We can't reason about C++20 spaceship operator yet.
+//
+// FIXME: Support C++20 spaceship operator.
+//The main problem here is that the result is not integer.
+return UnknownVal();
+  }
+
   if (Optional LV = lhs.getAs()) {
 if (Optional RV = rhs.getAs())
   return evalBinOpLL(state, op, *LV, *RV, type);

diff  --git a/clang/test/Analysis/PR47511.cpp b/clang/test/Analysis/PR47511.cpp
new file mode 100644
index ..d42799f4fbde
--- /dev/null
+++ b/clang/test/Analysis/PR47511.cpp
@@ -0,0 +1,19 @@
+// RUN: %clang_analyze_cc1 -std=c++20 -w -analyzer-checker=core -verify %s
+
+// expected-no-diagnostics
+
+namespace std {
+struct strong_ordering {
+  int n;
+  constexpr operator int() const { return n; }
+  static const strong_ordering equal, greater, less;
+};
+constexpr strong_ordering strong_ordering::equal = {0};
+constexpr strong_ordering strong_ordering::greater = {1};
+constexpr strong_ordering strong_ordering::less = {-1};
+} // namespace std
+
+void test() {
+  // no crash
+  (void)(0 <=> 0);
+}



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

[PATCH] D99181: [analyzer] Fix crash on spaceship operator (PR47511)

2021-04-08 Thread Valeriy Savchenko via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG4b958dd6bcca: [analyzer] Fix crash on spaceship operator 
(PR47511) (authored by vsavchenko).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99181

Files:
  clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
  clang/test/Analysis/PR47511.cpp


Index: clang/test/Analysis/PR47511.cpp
===
--- /dev/null
+++ clang/test/Analysis/PR47511.cpp
@@ -0,0 +1,19 @@
+// RUN: %clang_analyze_cc1 -std=c++20 -w -analyzer-checker=core -verify %s
+
+// expected-no-diagnostics
+
+namespace std {
+struct strong_ordering {
+  int n;
+  constexpr operator int() const { return n; }
+  static const strong_ordering equal, greater, less;
+};
+constexpr strong_ordering strong_ordering::equal = {0};
+constexpr strong_ordering strong_ordering::greater = {1};
+constexpr strong_ordering strong_ordering::less = {-1};
+} // namespace std
+
+void test() {
+  // no crash
+  (void)(0 <=> 0);
+}
Index: clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
===
--- clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
+++ clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
@@ -423,6 +423,14 @@
 return UnknownVal();
   }
 
+  if (op == BinaryOperatorKind::BO_Cmp) {
+// We can't reason about C++20 spaceship operator yet.
+//
+// FIXME: Support C++20 spaceship operator.
+//The main problem here is that the result is not integer.
+return UnknownVal();
+  }
+
   if (Optional LV = lhs.getAs()) {
 if (Optional RV = rhs.getAs())
   return evalBinOpLL(state, op, *LV, *RV, type);


Index: clang/test/Analysis/PR47511.cpp
===
--- /dev/null
+++ clang/test/Analysis/PR47511.cpp
@@ -0,0 +1,19 @@
+// RUN: %clang_analyze_cc1 -std=c++20 -w -analyzer-checker=core -verify %s
+
+// expected-no-diagnostics
+
+namespace std {
+struct strong_ordering {
+  int n;
+  constexpr operator int() const { return n; }
+  static const strong_ordering equal, greater, less;
+};
+constexpr strong_ordering strong_ordering::equal = {0};
+constexpr strong_ordering strong_ordering::greater = {1};
+constexpr strong_ordering strong_ordering::less = {-1};
+} // namespace std
+
+void test() {
+  // no crash
+  (void)(0 <=> 0);
+}
Index: clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
===
--- clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
+++ clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
@@ -423,6 +423,14 @@
 return UnknownVal();
   }
 
+  if (op == BinaryOperatorKind::BO_Cmp) {
+// We can't reason about C++20 spaceship operator yet.
+//
+// FIXME: Support C++20 spaceship operator.
+//The main problem here is that the result is not integer.
+return UnknownVal();
+  }
+
   if (Optional LV = lhs.getAs()) {
 if (Optional RV = rhs.getAs())
   return evalBinOpLL(state, op, *LV, *RV, type);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 663ac91 - [analyzer] Fix false positives in inner pointer checker (PR49628)

2021-04-08 Thread Valeriy Savchenko via cfe-commits


Author: Valeriy Savchenko
Date: 2021-04-08T20:30:12+03:00
New Revision: 663ac91ed1d6156e848e5f5f00cd7e7dd6cf867f

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

LOG: [analyzer] Fix false positives in inner pointer checker (PR49628)

This patch supports std::data and std::addressof functions.

rdar://73463300

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

Added: 


Modified: 
clang/lib/StaticAnalyzer/Checkers/InnerPointerChecker.cpp
clang/test/Analysis/inner-pointer.cpp

Removed: 




diff  --git a/clang/lib/StaticAnalyzer/Checkers/InnerPointerChecker.cpp 
b/clang/lib/StaticAnalyzer/Checkers/InnerPointerChecker.cpp
index 65e52e139ee4..bcae73378028 100644
--- a/clang/lib/StaticAnalyzer/Checkers/InnerPointerChecker.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/InnerPointerChecker.cpp
@@ -34,9 +34,9 @@ namespace {
 class InnerPointerChecker
 : public Checker {
 
-  CallDescription AppendFn, AssignFn, ClearFn, CStrFn, DataFn, EraseFn,
-  InsertFn, PopBackFn, PushBackFn, ReplaceFn, ReserveFn, ResizeFn,
-  ShrinkToFitFn, SwapFn;
+  CallDescription AppendFn, AssignFn, AddressofFn, ClearFn, CStrFn, DataFn,
+  DataMemberFn, EraseFn, InsertFn, PopBackFn, PushBackFn, ReplaceFn,
+  ReserveFn, ResizeFn, ShrinkToFitFn, SwapFn;
 
 public:
   class InnerPointerBRVisitor : public BugReporterVisitor {
@@ -73,9 +73,10 @@ class InnerPointerChecker
   InnerPointerChecker()
   : AppendFn({"std", "basic_string", "append"}),
 AssignFn({"std", "basic_string", "assign"}),
+AddressofFn({"std", "addressof"}),
 ClearFn({"std", "basic_string", "clear"}),
-CStrFn({"std", "basic_string", "c_str"}),
-DataFn({"std", "basic_string", "data"}),
+CStrFn({"std", "basic_string", "c_str"}), DataFn({"std", "data"}, 1),
+DataMemberFn({"std", "basic_string", "data"}),
 EraseFn({"std", "basic_string", "erase"}),
 InsertFn({"std", "basic_string", "insert"}),
 PopBackFn({"std", "basic_string", "pop_back"}),
@@ -90,6 +91,9 @@ class InnerPointerChecker
   /// pointers referring to the container object's inner buffer.
   bool isInvalidatingMemberFunction(const CallEvent &Call) const;
 
+  /// Check whether the called function returns a raw inner pointer.
+  bool isInnerPointerAccessFunction(const CallEvent &Call) const;
+
   /// Mark pointer symbols associated with the given memory region released
   /// in the program state.
   void markPtrSymbolsReleased(const CallEvent &Call, ProgramStateRef State,
@@ -130,6 +134,12 @@ bool InnerPointerChecker::isInvalidatingMemberFunction(
   Call.isCalled(SwapFn));
 }
 
+bool InnerPointerChecker::isInnerPointerAccessFunction(
+const CallEvent &Call) const {
+  return (Call.isCalled(CStrFn) || Call.isCalled(DataFn) ||
+  Call.isCalled(DataMemberFn));
+}
+
 void InnerPointerChecker::markPtrSymbolsReleased(const CallEvent &Call,
  ProgramStateRef State,
  const MemRegion *MR,
@@ -172,6 +182,11 @@ void InnerPointerChecker::checkFunctionArguments(const 
CallEvent &Call,
   if (!ArgRegion)
 continue;
 
+  // std::addressof function accepts a non-const reference as an argument,
+  // but doesn't modify it.
+  if (Call.isCalled(AddressofFn))
+continue;
+
   markPtrSymbolsReleased(Call, State, ArgRegion, C);
 }
   }
@@ -195,36 +210,49 @@ void InnerPointerChecker::checkPostCall(const CallEvent 
&Call,
 CheckerContext &C) const {
   ProgramStateRef State = C.getState();
 
+  // TODO: Do we need these to be typed?
+  const TypedValueRegion *ObjRegion = nullptr;
+
   if (const auto *ICall = dyn_cast(&Call)) {
-// TODO: Do we need these to be typed?
-const auto *ObjRegion = dyn_cast_or_null(
+ObjRegion = dyn_cast_or_null(
 ICall->getCXXThisVal().getAsRegion());
-if (!ObjRegion)
-  return;
 
-if (Call.isCalled(CStrFn) || Call.isCalled(DataFn)) {
-  SVal RawPtr = Call.getReturnValue();
-  if (SymbolRef Sym = RawPtr.getAsSymbol(/*IncludeBaseRegions=*/true)) {
-// Start tracking this raw pointer by adding it to the set of symbols
-// associated with this container object in the program state map.
+// Check [string.require] / second point.
+if (isInvalidatingMemberFunction(Call)) {
+  markPtrSymbolsReleased(Call, State, ObjRegion, C);
+  return;
+}
+  }
 
-PtrSet::Factory &F = State->getStateManager().get_context();
-const PtrSet *SetPtr = State->get(ObjRegion);
-PtrSet Set = SetPtr ? *SetPtr : F.getEmptySet();
-assert(C.wasInlined || !Set.contains(Sym));
-Set = F.add(Set, Sym);
+  if (

[PATCH] D99260: [analyzer] Fix false positives in inner pointer checker (PR49628)

2021-04-08 Thread Valeriy Savchenko via Phabricator via cfe-commits

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG663ac91ed1d6: [analyzer] Fix false positives in inner 
pointer checker (PR49628) (authored by vsavchenko).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99260

Files:
  clang/lib/StaticAnalyzer/Checkers/InnerPointerChecker.cpp
  clang/test/Analysis/inner-pointer.cpp

Index: clang/test/Analysis/inner-pointer.cpp
===
--- clang/test/Analysis/inner-pointer.cpp
+++ clang/test/Analysis/inner-pointer.cpp
@@ -17,6 +17,11 @@
 string my_string = "default";
 void default_arg(int a = 42, string &b = my_string);
 
+template 
+T *addressof(T &arg);
+
+char *data(std::string &c);
+
 } // end namespace std
 
 void consume(const char *) {}
@@ -273,6 +278,15 @@
   // expected-note@-1 {{Inner pointer of container used after re/deallocation}}
 }
 
+void deref_after_std_data() {
+  const char *c;
+  std::string s;
+  c = std::data(s); // expected-note {{Pointer to inner buffer of 'std::string' obtained here}}
+  s.push_back('c'); // expected-note {{Inner buffer of 'std::string' reallocated by call to 'push_back'}}
+  consume(c);   // expected-warning {{Inner pointer of container used after re/deallocation}}
+  // expected-note@-1 {{Inner pointer of container used after re/deallocation}}
+}
+
 struct S {
   std::string s;
   const char *name() {
@@ -361,8 +375,24 @@
   // expected-note@-1 {{Inner pointer of container used after re/deallocation}}
 }
 
+void func_addressof() {
+  const char *c;
+  std::string s;
+  c = s.c_str();
+  addressof(s);
+  consume(c); // no-warning
+}
+
+void func_std_data() {
+  const char *c;
+  std::string s;
+  c = std::data(s);
+  consume(c); // no-warning
+}
+
 struct T {
   std::string to_string() { return s; }
+
 private:
   std::string s;
 };
Index: clang/lib/StaticAnalyzer/Checkers/InnerPointerChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/InnerPointerChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/InnerPointerChecker.cpp
@@ -34,9 +34,9 @@
 class InnerPointerChecker
 : public Checker {
 
-  CallDescription AppendFn, AssignFn, ClearFn, CStrFn, DataFn, EraseFn,
-  InsertFn, PopBackFn, PushBackFn, ReplaceFn, ReserveFn, ResizeFn,
-  ShrinkToFitFn, SwapFn;
+  CallDescription AppendFn, AssignFn, AddressofFn, ClearFn, CStrFn, DataFn,
+  DataMemberFn, EraseFn, InsertFn, PopBackFn, PushBackFn, ReplaceFn,
+  ReserveFn, ResizeFn, ShrinkToFitFn, SwapFn;
 
 public:
   class InnerPointerBRVisitor : public BugReporterVisitor {
@@ -73,9 +73,10 @@
   InnerPointerChecker()
   : AppendFn({"std", "basic_string", "append"}),
 AssignFn({"std", "basic_string", "assign"}),
+AddressofFn({"std", "addressof"}),
 ClearFn({"std", "basic_string", "clear"}),
-CStrFn({"std", "basic_string", "c_str"}),
-DataFn({"std", "basic_string", "data"}),
+CStrFn({"std", "basic_string", "c_str"}), DataFn({"std", "data"}, 1),
+DataMemberFn({"std", "basic_string", "data"}),
 EraseFn({"std", "basic_string", "erase"}),
 InsertFn({"std", "basic_string", "insert"}),
 PopBackFn({"std", "basic_string", "pop_back"}),
@@ -90,6 +91,9 @@
   /// pointers referring to the container object's inner buffer.
   bool isInvalidatingMemberFunction(const CallEvent &Call) const;
 
+  /// Check whether the called function returns a raw inner pointer.
+  bool isInnerPointerAccessFunction(const CallEvent &Call) const;
+
   /// Mark pointer symbols associated with the given memory region released
   /// in the program state.
   void markPtrSymbolsReleased(const CallEvent &Call, ProgramStateRef State,
@@ -130,6 +134,12 @@
   Call.isCalled(SwapFn));
 }
 
+bool InnerPointerChecker::isInnerPointerAccessFunction(
+const CallEvent &Call) const {
+  return (Call.isCalled(CStrFn) || Call.isCalled(DataFn) ||
+  Call.isCalled(DataMemberFn));
+}
+
 void InnerPointerChecker::markPtrSymbolsReleased(const CallEvent &Call,
  ProgramStateRef State,
  const MemRegion *MR,
@@ -172,6 +182,11 @@
   if (!ArgRegion)
 continue;
 
+  // std::addressof function accepts a non-const reference as an argument,
+  // but doesn't modify it.
+  if (Call.isCalled(AddressofFn))
+continue;
+
   markPtrSymbolsReleased(Call, State, ArgRegion, C);
 }
   }
@@ -195,36 +210,49 @@
 CheckerContext &C) const {
   ProgramStateRef State = C.getState();
 
+  // TODO: Do we need these to be typed?
+  const TypedValueRegion *ObjRegion = nullptr;
+
   if (const auto *ICall = dyn_cast(&Call)) {
-// TODO: Do we need these to be typed?
-const au

[PATCH] D100124: [Clang][NVPTX] Add NVPTX intrinsics and builtins for CUDA PTX redux.sync instructions

2021-04-08 Thread Artem Belevich via Phabricator via cfe-commits

tra added inline comments.



Comment at: clang/include/clang/Basic/BuiltinsNVPTX.def:460-468
+TARGET_BUILTIN(__nvvm_redux_sync_add_s32, "SiSii", "", SM_80)
+TARGET_BUILTIN(__nvvm_redux_sync_min_s32, "SiSii", "", SM_80)
+TARGET_BUILTIN(__nvvm_redux_sync_max_s32, "SiSii", "", SM_80)
+TARGET_BUILTIN(__nvvm_redux_sync_add_u32, "UiUii", "", SM_80)
+TARGET_BUILTIN(__nvvm_redux_sync_min_u32, "UiUii", "", SM_80)
+TARGET_BUILTIN(__nvvm_redux_sync_max_u32, "UiUii", "", SM_80)
+TARGET_BUILTIN(__nvvm_redux_sync_and_b32, "iii", "", SM_80)

Instead of creating one builtin per integer variant, can we use a more generic 
builtin `__nvvm_redux_sync_add_i`, similar to how we handle 
`__nvvm_atom_add_gen_i` ?




Comment at: llvm/include/llvm/IR/IntrinsicsNVVM.td:4103
+// redux.sync.add.u32 dst, src, membermask;
+def int_nvvm_redux_sync_add_u32 : GCCBuiltin<"__nvvm_redux_sync_add_u32">,
+  Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty],

This could also be consolidated into an overloaded intrinsic operating on 
`llvm_anyint_ty`



Comment at: llvm/include/llvm/IR/IntrinsicsNVVM.td:4105
+  Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty],
+[IntrConvergent, IntrNoMem]>;
+

Similar to `shfl`, these intrinsics probably need `IntrInaccessibleMemOnly` as 
they exchange data with other threads.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100124

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

[PATCH] D98798: Produce warning for performing pointer arithmetic on a null pointer.

2021-04-08 Thread Eli Friedman via Phabricator via cfe-commits

efriedma added a comment.

Please add a test for `(char*)0-(char*)0`.


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

https://reviews.llvm.org/D98798

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

[PATCH] D100129: Tiny format fix

2021-04-08 Thread Nathan Sidwell via Phabricator via cfe-commits

urnathan created this revision.
urnathan added reviewers: rsmith, bruno.
urnathan requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

A mis-indented } in the middle of a function.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100129

Files:
  clang/lib/Parse/ParseDeclCXX.cpp


Index: clang/lib/Parse/ParseDeclCXX.cpp
===
--- clang/lib/Parse/ParseDeclCXX.cpp
+++ clang/lib/Parse/ParseDeclCXX.cpp
@@ -132,7 +132,7 @@
   << FixItHint::CreateRemoval(InlineLoc);
 Decl *NSAlias = ParseNamespaceAlias(NamespaceLoc, IdentLoc, Ident, 
DeclEnd);
 return Actions.ConvertDeclToDeclGroup(NSAlias);
-}
+  }
 
   BalancedDelimiterTracker T(*this, tok::l_brace);
   if (T.consumeOpen()) {


Index: clang/lib/Parse/ParseDeclCXX.cpp
===
--- clang/lib/Parse/ParseDeclCXX.cpp
+++ clang/lib/Parse/ParseDeclCXX.cpp
@@ -132,7 +132,7 @@
   << FixItHint::CreateRemoval(InlineLoc);
 Decl *NSAlias = ParseNamespaceAlias(NamespaceLoc, IdentLoc, Ident, DeclEnd);
 return Actions.ConvertDeclToDeclGroup(NSAlias);
-}
+  }
 
   BalancedDelimiterTracker T(*this, tok::l_brace);
   if (T.consumeOpen()) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D99683: [HIP] Support ThinLTO

2021-04-08 Thread Yaxun Liu via Phabricator via cfe-commits

yaxunl added a comment.

Any other concerns? Thanks.


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

https://reviews.llvm.org/D99683

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

[PATCH] D96090: [analyzer] Replace StoreManager::CastRetrievedVal with SValBuilder::evalCast

2021-04-08 Thread Artem Dergachev via Phabricator via cfe-commits

NoQ added a comment.

> Which is fairly shocking and mind blowing that we've organically developed 
> two independent implementations of casting, one for RegionStore and one for 
> everything else.

Wait, no, nvm, please disregard this. It wasn't like this forever, i just 
happened to catch code in an intermediate state after D90157 
. Either way, it's definitely getting much 
better, and either way, i'm curious if `dispatchCast` can now be eliminated.


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

https://reviews.llvm.org/D96090

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

[PATCH] D99675: RFC [llvm][clang] Create new intrinsic llvm.arith.fence to control FP optimization at expression level

2021-04-08 Thread Eli Friedman via Phabricator via cfe-commits

efriedma added a comment.

In D99675#2672138 , @kbsmith1 wrote:

> In D99675#2671924 , @efriedma wrote:
>
>> How is llvm.arith.fence() different from using "freeze" on a floating-point 
>> value?  The goal isn't really the same, sure, but the effects seem similar 
>> at first glance.
>
> They are similar.  However, freeze is a no-op if the operand can be proven 
> not to be undef or poison, and in such circumstances could be removed by an 
> optimizer.  llvm.arith.fence cannot be removed by an optimizer, because doing 
> so might allow instructions that were "outside" the fence from being 
> reassociated/distrbuted with the instructions/operands that were inside the 
> fence.

Okay.  In practice, it's basically impossible for us to prove that the result 
of "fast" arithmetic isn't poison, given the way ninf/nnan are defined, but 
depending on that would be fragile.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99675

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

[PATCH] D90157: [analyzer] Rework SValBuilder::evalCast function into maintainable and clear way

2021-04-08 Thread Artem Dergachev via Phabricator via cfe-commits

NoQ added a comment.

I'm catching up and these changes look great.

In D90157#2433657 , @steakhal wrote:

> I've run the baseline and your patch as well on 15 projects, both with and 
> without Z3 refutation enabled.
> (...)
> All in all, I'm still in favor of this change, but I'm really curious why did 
> we observe such changes. Debugging the cause seems really tricky to me.

If testing on a large codebase uncovered changes in behavior that weren't 
caught by our LIT test suite it often make sense to update our LIT test suite 
to include those tests in order to avoid similar regressions in the future. 
Regressions like this are easy to auto-reduce with tools like `creduce` because 
there's no functional change intended in the patch so there's a 100% formal 
reduction criterion "any change in diagnostics is observed" which can be easily 
fed to `creduce`. Even though NFC commits don't require tests, this doesn't 
mean they shouldn't add them!

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90157

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

[PATCH] D92024: [clang] Implement P0692R1 from C++20 (access checking on specializations and instantiations)

2021-04-08 Thread Alex Orlov via Phabricator via cfe-commits

aorlov added a comment.

@krisb Thank you for your comments. I will consider them.




Comment at: clang/test/CXX/temp/temp.spec/func.spec.cpp:105
+template  void func10(A::B, int x) {}
+template  void func11(A::C, A::D, int) {}
+template  void func12() {}

krisb wrote:
> Before this patch clang diagnosed cases like 
> 
> ```
> class A { class C {}; };
> template  void func(A::C) {}
> ```
> Why is it no longer the case?
> 
Your example generates an error `error: 'C' is a private member of 'A'` on 
latest clang.
This patch is intended to implement a proposal [[ 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0692r1.html | 
p0692r1]] and consider this example as valid.
Did I understand your question correctly?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92024

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

[PATCH] D99877: [Clang] Allow processing of attributes on statements by plugins

2021-04-08 Thread Josh Junon via Phabricator via cfe-commits

Qix- updated this revision to Diff 336172.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99877

Files:
  clang/include/clang/Sema/ParsedAttr.h
  clang/lib/Sema/SemaStmtAttr.cpp


Index: clang/lib/Sema/SemaStmtAttr.cpp
===
--- clang/lib/Sema/SemaStmtAttr.cpp
+++ clang/lib/Sema/SemaStmtAttr.cpp
@@ -430,11 +430,12 @@
   case ParsedAttr::AT_Unlikely:
 return handleUnlikely(S, St, A, Range);
   default:
-// N.B., ClangAttrEmitter.cpp emits a diagnostic helper that ensures a
-// declaration attribute is not written on a statement, but this code is
-// needed for attributes in Attr.td that do not list any subjects.
-S.Diag(A.getRange().getBegin(), diag::err_decl_attribute_invalid_on_stmt)
-<< A << St->getBeginLoc();
+if (A.getInfo().handleStmtAttribute(S, St, A) == 
ParsedAttrInfo::NotHandled)
+  // N.B., ClangAttrEmitter.cpp emits a diagnostic helper that ensures a
+  // declaration attribute is not written on a statement, but this code is
+  // needed for attributes in Attr.td that do not list any subjects.
+  S.Diag(A.getRange().getBegin(), diag::err_decl_attribute_invalid_on_stmt)
+  << A << St->getBeginLoc();
 return nullptr;
   }
 }
Index: clang/include/clang/Sema/ParsedAttr.h
===
--- clang/include/clang/Sema/ParsedAttr.h
+++ clang/include/clang/Sema/ParsedAttr.h
@@ -117,6 +117,13 @@
const ParsedAttr &Attr) const {
 return NotHandled;
   }
+  /// If this ParsedAttrInfo knows how to handle this ParsedAttr applied to 
this
+  /// Stmt then do so and return either AttributeApplied if it was applied or
+  /// AttributeNotApplied if it wasn't. Otherwise return NotHandled.
+  virtual AttrHandling handleStmtAttribute(Sema &S, Stmt *St,
+   const ParsedAttr &Attr) const {
+return NotHandled;
+  }
 
   static const ParsedAttrInfo &get(const AttributeCommonInfo &A);
 };


Index: clang/lib/Sema/SemaStmtAttr.cpp
===
--- clang/lib/Sema/SemaStmtAttr.cpp
+++ clang/lib/Sema/SemaStmtAttr.cpp
@@ -430,11 +430,12 @@
   case ParsedAttr::AT_Unlikely:
 return handleUnlikely(S, St, A, Range);
   default:
-// N.B., ClangAttrEmitter.cpp emits a diagnostic helper that ensures a
-// declaration attribute is not written on a statement, but this code is
-// needed for attributes in Attr.td that do not list any subjects.
-S.Diag(A.getRange().getBegin(), diag::err_decl_attribute_invalid_on_stmt)
-<< A << St->getBeginLoc();
+if (A.getInfo().handleStmtAttribute(S, St, A) == ParsedAttrInfo::NotHandled)
+  // N.B., ClangAttrEmitter.cpp emits a diagnostic helper that ensures a
+  // declaration attribute is not written on a statement, but this code is
+  // needed for attributes in Attr.td that do not list any subjects.
+  S.Diag(A.getRange().getBegin(), diag::err_decl_attribute_invalid_on_stmt)
+  << A << St->getBeginLoc();
 return nullptr;
   }
 }
Index: clang/include/clang/Sema/ParsedAttr.h
===
--- clang/include/clang/Sema/ParsedAttr.h
+++ clang/include/clang/Sema/ParsedAttr.h
@@ -117,6 +117,13 @@
const ParsedAttr &Attr) const {
 return NotHandled;
   }
+  /// If this ParsedAttrInfo knows how to handle this ParsedAttr applied to this
+  /// Stmt then do so and return either AttributeApplied if it was applied or
+  /// AttributeNotApplied if it wasn't. Otherwise return NotHandled.
+  virtual AttrHandling handleStmtAttribute(Sema &S, Stmt *St,
+   const ParsedAttr &Attr) const {
+return NotHandled;
+  }
 
   static const ParsedAttrInfo &get(const AttributeCommonInfo &A);
 };
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D99861: [Clang] Record tokens in attribute arguments for user-defined C++/C2x attributes

2021-04-08 Thread Josh Junon via Phabricator via cfe-commits

Qix- updated this revision to Diff 336173.
Qix- added a comment.

Updated the diff to include a lot more context (-U). Thanks again for the 
tip :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99861

Files:
  clang/examples/CMakeLists.txt
  clang/examples/PrintAttributeTokens/CMakeLists.txt
  clang/examples/PrintAttributeTokens/PrintAttributeTokens.cpp
  clang/examples/PrintAttributeTokens/PrintAttributeTokens.exports
  clang/examples/PrintAttributeTokens/README.txt
  clang/include/clang/Lex/Preprocessor.h
  clang/include/clang/Sema/ParsedAttr.h
  clang/lib/Lex/Preprocessor.cpp
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Sema/ParsedAttr.cpp
  clang/test/Frontend/plugin-print-attr-tokens.cpp

Index: clang/test/Frontend/plugin-print-attr-tokens.cpp
===
--- /dev/null
+++ clang/test/Frontend/plugin-print-attr-tokens.cpp
@@ -0,0 +1,12 @@
+// RUN: %clang -cc1 -load %llvmshlibdir/PrintAttributeTokens%pluginext -fsyntax-only -ast-dump -verify %s
+// REQUIRES: plugins, examples
+
+// expected-no-diagnostics
+[[print_tokens(
+the, mitochondria,
+, Of::The($cell))]] void
+fn1a() {}
+[[plugin::print_tokens("a string")]] void fn1b() {}
+[[plugin::print_tokens()]] void fn1c() {}
+[[plugin::print_tokens(some_ident)]] void fn1d() {}
+[[plugin::print_tokens(int)]] void fn1e() {}
Index: clang/lib/Sema/ParsedAttr.cpp
===
--- clang/lib/Sema/ParsedAttr.cpp
+++ clang/lib/Sema/ParsedAttr.cpp
@@ -45,10 +45,11 @@
   else if (HasParsedType)
 return totalSizeToAlloc(0, 0, 0, 1, 0);
+detail::PropertyData, Token>(0, 0, 0, 1, 0, 0);
   return totalSizeToAlloc(NumArgs, 0, 0, 0, 0);
+  detail::PropertyData, Token>(NumArgs, 0, 0, 0, 0,
+   NumTokens);
 }
 
 AttributeFactory::AttributeFactory() {
Index: clang/lib/Parse/ParseDeclCXX.cpp
===
--- clang/lib/Parse/ParseDeclCXX.cpp
+++ clang/lib/Parse/ParseDeclCXX.cpp
@@ -4096,13 +4096,39 @@
   LO.CPlusPlus ? ParsedAttr::AS_CXX11 : ParsedAttr::AS_C2x;
 
   // If the attribute isn't known, we will not attempt to parse any
-  // arguments.
+  // arguments. Instead, we just record the tokens and add the attribute
+  // directly. The recording happens here because this is the only place
+  // where user-defined (via plugins) attributes are parsed, and thus
+  // they care about the token stream directly.
   if (!hasAttribute(LO.CPlusPlus ? AttrSyntax::CXX : AttrSyntax::C, ScopeName,
 AttrName, getTargetInfo(), getLangOpts())) {
-// Eat the left paren, then skip to the ending right paren.
+// Begin recording session.
+SmallVector RecordedTokens;
+assert(!PP.hasTokenRecorder());
+PP.setTokenRecorder(
+[&RecordedTokens](const Token &Tok) { RecordedTokens.push_back(Tok); });
+
+// Eat the left paren.
 ConsumeParen();
+
+// skip to the ending right paren.
 SkipUntil(tok::r_paren);
-return false;
+
+// End recording session.
+PP.setTokenRecorder(nullptr);
+
+// Add new attribute with the token list.
+// We assert that we have at least one token,
+// since we have to ignore the final r_paren.
+assert(RecordedTokens.size() > 0);
+Attrs.addNew(
+AttrName,
+SourceRange(ScopeLoc.isValid() ? ScopeLoc : AttrNameLoc, AttrNameLoc),
+ScopeName, ScopeLoc, nullptr, 0,
+getLangOpts().CPlusPlus ? ParsedAttr::AS_CXX11 : ParsedAttr::AS_C2x,
+RecordedTokens.data(), RecordedTokens.size() - 2);
+
+return true;
   }
 
   if (ScopeName && (ScopeName->isStr("gnu") || ScopeName->isStr("__gnu__"))) {
Index: clang/lib/Parse/ParseDecl.cpp
===
--- clang/lib/Parse/ParseDecl.cpp
+++ clang/lib/Parse/ParseDecl.cpp
@@ -2828,7 +2828,7 @@
   ArgsVector ArgExprs;
   ArgExprs.push_back(ArgExpr.get());
   Attrs.addNew(KWName, KWLoc, nullptr, KWLoc, ArgExprs.data(), 1,
-   ParsedAttr::AS_Keyword, EllipsisLoc);
+   ParsedAttr::AS_Keyword, nullptr, 0, EllipsisLoc);
 }
 
 ExprResult Parser::ParseExtIntegerArgument() {
Index: clang/lib/Lex/Preprocessor.cpp
===
--- clang/lib/Lex/Preprocessor.cpp
+++ clang/lib/Lex/Preprocessor.cpp
@@ -970,6 +970,9 @@
 if (OnToken)
   OnToken(Result);
   }
+
+  if (OnRecordedToken)
+OnRecordedToken(Result);
 }
 
 /// Lex a header-name token (including one formed from header-name-tokens if
Index: clang/include/clang/Sema/ParsedAttr.h
===
--- clang/include/clang/Sema/ParsedAttr.h
+++ clang/include/clang/Sema/ParsedAttr.h
@@ -1

[PATCH] D100057: Remove warning "suggest braces" for aggregate initialization of an empty class with an aggregate base class.

2021-04-08 Thread Louis Dionne via Phabricator via cfe-commits

ldionne added a comment.

FWIW, I think this is acceptable, but I think even better would be to make it 
clear in the Standard that this is acceptable. Having spoken with a few folks 
about this, it doesn't appear to be specified very clearly.


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

https://reviews.llvm.org/D100057

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

[PATCH] D75844: [clang] Set begin loc on GNU attribute parsed attrs

2021-04-08 Thread Brooks Moses via Phabricator via cfe-commits

brooksmoses added a comment.

FWIW, this now causes Clang to produce an error on this code, when it didn't 
before:

  using namespace::foo __attribute__((deprecated("message")));

I discussed this with Richard Smith, who points out that GCC does not accept 
this and it's not permitted according to the C++ standard, so this should 
probably be considered an accidental fix of a longstanding bug.   With that 
said, would it be useful to add this as a tested case?


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

https://reviews.llvm.org/D75844

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

[clang] 02ef996 - [RISCV] Prevent __builtin_riscv_orc_b_64 from being compiled RV32 target.

2021-04-08 Thread Craig Topper via cfe-commits


Author: Craig Topper
Date: 2021-04-08T11:34:56-07:00
New Revision: 02ef9963e1ad1e6ded539c830861a074b879dc70

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

LOG: [RISCV] Prevent __builtin_riscv_orc_b_64 from being compiled RV32 target.

The backend can't handle this and will throw a fatal error from
type legalization. It's easy enough to fix that for this intrinsic
by just splitting the IR intrinsic since it works on individual bytes.

There will be other intrinsics in the future that would be harder
to support through splitting, for example grev, gorc, and shfl. Those
would require a compare and a select be inserted to check the MSB of
their control input.

This patch adds support for preventing this in the frontend with
a nice diagnostic.

Reviewed By: frasercrmck

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

Added: 
clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbb-error.c

Modified: 
clang/include/clang/Basic/BuiltinsRISCV.def
clang/lib/Basic/Targets/RISCV.cpp
clang/lib/Basic/Targets/RISCV.h
clang/lib/Sema/SemaChecking.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsRISCV.def 
b/clang/include/clang/Basic/BuiltinsRISCV.def
index e0b28011e61ad..8105263ca3ca6 100644
--- a/clang/include/clang/Basic/BuiltinsRISCV.def
+++ b/clang/include/clang/Basic/BuiltinsRISCV.def
@@ -19,7 +19,7 @@
 
 // Zbb extension
 TARGET_BUILTIN(__builtin_riscv_orc_b_32, "ZiZi", "nc", "experimental-zbb")
-TARGET_BUILTIN(__builtin_riscv_orc_b_64, "WiWi", "nc", "experimental-zbb")
+TARGET_BUILTIN(__builtin_riscv_orc_b_64, "WiWi", "nc", 
"experimental-zbb,64bit")
 
 // Zbc extension
 TARGET_BUILTIN(__builtin_riscv_clmul, "LiLiLi", "nc", "experimental-zbc")

diff  --git a/clang/lib/Basic/Targets/RISCV.cpp 
b/clang/lib/Basic/Targets/RISCV.cpp
index 4ca41414a9d62..1f31f471db3a4 100644
--- a/clang/lib/Basic/Targets/RISCV.cpp
+++ b/clang/lib/Basic/Targets/RISCV.cpp
@@ -239,6 +239,16 @@ ArrayRef 
RISCVTargetInfo::getTargetBuiltins() const {
  Builtin::FirstTSBuiltin);
 }
 
+bool RISCVTargetInfo::initFeatureMap(
+llvm::StringMap &Features, DiagnosticsEngine &Diags, StringRef CPU,
+const std::vector &FeaturesVec) const {
+
+  if (getTriple().getArch() == llvm::Triple::riscv64)
+Features["64bit"] = true;
+
+  return TargetInfo::initFeatureMap(Features, Diags, CPU, FeaturesVec);
+}
+
 /// Return true if has this feature, need to sync with handleTargetFeatures.
 bool RISCVTargetInfo::hasFeature(StringRef Feature) const {
   bool Is64Bit = getTriple().getArch() == llvm::Triple::riscv64;
@@ -246,6 +256,7 @@ bool RISCVTargetInfo::hasFeature(StringRef Feature) const {
   .Case("riscv", true)
   .Case("riscv32", !Is64Bit)
   .Case("riscv64", Is64Bit)
+  .Case("64bit", Is64Bit)
   .Case("m", HasM)
   .Case("a", HasA)
   .Case("f", HasF)

diff  --git a/clang/lib/Basic/Targets/RISCV.h b/clang/lib/Basic/Targets/RISCV.h
index 4fc8cd1e22dfb..4e650d3b2dc16 100644
--- a/clang/lib/Basic/Targets/RISCV.h
+++ b/clang/lib/Basic/Targets/RISCV.h
@@ -99,6 +99,11 @@ class RISCVTargetInfo : public TargetInfo {
 
   std::string convertConstraint(const char *&Constraint) const override;
 
+  bool
+  initFeatureMap(llvm::StringMap &Features, DiagnosticsEngine &Diags,
+ StringRef CPU,
+ const std::vector &FeaturesVec) const override;
+
   bool hasFeature(StringRef Feature) const override;
 
   bool handleTargetFeatures(std::vector &Features,

diff  --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index 1d39de7ade8b1..be015f02027f5 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -3422,12 +3422,18 @@ bool Sema::CheckRISCVBuiltinFunctionCall(const 
TargetInfo &TI,
   Features.split(ReqFeatures, ',');
 
   // Check if each required feature is included
-  for (auto &I : ReqFeatures) {
-if (TI.hasFeature(I))
+  for (StringRef F : ReqFeatures) {
+if (TI.hasFeature(F))
   continue;
+
+// If the feature is 64bit, alter the string so it will print better in
+// the diagnostic.
+if (F == "64bit")
+  F = "RV64";
+
 // Convert features like "zbr" and "experimental-zbr" to "Zbr".
-I.consume_front("experimental-");
-std::string FeatureStr = I.str();
+F.consume_front("experimental-");
+std::string FeatureStr = F.str();
 FeatureStr[0] = std::toupper(FeatureStr[0]);
 
 // Error message

diff  --git a/clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbb-error.c 
b/clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbb-error.c
new file mode 100644
index 0..ad864aa65feff
--- /dev/null
+++ b/clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbb-error.c
@@ -0,0 +1,6 @@
+// NOTE: Assertio

[PATCH] D99984: [RISCV] Prevent __builtin_riscv_orc_b_64 from being compiled RV32 target.

2021-04-08 Thread Craig Topper via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG02ef9963e1ad: [RISCV] Prevent __builtin_riscv_orc_b_64 from 
being compiled RV32 target. (authored by craig.topper).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99984

Files:
  clang/include/clang/Basic/BuiltinsRISCV.def
  clang/lib/Basic/Targets/RISCV.cpp
  clang/lib/Basic/Targets/RISCV.h
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbb-error.c


Index: clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbb-error.c
===
--- /dev/null
+++ clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbb-error.c
@@ -0,0 +1,6 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 -triple riscv32 -target-feature +experimental-zbb -verify 
%s -o -
+
+int orc_b_64(int a) {
+  return __builtin_riscv_orc_b_64(a); // expected-error {{builtin requires 
'RV64' extension support to be enabled}}
+}
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -3422,12 +3422,18 @@
   Features.split(ReqFeatures, ',');
 
   // Check if each required feature is included
-  for (auto &I : ReqFeatures) {
-if (TI.hasFeature(I))
+  for (StringRef F : ReqFeatures) {
+if (TI.hasFeature(F))
   continue;
+
+// If the feature is 64bit, alter the string so it will print better in
+// the diagnostic.
+if (F == "64bit")
+  F = "RV64";
+
 // Convert features like "zbr" and "experimental-zbr" to "Zbr".
-I.consume_front("experimental-");
-std::string FeatureStr = I.str();
+F.consume_front("experimental-");
+std::string FeatureStr = F.str();
 FeatureStr[0] = std::toupper(FeatureStr[0]);
 
 // Error message
Index: clang/lib/Basic/Targets/RISCV.h
===
--- clang/lib/Basic/Targets/RISCV.h
+++ clang/lib/Basic/Targets/RISCV.h
@@ -99,6 +99,11 @@
 
   std::string convertConstraint(const char *&Constraint) const override;
 
+  bool
+  initFeatureMap(llvm::StringMap &Features, DiagnosticsEngine &Diags,
+ StringRef CPU,
+ const std::vector &FeaturesVec) const override;
+
   bool hasFeature(StringRef Feature) const override;
 
   bool handleTargetFeatures(std::vector &Features,
Index: clang/lib/Basic/Targets/RISCV.cpp
===
--- clang/lib/Basic/Targets/RISCV.cpp
+++ clang/lib/Basic/Targets/RISCV.cpp
@@ -239,6 +239,16 @@
  Builtin::FirstTSBuiltin);
 }
 
+bool RISCVTargetInfo::initFeatureMap(
+llvm::StringMap &Features, DiagnosticsEngine &Diags, StringRef CPU,
+const std::vector &FeaturesVec) const {
+
+  if (getTriple().getArch() == llvm::Triple::riscv64)
+Features["64bit"] = true;
+
+  return TargetInfo::initFeatureMap(Features, Diags, CPU, FeaturesVec);
+}
+
 /// Return true if has this feature, need to sync with handleTargetFeatures.
 bool RISCVTargetInfo::hasFeature(StringRef Feature) const {
   bool Is64Bit = getTriple().getArch() == llvm::Triple::riscv64;
@@ -246,6 +256,7 @@
   .Case("riscv", true)
   .Case("riscv32", !Is64Bit)
   .Case("riscv64", Is64Bit)
+  .Case("64bit", Is64Bit)
   .Case("m", HasM)
   .Case("a", HasA)
   .Case("f", HasF)
Index: clang/include/clang/Basic/BuiltinsRISCV.def
===
--- clang/include/clang/Basic/BuiltinsRISCV.def
+++ clang/include/clang/Basic/BuiltinsRISCV.def
@@ -19,7 +19,7 @@
 
 // Zbb extension
 TARGET_BUILTIN(__builtin_riscv_orc_b_32, "ZiZi", "nc", "experimental-zbb")
-TARGET_BUILTIN(__builtin_riscv_orc_b_64, "WiWi", "nc", "experimental-zbb")
+TARGET_BUILTIN(__builtin_riscv_orc_b_64, "WiWi", "nc", 
"experimental-zbb,64bit")
 
 // Zbc extension
 TARGET_BUILTIN(__builtin_riscv_clmul, "LiLiLi", "nc", "experimental-zbc")


Index: clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbb-error.c
===
--- /dev/null
+++ clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbb-error.c
@@ -0,0 +1,6 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 -triple riscv32 -target-feature +experimental-zbb -verify %s -o -
+
+int orc_b_64(int a) {
+  return __builtin_riscv_orc_b_64(a); // expected-error {{builtin requires 'RV64' extension support to be enabled}}
+}
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -3422,12 +3422,18 @@
   Features.split(ReqFeatures, ',');
 
   // Check if each required feature is included

[PATCH] D99037: [Matrix] Implement C-style explicit type conversions for matrix types

2021-04-08 Thread Saurabh Jha via Phabricator via cfe-commits

SaurabhJha added a comment.

The windows build failure is solved by itself and its all passing now!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99037

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

[PATCH] D99994: [CodeView] Add CodeView support for PGO debug information

2021-04-08 Thread Reid Kleckner via Phabricator via cfe-commits

rnk added a comment.

IMO it's best to avoid adding fields to DICompileUnit if at all possible. It's 
the "god object" / "katamari damacy" of module debug info. Is there something 
about the IR module that indicates if PGO data is present or not? We could 
check that instead. I looked, but I wasn't able to find anything quickly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D4

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

[PATCH] D100127: [RISCV][Clang] Add some RVV Permutation intrinsic functions.

2021-04-08 Thread Craig Topper via Phabricator via cfe-commits

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

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100127

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

[clang] d508561 - [AIX] Support init priority attribute

2021-04-08 Thread Xiangling Liao via cfe-commits


Author: Xiangling Liao
Date: 2021-04-08T15:40:09-04:00
New Revision: d5085617986e8ceabe7af02eb9c50f5350b3f980

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

LOG: [AIX] Support init priority attribute

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

Added: 


Modified: 
clang/lib/CodeGen/CGDeclCXX.cpp
clang/lib/CodeGen/CodeGenFunction.h
clang/lib/CodeGen/CodeGenModule.h
clang/lib/CodeGen/ItaniumCXXABI.cpp
clang/lib/Sema/SemaDeclAttr.cpp
clang/test/CodeGen/aix-init-priority-attribute.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGDeclCXX.cpp b/clang/lib/CodeGen/CGDeclCXX.cpp
index c551901acc43..8131b5285075 100644
--- a/clang/lib/CodeGen/CGDeclCXX.cpp
+++ b/clang/lib/CodeGen/CGDeclCXX.cpp
@@ -499,7 +499,8 @@ CodeGenModule::EmitCXXGlobalVarDeclInitFunc(const VarDecl 
*D,
   } else if (PerformInit && ISA) {
 EmitPointerToInitFunc(D, Addr, Fn, ISA);
   } else if (auto *IPA = D->getAttr()) {
-OrderGlobalInits Key(IPA->getPriority(), PrioritizedCXXGlobalInits.size());
+OrderGlobalInitsOrStermFinalizers Key(IPA->getPriority(),
+  PrioritizedCXXGlobalInits.size());
 PrioritizedCXXGlobalInits.push_back(std::make_pair(Key, Fn));
   } else if (isTemplateInstantiation(D->getTemplateSpecializationKind()) ||
  getContext().GetGVALinkageForVariable(D) == GVA_DiscardableODR) {
@@ -566,6 +567,17 @@ static SmallString<128> 
getTransformedFileName(llvm::Module &M) {
   return FileName;
 }
 
+static std::string getPrioritySuffix(unsigned int Priority) {
+  assert(Priority <= 65535 && "Priority should always be <= 65535.");
+
+  // Compute the function suffix from priority. Prepend with zeroes to make
+  // sure the function names are also ordered as priorities.
+  std::string PrioritySuffix = llvm::utostr(Priority);
+  PrioritySuffix = std::string(6 - PrioritySuffix.size(), '0') + 
PrioritySuffix;
+
+  return PrioritySuffix;
+}
+
 void
 CodeGenModule::EmitCXXGlobalInitFunc() {
   while (!CXXGlobalInits.empty() && !CXXGlobalInits.back())
@@ -577,12 +589,8 @@ CodeGenModule::EmitCXXGlobalInitFunc() {
   llvm::FunctionType *FTy = llvm::FunctionType::get(VoidTy, false);
   const CGFunctionInfo &FI = getTypes().arrangeNullaryFunction();
 
-  const bool UseSinitAndSterm = getCXXABI().useSinitAndSterm();
   // Create our global prioritized initialization function.
   if (!PrioritizedCXXGlobalInits.empty()) {
-assert(!UseSinitAndSterm && "Prioritized sinit and sterm functions are not"
-" supported yet.");
-
 SmallVector LocalCXXGlobalInits;
 llvm::array_pod_sort(PrioritizedCXXGlobalInits.begin(),
  PrioritizedCXXGlobalInits.end());
@@ -596,14 +604,10 @@ CodeGenModule::EmitCXXGlobalInitFunc() {
 PrioE = std::upper_bound(I + 1, E, *I, GlobalInitPriorityCmp());
 
   LocalCXXGlobalInits.clear();
-  unsigned Priority = I->first.priority;
-  // Compute the function suffix from priority. Prepend with zeroes to make
-  // sure the function names are also ordered as priorities.
-  std::string PrioritySuffix = llvm::utostr(Priority);
-  // Priority is always <= 65535 (enforced by sema).
-  PrioritySuffix = std::string(6-PrioritySuffix.size(), 
'0')+PrioritySuffix;
+
+  unsigned int Priority = I->first.priority;
   llvm::Function *Fn = CreateGlobalInitOrCleanUpFunction(
-  FTy, "_GLOBAL__I_" + PrioritySuffix, FI);
+  FTy, "_GLOBAL__I_" + getPrioritySuffix(Priority), FI);
 
   for (; I < PrioE; ++I)
 LocalCXXGlobalInits.push_back(I->second);
@@ -614,7 +618,7 @@ CodeGenModule::EmitCXXGlobalInitFunc() {
 PrioritizedCXXGlobalInits.clear();
   }
 
-  if (UseSinitAndSterm && CXXGlobalInits.empty())
+  if (getCXXABI().useSinitAndSterm() && CXXGlobalInits.empty())
 return;
 
   // Include the filename in the symbol name. Including "sub_" matches gcc
@@ -649,12 +653,50 @@ CodeGenModule::EmitCXXGlobalInitFunc() {
 }
 
 void CodeGenModule::EmitCXXGlobalCleanUpFunc() {
-  if (CXXGlobalDtorsOrStermFinalizers.empty())
+  if (CXXGlobalDtorsOrStermFinalizers.empty() &&
+  PrioritizedCXXStermFinalizers.empty())
 return;
 
   llvm::FunctionType *FTy = llvm::FunctionType::get(VoidTy, false);
   const CGFunctionInfo &FI = getTypes().arrangeNullaryFunction();
 
+  // Create our global prioritized cleanup function.
+  if (!PrioritizedCXXStermFinalizers.empty()) {
+SmallVector LocalCXXStermFinalizers;
+llvm::array_pod_sort(PrioritizedCXXStermFinalizers.begin(),
+ PrioritizedCXXStermFinalizers.end());
+// Iterate over "chunks" of dtors with same priority and emit each chunk
+// into separate function. Note - everything is sorted first by priority

[PATCH] D99291: [AIX] Support init priority attribute

2021-04-08 Thread Xiangling Liao via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Xiangling_L marked an inline comment as done.
Closed by commit rGd5085617986e: [AIX] Support init priority attribute 
(authored by Xiangling_L).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99291

Files:
  clang/lib/CodeGen/CGDeclCXX.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/CodeGen/CodeGenModule.h
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGen/aix-init-priority-attribute.cpp

Index: clang/test/CodeGen/aix-init-priority-attribute.cpp
===
--- clang/test/CodeGen/aix-init-priority-attribute.cpp
+++ clang/test/CodeGen/aix-init-priority-attribute.cpp
@@ -1,19 +1,72 @@
-// RUN: not %clang_cc1 -triple powerpc-ibm-aix-xcoff -x c++ -emit-llvm < %s \
-// RUN: 2>&1 | \
+// RUN: %clang_cc1 -triple powerpc-ibm-aix-xcoff -x c++ -emit-llvm < %s | \
 // RUN:   FileCheck %s
-// RUN: not %clang_cc1 -triple powerpc64-ibm-aix-xcoff -x c++ -emit-llvm < %s \
-// RUN: 2>&1 | \
+// RUN: %clang_cc1 -triple powerpc64-ibm-aix-xcoff -x c++ -emit-llvm < %s | \
 // RUN:   FileCheck %s
 
-class test {
-  int a;
-
-public:
-  test(int c) { a = c; }
-  ~test() { a = 0; }
+struct test {
+  test() {}
+  ~test() {}
 };
 
-__attribute__((init_priority(2000)))
-test t(1);
+__attribute__((init_priority(200)))
+test t1;
+__attribute__((init_priority(200)))
+test t2;
+__attribute__((init_priority(300)))
+test t3;
+__attribute__((init_priority(150)))
+test t4;
+test t5;
+
+// CHECK: @llvm.global_ctors = appending global [4 x { i32, void ()*, i8* }] [{ i32, void ()*, i8* } { i32 150, void ()* @_GLOBAL__I_000150, i8* null }, { i32, void ()*, i8* } { i32 200, void ()* @_GLOBAL__I_000200, i8* null }, { i32, void ()*, i8* } { i32 300, void ()* @_GLOBAL__I_000300, i8* null }, { i32, void ()*, i8* } { i32 65535, void ()* @_GLOBAL__sub_I__, i8* null }]
+// CHECK: @llvm.global_dtors = appending global [4 x { i32, void ()*, i8* }] [{ i32, void ()*, i8* } { i32 150, void ()* @_GLOBAL__a_000150, i8* null }, { i32, void ()*, i8* } { i32 200, void ()* @_GLOBAL__a_000200, i8* null }, { i32, void ()*, i8* } { i32 300, void ()* @_GLOBAL__a_000300, i8* null }, { i32, void ()*, i8* } { i32 65535, void ()* @_GLOBAL__D_a, i8* null }]
+
+// CHECK: define internal void @_GLOBAL__I_000150() [[ATTR:#[0-9]+]] {
+// CHECK: entry:
+// CHECK:   call void @__cxx_global_var_init.3()
+// CHECK:   ret void
+// CHECK: }
+
+// CHECK: define internal void @_GLOBAL__I_000200() [[ATTR:#[0-9]+]] {
+// CHECK: entry:
+// CHECK:   call void @__cxx_global_var_init()
+// CHECK:   call void @__cxx_global_var_init.1()
+// CHECK:   ret void
+// CHECK: }
+
+// CHECK: define internal void @_GLOBAL__I_000300() [[ATTR:#[0-9]+]] {
+// CHECK: entry:
+// CHECK:   call void @__cxx_global_var_init.2()
+// CHECK:   ret void
+// CHECK: }
+
+// CHECK: define internal void @_GLOBAL__sub_I__() [[ATTR:#[0-9]+]] {
+// CHECK: entry:
+// CHECK:   call void @__cxx_global_var_init.4()
+// CHECK:   ret void
+// CHECK: }
+
+// CHECK: define internal void @_GLOBAL__a_000150() [[ATTR:#[0-9]+]] {
+// CHECK: entry:
+// CHECK:   call void @__finalize_t4()
+// CHECK:   ret void
+// CHECK: }
+
+// CHECK: define internal void @_GLOBAL__a_000200() [[ATTR:#[0-9]+]] {
+// CHECK: entry:
+// CHECK:   call void @__finalize_t2()
+// CHECK:   call void @__finalize_t1()
+// CHECK:   ret void
+// CHECK: }
+
+// CHECK: define internal void @_GLOBAL__a_000300() [[ATTR:#[0-9]+]] {
+// CHECK: entry:
+// CHECK:   call void @__finalize_t3()
+// CHECK:   ret void
+// CHECK: }
 
-// CHECK: fatal error: error in backend: 'init_priority' attribute is not yet supported on AIX
+// CHECK: define internal void @_GLOBAL__D_a() [[ATTR:#[0-9]+]] {
+// CHECK: entry:
+// CHECK:   call void @__finalize_t5()
+// CHECK:   ret void
+// CHECK: }
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -7926,10 +7926,6 @@
 handleVecTypeHint(S, D, AL);
 break;
   case ParsedAttr::AT_InitPriority:
-if (S.Context.getTargetInfo().getTriple().isOSAIX())
-  llvm::report_fatal_error(
-  "'init_priority' attribute is not yet supported on AIX");
-else
   handleInitPriorityAttr(S, D, AL);
 break;
   case ParsedAttr::AT_Packed:
Index: clang/lib/CodeGen/ItaniumCXXABI.cpp
===
--- clang/lib/CodeGen/ItaniumCXXABI.cpp
+++ clang/lib/CodeGen/ItaniumCXXABI.cpp
@@ -4728,16 +4728,17 @@
 
   CGF.FinishFunction();
 
-  assert(!D.getAttr() &&
- "Prioritized sinit and sterm functions are not yet supported.");
-
-  if (isTemplateInstantiation(D.getTemplateSpecializationKind()) ||
-  getContext().GetGVALinkageForVariable(&D) == GVA_DiscardableODR)
+  if (auto *IPA =

[clang] 189310a - [AMDGPU] Allow -amdgpu-unsafe-fp-atomics to ignore denorm mode

2021-04-08 Thread Stanislav Mekhanoshin via cfe-commits


Author: Stanislav Mekhanoshin
Date: 2021-04-08T12:46:36-07:00
New Revision: 189310a140fa1c33f8f4838560f567bab9e99245

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

LOG: [AMDGPU] Allow -amdgpu-unsafe-fp-atomics to ignore denorm mode

Fixes: SWDEV-274276

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

Added: 


Modified: 
clang/docs/ClangCommandLineReference.rst
llvm/lib/Target/AMDGPU/SIISelLowering.cpp
llvm/test/CodeGen/AMDGPU/fp64-atomics-gfx90a.ll
llvm/test/CodeGen/AMDGPU/global-atomics-fp.ll

Removed: 




diff  --git a/clang/docs/ClangCommandLineReference.rst 
b/clang/docs/ClangCommandLineReference.rst
index d895587c458a4..97812f2b6e29e 100644
--- a/clang/docs/ClangCommandLineReference.rst
+++ b/clang/docs/ClangCommandLineReference.rst
@@ -2997,6 +2997,10 @@ Enable threadgroup split execution mode (AMDGPU only)
 
 Specify XNACK mode (AMDGPU only)
 
+.. option:: -munsafe-fp-atomics, -mno-unsafe-fp-atomics
+
+Enable generation of unsafe floating point atomic instructions. May generate 
more efficient code, but may not respect rounding and denormal modes, and may 
give incorrect results for certain memory destinations. (AMDGPU only)
+
 ARM
 ---
 .. option:: -faapcs-bitfield-load

diff  --git a/llvm/lib/Target/AMDGPU/SIISelLowering.cpp 
b/llvm/lib/Target/AMDGPU/SIISelLowering.cpp
index e8cfca1c726e1..596612e79036e 100644
--- a/llvm/lib/Target/AMDGPU/SIISelLowering.cpp
+++ b/llvm/lib/Target/AMDGPU/SIISelLowering.cpp
@@ -12055,9 +12055,14 @@ 
SITargetLowering::shouldExpandAtomicRMWInIR(AtomicRMWInst *RMW) const {
 
 if ((AS == AMDGPUAS::GLOBAL_ADDRESS || AS == AMDGPUAS::FLAT_ADDRESS) &&
  Subtarget->hasAtomicFaddInsts()) {
-  if (!fpModeMatchesGlobalFPAtomicMode(RMW) ||
-  RMW->getFunction()->getFnAttribute("amdgpu-unsafe-fp-atomics")
-  .getValueAsString() != "true")
+  // The amdgpu-unsafe-fp-atomics attribute enables generation of unsafe
+  // floating point atomic instructions. May generate more efficient code,
+  // but may not respect rounding and denormal modes, and may give 
incorrect
+  // results for certain memory destinations.
+  if (!fpModeMatchesGlobalFPAtomicMode(RMW) &&
+  RMW->getFunction()
+  ->getFnAttribute("amdgpu-unsafe-fp-atomics")
+  .getValueAsString() != "true")
 return AtomicExpansionKind::CmpXChg;
 
   if (Subtarget->hasGFX90AInsts()) {

diff  --git a/llvm/test/CodeGen/AMDGPU/fp64-atomics-gfx90a.ll 
b/llvm/test/CodeGen/AMDGPU/fp64-atomics-gfx90a.ll
index 3047d4a3eff38..d5348038f3c3d 100644
--- a/llvm/test/CodeGen/AMDGPU/fp64-atomics-gfx90a.ll
+++ b/llvm/test/CodeGen/AMDGPU/fp64-atomics-gfx90a.ll
@@ -490,25 +490,13 @@ define amdgpu_kernel void 
@global_atomic_fadd_f64_noret_pat_flush(double addrspa
 ; GFX90A-LABEL: global_atomic_fadd_f64_noret_pat_flush:
 ; GFX90A:   ; %bb.0: ; %main_body
 ; GFX90A-NEXT:s_load_dwordx2 s[0:1], s[0:1], 0x24
-; GFX90A-NEXT:s_mov_b64 s[2:3], 0
-; GFX90A-NEXT:s_waitcnt lgkmcnt(0)
-; GFX90A-NEXT:s_load_dwordx2 s[4:5], s[0:1], 0x0
-; GFX90A-NEXT:s_waitcnt lgkmcnt(0)
-; GFX90A-NEXT:v_pk_mov_b32 v[2:3], s[4:5], s[4:5] op_sel:[0,1]
-; GFX90A-NEXT:  BB27_1: ; %atomicrmw.start
-; GFX90A-NEXT:; =>This Inner Loop Header: Depth=1
-; GFX90A-NEXT:v_mov_b32_e32 v4, 0
-; GFX90A-NEXT:v_add_f64 v[0:1], v[2:3], 4.0
+; GFX90A-NEXT:v_mov_b32_e32 v0, 0
+; GFX90A-NEXT:v_mov_b32_e32 v2, 0
+; GFX90A-NEXT:v_mov_b32_e32 v1, 0x4010
 ; GFX90A-NEXT:s_waitcnt vmcnt(0) lgkmcnt(0)
-; GFX90A-NEXT:global_atomic_cmpswap_x2 v[0:1], v4, v[0:3], s[0:1] glc
+; GFX90A-NEXT:global_atomic_add_f64 v2, v[0:1], s[0:1]
 ; GFX90A-NEXT:s_waitcnt vmcnt(0)
 ; GFX90A-NEXT:buffer_wbinvl1_vol
-; GFX90A-NEXT:v_cmp_eq_u64_e32 vcc, v[0:1], v[2:3]
-; GFX90A-NEXT:s_or_b64 s[2:3], vcc, s[2:3]
-; GFX90A-NEXT:v_pk_mov_b32 v[2:3], v[0:1], v[0:1] op_sel:[0,1]
-; GFX90A-NEXT:s_andn2_b64 exec, exec, s[2:3]
-; GFX90A-NEXT:s_cbranch_execnz BB27_1
-; GFX90A-NEXT:  ; %bb.2: ; %atomicrmw.end
 ; GFX90A-NEXT:s_endpgm
 main_body:
   %ret = atomicrmw fadd double addrspace(1)* %ptr, double 4.0 
syncscope("agent") seq_cst

diff  --git a/llvm/test/CodeGen/AMDGPU/global-atomics-fp.ll 
b/llvm/test/CodeGen/AMDGPU/global-atomics-fp.ll
index ecc914123405d..143ef2d14c3d5 100644
--- a/llvm/test/CodeGen/AMDGPU/global-atomics-fp.ll
+++ b/llvm/test/CodeGen/AMDGPU/global-atomics-fp.ll
@@ -171,26 +171,12 @@ define amdgpu_kernel void 
@global_atomic_fadd_ret_f32_ieee(float addrspace(1)* %
 ; GFX90A-LABEL: global_atomic_fadd_ret_f32_ieee:
 ; GFX90A:   ; %bb.0:
 ; GFX90A-NEXT:s_load_dwordx2 s[0:1], s[0:1], 0x24
-; GFX90A-NEXT:s_mov_b64 s[2:3], 0
-; GFX90A-NEXT:s_waitcnt

1 2 >

1 - 100 of 155 matches

Mail list logo