[PATCH] D105821: [analyzer] [WIP] Model destructor for std::unique_ptr

2021-08-16 Thread Deep Majumder via Phabricator via cfe-commits
RedDocMD updated this revision to Diff 366558.
RedDocMD added a comment.

Connecting to MallocChecker


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105821

Files:
  clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
  clang/lib/StaticAnalyzer/Core/CheckerManager.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp

Index: clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
===
--- clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
+++ clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
@@ -753,10 +753,13 @@
 *Call, *this);
 
   ExplodedNodeSet DstInvalidated;
-  StmtNodeBuilder Bldr(DstPreCall, DstInvalidated, *currBldrCtx);
-  for (ExplodedNodeSet::iterator I = DstPreCall.begin(), E = DstPreCall.end();
-   I != E; ++I)
-defaultEvalCall(Bldr, *I, *Call, CallOpts);
+  // StmtNodeBuilder Bldr(DstPreCall, DstInvalidated, *currBldrCtx);
+  // for (ExplodedNodeSet::iterator I = DstPreCall.begin(), E =
+  // DstPreCall.end();
+  //  I != E; ++I)
+  //   defaultEvalCall(Bldr, *I, *Call, CallOpts);
+  getCheckerManager().runCheckersForEvalCall(DstInvalidated, DstPreCall, *Call,
+ *this, CallOpts);
 
   getCheckerManager().runCheckersForPostCall(Dst, DstInvalidated,
  *Call, *this);
Index: clang/lib/StaticAnalyzer/Core/CheckerManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/CheckerManager.cpp
+++ clang/lib/StaticAnalyzer/Core/CheckerManager.cpp
@@ -664,14 +664,11 @@
 for (const auto &EvalCallChecker : EvalCallCheckers) {
   // TODO: Support the situation when the call doesn't correspond
   // to any Expr.
-  ProgramPoint L = ProgramPoint::getProgramPoint(
-  Call.getOriginExpr(), ProgramPoint::PostStmtKind,
-  Pred->getLocationContext(), EvalCallChecker.Checker);
   bool evaluated = false;
   { // CheckerContext generates transitions(populates checkDest) on
 // destruction, so introduce the scope to make sure it gets properly
 // populated.
-CheckerContext C(B, Eng, Pred, L);
+CheckerContext C(B, Eng, Pred, Call.getProgramPoint());
 evaluated = EvalCallChecker(Call, C);
   }
   assert(!(evaluated && anyEvaluated)
Index: clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
+++ clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
@@ -11,6 +11,7 @@
 //
 //===--===//
 
+#include "AllocationState.h"
 #include "Move.h"
 #include "SmartPtr.h"
 
@@ -46,6 +47,8 @@
   bool isBoolConversionMethod(const CallEvent &Call) const;
 
 public:
+  SmartPtrModeling(CheckerManager &ChkMgr) : ChkMgr(ChkMgr) {}
+
   // Whether the checker should model for null dereferences of smart pointers.
   DefaultBool ModelSmartPtrDereference;
   bool evalCall(const CallEvent &Call, CheckerContext &C) const;
@@ -92,6 +95,7 @@
   const CallDescription StdMakeUniqueCall{{"std", "make_unique"}};
   const CallDescription StdMakeUniqueForOverwriteCall{
   {"std", "make_unique_for_overwrite"}};
+  CheckerManager &ChkMgr;
 };
 } // end of anonymous namespace
 
@@ -139,7 +143,7 @@
 
   if (RD->getDeclName().isIdentifier()) {
 StringRef Name = RD->getName();
-return Name == "shared_ptr" || Name == "unique_ptr" || Name == "weak_ptr";
+return llvm::is_contained(STD_PTR_NAMES, Name);
   }
   return false;
 }
@@ -157,20 +161,6 @@
 } // namespace ento
 } // namespace clang
 
-// If a region is removed all of the subregions need to be removed too.
-static TrackedRegionMapTy
-removeTrackedSubregions(TrackedRegionMapTy RegionMap,
-TrackedRegionMapTy::Factory &RegionMapFactory,
-const MemRegion *Region) {
-  if (!Region)
-return RegionMap;
-  for (const auto &E : RegionMap) {
-if (E.first->isSubRegionOf(Region))
-  RegionMap = RegionMapFactory.remove(RegionMap, E.first);
-  }
-  return RegionMap;
-}
-
 static ProgramStateRef updateSwappedRegion(ProgramStateRef State,
const MemRegion *Region,
const SVal *RegionInnerPointerVal) {
@@ -275,6 +265,32 @@
  smartptr::isStdSmartPtr(Call.getArgExpr(1));
 }
 
+ProgramStateRef
+invalidateInnerPointer(const MemRegion *ThisRegion, ProgramStateRef State,
+   const CallEvent &Call, CheckerContext &C) {
+  const auto *InnerPtrVal = State->get(ThisRegion);
+  if (InnerPtrVal) {
+const auto *Sym = InnerPtrVal->getAsSymbol();
+if (Sym)
+  State = allocation_state::markReleased(State, Sym, Call.getOriginExp

[PATCH] D107900: [clang-tidy] Add a new clang-tidy check for trivially copyable types passed by const reference

2021-08-16 Thread Whisperity via Phabricator via cfe-commits
whisperity added inline comments.



Comment at: clang-tools-extra/clang-tidy/misc/PodConstRefToValueCheck.h:18-25
+/// The check detects when trivially_copyable types are passed by
+/// const-reference to a function and changes that to by value
+//
+//  RestrictToBuiltInTypes: if true (default false), restricts the check to the
+//  built-in types (int, double, etc)
+//
+//  MaxSize: int, default 16. Above this size, passing by const-reference makes





Comment at: clang-tools-extra/docs/ReleaseNotes.rst:78
+
+  Finds trivially_copyable types are passed by const-reference to a function
+  and changes that to by value





Comment at: clang-tools-extra/docs/ReleaseNotes.rst:79
+  Finds trivially_copyable types are passed by const-reference to a function
+  and changes that to by value
+





Comment at: 
clang-tools-extra/docs/clang-tidy/checks/misc-pod-const-ref-to-value.rst:7
+This check detects when ``trivially_copyable`` types are passed by 
const-reference
+to a function and changes that to by value
+





Comment at: 
clang-tools-extra/docs/clang-tidy/checks/misc-pod-const-ref-to-value.rst:9
+
+For example in the following code, it is replaced by ``void f(int i, double 
d)``
+




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

https://reviews.llvm.org/D107900

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


[clang] b8d451d - Add support of the future Debian (Debian 12 - Bookworm)

2021-08-16 Thread Sylvestre Ledru via cfe-commits

Author: Sylvestre Ledru
Date: 2021-08-16T09:11:31+02:00
New Revision: b8d451da8610f0dd3ab55289606d7f2973e708d6

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

LOG: Add support of the future Debian (Debian 12 - Bookworm)
https://wiki.debian.org/DebianBookworm

ETA: 2023

Added: 


Modified: 
clang/include/clang/Driver/Distro.h
clang/lib/Driver/Distro.cpp

Removed: 




diff  --git a/clang/include/clang/Driver/Distro.h 
b/clang/include/clang/Driver/Distro.h
index 0d2a0939639ea..d9909bcf96968 100644
--- a/clang/include/clang/Driver/Distro.h
+++ b/clang/include/clang/Driver/Distro.h
@@ -37,6 +37,7 @@ class Distro {
 DebianStretch,
 DebianBuster,
 DebianBullseye,
+DebianBookworm,
 Exherbo,
 RHEL5,
 RHEL6,
@@ -119,7 +120,7 @@ class Distro {
   bool IsOpenSUSE() const { return DistroVal == OpenSUSE; }
 
   bool IsDebian() const {
-return DistroVal >= DebianLenny && DistroVal <= DebianBullseye;
+return DistroVal >= DebianLenny && DistroVal <= DebianBookworm;
   }
 
   bool IsUbuntu() const {

diff  --git a/clang/lib/Driver/Distro.cpp b/clang/lib/Driver/Distro.cpp
index c4cf4e48b5b8d..cdb5a1725750f 100644
--- a/clang/lib/Driver/Distro.cpp
+++ b/clang/lib/Driver/Distro.cpp
@@ -150,6 +150,8 @@ static Distro::DistroType 
DetectDistro(llvm::vfs::FileSystem &VFS) {
 return Distro::DebianBuster;
   case 11:
 return Distro::DebianBullseye;
+  case 12:
+return Distro::DebianBookworm;
   default:
 return Distro::UnknownDistro;
   }
@@ -161,6 +163,7 @@ static Distro::DistroType 
DetectDistro(llvm::vfs::FileSystem &VFS) {
 .Case("stretch/sid", Distro::DebianStretch)
 .Case("buster/sid", Distro::DebianBuster)
 .Case("bullseye/sid", Distro::DebianBullseye)
+.Case("bookworm/sid", Distro::DebianBookworm)
 .Default(Distro::UnknownDistro);
   }
 



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


[PATCH] D107873: [clang-tidy] adds a const-qualified parameter check

2021-08-16 Thread Whisperity via Phabricator via cfe-commits
whisperity added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/performance/ConstParameterValueOrRef.cpp:73
+
+  const QualType &T = Param.getType();
+

QualType is small (AFAIK it's just 2 pointers), no need for a reference on 
this, it can live on the stack.



Comment at: 
clang-tools-extra/clang-tidy/performance/ConstParameterValueOrRef.cpp:92
+diag(Loc,
+ "%0 is not trivially copyable: pass by reference-to-const instead")
+<< T << Hint;

This reminds me eerily of [[ 
http://clang.llvm.org/extra/clang-tidy/checks/performance-unnecessary-value-param.html
 | performance-unnecessary-value-param ]]!



Comment at: 
clang-tools-extra/clang-tidy/performance/ConstParameterValueOrRef.cpp:57
+namespace {
+bool isSharedPtr(const QualType &T) {
+  if (auto R = T->getAsCXXRecordDecl())

cjdb wrote:
> Eugene.Zelenko wrote:
> > Please use `static`, not anonymous namespace for functions.
> Hmm... there are lots of instances of `namespace {` in clang-tidy.
Yeah, because you can't do `static class/struct X`.



Comment at: 
clang-tools-extra/clang-tidy/performance/ConstParameterValueOrRef.h:19-22
+// Checks ``const``-qualified parameters to determine if they should be passed
+// by value or by reference-to-``const`` for function definitions. Ignores
+// proper function declarations, parameters without ``const`` in their type
+// specifier, and dependent types.





Comment at: 
clang-tools-extra/docs/clang-tidy/checks/performance-const-parameter-value-or-ref.rst:59
+
+.. option:: SmallMaxSize
+

(Minor suggestion: maybe MaxSmallSize would be a better name here than 
SmallMaxSize.)



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/performance-const-parameter-value-or-ref.rst:102-103
+determine when passing by value was no longer competetive with passing by
+reference for various `boards `_. The benchmark source 
can
+be found on `Compiler Explorer `_.
+

Will GitHub and Godbolt outlive LLVM? I am not comfortable with depending on 
external sources (such as shortlinks like that `git.io` one that I was a bit 
anxious to click...) to explain decisions. I get it that the code is long to be 
put into the documentation, though... But perhaps the benchmark's tables could 
go in here, at the very bottom, as an appendix.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107873

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


[PATCH] D107719: [Clang][AST][NFC] Resolve FIXME: Remove unused QualType ElementType member from the ASTContext class.

2021-08-16 Thread Cullen Rhodes via Phabricator via cfe-commits
c-rhodes added a comment.

In D107719#2945656 , @gAlfonso-bit 
wrote:

> Not sure about the timing of base patch, but maybe this patch is also 
> candidate for llvm 13 (backport)?

What's the value in backporting it to 13? It's NFC


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

https://reviews.llvm.org/D107719

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


[PATCH] D107961: [clang-format] Distinguish K&R C function definition and attribute

2021-08-16 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added a comment.

Nit: There is something niggling in the back of my mind that this is too much 
logic here to be in parseStructuralElement that sort of suggests to me that 
this isn't the correct place to handle this.

I don't really see any other structural element being handled like this and I'm 
a little concerned that we could end up in this code for more than just 
function declarations as parseStructuralElement is called from all over the 
place.

There seems to be no reference to TT_FunctionOrDecalartionName or 
TT_StartOfName which I would normally consider to be indicators of a function. 
I think ultimately you are trying to identify a function which doesn't have 
type information as actually being a function

so I sort of feel it should be in isFunctionDeclarationName, did you consider 
that at any point? or is the problem about trying to add the newline after.

What made you decide it should always have a new line and what about 
indentation? I see alot of code on github like this?

int main(argc, argv)
int argc;
char **argv;
int main (argc, argv)
int argc;
char *argv[];
int main(argc, argv) int argc;
char** argv;
int main(argc, argv)int argc; char* argv [];
Aren't we now going to unify them around a single style?

https://github.com/search?l=C&p=99&q=%22int+main%28argc%2C+argv%29%22&type=Code


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107961

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


[PATCH] D108094: [clang-format] Improve detection of parameter declarations in K&R C

2021-08-16 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added inline comments.



Comment at: clang/lib/Format/UnwrappedLineParser.cpp:1025
   if (!isC78Type(*Tok) &&
   !Tok->isOneOf(tok::kw_register, tok::kw_struct, tok::kw_union))
 return false;

should we have test cases showing these examples?



Comment at: clang/lib/Format/UnwrappedLineParser.cpp:1029
+  if (Next->isNot(tok::star) && !Next->Tok.getIdentifierInfo())
+return false;
+

Can you add unit tests for these cases?



Comment at: clang/lib/Format/UnwrappedLineParser.cpp:1397
   assert(Position < AllTokens.size());
-  const FormatToken *Next = AllTokens[Position];
-  if (Next && Next->isOneOf(tok::l_paren, tok::semi))
-break;
-  if (isC78ParameterDecl(FormatTok)) {
+  if (isC78ParameterDecl(FormatTok, AllTokens[Position], Previous)) {
 addUnwrappedLine();

Can't next be null once again?


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

https://reviews.llvm.org/D108094

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


[PATCH] D105265: [X86] AVX512FP16 instructions enabling 3/6

2021-08-16 Thread LuoYuanke via Phabricator via cfe-commits
LuoYuanke added a comment.

Thank Craig for the clarification!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105265

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


[PATCH] D105331: [CFE][X86] Enable complex _Float16.

2021-08-16 Thread LuoYuanke via Phabricator via cfe-commits
LuoYuanke added a comment.

Could you add the linkage of ABI in the commit message?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105331

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


[PATCH] D108094: [clang-format] Improve detection of parameter declarations in K&R C

2021-08-16 Thread Owen Pan via Phabricator via cfe-commits
owenpan added inline comments.



Comment at: clang/lib/Format/UnwrappedLineParser.cpp:1025
   if (!isC78Type(*Tok) &&
   !Tok->isOneOf(tok::kw_register, tok::kw_struct, tok::kw_union))
 return false;

MyDeveloperDay wrote:
> should we have test cases showing these examples?
Probably not unless we are to include a test case for every keyword. I can add 
them if you insist.



Comment at: clang/lib/Format/UnwrappedLineParser.cpp:1029
+  if (Next->isNot(tok::star) && !Next->Tok.getIdentifierInfo())
+return false;
+

MyDeveloperDay wrote:
> Can you add unit tests for these cases?
I think the existing test cases already cover this, which is a subset of the 
previous cases (the second token can be anything but `tok::l_paren` and 
`tok::semi`)?



Comment at: clang/lib/Format/UnwrappedLineParser.cpp:1397
   assert(Position < AllTokens.size());
-  const FormatToken *Next = AllTokens[Position];
-  if (Next && Next->isOneOf(tok::l_paren, tok::semi))
-break;
-  if (isC78ParameterDecl(FormatTok)) {
+  if (isC78ParameterDecl(FormatTok, AllTokens[Position], Previous)) {
 addUnwrappedLine();

MyDeveloperDay wrote:
> Can't next be null once again?
No because `FormatTok` is not `tok::eof`. If `AllTokens[Position]` is null, it 
would be an internal error, which is asserted at the top of 
`isC78ParameterDecl()`.


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

https://reviews.llvm.org/D108094

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


[PATCH] D105331: [CFE][X86] Enable complex _Float16 support

2021-08-16 Thread LuoYuanke via Phabricator via cfe-commits
LuoYuanke accepted this revision.
LuoYuanke added a comment.
This revision is now accepted and ready to land.

LGTM, but wait 1 or 2 days to see if there is any comments from others.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105331

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


[PATCH] D108029: [clang][Codegen] Introduce the no_sanitizer_instrumentation attribute

2021-08-16 Thread Alexander Potapenko via Phabricator via cfe-commits
glider updated this revision to Diff 366570.
glider added a comment.

Renamed no_sanitizer_instrumentation to disable_sanitizer_instrumentation
Added bitcode attribute declaration and missing handling of the new attribute 
in switches.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108029

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGen/attr-no-sanitize-coverage.c
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  llvm/include/llvm/AsmParser/LLToken.h
  llvm/include/llvm/Bitcode/LLVMBitCodes.h
  llvm/include/llvm/IR/Attributes.td
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/Transforms/Utils/CodeExtractor.cpp

Index: llvm/lib/Transforms/Utils/CodeExtractor.cpp
===
--- llvm/lib/Transforms/Utils/CodeExtractor.cpp
+++ llvm/lib/Transforms/Utils/CodeExtractor.cpp
@@ -943,6 +943,7 @@
   // Those attributes should be safe to propagate to the extracted function.
   case Attribute::AlwaysInline:
   case Attribute::Cold:
+  case Attribute::DisableSanitizerInstrumentation:
   case Attribute::Hot:
   case Attribute::NoRecurse:
   case Attribute::InlineHint:
Index: llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
===
--- llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
+++ llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
@@ -628,6 +628,8 @@
 return bitc::ATTR_KIND_IN_ALLOCA;
   case Attribute::Cold:
 return bitc::ATTR_KIND_COLD;
+  case Attribute::DisableSanitizerInstrumentation:
+return bitc::ATTR_DISABLE_SANITIZER_INSTRUMENTATION;
   case Attribute::Hot:
 return bitc::ATTR_KIND_HOT;
   case Attribute::ElementType:
Index: llvm/include/llvm/IR/Attributes.td
===
--- llvm/include/llvm/IR/Attributes.td
+++ llvm/include/llvm/IR/Attributes.td
@@ -86,6 +86,9 @@
 def DereferenceableOrNull : IntAttr<"dereferenceable_or_null",
 [ParamAttr, RetAttr]>;
 
+/// Do not instrument function with sanitizers.
+def DisableSanitizerInstrumentation: EnumAttr<"disable_sanitizer_instrumentation", [FnAttr]>;
+
 /// Provide pointer element type to intrinsic.
 def ElementType : TypeAttr<"elementtype", [ParamAttr]>;
 
Index: llvm/include/llvm/Bitcode/LLVMBitCodes.h
===
--- llvm/include/llvm/Bitcode/LLVMBitCodes.h
+++ llvm/include/llvm/Bitcode/LLVMBitCodes.h
@@ -671,6 +671,7 @@
   ATTR_KIND_SWIFT_ASYNC = 75,
   ATTR_KIND_NO_SANITIZE_COVERAGE = 76,
   ATTR_KIND_ELEMENTTYPE = 77,
+  ATTR_DISABLE_SANITIZER_INSTRUMENTATION = 78,
 };
 
 enum ComdatSelectionKindCodes {
Index: llvm/include/llvm/AsmParser/LLToken.h
===
--- llvm/include/llvm/AsmParser/LLToken.h
+++ llvm/include/llvm/AsmParser/LLToken.h
@@ -190,6 +190,7 @@
   kw_convergent,
   kw_dereferenceable,
   kw_dereferenceable_or_null,
+  kw_disable_sanitizer_instrumentation,
   kw_elementtype,
   kw_inaccessiblememonly,
   kw_inaccessiblemem_or_argmemonly,
Index: clang/test/Misc/pragma-attribute-supported-attributes-list.test
===
--- clang/test/Misc/pragma-attribute-supported-attributes-list.test
+++ clang/test/Misc/pragma-attribute-supported-attributes-list.test
@@ -56,6 +56,7 @@
 // CHECK-NEXT: DLLExport (SubjectMatchRule_function, SubjectMatchRule_variable, SubjectMatchRule_record, SubjectMatchRule_objc_interface)
 // CHECK-NEXT: DLLImport (SubjectMatchRule_function, SubjectMatchRule_variable, SubjectMatchRule_record, SubjectMatchRule_objc_interface)
 // CHECK-NEXT: Destructor (SubjectMatchRule_function)
+// CHECK-NEXT: DisableSanitizerInstrumentation (SubjectMatchRule_function)
 // CHECK-NEXT: DisableTailCalls (SubjectMatchRule_function, SubjectMatchRule_objc_method)
 // CHECK-NEXT: EnableIf (SubjectMatchRule_function)
 // CHECK-NEXT: EnforceTCB (SubjectMatchRule_function)
Index: clang/test/CodeGen/attr-no-sanitize-coverage.c
===
--- /dev/null
+++ clang/test/CodeGen/attr-no-sanitize-coverage.c
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -debug-info-kind=limited %s -emit-llvm -o - | FileCheck %s
+
+void t1() __attribute__((disable_sanitizer_instrumentation)) {
+}
+// CHECK: disable_sanitizer_instrumentation
+// CHECK-NEXT: void @t1
+
+// CHECK-NOT: disable_sanitizer_instrumentation
+// CHECK: void @t2
+void t2() {
+}
Index: clang/lib/CodeGen/CodeGenFunction.h
===
--- clang/lib/CodeGen/CodeGenFunction.h
+++ clang/lib/CodeGen/CodeGenFunction.h
@@ -2286,6 +2286,10 @@
   /// instrumented with __cyg_prof

[PATCH] D107961: [clang-format] Distinguish K&R C function definition and attribute

2021-08-16 Thread Owen Pan via Phabricator via cfe-commits
owenpan added a comment.

In D107961#2946183 , @MyDeveloperDay 
wrote:

> Nit: There is something niggling in the back of my mind that this is too much 
> logic here to be in parseStructuralElement that sort of suggests to me that 
> this isn't the correct place to handle this.
>
> I don't really see any other structural element being handled like this and 
> I'm a little concerned that we could end up in this code for more than just 
> function declarations as parseStructuralElement is called from all over the 
> place.

The `IsTopLevel` and `Style.isCpp()` checks should cut it down a lot, and we 
are already doing this with `tryToParseJSFunction()` anyway.

> There seems to be no reference to TT_FunctionOrDecalartionName or 
> TT_StartOfName which I would normally consider to be indicators of a 
> function. I think ultimately you are trying to identify a function which 
> doesn't have type information as actually being a function
>
> so I sort of feel it should be in isFunctionDeclarationName, did you consider 
> that at any point? or is the problem about trying to add the newline after.

The latter although I did consider handling it in `isFunctionDeclarationName()` 
with the help of `TT_StartOfName` and `TT_FunctionOrDeclarationName`. In the 
end, I came to the conclusion that we must break the line in the unwrapped-line 
parser.

> What made you decide it should always have a new line and what about 
> indentation? I see alot of code on github like this?
>
>   int main(argc, argv)
>   int argc;
>   char **argv;
>
>   int main (argc, argv)
>   int argc;
>   char *argv[];
>
>   int main(argc, argv) int argc;
>   char** argv;
>
>   int main(argc, argv)int argc; char* argv [];
>
> Aren't we now going to unify them around a single style?
>
> https://github.com/search?l=C&p=99&q=%22int+main%28argc%2C+argv%29%22&type=Code

I only break the line. The indentation would be lost even if we didn't break 
it. For example:

  int main(argc, argv)
  int argc;
  char *argv[];

would be formatted to:

  int main(argc, argv) int argc;
  char *argv[];

which is worse than:

  int main(argc, argv)
  int argc;
  char *argv[];


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107961

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


[PATCH] D108029: [clang][Codegen] Introduce the no_sanitizer_instrumentation attribute

2021-08-16 Thread Alexander Potapenko via Phabricator via cfe-commits
glider marked 2 inline comments as done.
glider added inline comments.



Comment at: clang/include/clang/Basic/AttrDocs.td:2601-2602
+
+This is not the same as ``__attribute__((no_sanitize(...)))``, which depending
+on the tool may still insert instrumentation to prevent false positive reports.
+  }];

aaron.ballman wrote:
> melver wrote:
> > aaron.ballman wrote:
> > > glider wrote:
> > > > aaron.ballman wrote:
> > > > > Has there been agreement that this isn't actually a bug? My 
> > > > > understanding of `no_sanitize` is that it disables sanitizer support 
> > > > > for a function or global. The documentation for that attribute says:
> > > > > ```
> > > > > Use the ``no_sanitize`` attribute on a function or a global variable
> > > > > declaration to specify that a particular instrumentation or set of
> > > > > instrumentations should not be applied.
> > > > > ```
> > > > > That sure reads like "do not instrument this at all" to me, and makes 
> > > > > me think we don't need a second attribute that says "no, really, I 
> > > > > mean it this time."
> > > > No, this isn't a bug, but might need to be better clarified in the docs.
> > > > ThreadSanitizer and MemorySanitizer do insert some instrumentation into 
> > > > ignore functions to prevent false positives:
> > > > 
> > > > > ThreadSanitizer still instruments such functions to avoid false 
> > > > > positives and provide meaningful stack traces.
> > > > 
> > > > (https://clang.llvm.org/docs/ThreadSanitizer.html#attribute-no-sanitize-thread)
> > > > 
> > > > and 
> > > > 
> > > > > MemorySanitizer may still instrument such functions to avoid false 
> > > > > positives.
> > > > 
> > > > (https://clang.llvm.org/docs/MemorySanitizer.html#attribute-no-sanitize-memory)
> > > > 
> > > > This is the behavior people rely onto, although at this point I don't 
> > > > think `no_sanitize(...)` is the best name for attribute not disabling 
> > > > instrumentation completely.
> > > Thank you for the information!
> > > 
> > > Having two attributes with basically the same name to perform this 
> > > functionality is confusing because users (understandably) will reach for 
> > > the succinctly named one and make assumptions about what it does from the 
> > > name.
> > > 
> > > One possibility would be to change `no_sanitize` to take an additional 
> > > argument, as in: `__attribute__((no_sanitize(fully_disable, "thread")))`. 
> > > Perhaps another solution would be to give the proposed attribute a more 
> > > distinct name, like `disable_sanitizer_instrumentation`, 
> > > `sanitizer_instrumentation_disabled`, or something else.
> > Last I looked at `no_sanitize`, it's quite awkward that it is an attribute 
> > that accepts arguments, because it makes it very hard to query for 
> > existence of attribute additions/changes with `__has_attribute()`. Given 
> > this new attribute is meant to be semantically quite different, the cleaner 
> > and less intrusive way with that in mind is to create a new attribute. 
> > Unless of course there's a nice way to make `__has_attribute()` work.
> > 
> > Here's another suggestion for name, which actually makes the difference 
> > between `no_sanitize` and the new one obvious: 
> > `no_sanitize_any_permit_false_positives`
> > 
> > At least it would semantically tell a user what might happen, which in turn 
> > would hopefully make them avoid this attribute (also because it's hard 
> > enough to type) unless they are absolutely sure.
> > Given this new attribute is meant to be semantically quite different, the 
> > cleaner and less intrusive way with that in mind is to create a new 
> > attribute. Unless of course there's a nice way to make __has_attribute() 
> > work.
> 
> That sounds like good rationale for a separate attribute.
> 
> > Here's another suggestion for name, which actually makes the difference 
> > between no_sanitize and the new one obvious: 
> > no_sanitize_any_permit_false_positives
> >
> > At least it would semantically tell a user what might happen, which in turn 
> > would hopefully make them avoid this attribute (also because it's hard 
> > enough to type) unless they are absolutely sure.
> 
> That would certainly solve my concerns! Do you envision this being used far 
> less often than `no_sanitize`? (That's my intuition, so I'm just 
> double-checking that this isn't expected to be a popular replacement or 
> something where the long name may be really undesirable.)
Yes, right now we only want to apply this attribute to a couple of critical 
places in the Linux kernel.
Other users may pop up in e.g. other kernels (NetBSD is using KMSAN) and maybe 
userspace programs, but we don't expect it to be popular, so having a lengthy 
attribute name is fine.



Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:524
+bool CodeGenFunction::ShouldSkipSanitizerInstrumentation() {
+  if (!CurFuncDecl)
+return false;

dvyukov wrote:
> When is CurFuncDecl nullp

[PATCH] D108029: [clang][Codegen] Introduce the no_sanitizer_instrumentation attribute

2021-08-16 Thread Alexander Potapenko via Phabricator via cfe-commits
glider added a subscriber: krytarowski.
glider marked 2 inline comments as done.
glider added a comment.

+krytarowski FYI


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108029

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


[PATCH] D108109: [CodeCompletion] Provide placeholders for known attribute arguments

2021-08-16 Thread Sam McCall via Phabricator via cfe-commits
sammccall created this revision.
sammccall added a reviewer: aaron.ballman.
Herald added a subscriber: krytarowski.
sammccall requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

Completion now looks more like function/member completion:

  used
  alias(Aliasee)
  abi_tag(Tags...)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108109

Files:
  clang/include/clang/Sema/ParsedAttr.h
  clang/lib/Sema/SemaCodeComplete.cpp
  clang/test/CodeCompletion/attr.cpp
  clang/utils/TableGen/ClangAttrEmitter.cpp

Index: clang/utils/TableGen/ClangAttrEmitter.cpp
===
--- clang/utils/TableGen/ClangAttrEmitter.cpp
+++ clang/utils/TableGen/ClangAttrEmitter.cpp
@@ -3959,6 +3959,27 @@
   }
   OS << "};\n";
 }
+
+std::vector ArgNames;
+for (const auto &Arg : Attr.getValueAsListOfDefs("Args")) {
+  bool UnusedUnset;
+  if (Arg->getValueAsBitOrUnset("Fake", UnusedUnset))
+continue;
+  ArgNames.push_back(Arg->getValueAsString("Name").str());
+  for (const auto &Class : Arg->getSuperClasses()) {
+if (Class.first->getName().startswith("Variadic")) {
+  ArgNames.back().append("...");
+  break;
+}
+  }
+}
+if (!ArgNames.empty()) {
+  OS << "static constexpr const char *" << I->first << "ArgNames[] = {\n";
+  for (const auto &N : ArgNames)
+OS << '"' << N << "\",";
+  OS << "};\n";
+}
+
 OS << "struct ParsedAttrInfo" << I->first
<< " final : public ParsedAttrInfo {\n";
 OS << "  ParsedAttrInfo" << I->first << "() {\n";
@@ -3980,6 +4001,8 @@
 OS << PragmaAttributeSupport.isAttributedSupported(*I->second) << ";\n";
 if (!Spellings.empty())
   OS << "Spellings = " << I->first << "Spellings;\n";
+if (!ArgNames.empty())
+  OS << "ArgNames = " << I->first << "ArgNames;\n";
 OS << "  }\n";
 GenerateAppertainsTo(Attr, OS);
 GenerateMutualExclusionsChecks(Attr, Records, OS, MergeDeclOS, MergeStmtOS);
Index: clang/test/CodeCompletion/attr.cpp
===
--- clang/test/CodeCompletion/attr.cpp
+++ clang/test/CodeCompletion/attr.cpp
@@ -1,78 +1,80 @@
 int a [[gnu::used]];
 // RUN: %clang_cc1 -code-completion-at=%s:1:9 %s | FileCheck --check-prefix=STD %s
-// STD: COMPLETION: __carries_dependency__
-// STD-NOT: COMPLETION: __convergent__
-// STD: COMPLETION: __gnu__::__used__
-// STD-NOT: COMPLETION: __gnu__::used
-// STD-NOT: COMPLETION: __used__
-// STD: COMPLETION: _Clang::__convergent__
-// STD: COMPLETION: carries_dependency
-// STD: COMPLETION: clang::convergent
-// STD-NOT: COMPLETION: convergent
-// STD-NOT: COMPLETION: gnu::__used__
-// STD: COMPLETION: gnu::used
-// STD-NOT: COMPLETION: used
+// STD: COMPLETION: Pattern : __carries_dependency__
+// STD-NOT: COMPLETION: Pattern : __convergent__
+// STD: COMPLETION: Pattern : __gnu__::__used__
+// STD-NOT: COMPLETION: Pattern : __gnu__::used
+// STD-NOT: COMPLETION: Pattern : __used__
+// STD: COMPLETION: Pattern : _Clang::__convergent__
+// STD: COMPLETION: Pattern : carries_dependency
+// STD: COMPLETION: Pattern : clang::convergent
+// STD-NOT: COMPLETION: Pattern : convergent
+// STD-NOT: COMPLETION: Pattern : gnu::__used__
+// STD: COMPLETION: Pattern : gnu::abi_tag(<#Tags...#>)
+// STD: COMPLETION: Pattern : gnu::alias(<#Aliasee#>)
+// STD: COMPLETION: Pattern : gnu::used
+// STD-NOT: COMPLETION: Pattern : used
 // RUN: %clang_cc1 -code-completion-at=%s:1:14 %s | FileCheck --check-prefix=STD-NS %s
-// STD-NS-NOT: COMPLETION: __used__
-// STD-NS-NOT: COMPLETION: carries_dependency
-// STD-NS-NOT: COMPLETION: clang::convergent
-// STD-NS-NOT: COMPLETION: convergent
-// STD-NS-NOT: COMPLETION: gnu::used
-// STD-NS: COMPLETION: used
+// STD-NS-NOT: COMPLETION: Pattern : __used__
+// STD-NS-NOT: COMPLETION: Pattern : carries_dependency
+// STD-NS-NOT: COMPLETION: Pattern : clang::convergent
+// STD-NS-NOT: COMPLETION: Pattern : convergent
+// STD-NS-NOT: COMPLETION: Pattern : gnu::used
+// STD-NS: COMPLETION: Pattern : used
 int b [[__gnu__::used]];
-// RUN: %clang_cc1 -code-completion-at=%s:22:18 %s | FileCheck --check-prefix=STD-NSU %s
-// STD-NSU: COMPLETION: __used__
-// STD-NSU-NOT: COMPLETION: used
+// RUN: %clang_cc1 -code-completion-at=%s:24:18 %s | FileCheck --check-prefix=STD-NSU %s
+// STD-NSU: COMPLETION: Pattern : __used__
+// STD-NSU-NOT: COMPLETION: Pattern : used
 
 int c [[using gnu: used]];
-// RUN: %clang_cc1 -code-completion-at=%s:27:15 %s | FileCheck --check-prefix=STD-USING %s
+// RUN: %clang_cc1 -code-completion-at=%s:29:15 %s | FileCheck --check-prefix=STD-USING %s
 // STD-USING: COMPLETION: __gnu__
 // STD-USING: COMPLETION: _Clang
-// STD-USING-NOT: COMPLETION: carries_dependency

[PATCH] D108110: Fix LLVM_ENABLE_THREADS check from 26a92d5852b2c6bf77efd26f6c0194c913f40285

2021-08-16 Thread Alexander Richardson via Phabricator via cfe-commits
arichardson created this revision.
arichardson added reviewers: aaron.ballman, rsmith.
Herald added a subscriber: dexonsmith.
arichardson requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

We should be using #if instead of #ifdef here since LLVM_ENABLE_THREADS
is set using #cmakedefine01 so is always defined.

Since the other branch has never been used I wonder if we should just remove it 
instead?


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108110

Files:
  clang/include/clang/Basic/Stack.h


Index: clang/include/clang/Basic/Stack.h
===
--- clang/include/clang/Basic/Stack.h
+++ clang/include/clang/Basic/Stack.h
@@ -39,7 +39,7 @@
   /// is insufficient, calls Diag to emit a diagnostic before calling Fn.
   inline void runWithSufficientStackSpace(llvm::function_ref Diag,
   llvm::function_ref Fn) {
-#ifdef LLVM_ENABLE_THREADS
+#if LLVM_ENABLE_THREADS
 if (LLVM_UNLIKELY(isStackNearlyExhausted()))
   runWithSufficientStackSpaceSlow(Diag, Fn);
 else


Index: clang/include/clang/Basic/Stack.h
===
--- clang/include/clang/Basic/Stack.h
+++ clang/include/clang/Basic/Stack.h
@@ -39,7 +39,7 @@
   /// is insufficient, calls Diag to emit a diagnostic before calling Fn.
   inline void runWithSufficientStackSpace(llvm::function_ref Diag,
   llvm::function_ref Fn) {
-#ifdef LLVM_ENABLE_THREADS
+#if LLVM_ENABLE_THREADS
 if (LLVM_UNLIKELY(isStackNearlyExhausted()))
   runWithSufficientStackSpaceSlow(Diag, Fn);
 else
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 7313a6d - [CLANG][PATCH][FPEnv] Add support for option -ffp-eval-method and extend #pragma float_control similarly

2021-08-16 Thread Kazushi Marukawa via cfe-commits

Author: Kazushi (Jam) Marukawa
Date: 2021-08-16T18:34:29+09:00
New Revision: 7313a6d87c04c33f0bc67297241e33f2d82a0d5d

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

LOG: [CLANG][PATCH][FPEnv] Add support for option -ffp-eval-method and extend 
#pragma float_control similarly

Need to update a clang regression test for VE after
https://reviews.llvm.org/D93769.

Reviewed By: simoll

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

Added: 


Modified: 
clang/test/Preprocessor/init-ve.c

Removed: 




diff  --git a/clang/test/Preprocessor/init-ve.c 
b/clang/test/Preprocessor/init-ve.c
index 4686315f4ea0..b3ff47d54c13 100644
--- a/clang/test/Preprocessor/init-ve.c
+++ b/clang/test/Preprocessor/init-ve.c
@@ -32,7 +32,6 @@
 // VE:#define __FLT_DENORM_MIN__ 1.40129846e-45F
 // VE:#define __FLT_DIG__ 6
 // VE:#define __FLT_EPSILON__ 1.19209290e-7F
-// VE:#define __FLT_EVAL_METHOD__ 0
 // VE:#define __FLT_HAS_DENORM__ 1
 // VE:#define __FLT_HAS_INFINITY__ 1
 // VE:#define __FLT_HAS_QUIET_NAN__ 1



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


[PATCH] D108069: [CLANG][PATCH][FPEnv] Add support for option -ffp-eval-method and extend #pragma float_control similarly

2021-08-16 Thread Kazushi Marukawa via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG7313a6d87c04: [CLANG][PATCH][FPEnv] Add support for option 
-ffp-eval-method and extend… (authored by kaz7).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108069

Files:
  clang/test/Preprocessor/init-ve.c


Index: clang/test/Preprocessor/init-ve.c
===
--- clang/test/Preprocessor/init-ve.c
+++ clang/test/Preprocessor/init-ve.c
@@ -32,7 +32,6 @@
 // VE:#define __FLT_DENORM_MIN__ 1.40129846e-45F
 // VE:#define __FLT_DIG__ 6
 // VE:#define __FLT_EPSILON__ 1.19209290e-7F
-// VE:#define __FLT_EVAL_METHOD__ 0
 // VE:#define __FLT_HAS_DENORM__ 1
 // VE:#define __FLT_HAS_INFINITY__ 1
 // VE:#define __FLT_HAS_QUIET_NAN__ 1


Index: clang/test/Preprocessor/init-ve.c
===
--- clang/test/Preprocessor/init-ve.c
+++ clang/test/Preprocessor/init-ve.c
@@ -32,7 +32,6 @@
 // VE:#define __FLT_DENORM_MIN__ 1.40129846e-45F
 // VE:#define __FLT_DIG__ 6
 // VE:#define __FLT_EPSILON__ 1.19209290e-7F
-// VE:#define __FLT_EVAL_METHOD__ 0
 // VE:#define __FLT_HAS_DENORM__ 1
 // VE:#define __FLT_HAS_INFINITY__ 1
 // VE:#define __FLT_HAS_QUIET_NAN__ 1
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D108111: [CodeComplete] Only complete attributes that match the current LangOpts

2021-08-16 Thread Sam McCall via Phabricator via cfe-commits
sammccall created this revision.
sammccall added a reviewer: aaron.ballman.
sammccall requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108111

Files:
  clang/lib/Sema/SemaCodeComplete.cpp
  clang/test/CodeCompletion/attr.cpp


Index: clang/test/CodeCompletion/attr.cpp
===
--- clang/test/CodeCompletion/attr.cpp
+++ clang/test/CodeCompletion/attr.cpp
@@ -7,11 +7,14 @@
 // STD-NOT: COMPLETION: __used__
 // STD: COMPLETION: _Clang::__convergent__
 // STD: COMPLETION: carries_dependency
+// STD-NOT: COMPLETION: clang::called_once
 // STD: COMPLETION: clang::convergent
 // STD-NOT: COMPLETION: convergent
 // STD-NOT: COMPLETION: gnu::__used__
 // STD: COMPLETION: gnu::used
 // STD-NOT: COMPLETION: used
+// RUN: %clang_cc1 -code-completion-at=%s:1:9 -xobjective-c++ %s | FileCheck 
--check-prefix=STD-OBJC %s
+// STD-OBJC: COMPLETION: clang::called_once
 // RUN: %clang_cc1 -code-completion-at=%s:1:14 %s | FileCheck 
--check-prefix=STD-NS %s
 // STD-NS-NOT: COMPLETION: __used__
 // STD-NS-NOT: COMPLETION: carries_dependency
@@ -20,12 +23,12 @@
 // STD-NS-NOT: COMPLETION: gnu::used
 // STD-NS: COMPLETION: used
 int b [[__gnu__::used]];
-// RUN: %clang_cc1 -code-completion-at=%s:22:18 %s | FileCheck 
--check-prefix=STD-NSU %s
+// RUN: %clang_cc1 -code-completion-at=%s:25:18 %s | FileCheck 
--check-prefix=STD-NSU %s
 // STD-NSU: COMPLETION: __used__
 // STD-NSU-NOT: COMPLETION: used
 
 int c [[using gnu: used]];
-// RUN: %clang_cc1 -code-completion-at=%s:27:15 %s | FileCheck 
--check-prefix=STD-USING %s
+// RUN: %clang_cc1 -code-completion-at=%s:30:15 %s | FileCheck 
--check-prefix=STD-USING %s
 // STD-USING: COMPLETION: __gnu__
 // STD-USING: COMPLETION: _Clang
 // STD-USING-NOT: COMPLETION: carries_dependency
@@ -33,10 +36,10 @@
 // STD-USING-NOT: COMPLETION: clang::
 // STD-USING-NOT: COMPLETION: gnu::
 // STD-USING: COMPLETION: gnu
-// RUN: %clang_cc1 -code-completion-at=%s:27:20 %s | FileCheck 
--check-prefix=STD-NS %s
+// RUN: %clang_cc1 -code-completion-at=%s:30:20 %s | FileCheck 
--check-prefix=STD-NS %s
 
 int d __attribute__((used));
-// RUN: %clang_cc1 -code-completion-at=%s:38:22 %s | FileCheck 
--check-prefix=GNU %s
+// RUN: %clang_cc1 -code-completion-at=%s:41:22 %s | FileCheck 
--check-prefix=GNU %s
 // GNU: COMPLETION: __carries_dependency__
 // GNU: COMPLETION: __convergent__
 // GNU-NOT: COMPLETION: __gnu__::__used__
@@ -51,12 +54,12 @@
 #pragma clang attribute push (__attribute__((internal_linkage)), 
apply_to=variable)
 int e;
 #pragma clang attribute pop
-// RUN: %clang_cc1 -code-completion-at=%s:51:46 %s | FileCheck 
--check-prefix=PRAGMA %s
+// RUN: %clang_cc1 -code-completion-at=%s:54:46 %s | FileCheck 
--check-prefix=PRAGMA %s
 // PRAGMA: internal_linkage
 
 #ifdef MS_EXT
 int __declspec(thread) f;
-// RUN: %clang_cc1 -fms-extensions -DMS_EXT -code-completion-at=%s:58:16 %s | 
FileCheck --check-prefix=DS %s
+// RUN: %clang_cc1 -fms-extensions -DMS_EXT -code-completion-at=%s:61:16 %s | 
FileCheck --check-prefix=DS %s
 // DS-NOT: COMPLETION: __convergent__
 // DS-NOT: COMPLETION: __used__
 // DS-NOT: COMPLETION: clang::convergent
@@ -66,7 +69,7 @@
 // DS: COMPLETION: uuid
 
 [uuid("123e4567-e89b-12d3-a456-426614174000")] struct g;
-// RUN: %clang_cc1 -fms-extensions -DMS_EXT -code-completion-at=%s:68:2 %s | 
FileCheck --check-prefix=MS %s
+// RUN: %clang_cc1 -fms-extensions -DMS_EXT -code-completion-at=%s:71:2 %s | 
FileCheck --check-prefix=MS %s
 // MS-NOT: COMPLETION: __uuid__
 // MS-NOT: COMPLETION: clang::convergent
 // MS-NOT: COMPLETION: convergent
@@ -80,9 +83,9 @@
   {}
 }
 // FIXME: support for omp attributes would be nice.
-// RUN: %clang_cc1 -fopenmp -code-completion-at=%s:79:5 %s | FileCheck 
--check-prefix=OMP-NS --allow-empty %s
+// RUN: %clang_cc1 -fopenmp -code-completion-at=%s:82:5 %s | FileCheck 
--check-prefix=OMP-NS --allow-empty %s
 // OMP-NS-NOT: omp
-// RUN: %clang_cc1 -fopenmp -code-completion-at=%s:79:10 %s | FileCheck 
--check-prefix=OMP-ATTR --allow-empty %s
+// RUN: %clang_cc1 -fopenmp -code-completion-at=%s:82:10 %s | FileCheck 
--check-prefix=OMP-ATTR --allow-empty %s
 // OMP-ATTR-NOT: sequence
-// RUN: %clang_cc1 -fopenmp -code-completion-at=%s:79:19 %s | FileCheck 
--check-prefix=OMP-NESTED --allow-empty %s
+// RUN: %clang_cc1 -fopenmp -code-completion-at=%s:82:19 %s | FileCheck 
--check-prefix=OMP-NESTED --allow-empty %s
 // OMP-NESTED-NOT: directive
Index: clang/lib/Sema/SemaCodeComplete.cpp
===
--- clang/lib/Sema/SemaCodeComplete.cpp
+++ clang/lib/Sema/SemaCodeComplete.cpp
@@ -4389,7 +4389,8 @@
   auto AddCompletions = [&](const ParsedAttrInfo &A) {
 if (A.IsTargetSpecific && !A.existsInTarget(Context.getTargetInfo()

[PATCH] D108113: [C++4OpenCL] Enable -cl-std flag clc++21 as a shorthand for clc++2021

2021-08-16 Thread Justas Janickas via Phabricator via cfe-commits
Topotuna created this revision.
Topotuna added a reviewer: Anastasia.
Herald added subscribers: ldrumm, dexonsmith, dang, yaxunl.
Topotuna requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Allows `clc++21` and `CLC++21` to be used as possible options for
`-cl-std` in command line to represent C++ for OpenCL version 2021.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108113

Files:
  clang/include/clang/Basic/LangStandards.def
  clang/include/clang/Driver/Options.td
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/Driver/autocomplete.c
  clang/test/Frontend/stdlang.c


Index: clang/test/Frontend/stdlang.c
===
--- clang/test/Frontend/stdlang.c
+++ clang/test/Frontend/stdlang.c
@@ -9,6 +9,7 @@
 // RUN: %clang_cc1 -x cl -cl-std=clc++ -DOPENCL %s
 // RUN: %clang_cc1 -x cl -cl-std=clc++1.0 -DOPENCL %s
 // RUN: %clang_cc1 -x cl -cl-std=clc++2021 -DOPENCL %s
+// RUN: %clang_cc1 -x cl -cl-std=clc++21 -DOPENCL %s
 // RUN: %clang_cc1 -x cl -cl-std=CL -DOPENCL %s
 // RUN: %clang_cc1 -x cl -cl-std=CL1.1 -DOPENCL %s
 // RUN: %clang_cc1 -x cl -cl-std=CL1.2 -DOPENCL %s
@@ -17,6 +18,7 @@
 // RUN: %clang_cc1 -x cl -cl-std=CLC++ -DOPENCL %s
 // RUN: %clang_cc1 -x cl -cl-std=CLC++1.0 -DOPENCL %s
 // RUN: %clang_cc1 -x cl -cl-std=CLC++2021 -DOPENCL %s
+// RUN: %clang_cc1 -x cl -cl-std=CLC++21 -DOPENCL %s
 // RUN: not %clang_cc1 -x cl -std=c99 -DOPENCL %s 2>&1 | FileCheck 
--check-prefix=CHECK-C99 %s
 // RUN: not %clang_cc1 -x cl -cl-std=invalid -DOPENCL %s 2>&1 | FileCheck 
--check-prefix=CHECK-INVALID %s
 // CHECK-C99: error: invalid argument '-std=c99' not allowed with 'OpenCL'
Index: clang/test/Driver/autocomplete.c
===
--- clang/test/Driver/autocomplete.c
+++ clang/test/Driver/autocomplete.c
@@ -53,6 +53,8 @@
 // CLSTDALL-NEXT: CLC++1.0
 // CLSTDALL-NEXT: clc++2021
 // CLSTDALL-NEXT: CLC++2021
+// CLSTDALL-NEXT: clc++21
+// CLSTDALL-NEXT: CLC++21
 // RUN: %clang --autocomplete=-fno-sanitize-coverage=,f | FileCheck %s 
-check-prefix=FNOSANICOVER
 // FNOSANICOVER: func
 // RUN: %clang --autocomplete=-fno-sanitize-coverage= | FileCheck %s 
-check-prefix=FNOSANICOVERALL
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -3616,6 +3616,7 @@
 .Cases("clc++", "CLC++", LangStandard::lang_openclcpp10)
 .Cases("clc++1.0", "CLC++1.0", LangStandard::lang_openclcpp10)
 .Cases("clc++2021", "CLC++2021", LangStandard::lang_openclcpp2021)
+.Cases("clc++21", "CLC++21", LangStandard::lang_openclcpp2021)
 .Default(LangStandard::lang_unspecified);
 
 if (OpenCLLangStd == LangStandard::lang_unspecified) {
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -866,7 +866,7 @@
   MarshallingInfoFlag>;
 def cl_std_EQ : Joined<["-"], "cl-std=">, Group, 
Flags<[CC1Option]>,
   HelpText<"OpenCL language standard to compile for.">,
-  
Values<"cl,CL,cl1.0,CL1.0,cl1.1,CL1.1,cl1.2,CL1.2,cl2.0,CL2.0,cl3.0,CL3.0,clc++,CLC++,clc++1.0,CLC++1.0,clc++2021,CLC++2021">;
+  
Values<"cl,CL,cl1.0,CL1.0,cl1.1,CL1.1,cl1.2,CL1.2,cl2.0,CL2.0,cl3.0,CL3.0,clc++,CLC++,clc++1.0,CLC++1.0,clc++2021,CLC++2021,clc++21,CLC++21">;
 def cl_denorms_are_zero : Flag<["-"], "cl-denorms-are-zero">, 
Group,
   HelpText<"OpenCL only. Allow denormals to be flushed to zero.">;
 def cl_fp32_correctly_rounded_divide_sqrt : Flag<["-"], 
"cl-fp32-correctly-rounded-divide-sqrt">, Group, 
Flags<[CC1Option]>,
Index: clang/include/clang/Basic/LangStandards.def
===
--- clang/include/clang/Basic/LangStandards.def
+++ clang/include/clang/Basic/LangStandards.def
@@ -200,6 +200,8 @@
 LANGSTANDARD_ALIAS_DEPR(openclcpp10, "CLC++")
 LANGSTANDARD_ALIAS_DEPR(openclcpp10, "CLC++1.0")
 LANGSTANDARD_ALIAS_DEPR(openclcpp2021, "CLC++2021")
+LANGSTANDARD_ALIAS_DEPR(openclcpp2021, "clc++21")
+LANGSTANDARD_ALIAS_DEPR(openclcpp2021, "CLC++21")
 
 // CUDA
 LANGSTANDARD(cuda, "cuda", CUDA, "NVIDIA CUDA(tm)",


Index: clang/test/Frontend/stdlang.c
===
--- clang/test/Frontend/stdlang.c
+++ clang/test/Frontend/stdlang.c
@@ -9,6 +9,7 @@
 // RUN: %clang_cc1 -x cl -cl-std=clc++ -DOPENCL %s
 // RUN: %clang_cc1 -x cl -cl-std=clc++1.0 -DOPENCL %s
 // RUN: %clang_cc1 -x cl -cl-std=clc++2021 -DOPENCL %s
+// RUN: %clang_cc1 -x cl -cl-std=clc++21 -DOPENCL %s
 // RUN: %clang_cc1 -x cl -cl-std=CL -DOPENCL %s
 // RUN: %clang_cc1 -x cl -cl-std=CL1.1 -DOPENCL %s
 // RUN: %clang_cc1 -x cl -cl-std=CL1.2 -DOPENCL %s
@@ -17,6 +18,7 @@
 // RUN: %clang_cc1 -x c

[PATCH] D107719: [Clang][AST][NFC] Resolve FIXME: Remove unused QualType ElementType member from the ASTContext class.

2021-08-16 Thread Simon Pilgrim via Phabricator via cfe-commits
RKSimon added a comment.

@gAlfonso-bit Do you have commit access? I don't think there's any reason to 
merge this - it fixes no bug or regression - it's just a cleanup.


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

https://reviews.llvm.org/D107719

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


[PATCH] D106891: [Remarks] Emit optimization remarks for atomics generating CAS loop

2021-08-16 Thread Nikita Popov via Phabricator via cfe-commits
nikic added a comment.

In D106891#2945342 , @arsenm wrote:

> I don’t think constructing in the pass is the solution. Why exactly is this 
> introducing such a big slowdown?

The reason are the additional DominatorTree and LoopInfo calculations. These 
have a big impact at `O0`. These analysis calculations are caused by a 
deficiency in the legacy pass manager, which is still used for the codegen 
pipeline: Even though these analyses are only needed if diagnostic hotness is 
used, the pass manager requires them to be scheduled unconditionally.

The way to avoid this is to construct ORE without going through the pass 
manager. Grep for `OptimizationRemarkEmitter ORE` for various passes that 
already do this (though the reason is different in some cases -- there are some 
analysis preservation concerns with loop passes).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106891

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


[PATCH] D107717: [LLVM][CMake][NFC] Resolve FIXME: Rename LLVM_CMAKE_PATH to LLVM_CMAKE_DIR throughout the project

2021-08-16 Thread Alf via Phabricator via cfe-commits
gAlfonso-bit updated this revision to Diff 366497.
gAlfonso-bit added a comment.

Rebased to main


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

https://reviews.llvm.org/D107717

Files:
  clang/CMakeLists.txt
  clang/lib/Basic/CMakeLists.txt
  compiler-rt/cmake/Modules/CompilerRTMockLLVMCMakeConfig.cmake
  compiler-rt/cmake/Modules/CompilerRTUtils.cmake
  flang/CMakeLists.txt
  libcxx/cmake/Modules/HandleOutOfTreeLLVM.cmake
  libunwind/CMakeLists.txt
  lld/CMakeLists.txt
  lld/Common/CMakeLists.txt
  lldb/cmake/modules/LLDBStandalone.cmake
  lldb/source/CMakeLists.txt
  llvm/CMakeLists.txt
  llvm/include/llvm/Support/CMakeLists.txt
  runtimes/CMakeLists.txt

Index: runtimes/CMakeLists.txt
===
--- runtimes/CMakeLists.txt
+++ runtimes/CMakeLists.txt
@@ -65,7 +65,7 @@
 
 # This variable makes sure that e.g. llvm-lit is found.
 set(LLVM_MAIN_SRC_DIR ${LLVM_BUILD_MAIN_SRC_DIR})
-set(LLVM_CMAKE_PATH ${LLVM_MAIN_SRC_DIR}/cmake/modules)
+set(LLVM_CMAKE_DIR ${LLVM_MAIN_SRC_DIR}/cmake/modules)
 
 # This variable is used by individual runtimes to locate LLVM files.
 set(LLVM_PATH ${LLVM_BUILD_MAIN_SRC_DIR})
Index: llvm/include/llvm/Support/CMakeLists.txt
===
--- llvm/include/llvm/Support/CMakeLists.txt
+++ llvm/include/llvm/Support/CMakeLists.txt
@@ -3,7 +3,7 @@
 # The VC revision include that we want to generate.
 set(version_inc "${CMAKE_CURRENT_BINARY_DIR}/VCSRevision.h")
 
-set(generate_vcs_version_script "${LLVM_CMAKE_PATH}/GenerateVersionFromVCS.cmake")
+set(generate_vcs_version_script "${LLVM_CMAKE_DIR}/GenerateVersionFromVCS.cmake")
 
 if(LLVM_APPEND_VC_REV)
   set(llvm_source_dir ${LLVM_MAIN_SRC_DIR})
Index: llvm/CMakeLists.txt
===
--- llvm/CMakeLists.txt
+++ llvm/CMakeLists.txt
@@ -295,8 +295,8 @@
 set(LLVM_MAIN_INCLUDE_DIR ${LLVM_MAIN_SRC_DIR}/include ) # --includedir
 set(LLVM_BINARY_DIR   ${CMAKE_CURRENT_BINARY_DIR}  ) # --prefix
 
-# Note: LLVM_CMAKE_PATH does not include generated files
-set(LLVM_CMAKE_PATH ${LLVM_MAIN_SRC_DIR}/cmake/modules)
+# Note: LLVM_CMAKE_DIR does not include generated files
+set(LLVM_CMAKE_DIR ${LLVM_MAIN_SRC_DIR}/cmake/modules)
 set(LLVM_EXAMPLES_BINARY_DIR ${LLVM_BINARY_DIR}/examples)
 set(LLVM_INCLUDE_DIR ${CMAKE_CURRENT_BINARY_DIR}/include)
 
Index: lldb/source/CMakeLists.txt
===
--- lldb/source/CMakeLists.txt
+++ lldb/source/CMakeLists.txt
@@ -8,7 +8,7 @@
 find_first_existing_vc_file("${LLDB_SOURCE_DIR}" lldb_vc)
 
 set(version_inc "${CMAKE_CURRENT_BINARY_DIR}/VCSVersion.inc")
-set(generate_vcs_version_script "${LLVM_CMAKE_PATH}/GenerateVersionFromVCS.cmake")
+set(generate_vcs_version_script "${LLVM_CMAKE_DIR}/GenerateVersionFromVCS.cmake")
 
 if(lldb_vc AND LLVM_APPEND_VC_REV)
   set(lldb_source_dir ${LLDB_SOURCE_DIR})
Index: lldb/cmake/modules/LLDBStandalone.cmake
===
--- lldb/cmake/modules/LLDBStandalone.cmake
+++ lldb/cmake/modules/LLDBStandalone.cmake
@@ -3,8 +3,8 @@
 find_package(LLVM REQUIRED CONFIG HINTS ${LLVM_DIR} NO_CMAKE_FIND_ROOT_PATH)
 find_package(Clang REQUIRED CONFIG HINTS ${Clang_DIR} ${LLVM_DIR}/../clang NO_CMAKE_FIND_ROOT_PATH)
 
-# We set LLVM_CMAKE_PATH so that GetSVN.cmake is found correctly when building SVNVersion.inc
-set(LLVM_CMAKE_PATH ${LLVM_CMAKE_DIR} CACHE PATH "Path to LLVM CMake modules")
+# We set LLVM_CMAKE_DIR so that GetSVN.cmake is found correctly when building SVNVersion.inc
+set(LLVM_CMAKE_DIR ${LLVM_CMAKE_DIR} CACHE PATH "Path to LLVM CMake modules")
 
 set(LLVM_MAIN_SRC_DIR ${LLVM_BUILD_MAIN_SRC_DIR} CACHE PATH "Path to LLVM source tree")
 set(LLVM_MAIN_INCLUDE_DIR ${LLVM_MAIN_INCLUDE_DIR} CACHE PATH "Path to llvm/include")
Index: lld/Common/CMakeLists.txt
===
--- lld/Common/CMakeLists.txt
+++ lld/Common/CMakeLists.txt
@@ -8,7 +8,7 @@
 find_first_existing_vc_file("${LLD_SOURCE_DIR}" lld_vc)
 
 set(version_inc "${CMAKE_CURRENT_BINARY_DIR}/VCSVersion.inc")
-set(generate_vcs_version_script "${LLVM_CMAKE_PATH}/GenerateVersionFromVCS.cmake")
+set(generate_vcs_version_script "${LLVM_CMAKE_DIR}/GenerateVersionFromVCS.cmake")
 
 if(lld_vc AND LLVM_APPEND_VC_REV)
   set(lld_source_dir ${LLD_SOURCE_DIR})
Index: lld/CMakeLists.txt
===
--- lld/CMakeLists.txt
+++ lld/CMakeLists.txt
@@ -27,7 +27,7 @@
 
   list(GET LLVM_CONFIG_OUTPUT 0 OBJ_ROOT)
   list(GET LLVM_CONFIG_OUTPUT 1 MAIN_INCLUDE_DIR)
-  list(GET LLVM_CONFIG_OUTPUT 2 LLVM_CMAKE_PATH)
+  list(GET LLVM_CONFIG_OUTPUT 2 LLVM_CMAKE_DIR)
   list(GET LLVM_CONFIG_OUTPUT 3 MAIN_SRC_DIR)
 
   set(LLVM_OBJ_ROOT ${OBJ_ROOT} CACHE PATH "path to LLVM build tree")
@@ -35,14 +35,14 @@
   set(LLVM_MAIN_SRC_DIR ${MAIN_SRC_DIR} CACHE PATH 

[PATCH] D106891: [Remarks] Emit optimization remarks for atomics generating CAS loop

2021-08-16 Thread Anshil Gandhi via Phabricator via cfe-commits
gandhi21299 added a comment.

Okay, sorry about that. Thanks for reverting my commit. I will use a unique_ptr 
and wait for another approval.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106891

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


[PATCH] D106891: [Remarks] Emit optimization remarks for atomics generating CAS loop

2021-08-16 Thread Anshil Gandhi via Phabricator via cfe-commits
gandhi21299 updated this revision to Diff 366504.
gandhi21299 added a comment.

reverting type of ORE from `OptimizationRemarkEmitter * ` back to 
`std::unique_ptr ` and constructing it in 
AtomicExpand to avoid DTC and LI overhead.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106891

Files:
  clang/test/CodeGenCUDA/atomics-remarks-gfx90a.cu
  clang/test/CodeGenOpenCL/atomics-remarks-gfx90a.cl
  llvm/lib/CodeGen/AtomicExpandPass.cpp
  llvm/test/CodeGen/AArch64/O0-pipeline.ll
  llvm/test/CodeGen/AArch64/O3-pipeline.ll
  llvm/test/CodeGen/AMDGPU/atomics-remarks-gfx90a.ll
  llvm/test/CodeGen/AMDGPU/llc-pipeline.ll
  llvm/test/CodeGen/ARM/O3-pipeline.ll
  llvm/test/CodeGen/PowerPC/O3-pipeline.ll
  llvm/test/CodeGen/X86/O0-pipeline.ll
  llvm/test/CodeGen/X86/opt-pipeline.ll

Index: llvm/test/CodeGen/X86/opt-pipeline.ll
===
--- llvm/test/CodeGen/X86/opt-pipeline.ll
+++ llvm/test/CodeGen/X86/opt-pipeline.ll
@@ -16,15 +16,20 @@
 ; CHECK-NEXT: Target Pass Configuration
 ; CHECK-NEXT: Machine Module Information
 ; CHECK-NEXT: Target Transform Information
+; CHECK-NEXT: Profile summary info
 ; CHECK-NEXT: Type-Based Alias Analysis
 ; CHECK-NEXT: Scoped NoAlias Alias Analysis
 ; CHECK-NEXT: Assumption Cache Tracker
-; CHECK-NEXT: Profile summary info
 ; CHECK-NEXT: Create Garbage Collector Module Metadata
 ; CHECK-NEXT: Machine Branch Probability Analysis
 ; CHECK-NEXT:   ModulePass Manager
 ; CHECK-NEXT: Pre-ISel Intrinsic Lowering
 ; CHECK-NEXT: FunctionPass Manager
+; CHECK-NEXT:   Dominator Tree Construction
+; CHECK-NEXT:   Natural Loop Information
+; CHECK-NEXT:   Lazy Branch Probability Analysis
+; CHECK-NEXT:   Lazy Block Frequency Analysis
+; CHECK-NEXT:   Optimization Remark Emitter
 ; CHECK-NEXT:   Expand Atomic instructions
 ; CHECK-NEXT:   Lower AMX intrinsics
 ; CHECK-NEXT:   Lower AMX type for load/store
Index: llvm/test/CodeGen/X86/O0-pipeline.ll
===
--- llvm/test/CodeGen/X86/O0-pipeline.ll
+++ llvm/test/CodeGen/X86/O0-pipeline.ll
@@ -10,13 +10,18 @@
 ; CHECK-NEXT: Target Pass Configuration
 ; CHECK-NEXT: Machine Module Information
 ; CHECK-NEXT: Target Transform Information
+; CHECK-NEXT: Profile summary info
 ; CHECK-NEXT: Create Garbage Collector Module Metadata
 ; CHECK-NEXT: Assumption Cache Tracker
-; CHECK-NEXT: Profile summary info
 ; CHECK-NEXT: Machine Branch Probability Analysis
 ; CHECK-NEXT:   ModulePass Manager
 ; CHECK-NEXT: Pre-ISel Intrinsic Lowering
 ; CHECK-NEXT: FunctionPass Manager
+; CHECK-NEXT:   Dominator Tree Construction
+; CHECK-NEXT:   Natural Loop Information
+; CHECK-NEXT:   Lazy Branch Probability Analysis
+; CHECK-NEXT:   Lazy Block Frequency Analysis
+; CHECK-NEXT:   Optimization Remark Emitter
 ; CHECK-NEXT:   Expand Atomic instructions
 ; CHECK-NEXT:   Lower AMX intrinsics
 ; CHECK-NEXT:   Lower AMX type for load/store
Index: llvm/test/CodeGen/PowerPC/O3-pipeline.ll
===
--- llvm/test/CodeGen/PowerPC/O3-pipeline.ll
+++ llvm/test/CodeGen/PowerPC/O3-pipeline.ll
@@ -8,16 +8,21 @@
 ; CHECK-NEXT: Target Pass Configuration
 ; CHECK-NEXT: Machine Module Information
 ; CHECK-NEXT: Target Transform Information
+; CHECK-NEXT: Profile summary info
 ; CHECK-NEXT: Assumption Cache Tracker
 ; CHECK-NEXT: Type-Based Alias Analysis
 ; CHECK-NEXT: Scoped NoAlias Alias Analysis
-; CHECK-NEXT: Profile summary info
 ; CHECK-NEXT: Create Garbage Collector Module Metadata
 ; CHECK-NEXT: Machine Branch Probability Analysis
 ; CHECK-NEXT:   ModulePass Manager
 ; CHECK-NEXT: Pre-ISel Intrinsic Lowering
 ; CHECK-NEXT: FunctionPass Manager
 ; CHECK-NEXT:   Convert i1 constants to i32/i64 if they are returned
+; CHECK-NEXT:   Dominator Tree Construction
+; CHECK-NEXT:   Natural Loop Information
+; CHECK-NEXT:   Lazy Branch Probability Analysis
+; CHECK-NEXT:   Lazy Block Frequency Analysis
+; CHECK-NEXT:   Optimization Remark Emitter
 ; CHECK-NEXT:   Expand Atomic instructions
 ; CHECK-NEXT: PPC Lower MASS Entries
 ; CHECK-NEXT: FunctionPass Manager
@@ -206,4 +211,4 @@
 
 define void @f() {
   ret void
-}
\ No newline at end of file
+}
Index: llvm/test/CodeGen/ARM/O3-pipeline.ll
===
--- llvm/test/CodeGen/ARM/O3-pipeline.ll
+++ llvm/test/CodeGen/ARM/O3-pipeline.ll
@@ -5,6 +5,11 @@
 ; CHECK:   ModulePass Manager
 ; CHECK-NEXT:Pre-ISel Intrinsic Lowering
 ; CHECK-NEXT:FunctionPass Manager
+; CHECK-NEXT:   Dominator Tree Construction
+; CHECK-NEXT:   Natural Loop Information
+; CHECK-NEXT:   Lazy Branch Probability Analysis
+; CHECK-NEXT:   Lazy Block Frequency Analysis
+; CHECK-NEXT:   Optimization Remark Em

[PATCH] D106891: [Remarks] Emit optimization remarks for atomics generating CAS loop

2021-08-16 Thread Nikita Popov via Phabricator via cfe-commits
nikic added a comment.

You also need to drop the `getAnalysisUsage()` change, otherwise the pass 
manager will still create the ORE itself.

PS: This revision still has incorrectly configured permissions, which prevents 
me from leaving line comments. Revisions on this Phabricator instance should 
always be publicly writable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106891

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


[PATCH] D106891: [Remarks] Emit optimization remarks for atomics generating CAS loop

2021-08-16 Thread Anshil Gandhi via Phabricator via cfe-commits
gandhi21299 updated this revision to Diff 366507.
gandhi21299 added a reviewer: nikic.
gandhi21299 added a comment.

- removing analysis requirement as requested

+ nikic


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106891

Files:
  clang/test/CodeGenCUDA/atomics-remarks-gfx90a.cu
  clang/test/CodeGenOpenCL/atomics-remarks-gfx90a.cl
  llvm/lib/CodeGen/AtomicExpandPass.cpp
  llvm/test/CodeGen/AArch64/O0-pipeline.ll
  llvm/test/CodeGen/AArch64/O3-pipeline.ll
  llvm/test/CodeGen/AMDGPU/atomics-remarks-gfx90a.ll
  llvm/test/CodeGen/AMDGPU/llc-pipeline.ll
  llvm/test/CodeGen/ARM/O3-pipeline.ll
  llvm/test/CodeGen/PowerPC/O3-pipeline.ll
  llvm/test/CodeGen/X86/O0-pipeline.ll
  llvm/test/CodeGen/X86/opt-pipeline.ll

Index: llvm/test/CodeGen/X86/opt-pipeline.ll
===
--- llvm/test/CodeGen/X86/opt-pipeline.ll
+++ llvm/test/CodeGen/X86/opt-pipeline.ll
@@ -16,15 +16,20 @@
 ; CHECK-NEXT: Target Pass Configuration
 ; CHECK-NEXT: Machine Module Information
 ; CHECK-NEXT: Target Transform Information
+; CHECK-NEXT: Profile summary info
 ; CHECK-NEXT: Type-Based Alias Analysis
 ; CHECK-NEXT: Scoped NoAlias Alias Analysis
 ; CHECK-NEXT: Assumption Cache Tracker
-; CHECK-NEXT: Profile summary info
 ; CHECK-NEXT: Create Garbage Collector Module Metadata
 ; CHECK-NEXT: Machine Branch Probability Analysis
 ; CHECK-NEXT:   ModulePass Manager
 ; CHECK-NEXT: Pre-ISel Intrinsic Lowering
 ; CHECK-NEXT: FunctionPass Manager
+; CHECK-NEXT:   Dominator Tree Construction
+; CHECK-NEXT:   Natural Loop Information
+; CHECK-NEXT:   Lazy Branch Probability Analysis
+; CHECK-NEXT:   Lazy Block Frequency Analysis
+; CHECK-NEXT:   Optimization Remark Emitter
 ; CHECK-NEXT:   Expand Atomic instructions
 ; CHECK-NEXT:   Lower AMX intrinsics
 ; CHECK-NEXT:   Lower AMX type for load/store
Index: llvm/test/CodeGen/X86/O0-pipeline.ll
===
--- llvm/test/CodeGen/X86/O0-pipeline.ll
+++ llvm/test/CodeGen/X86/O0-pipeline.ll
@@ -10,13 +10,18 @@
 ; CHECK-NEXT: Target Pass Configuration
 ; CHECK-NEXT: Machine Module Information
 ; CHECK-NEXT: Target Transform Information
+; CHECK-NEXT: Profile summary info
 ; CHECK-NEXT: Create Garbage Collector Module Metadata
 ; CHECK-NEXT: Assumption Cache Tracker
-; CHECK-NEXT: Profile summary info
 ; CHECK-NEXT: Machine Branch Probability Analysis
 ; CHECK-NEXT:   ModulePass Manager
 ; CHECK-NEXT: Pre-ISel Intrinsic Lowering
 ; CHECK-NEXT: FunctionPass Manager
+; CHECK-NEXT:   Dominator Tree Construction
+; CHECK-NEXT:   Natural Loop Information
+; CHECK-NEXT:   Lazy Branch Probability Analysis
+; CHECK-NEXT:   Lazy Block Frequency Analysis
+; CHECK-NEXT:   Optimization Remark Emitter
 ; CHECK-NEXT:   Expand Atomic instructions
 ; CHECK-NEXT:   Lower AMX intrinsics
 ; CHECK-NEXT:   Lower AMX type for load/store
Index: llvm/test/CodeGen/PowerPC/O3-pipeline.ll
===
--- llvm/test/CodeGen/PowerPC/O3-pipeline.ll
+++ llvm/test/CodeGen/PowerPC/O3-pipeline.ll
@@ -8,16 +8,21 @@
 ; CHECK-NEXT: Target Pass Configuration
 ; CHECK-NEXT: Machine Module Information
 ; CHECK-NEXT: Target Transform Information
+; CHECK-NEXT: Profile summary info
 ; CHECK-NEXT: Assumption Cache Tracker
 ; CHECK-NEXT: Type-Based Alias Analysis
 ; CHECK-NEXT: Scoped NoAlias Alias Analysis
-; CHECK-NEXT: Profile summary info
 ; CHECK-NEXT: Create Garbage Collector Module Metadata
 ; CHECK-NEXT: Machine Branch Probability Analysis
 ; CHECK-NEXT:   ModulePass Manager
 ; CHECK-NEXT: Pre-ISel Intrinsic Lowering
 ; CHECK-NEXT: FunctionPass Manager
 ; CHECK-NEXT:   Convert i1 constants to i32/i64 if they are returned
+; CHECK-NEXT:   Dominator Tree Construction
+; CHECK-NEXT:   Natural Loop Information
+; CHECK-NEXT:   Lazy Branch Probability Analysis
+; CHECK-NEXT:   Lazy Block Frequency Analysis
+; CHECK-NEXT:   Optimization Remark Emitter
 ; CHECK-NEXT:   Expand Atomic instructions
 ; CHECK-NEXT: PPC Lower MASS Entries
 ; CHECK-NEXT: FunctionPass Manager
@@ -206,4 +211,4 @@
 
 define void @f() {
   ret void
-}
\ No newline at end of file
+}
Index: llvm/test/CodeGen/ARM/O3-pipeline.ll
===
--- llvm/test/CodeGen/ARM/O3-pipeline.ll
+++ llvm/test/CodeGen/ARM/O3-pipeline.ll
@@ -5,6 +5,11 @@
 ; CHECK:   ModulePass Manager
 ; CHECK-NEXT:Pre-ISel Intrinsic Lowering
 ; CHECK-NEXT:FunctionPass Manager
+; CHECK-NEXT:   Dominator Tree Construction
+; CHECK-NEXT:   Natural Loop Information
+; CHECK-NEXT:   Lazy Branch Probability Analysis
+; CHECK-NEXT:   Lazy Block Frequency Analysis
+; CHECK-NEXT:   Optimization Remark Emitter
 ; CHECK-NEXT:  Expand Atomic instructions
 ; CHECK-

[PATCH] D106891: [Remarks] Emit optimization remarks for atomics generating CAS loop

2021-08-16 Thread Anshil Gandhi via Phabricator via cfe-commits
gandhi21299 updated this revision to Diff 366514.
gandhi21299 added a comment.

- fixing breaking tests by eliminating passes that are no longer in the pass 
pipelines


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106891

Files:
  clang/test/CodeGenCUDA/atomics-remarks-gfx90a.cu
  clang/test/CodeGenOpenCL/atomics-remarks-gfx90a.cl
  llvm/lib/CodeGen/AtomicExpandPass.cpp
  llvm/test/CodeGen/AMDGPU/atomics-remarks-gfx90a.ll
  llvm/test/CodeGen/PowerPC/O3-pipeline.ll

Index: llvm/test/CodeGen/PowerPC/O3-pipeline.ll
===
--- llvm/test/CodeGen/PowerPC/O3-pipeline.ll
+++ llvm/test/CodeGen/PowerPC/O3-pipeline.ll
@@ -206,4 +206,4 @@
 
 define void @f() {
   ret void
-}
\ No newline at end of file
+}
Index: llvm/test/CodeGen/AMDGPU/atomics-remarks-gfx90a.ll
===
--- /dev/null
+++ llvm/test/CodeGen/AMDGPU/atomics-remarks-gfx90a.ll
@@ -0,0 +1,103 @@
+; RUN: llc -march=amdgcn -mcpu=gfx90a -verify-machineinstrs --pass-remarks=atomic-expand \
+; RUN:  %s -o - 2>&1 | FileCheck %s --check-prefix=GFX90A-CAS
+
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at system memory scope
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at agent memory scope
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at workgroup memory scope
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at wavefront memory scope
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at singlethread memory scope
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at one-as memory scope
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at agent-one-as memory scope
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at workgroup-one-as memory scope
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at wavefront-one-as memory scope
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at singlethread-one-as memory scope
+
+; GFX90A-CAS-LABEL: atomic_add_cas:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], v[4:5] glc
+; GFX90A-CAS: s_cbranch_execnz
+define dso_local void @atomic_add_cas(float* %p, float %q) {
+entry:
+  %ret = atomicrmw fadd float* %p, float %q monotonic, align 4
+  ret void
+}
+
+; GFX90A-CAS-LABEL: atomic_add_cas_agent:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], v[4:5] glc
+; GFX90A-CAS: s_cbranch_execnz
+define dso_local void @atomic_add_cas_agent(float* %p, float %q) {
+entry:
+  %ret = atomicrmw fadd float* %p, float %q syncscope("agent") monotonic, align 4
+  ret void
+}
+
+; GFX90A-CAS-LABEL: atomic_add_cas_workgroup:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], v[4:5] glc
+; GFX90A-CAS: s_cbranch_execnz
+define dso_local void @atomic_add_cas_workgroup(float* %p, float %q) {
+entry:
+  %ret = atomicrmw fadd float* %p, float %q syncscope("workgroup") monotonic, align 4
+  ret void
+}
+
+; GFX90A-CAS-LABEL: atomic_add_cas_wavefront:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], v[4:5] glc
+; GFX90A-CAS: s_cbranch_execnz
+define dso_local void @atomic_add_cas_wavefront(float* %p, float %q) {
+entry:
+  %ret = atomicrmw fadd float* %p, float %q syncscope("wavefront") monotonic, align 4
+  ret void
+}
+
+; GFX90A-CAS-LABEL: atomic_add_cas_singlethread:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], v[4:5] glc
+; GFX90A-CAS: s_cbranch_execnz
+define dso_local void @atomic_add_cas_singlethread(float* %p, float %q) {
+entry:
+  %ret = atomicrmw fadd float* %p, float %q syncscope("singlethread") monotonic, align 4
+  ret void
+}
+
+; GFX90A-CAS-LABEL: atomic_add_cas_one_as:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], v[4:5] glc
+; GFX90A-CAS: s_cbranch_execnz
+define dso_local void @atomic_add_cas_one_as(float* %p, float %q) {
+entry:
+  %ret = atomicrmw fadd float* %p, float %q syncscope("one-as") monotonic, align 4
+  ret void
+}
+
+; GFX90A-CAS-LABEL: atomic_add_cas_agent_one_as:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], v[4:5] glc
+; GFX90A-CAS: s_cbranch_execnz
+define dso_local void @atomic_add_cas_agent_one_as(float* %p, float %q) {
+entry:
+  %ret = atomicrmw fadd float* %p, float %q syncscope("agent-one-as") monotonic, align 4
+  ret void
+}
+
+; GFX90A-CAS-LABEL: atomic_add_cas_workgroup_one_as:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], v[4:5] glc
+; GFX90A-CAS: s_cbranch_execnz
+define dso_local void @atomic_add_cas_workgroup_one_as(float* %p, float %q) {
+entry:
+  %ret = atomicrmw fadd float* %p, float %q syncscope("workgroup-one-as") monotonic, align 4
+  ret void
+}
+
+; GFX90A-CAS-LABEL: atomic_add_cas_wavefront_one_as:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], v[4:5] glc
+; GFX90A-CAS: s

[PATCH] D106891: [Remarks] Emit optimization remarks for atomics generating CAS loop

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

Please drop a change in  PowerPC/O3 
-pipeline.ll


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106891

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


[PATCH] D106891: [Remarks] Emit optimization remarks for atomics generating CAS loop

2021-08-16 Thread Anshil Gandhi via Phabricator via cfe-commits
gandhi21299 updated this revision to Diff 366517.
gandhi21299 added a comment.

- eliminated changes in PowerPC/O3 
-pipeline.ll, as requested


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106891

Files:
  clang/test/CodeGenCUDA/atomics-remarks-gfx90a.cu
  clang/test/CodeGenOpenCL/atomics-remarks-gfx90a.cl
  llvm/lib/CodeGen/AtomicExpandPass.cpp
  llvm/test/CodeGen/AMDGPU/atomics-remarks-gfx90a.ll

Index: llvm/test/CodeGen/AMDGPU/atomics-remarks-gfx90a.ll
===
--- /dev/null
+++ llvm/test/CodeGen/AMDGPU/atomics-remarks-gfx90a.ll
@@ -0,0 +1,103 @@
+; RUN: llc -march=amdgcn -mcpu=gfx90a -verify-machineinstrs --pass-remarks=atomic-expand \
+; RUN:  %s -o - 2>&1 | FileCheck %s --check-prefix=GFX90A-CAS
+
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at system memory scope
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at agent memory scope
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at workgroup memory scope
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at wavefront memory scope
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at singlethread memory scope
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at one-as memory scope
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at agent-one-as memory scope
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at workgroup-one-as memory scope
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at wavefront-one-as memory scope
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at singlethread-one-as memory scope
+
+; GFX90A-CAS-LABEL: atomic_add_cas:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], v[4:5] glc
+; GFX90A-CAS: s_cbranch_execnz
+define dso_local void @atomic_add_cas(float* %p, float %q) {
+entry:
+  %ret = atomicrmw fadd float* %p, float %q monotonic, align 4
+  ret void
+}
+
+; GFX90A-CAS-LABEL: atomic_add_cas_agent:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], v[4:5] glc
+; GFX90A-CAS: s_cbranch_execnz
+define dso_local void @atomic_add_cas_agent(float* %p, float %q) {
+entry:
+  %ret = atomicrmw fadd float* %p, float %q syncscope("agent") monotonic, align 4
+  ret void
+}
+
+; GFX90A-CAS-LABEL: atomic_add_cas_workgroup:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], v[4:5] glc
+; GFX90A-CAS: s_cbranch_execnz
+define dso_local void @atomic_add_cas_workgroup(float* %p, float %q) {
+entry:
+  %ret = atomicrmw fadd float* %p, float %q syncscope("workgroup") monotonic, align 4
+  ret void
+}
+
+; GFX90A-CAS-LABEL: atomic_add_cas_wavefront:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], v[4:5] glc
+; GFX90A-CAS: s_cbranch_execnz
+define dso_local void @atomic_add_cas_wavefront(float* %p, float %q) {
+entry:
+  %ret = atomicrmw fadd float* %p, float %q syncscope("wavefront") monotonic, align 4
+  ret void
+}
+
+; GFX90A-CAS-LABEL: atomic_add_cas_singlethread:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], v[4:5] glc
+; GFX90A-CAS: s_cbranch_execnz
+define dso_local void @atomic_add_cas_singlethread(float* %p, float %q) {
+entry:
+  %ret = atomicrmw fadd float* %p, float %q syncscope("singlethread") monotonic, align 4
+  ret void
+}
+
+; GFX90A-CAS-LABEL: atomic_add_cas_one_as:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], v[4:5] glc
+; GFX90A-CAS: s_cbranch_execnz
+define dso_local void @atomic_add_cas_one_as(float* %p, float %q) {
+entry:
+  %ret = atomicrmw fadd float* %p, float %q syncscope("one-as") monotonic, align 4
+  ret void
+}
+
+; GFX90A-CAS-LABEL: atomic_add_cas_agent_one_as:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], v[4:5] glc
+; GFX90A-CAS: s_cbranch_execnz
+define dso_local void @atomic_add_cas_agent_one_as(float* %p, float %q) {
+entry:
+  %ret = atomicrmw fadd float* %p, float %q syncscope("agent-one-as") monotonic, align 4
+  ret void
+}
+
+; GFX90A-CAS-LABEL: atomic_add_cas_workgroup_one_as:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], v[4:5] glc
+; GFX90A-CAS: s_cbranch_execnz
+define dso_local void @atomic_add_cas_workgroup_one_as(float* %p, float %q) {
+entry:
+  %ret = atomicrmw fadd float* %p, float %q syncscope("workgroup-one-as") monotonic, align 4
+  ret void
+}
+
+; GFX90A-CAS-LABEL: atomic_add_cas_wavefront_one_as:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], v[4:5] glc
+; GFX90A-CAS: s_cbranch_execnz
+define dso_local void @atomic_add_cas_wavefront_one_as(float* %p, float %q) {
+entry:
+  %ret = atomicrmw fadd float* %p, float %q syncscope("wavefront-one-as") monotonic, align 4
+  ret void
+}
+
+; GFX90A-CAS-LABEL: atomic_add_cas_singlethread_one_as:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], 

[PATCH] D106891: [Remarks] Emit optimization remarks for atomics generating CAS loop

2021-08-16 Thread Anshil Gandhi via Phabricator via cfe-commits
gandhi21299 added a comment.

Any ideas on what could be causing the failure in windows pre-merge checks?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106891

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


[PATCH] D106891: [Remarks] Emit optimization remarks for atomics generating CAS loop

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

Not related to your patch, feel free to ignore


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106891

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


[PATCH] D106891: [Remarks] Emit optimization remarks for atomics generating CAS loop

2021-08-16 Thread Anshil Gandhi via Phabricator via cfe-commits
gandhi21299 added a comment.

Alright, please let me know if this patch is good for merge at your convenience.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106891

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


[PATCH] D107347: [Sema] haveSameParameterTypes - fix repeated isNull() test

2021-08-16 Thread Simon Pilgrim via Phabricator via cfe-commits
RKSimon added a comment.

ping - any comments?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107347

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


[PATCH] D108119: wired up standard library indexing

2021-08-16 Thread Christian KĂĽhnel via Phabricator via cfe-commits
kuhnel created this revision.
kuhnel added a reviewer: sammccall.
Herald added subscribers: usaxena95, kadircet, arphaman.
kuhnel requested review of this revision.
Herald added a project: clang-tools-extra.
Herald added a subscriber: cfe-commits.

Only plumbing code to enable standard library indexing
to enable end-to-end testing.
No changes to stdlib indexing behavior.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108119

Files:
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/tool/ClangdMain.cpp


Index: clang-tools-extra/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -484,6 +484,18 @@
 init(true),
 };
 
+opt IndexStandardLibrary{
+"index-standard-library",
+cat(Features),
+desc("Background index should always include the STL headers even if \n"
+ "not used at the moment. This will enable code completion and \n"
+ "include fixer."
+ "WARNING: This option is experimental only, and will be removed "
+ "eventually. Don't rely on it"),
+init(false),
+Hidden,
+};
+
 std::function getMemoryCleanupFunction() {
   if (!EnableMallocTrim)
 return nullptr;
@@ -912,6 +924,7 @@
   if (ForceOffsetEncoding != OffsetEncoding::UnsupportedEncoding)
 Opts.Encoding = ForceOffsetEncoding;
 
+  Opts.IndexStandardLibrary = IndexStandardLibrary;
   if (CheckFile.getNumOccurrences()) {
 llvm::SmallString<256> Path;
 if (auto Error =
Index: clang-tools-extra/clangd/ClangdServer.h
===
--- clang-tools-extra/clangd/ClangdServer.h
+++ clang-tools-extra/clangd/ClangdServer.h
@@ -167,7 +167,11 @@
 FeatureModuleSet *FeatureModules = nullptr;
 
 explicit operator TUScheduler::Options() const;
+
+// Automatically index the standard library - experimental feature
+bool IndexStandardLibrary = false;
   };
+
   // Sensible default options for use in tests.
   // Features like indexing must be enabled if desired.
   static Options optsForTest();
Index: clang-tools-extra/clangd/ClangdServer.cpp
===
--- clang-tools-extra/clangd/ClangdServer.cpp
+++ clang-tools-extra/clangd/ClangdServer.cpp
@@ -27,6 +27,7 @@
 #include "index/CanonicalIncludes.h"
 #include "index/FileIndex.h"
 #include "index/Merge.h"
+#include "index/StdLib.h"
 #include "refactor/Rename.h"
 #include "refactor/Tweak.h"
 #include "support/Logger.h"
@@ -175,6 +176,13 @@
   this->Index = Idx;
 }
   };
+  if (Opts.IndexStandardLibrary) {
+auto SLIndex = indexStandardLibrary(TFS);
+if (!SLIndex || !SLIndex->get()) {
+  log("Unable to build standard library index. Not using it.");
+}
+AddIndex(SLIndex->get());
+  }
   if (Opts.StaticIndex)
 AddIndex(Opts.StaticIndex);
   if (Opts.BackgroundIndex) {


Index: clang-tools-extra/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -484,6 +484,18 @@
 init(true),
 };
 
+opt IndexStandardLibrary{
+"index-standard-library",
+cat(Features),
+desc("Background index should always include the STL headers even if \n"
+ "not used at the moment. This will enable code completion and \n"
+ "include fixer."
+ "WARNING: This option is experimental only, and will be removed "
+ "eventually. Don't rely on it"),
+init(false),
+Hidden,
+};
+
 std::function getMemoryCleanupFunction() {
   if (!EnableMallocTrim)
 return nullptr;
@@ -912,6 +924,7 @@
   if (ForceOffsetEncoding != OffsetEncoding::UnsupportedEncoding)
 Opts.Encoding = ForceOffsetEncoding;
 
+  Opts.IndexStandardLibrary = IndexStandardLibrary;
   if (CheckFile.getNumOccurrences()) {
 llvm::SmallString<256> Path;
 if (auto Error =
Index: clang-tools-extra/clangd/ClangdServer.h
===
--- clang-tools-extra/clangd/ClangdServer.h
+++ clang-tools-extra/clangd/ClangdServer.h
@@ -167,7 +167,11 @@
 FeatureModuleSet *FeatureModules = nullptr;
 
 explicit operator TUScheduler::Options() const;
+
+// Automatically index the standard library - experimental feature
+bool IndexStandardLibrary = false;
   };
+
   // Sensible default options for use in tests.
   // Features like indexing must be enabled if desired.
   static Options optsForTest();
Index: clang-tools-extra/clangd/ClangdServer.cpp
===
--- clang-tools-extra/clangd/ClangdServer.cpp
+++ clang-tools-extra/clangd/ClangdServer.cpp
@@ -27,6 +27,7 @@
 #include "index/CanonicalIncludes.h"
 #include "index/FileIndex.h"
 #include "index/

[PATCH] D108029: [clang][Codegen] Introduce the no_sanitizer_instrumentation attribute

2021-08-16 Thread Alexander Potapenko via Phabricator via cfe-commits
glider updated this revision to Diff 366591.
glider added a comment.

Updated patch description


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108029

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGen/attr-no-sanitize-coverage.c
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  llvm/include/llvm/AsmParser/LLToken.h
  llvm/include/llvm/Bitcode/LLVMBitCodes.h
  llvm/include/llvm/IR/Attributes.td
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/Transforms/Utils/CodeExtractor.cpp

Index: llvm/lib/Transforms/Utils/CodeExtractor.cpp
===
--- llvm/lib/Transforms/Utils/CodeExtractor.cpp
+++ llvm/lib/Transforms/Utils/CodeExtractor.cpp
@@ -943,6 +943,7 @@
   // Those attributes should be safe to propagate to the extracted function.
   case Attribute::AlwaysInline:
   case Attribute::Cold:
+  case Attribute::DisableSanitizerInstrumentation:
   case Attribute::Hot:
   case Attribute::NoRecurse:
   case Attribute::InlineHint:
Index: llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
===
--- llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
+++ llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
@@ -628,6 +628,8 @@
 return bitc::ATTR_KIND_IN_ALLOCA;
   case Attribute::Cold:
 return bitc::ATTR_KIND_COLD;
+  case Attribute::DisableSanitizerInstrumentation:
+return bitc::ATTR_DISABLE_SANITIZER_INSTRUMENTATION;
   case Attribute::Hot:
 return bitc::ATTR_KIND_HOT;
   case Attribute::ElementType:
Index: llvm/include/llvm/IR/Attributes.td
===
--- llvm/include/llvm/IR/Attributes.td
+++ llvm/include/llvm/IR/Attributes.td
@@ -86,6 +86,9 @@
 def DereferenceableOrNull : IntAttr<"dereferenceable_or_null",
 [ParamAttr, RetAttr]>;
 
+/// Do not instrument function with sanitizers.
+def DisableSanitizerInstrumentation: EnumAttr<"disable_sanitizer_instrumentation", [FnAttr]>;
+
 /// Provide pointer element type to intrinsic.
 def ElementType : TypeAttr<"elementtype", [ParamAttr]>;
 
Index: llvm/include/llvm/Bitcode/LLVMBitCodes.h
===
--- llvm/include/llvm/Bitcode/LLVMBitCodes.h
+++ llvm/include/llvm/Bitcode/LLVMBitCodes.h
@@ -671,6 +671,7 @@
   ATTR_KIND_SWIFT_ASYNC = 75,
   ATTR_KIND_NO_SANITIZE_COVERAGE = 76,
   ATTR_KIND_ELEMENTTYPE = 77,
+  ATTR_DISABLE_SANITIZER_INSTRUMENTATION = 78,
 };
 
 enum ComdatSelectionKindCodes {
Index: llvm/include/llvm/AsmParser/LLToken.h
===
--- llvm/include/llvm/AsmParser/LLToken.h
+++ llvm/include/llvm/AsmParser/LLToken.h
@@ -190,6 +190,7 @@
   kw_convergent,
   kw_dereferenceable,
   kw_dereferenceable_or_null,
+  kw_disable_sanitizer_instrumentation,
   kw_elementtype,
   kw_inaccessiblememonly,
   kw_inaccessiblemem_or_argmemonly,
Index: clang/test/Misc/pragma-attribute-supported-attributes-list.test
===
--- clang/test/Misc/pragma-attribute-supported-attributes-list.test
+++ clang/test/Misc/pragma-attribute-supported-attributes-list.test
@@ -56,6 +56,7 @@
 // CHECK-NEXT: DLLExport (SubjectMatchRule_function, SubjectMatchRule_variable, SubjectMatchRule_record, SubjectMatchRule_objc_interface)
 // CHECK-NEXT: DLLImport (SubjectMatchRule_function, SubjectMatchRule_variable, SubjectMatchRule_record, SubjectMatchRule_objc_interface)
 // CHECK-NEXT: Destructor (SubjectMatchRule_function)
+// CHECK-NEXT: DisableSanitizerInstrumentation (SubjectMatchRule_function)
 // CHECK-NEXT: DisableTailCalls (SubjectMatchRule_function, SubjectMatchRule_objc_method)
 // CHECK-NEXT: EnableIf (SubjectMatchRule_function)
 // CHECK-NEXT: EnforceTCB (SubjectMatchRule_function)
Index: clang/test/CodeGen/attr-no-sanitize-coverage.c
===
--- /dev/null
+++ clang/test/CodeGen/attr-no-sanitize-coverage.c
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -debug-info-kind=limited %s -emit-llvm -o - | FileCheck %s
+
+void t1() __attribute__((disable_sanitizer_instrumentation)) {
+}
+// CHECK: disable_sanitizer_instrumentation
+// CHECK-NEXT: void @t1
+
+// CHECK-NOT: disable_sanitizer_instrumentation
+// CHECK: void @t2
+void t2() {
+}
Index: clang/lib/CodeGen/CodeGenFunction.h
===
--- clang/lib/CodeGen/CodeGenFunction.h
+++ clang/lib/CodeGen/CodeGenFunction.h
@@ -2286,6 +2286,10 @@
   /// instrumented with __cyg_profile_func_* calls
   bool ShouldInstrumentFunction();
 
+  /// ShouldSkipSanitizerInstrumentation - Return true if the current function
+  //

[PATCH] D108029: [clang][Codegen] Introduce the disable_sanitizer_instrumentation attribute

2021-08-16 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/Attr.td:2945
+  let Spellings = [Clang<"disable_sanitizer_instrumentation">];
+  let Subjects = SubjectList<[Function]>;
+  let Documentation = [DisableSanitizerInstrumentationDocs];

Do we want this to also appertain to `GlobalVar` and `ObjCMethod` so it's got 
the same subjects as `no_sanitize`?



Comment at: clang/include/clang/Basic/AttrDocs.td:2601-2602
+
+This is not the same as ``__attribute__((no_sanitize(...)))``, which depending
+on the tool may still insert instrumentation to prevent false positive reports.
+  }];

glider wrote:
> aaron.ballman wrote:
> > melver wrote:
> > > aaron.ballman wrote:
> > > > glider wrote:
> > > > > aaron.ballman wrote:
> > > > > > Has there been agreement that this isn't actually a bug? My 
> > > > > > understanding of `no_sanitize` is that it disables sanitizer 
> > > > > > support for a function or global. The documentation for that 
> > > > > > attribute says:
> > > > > > ```
> > > > > > Use the ``no_sanitize`` attribute on a function or a global variable
> > > > > > declaration to specify that a particular instrumentation or set of
> > > > > > instrumentations should not be applied.
> > > > > > ```
> > > > > > That sure reads like "do not instrument this at all" to me, and 
> > > > > > makes me think we don't need a second attribute that says "no, 
> > > > > > really, I mean it this time."
> > > > > No, this isn't a bug, but might need to be better clarified in the 
> > > > > docs.
> > > > > ThreadSanitizer and MemorySanitizer do insert some instrumentation 
> > > > > into ignore functions to prevent false positives:
> > > > > 
> > > > > > ThreadSanitizer still instruments such functions to avoid false 
> > > > > > positives and provide meaningful stack traces.
> > > > > 
> > > > > (https://clang.llvm.org/docs/ThreadSanitizer.html#attribute-no-sanitize-thread)
> > > > > 
> > > > > and 
> > > > > 
> > > > > > MemorySanitizer may still instrument such functions to avoid false 
> > > > > > positives.
> > > > > 
> > > > > (https://clang.llvm.org/docs/MemorySanitizer.html#attribute-no-sanitize-memory)
> > > > > 
> > > > > This is the behavior people rely onto, although at this point I don't 
> > > > > think `no_sanitize(...)` is the best name for attribute not disabling 
> > > > > instrumentation completely.
> > > > Thank you for the information!
> > > > 
> > > > Having two attributes with basically the same name to perform this 
> > > > functionality is confusing because users (understandably) will reach 
> > > > for the succinctly named one and make assumptions about what it does 
> > > > from the name.
> > > > 
> > > > One possibility would be to change `no_sanitize` to take an additional 
> > > > argument, as in: `__attribute__((no_sanitize(fully_disable, 
> > > > "thread")))`. Perhaps another solution would be to give the proposed 
> > > > attribute a more distinct name, like 
> > > > `disable_sanitizer_instrumentation`, 
> > > > `sanitizer_instrumentation_disabled`, or something else.
> > > Last I looked at `no_sanitize`, it's quite awkward that it is an 
> > > attribute that accepts arguments, because it makes it very hard to query 
> > > for existence of attribute additions/changes with `__has_attribute()`. 
> > > Given this new attribute is meant to be semantically quite different, the 
> > > cleaner and less intrusive way with that in mind is to create a new 
> > > attribute. Unless of course there's a nice way to make 
> > > `__has_attribute()` work.
> > > 
> > > Here's another suggestion for name, which actually makes the difference 
> > > between `no_sanitize` and the new one obvious: 
> > > `no_sanitize_any_permit_false_positives`
> > > 
> > > At least it would semantically tell a user what might happen, which in 
> > > turn would hopefully make them avoid this attribute (also because it's 
> > > hard enough to type) unless they are absolutely sure.
> > > Given this new attribute is meant to be semantically quite different, the 
> > > cleaner and less intrusive way with that in mind is to create a new 
> > > attribute. Unless of course there's a nice way to make __has_attribute() 
> > > work.
> > 
> > That sounds like good rationale for a separate attribute.
> > 
> > > Here's another suggestion for name, which actually makes the difference 
> > > between no_sanitize and the new one obvious: 
> > > no_sanitize_any_permit_false_positives
> > >
> > > At least it would semantically tell a user what might happen, which in 
> > > turn would hopefully make them avoid this attribute (also because it's 
> > > hard enough to type) unless they are absolutely sure.
> > 
> > That would certainly solve my concerns! Do you envision this being used far 
> > less often than `no_sanitize`? (That's my intuition, so I'm just 
> > double-checking that this isn't expected to be a popular replacement or 
> > something where the long nam

[PATCH] D105553: [analyzer][NFC] Split the main logic of NoStoreFuncVisitor to an abstract NoStateChangeVisitor class

2021-08-16 Thread KristĂłf Umann 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 rGc019142a89b4: [analyzer][NFC] Split the main logic of 
NoStoreFuncVisitor to an abstract… (authored by Szelethus).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105553

Files:
  clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitors.h
  clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp

Index: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
===
--- clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
+++ clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
@@ -343,46 +343,140 @@
   return P;
 }
 
+//===--===//
+// Implementation of NoStateChangeFuncVisitor.
+//===--===//
+
+bool NoStateChangeFuncVisitor::isModifiedInFrame(const ExplodedNode *N) {
+  const LocationContext *Ctx = N->getLocationContext();
+  const StackFrameContext *SCtx = Ctx->getStackFrame();
+  if (!FramesModifyingCalculated.count(SCtx))
+findModifyingFrames(N);
+  return FramesModifying.count(SCtx);
+}
+
+void NoStateChangeFuncVisitor::findModifyingFrames(
+const ExplodedNode *const CallExitBeginN) {
+
+  assert(CallExitBeginN->getLocationAs());
+  const ExplodedNode *LastReturnN = CallExitBeginN;
+  const StackFrameContext *const OriginalSCtx =
+  CallExitBeginN->getLocationContext()->getStackFrame();
+
+  const ExplodedNode *CurrN = CallExitBeginN;
+
+  do {
+ProgramStateRef State = CurrN->getState();
+auto CallExitLoc = CurrN->getLocationAs();
+if (CallExitLoc) {
+  LastReturnN = CurrN;
+}
+
+FramesModifyingCalculated.insert(
+CurrN->getLocationContext()->getStackFrame());
+
+if (wasModifiedBeforeCallExit(CurrN, LastReturnN)) {
+  const StackFrameContext *SCtx = CurrN->getStackFrame();
+  while (!SCtx->inTopFrame()) {
+auto p = FramesModifying.insert(SCtx);
+if (!p.second)
+  break; // Frame and all its parents already inserted.
+SCtx = SCtx->getParent()->getStackFrame();
+  }
+}
+
+// Stop calculation at the call to the current function.
+if (auto CE = CurrN->getLocationAs())
+  if (CE->getCalleeContext() == OriginalSCtx)
+break;
+
+CurrN = CurrN->getFirstPred();
+  } while (CurrN);
+}
+
+PathDiagnosticPieceRef NoStateChangeFuncVisitor::VisitNode(
+const ExplodedNode *N, BugReporterContext &BR, PathSensitiveBugReport &R) {
+
+  const LocationContext *Ctx = N->getLocationContext();
+  const StackFrameContext *SCtx = Ctx->getStackFrame();
+  ProgramStateRef State = N->getState();
+  auto CallExitLoc = N->getLocationAs();
+
+  // No diagnostic if region was modified inside the frame.
+  if (!CallExitLoc || isModifiedInFrame(N))
+return nullptr;
+
+  CallEventRef<> Call =
+  BR.getStateManager().getCallEventManager().getCaller(SCtx, State);
+
+  // Optimistically suppress uninitialized value bugs that result
+  // from system headers having a chance to initialize the value
+  // but failing to do so. It's too unlikely a system header's fault.
+  // It's much more likely a situation in which the function has a failure
+  // mode that the user decided not to check. If we want to hunt such
+  // omitted checks, we should provide an explicit function-specific note
+  // describing the precondition under which the function isn't supposed to
+  // initialize its out-parameter, and additionally check that such
+  // precondition can actually be fulfilled on the current path.
+  if (Call->isInSystemHeader()) {
+// We make an exception for system header functions that have no branches.
+// Such functions unconditionally fail to initialize the variable.
+// If they call other functions that have more paths within them,
+// this suppression would still apply when we visit these inner functions.
+// One common example of a standard function that doesn't ever initialize
+// its out parameter is operator placement new; it's up to the follow-up
+// constructor (if any) to initialize the memory.
+if (!N->getStackFrame()->getCFG()->isLinear()) {
+  static int i = 0;
+  R.markInvalid(&i, nullptr);
+}
+return nullptr;
+  }
+
+  if (const auto *MC = dyn_cast(Call)) {
+// If we failed to construct a piece for self, we still want to check
+// whether the entity of interest is in a parameter.
+if (PathDiagnosticPieceRef Piece = maybeEmitNoteForObjCSelf(R, *MC, N))
+  return Piece;
+  }
+
+  if (const auto *CCall = dyn_cast(Call)) {
+// Do not generate diagnostics for not modified parameters in
+// constructors.
+return maybeEmitNoteForCXXThis(R, *CCall, N);
+  }
+
+  return maybeEmitNoteForParameters(

[clang] c019142 - [analyzer][NFC] Split the main logic of NoStoreFuncVisitor to an abstract NoStateChangeVisitor class

2021-08-16 Thread KristĂłf Umann via cfe-commits

Author: KristĂłf Umann
Date: 2021-08-16T15:03:22+02:00
New Revision: c019142a89b477cd247434c1d8f571662d26e19d

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

LOG: [analyzer][NFC] Split the main logic of NoStoreFuncVisitor to an abstract 
NoStateChangeVisitor class

Preceding discussion on cfe-dev: 
https://lists.llvm.org/pipermail/cfe-dev/2021-June/068450.html

NoStoreFuncVisitor is a rather unique visitor. As VisitNode is invoked on most
other visitors, they are looking for the point where something changed -- change
on a value, some checker-specific GDM trait, a new constraint.
NoStoreFuncVisitor, however, looks specifically for functions that *didn't*
write to a MemRegion of interesting. Quoting from its comments:

/// Put a diagnostic on return statement of all inlined functions
/// for which  the region of interest \p RegionOfInterest was passed into,
/// but not written inside, and it has caused an undefined read or a null
/// pointer dereference outside.

It so happens that there are a number of other similar properties that are
worth checking. For instance, if some memory leaks, it might be interesting why
a function didn't take ownership of said memory:

void sink(int *P) {} // no notes

void f() {
  sink(new int(5)); // note: Memory is allocated
// Well hold on, sink() was supposed to deal with
// that, this must be a false positive...
} // warning: Potential memory leak [cplusplus.NewDeleteLeaks]

In here, the entity of interest isn't a MemRegion, but a symbol. The property
that changed here isn't a change of value, but rather liveness and GDM traits
managed by MalloChecker.

This patch moves some of the logic of NoStoreFuncVisitor to a new abstract
class, NoStateChangeFuncVisitor. This is mostly calculating and caching the
stack frames in which the entity of interest wasn't changed.

Descendants of this interface have to define 3 things:

* What constitutes as a change to an entity (this is done by overriding
wasModifiedBeforeCallExit)
* What the diagnostic message should be (this is done by overriding
maybeEmitNoteFor.*)
* What constitutes as the entity of interest being passed into the function 
(this
is also done by overriding maybeEmitNoteFor.*)

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

Added: 


Modified: 
clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitors.h
clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp

Removed: 




diff  --git 
a/clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitors.h 
b/clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitors.h
index 24cae12af24a1..139b0dcd51704 100644
--- a/clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitors.h
+++ b/clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitors.h
@@ -21,6 +21,7 @@
 #include "llvm/ADT/FoldingSet.h"
 #include "llvm/ADT/IntrusiveRefCntPtr.h"
 #include "llvm/ADT/STLExtras.h"
+#include "llvm/ADT/SmallPtrSet.h"
 #include "llvm/ADT/StringRef.h"
 #include 
 #include 
@@ -622,6 +623,84 @@ class TagVisitor : public BugReporterVisitor {
PathSensitiveBugReport &R) override;
 };
 
+class ObjCMethodCall;
+class CXXConstructorCall;
+
+/// Put a diagnostic on return statement (or on } in its absence) of all 
inlined
+/// functions for which some property remained unchanged.
+/// Resulting diagnostics may read such as "Returning without writing to X".
+///
+/// Descendants can define what a "state change is", like a change of value
+/// to a memory region, liveness, etc. For function calls where the state did
+/// not change as defined, a custom note may be constructed.
+class NoStateChangeFuncVisitor : public BugReporterVisitor {
+private:
+  /// Frames modifying the state as defined in \c wasModifiedBeforeCallExit.
+  /// This visitor generates a note only if a function does *not* change the
+  /// state that way. This information is not immediately available
+  /// by looking at the node associated with the exit from the function
+  /// (usually the return statement). To avoid recomputing the same information
+  /// many times (going up the path for each node and checking whether the
+  /// region was written into) we instead lazily compute the stack frames
+  /// along the path.
+  llvm::SmallPtrSet FramesModifying;
+  llvm::SmallPtrSet FramesModifyingCalculated;
+
+  /// Check and lazily calculate whether the state is modified in the stack
+  /// frame to which \p CallExitBeginN belongs.
+  /// The calculation is cached in FramesModifying.
+  bool isModifiedInFrame(const ExplodedNode *CallExitBeginN);
+
+  /// Write to \c FramesModifying all stack frames along the path in the 
current
+  /// stack frame which modifie

[PATCH] D108110: Fix LLVM_ENABLE_THREADS check from 26a92d5852b2c6bf77efd26f6c0194c913f40285

2021-08-16 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM!

> Since the other branch has never been used I wonder if we should just remove 
> it instead?

I don't think removing the other branch entirely is a good approach because 
then the call will silently be a noop when threads are disabled. I'd rather we 
keep the support, or turn the other branch into a loud breakage so that callers 
of it find out at compile time that it's not supported when threads are 
disabled.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108110

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


[PATCH] D104975: Implement P1949

2021-08-16 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/lib/Lex/Lexer.cpp:1622-1623
+
+  const bool isIDStart = isAllowedInitiallyIDChar(CodePoint, LangOpts);
+  const bool isIDContinue = isIDStart || isAllowedIDChar(CodePoint, LangOpts);
+





Comment at: clang/lib/Lex/Lexer.cpp:1628
+
+  const bool InvalidOnlyAtStart = IsFirst && !isIDStart && isIDContinue;
+





Comment at: clang/lib/Lex/Lexer.cpp:1687-1689
+  if (Result != llvm::conversionOK) {
 return false;
+  }





Comment at: clang/lib/Lex/Lexer.cpp:1698-1700
+// We got a unicode codepoint that is neither a space nor a
+// a valid identifier part
+// Carry on as if the codepoint was valid for recovery purposes





Comment at: clang/www/make_cxx_dr_status:139
+if dup.startswith('P'):
+  avail = 'Superseded by %s' % (dup, dup)
+  avail_style = ' class="na"'




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104975

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


[clang] 2d3668c - [analyzer] MallocChecker: Add a visitor to leave a note on functions that could have, but did not change ownership on leaked memory

2021-08-16 Thread KristĂłf Umann via cfe-commits

Author: KristĂłf Umann
Date: 2021-08-16T16:19:00+02:00
New Revision: 2d3668c997faac1f64cd3b8eb336af989069d135

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

LOG: [analyzer] MallocChecker: Add a visitor to leave a note on functions that 
could have, but did not change ownership on leaked memory

This is a rather common feedback we get from out leak checkers: bug reports are
really short, and are contain barely any usable information on what the analyzer
did to conclude that a leak actually happened.

This happens because of our bug report minimizing effort. We construct bug
reports by inspecting the ExplodedNodes that lead to the error from the bottom
up (from the error node all the way to the root of the exploded graph), and mark
entities that were the cause of a bug, or have interacted with it as
interesting. In order to make the bug report a bit less verbose, whenever we
find an entire function call (from CallEnter to CallExitEnd) that didn't talk
about any interesting entity, we prune it (click here for more info on bug
report generation). Even if the event to highlight is exactly this lack of
interaction with interesting entities.

D105553 generalized the visitor that creates notes for these cases. This patch
adds a new kind of NoStateChangeVisitor that leaves notes in functions that
took a piece of dynamically allocated memory that later leaked as parameter,
and didn't change its ownership status.

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

Added: 
clang/test/Analysis/NewDeleteLeaks.cpp

Modified: 
clang/include/clang/StaticAnalyzer/Checkers/Checkers.td
clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp
clang/test/Analysis/analyzer-config.c

Removed: 




diff  --git a/clang/include/clang/StaticAnalyzer/Checkers/Checkers.td 
b/clang/include/clang/StaticAnalyzer/Checkers/Checkers.td
index 444b00d73f0b7..125ef859d1ebb 100644
--- a/clang/include/clang/StaticAnalyzer/Checkers/Checkers.td
+++ b/clang/include/clang/StaticAnalyzer/Checkers/Checkers.td
@@ -485,7 +485,17 @@ def DynamicMemoryModeling: 
Checker<"DynamicMemoryModeling">,
   "allocating and deallocating functions are annotated with "
   "ownership_holds, ownership_takes and ownership_returns.",
   "false",
-  InAlpha>
+  InAlpha>,
+CmdLineOption
   ]>,
   Dependencies<[CStringModeling]>,
   Documentation,

diff  --git a/clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp 
b/clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp
index a6470da09c458..7db4066653cbd 100644
--- a/clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp
@@ -48,6 +48,7 @@
 #include "InterCheckerAPI.h"
 #include "clang/AST/Attr.h"
 #include "clang/AST/DeclCXX.h"
+#include "clang/AST/DeclTemplate.h"
 #include "clang/AST/Expr.h"
 #include "clang/AST/ExprCXX.h"
 #include "clang/AST/ParentMap.h"
@@ -64,12 +65,15 @@
 #include "clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/CheckerHelpers.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/DynamicExtent.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/ExplodedGraph.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/ProgramStateTrait.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/ProgramState_Fwd.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/SVals.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/StoreRef.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h"
 #include "llvm/ADT/STLExtras.h"
+#include "llvm/ADT/SetOperations.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/Support/Compiler.h"
@@ -298,6 +302,8 @@ class MallocChecker
   /// which might free a pointer are annotated.
   DefaultBool ShouldIncludeOwnershipAnnotatedFunctions;
 
+  DefaultBool ShouldRegisterNoOwnershipChangeVisitor;
+
   /// Many checkers are essentially built into this one, so enabling them will
   /// make MallocChecker perform additional modeling and reporting.
   enum CheckKind {
@@ -722,11 +728,146 @@ class MallocChecker
   bool isArgZERO_SIZE_PTR(ProgramStateRef State, CheckerContext &C,
   SVal ArgVal) const;
 };
+} // end anonymous namespace
+
+//===--===//
+// Definition of NoOwnershipChangeVisitor.
+//===--===//
+
+namespace {
+class NoOwnershipChangeVisitor final : public NoStateChangeFuncVisitor {
+  SymbolRef Sym;
+  using OwnerSet = llvm::SmallPtrSet;
+
+  // Collect which entities point

[PATCH] D99732: [AST] Pick last tentative definition as the acting definition

2021-08-16 Thread Benson Chu via Phabricator via cfe-commits
pestctrl added a comment.

@mizvekov Thanks for the help! I recently got commit access, so I think I can 
commit this myself.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99732

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


[PATCH] D108132: Add implicit map for a list item appears in a reduction clause.

2021-08-16 Thread Jennifer Yu via Phabricator via cfe-commits
jyu2 created this revision.
jyu2 added reviewers: ABataev, mikerice, jdoerfert.
jyu2 requested review of this revision.
Herald added a subscriber: sstefan1.
Herald added a project: clang.

A new rule is added in 5.0:
If a list item appears in a reduction, lastprivate or linear clause
on a combined target construct then it is treated as if it also appears
in a map clause with a map-type of tofrom.

Currently map clauses for all capture variables are added implicitly.
But missing for list item of expression for array elements or array
sections.

The change is to add implicit map clause for array of elements used in
reduction clause. Skip adding map clause if the expression is not
mappable.
Noted: For linear and lastprivate, since only variable name is
accepted, the map has been added though capture variables.

To do so:
During the mappable checking, if error, ignore diagnose and skip
adding implicit map clause.

The changes:
1> Add code to generate implicit map in ActOnOpenMPExecutableDirective,

  for omp 5.0 and up.

2> Add extra default parameter NoDiagnose in ActOnOpenMPMapClause:
Use that to skip error as well as skip adding implicit map during the
mappable checking.

Note: there are only three places need to be check for NoDiagnose. Rest
of them either the check is for < omp 5.0 or the error already generated for
reduction clause.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108132

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaOpenMP.cpp
  clang/lib/Sema/TreeTransform.h
  clang/test/OpenMP/reduction_implicit_map.cpp

Index: clang/test/OpenMP/reduction_implicit_map.cpp
===
--- /dev/null
+++ clang/test/OpenMP/reduction_implicit_map.cpp
@@ -0,0 +1,115 @@
+// RUN: %clang_cc1 -verify -fopenmp -fopenmp-cuda-mode -x c++ \
+// RUN:  -triple powerpc64le-unknown-unknown -DCUDA \
+// RUN:  -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o \
+// RUN:  %t-ppc-host.bc
+
+// RUN: %clang_cc1 -verify -fopenmp -fopenmp-cuda-mode -x c++ \
+// RUN:  -triple nvptx64-unknown-unknown -DCUA \
+// RUN:  -fopenmp-targets=nvptx64-nvidia-cuda -DCUDA -emit-llvm %s \
+// RUN:  -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc \
+// RUN:  -o - | FileCheck %s --check-prefix CHECK
+
+// RUN: %clang_cc1 -verify -fopenmp -x c++ \
+// RUN:   -triple powerpc64le-unknown-unknown -DDIAG\
+// RUN:   -fopenmp-targets=powerpc64le-ibm-linux-gnu -emit-llvm \
+// RUN:   %s -o - | FileCheck  %s \
+// RUN:   --check-prefix=CHECK1
+
+// RUN: %clang_cc1 -verify -fopenmp -x c++ \
+// RUN:   -triple i386-unknown-unknown \
+// RUN:   -fopenmp-targets=i386-pc-linux-gnu -emit-llvm \
+// RUN:   %s -o - | FileCheck  %s \
+// RUN:   --check-prefix=CHECK2
+
+// expected-no-diagnostics
+
+#if defined(CUDA)
+int foo(int n) {
+  double *e;
+  //no error and no implicit map generated for e[:1]
+  #pragma omp target parallel reduction(+: e[:1])
+*e=10;
+  ;
+  return 0;
+}
+// CHECK-NOT @.offload_maptypes
+// CHECK: call void @__kmpc_nvptx_end_reduce_nowait(
+#elif defined(DIAG)
+class S2 {
+  mutable int a;
+public:
+  S2():a(0) { }
+  S2(S2 &s2):a(s2.a) { }
+  S2 &operator +(S2 &s);
+};
+int bar() {
+ S2 o[5];
+  //no warnig "copyable and not guaranteed to be mapped correctly" and
+  //implicit map generated.
+#pragma omp target reduction(+:o[0])
+  for (int i = 0; i < 10; i++);
+  double b[10][10][10];
+  //no error no implicit map generated, the map for b is generated but not
+  //for b[0:2][2:4][1].
+#pragma omp target parallel for reduction(task, +: b[0:2][2:4][1])
+  for (long long i = 0; i < 10; ++i);
+  return 0;
+}
+// map for variable o
+// CHECK1: offload_sizes = private unnamed_addr constant [1 x i64] [i64 20]
+// CHECK1: offload_maptypes = private unnamed_addr constant [1 x i64] [i64 547]
+// map for b:
+// CHECK1: @.offload_sizes.1 = private unnamed_addr constant [1 x i64] [i64 8000]
+// CHECK1: @.offload_maptypes.2 = private unnamed_addr constant [1 x i64] [i64 547]
+#else
+// generate implicit map for array elements or array sections in reduction
+// clause. In following case: the implicit map is generate for output[0]
+// with map size 4 and output[:3] with map size 12.
+void sum(int* input, int size, int* output)
+{
+#pragma omp target teams distribute parallel for reduction(+:output[0]) map(to:input[0:size])
+for(int i=0; i VarList,
   const OMPVarListLocTy &Locs, ArrayRef UnresolvedMappers) {
-return getSema().ActOnOpenMPMapClause(MapTypeModifiers, MapTypeModifiersLoc,
-  MapperIdScopeSpec, MapperId, MapType,
-  IsMapTypeImplicit, MapLoc, ColonLoc,
-  VarList, Locs, UnresolvedMappers);
+return getSema().ActOnOpenMPMapClause(
+MapTypeModifiers, MapTypeModifiersLoc, MapperIdScopeSpec, MapperId,
+MapType, IsMapTypeImplicit, MapLoc, ColonLoc, VarList, Locs,
+/*NoD

[PATCH] D105265: [X86] AVX512FP16 instructions enabling 3/6

2021-08-16 Thread Pengfei Wang via Phabricator via cfe-commits
pengfei updated this revision to Diff 366630.
pengfei added a comment.

1. Address Yuanke's comments.
2. Add missed strict FP handling.
3. Refactor the repeated declarations for strict FP.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105265

Files:
  clang/include/clang/Basic/BuiltinsX86.def
  clang/include/clang/Basic/BuiltinsX86_64.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Headers/avx512fp16intrin.h
  clang/lib/Headers/avx512vlfp16intrin.h
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/X86/avx512fp16-builtins.c
  clang/test/CodeGen/X86/avx512vlfp16-builtins.c
  llvm/include/llvm/IR/IntrinsicsX86.td
  llvm/include/llvm/IR/RuntimeLibcalls.def
  llvm/lib/CodeGen/TargetLoweringBase.cpp
  llvm/lib/Target/X86/X86ISelLowering.cpp
  llvm/lib/Target/X86/X86InstrAVX512.td
  llvm/lib/Target/X86/X86InstrFoldTables.cpp
  llvm/lib/Target/X86/X86InstrFragmentsSIMD.td
  llvm/lib/Target/X86/X86InstrInfo.cpp
  llvm/lib/Target/X86/X86InstrSSE.td
  llvm/lib/Target/X86/X86IntrinsicsInfo.h
  llvm/test/CodeGen/X86/avx512fp16-arith-intrinsics.ll
  llvm/test/CodeGen/X86/avx512fp16-arith-vl-intrinsics.ll
  llvm/test/CodeGen/X86/avx512fp16-arith.ll
  llvm/test/CodeGen/X86/avx512fp16-cvt-ph-w-intrinsics.ll
  llvm/test/CodeGen/X86/avx512fp16-cvt-ph-w-vl-intrinsics.ll
  llvm/test/CodeGen/X86/avx512fp16-cvt.ll
  llvm/test/CodeGen/X86/avx512fp16-intrinsics.ll
  llvm/test/CodeGen/X86/avx512fp16vl-intrinsics.ll
  llvm/test/CodeGen/X86/cvt16-2.ll
  llvm/test/CodeGen/X86/fp-strict-scalar-fp16.ll
  llvm/test/CodeGen/X86/fp-strict-scalar-fptoint-fp16.ll
  llvm/test/CodeGen/X86/fp-strict-scalar-inttofp-fp16.ll
  llvm/test/CodeGen/X86/stack-folding-fp-avx512fp16vl.ll
  llvm/test/CodeGen/X86/vec-strict-128-fp16.ll
  llvm/test/CodeGen/X86/vec-strict-256-fp16.ll
  llvm/test/CodeGen/X86/vec-strict-512-fp16.ll
  llvm/test/CodeGen/X86/vec-strict-fptoint-128-fp16.ll
  llvm/test/CodeGen/X86/vec-strict-fptoint-256-fp16.ll
  llvm/test/CodeGen/X86/vec-strict-fptoint-512-fp16.ll
  llvm/test/CodeGen/X86/vec-strict-inttofp-128-fp16.ll
  llvm/test/CodeGen/X86/vec-strict-inttofp-256-fp16.ll
  llvm/test/CodeGen/X86/vec-strict-inttofp-512-fp16.ll
  llvm/test/MC/Disassembler/X86/avx512fp16.txt
  llvm/test/MC/Disassembler/X86/avx512fp16vl.txt
  llvm/test/MC/X86/avx512fp16.s
  llvm/test/MC/X86/avx512fp16vl.s
  llvm/test/MC/X86/intel-syntax-avx512fp16.s
  llvm/test/MC/X86/intel-syntax-avx512fp16vl.s

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


[PATCH] D105265: [X86] AVX512FP16 instructions enabling 3/6

2021-08-16 Thread Pengfei Wang via Phabricator via cfe-commits
pengfei added inline comments.



Comment at: llvm/lib/Target/X86/X86ISelLowering.cpp:1996
   setOperationAction(ISD::SCALAR_TO_VECTOR,   MVT::v16f16, Custom);
+  setOperationAction(ISD::SINT_TO_FP, MVT::v16i16, Legal);
+  setOperationAction(ISD::STRICT_SINT_TO_FP,  MVT::v16i16, Legal);

LuoYuanke wrote:
> How do we know it covert to v16f16? Is it possible convert to v16f32?
No. Because `v16f32` is not a legal type on X86.



Comment at: llvm/lib/Target/X86/X86ISelLowering.cpp:2054
+  // vcvttph2[u]dq v4f16 -> v4i32/64, v2f16 -> v2i32/64
+  setOperationAction(ISD::FP_TO_SINT,MVT::v2f16, Custom);
+  setOperationAction(ISD::STRICT_FP_TO_SINT, MVT::v2f16, Custom);

LuoYuanke wrote:
> Why it is not v2i16?
This is used to customize vector widen, which always check the action of result 
type.



Comment at: llvm/lib/Target/X86/X86ISelLowering.cpp:19998
+  SDLoc dl(Op);
+  SDValue InVec = DAG.getNode(ISD::SCALAR_TO_VECTOR, dl, MVT::v2i64, Src);
+  if (IsStrict) {

LuoYuanke wrote:
> Should this node be chained to Op.getOperand(0) for strict FP and convert 
> operation be chained to this node?
Not, we just chain FP nodes together.



Comment at: llvm/lib/Target/X86/X86ISelLowering.cpp:22003
+  MakeLibCallOptions CallOptions;
+  return makeLibCall(DAG, LC, VT, In, CallOptions, SDLoc(Op)).first;
+}

LuoYuanke wrote:
> InChain for strict FP?
Good catch.



Comment at: llvm/lib/Target/X86/X86ISelLowering.cpp:22014
+SDValue Res = DAG.getNode(ISD::CONCAT_VECTORS, DL, MVT::v8f16, In,
+  DAG.getUNDEF(MVT::v4f16));
+if (IsStrict)

LuoYuanke wrote:
> Is there any case for v3f16?
No, v3f16 will be widen to v4f16 first.



Comment at: llvm/lib/Target/X86/X86ISelLowering.cpp:31265
+  if (Src.getValueType().getVectorElementType() == MVT::i16)
+return;
+

LuoYuanke wrote:
> Where is vXi16 handle? Is it promoted to vXi32 finally?
No. i16 and f16 has the same element size. So we don't need to replace them 
with custom nodes.



Comment at: llvm/lib/Target/X86/X86ISelLowering.cpp:31280
+unsigned Opc = IsSigned ? X86ISD::CVTSI2P : X86ISD::CVTUI2P;
+Results.push_back(DAG.getNode(Opc, dl, MVT::v8f16, Src));
+  }

LuoYuanke wrote:
> Isn't the result type changed to v8f16? Why we don't extract sub-vector here?
Yes. The common widen code widen both src and dst elements as the same size. We 
are customizing to different size here so than we can always select the 128 bit 
instructions. Result type larger than 128 bits doesn't have this problem.



Comment at: llvm/lib/Target/X86/X86ISelLowering.cpp:49327
+  // UINT_TO_FP(vXi33~63) -> UINT_TO_FP(ZEXT(vXi33~63 to vXi64))
+  if (InVT.isVector() && VT.getVectorElementType() == MVT::f16) {
+unsigned ScalarSize = InVT.getScalarSizeInBits();

LuoYuanke wrote:
> Need to check Subtarget.hasFP16() ?
No. We can't go to here without feature FP16 enabled.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105265

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


[PATCH] D108132: Add implicit map for a list item appears in a reduction clause.

2021-08-16 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

Why it can not be performed in codegen?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108132

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


[PATCH] D108132: Add implicit map for a list item appears in a reduction clause.

2021-08-16 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

Also, would be good to see a runtime test, which reveals the issue.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108132

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


[PATCH] D107719: [Clang][AST][NFC] Resolve FIXME: Remove unused QualType ElementType member from the ASTContext class.

2021-08-16 Thread Alf via Phabricator via cfe-commits
gAlfonso-bit added a comment.

I do not have commit access.


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

https://reviews.llvm.org/D107719

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


[PATCH] D107719: [Clang][AST][NFC] Resolve FIXME: Remove unused QualType ElementType member from the ASTContext class.

2021-08-16 Thread Alf via Phabricator via cfe-commits
gAlfonso-bit added a comment.

OK then we can just merge this in main only then


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

https://reviews.llvm.org/D107719

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


[PATCH] D105821: [analyzer] [WIP] Model destructor for std::unique_ptr

2021-08-16 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment.

The code looks great, I don't see any major problems.

We still need tests, I can't stress this enough. All the real-world cornercases 
you've covered here as you updated the patch deserve a test case.

Some of these changes should probably be separated into other patches, eg. 
invalidation and pointer escape for non-destructor operations.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105821

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


[PATCH] D107873: [clang-tidy] Add 'performance-const-parameter-value-or-ref' for checking const-qualified parameters

2021-08-16 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

It seems like there may be some considerable overlap between this check and the 
one proposed in https://reviews.llvm.org/D54943. I know the other check is more 
about C++ Core Guidelines so it's not perfect overlap. But I do wonder if it'd 
make sense to combine the efforts given that the goal of both checks is to find 
const correctness issues. Do you think there's a chance for sharing 
implementation efforts here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107873

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


[PATCH] D107719: [Clang][AST][NFC] Resolve FIXME: Remove unused QualType ElementType member from the ASTContext class.

2021-08-16 Thread Alf via Phabricator via cfe-commits
gAlfonso-bit added a comment.

@RKSimon could you commit for me please?


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

https://reviews.llvm.org/D107719

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


[PATCH] D108138: [SimplifyCFG] Remove switch statements before vectorization

2021-08-16 Thread Kerry McLaughlin via Phabricator via cfe-commits
kmclaughlin created this revision.
kmclaughlin added reviewers: david-arm, fhahn, dmgreen, craig.topper, 
lebedev.ri.
Herald added subscribers: ctetreau, ormris, wenlei, steven_wu, hiraditya, 
kristof.beyls.
kmclaughlin requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

This patch adds a new function, TurnSmallSwitchIntoICmps, to SimplifyCFG
which attempts to replace small switch statements with a series of conditional
branches and compares. The purpose of this is to allow vectorization of loops
which is not possible at the moment due to the presence of switch statements.
We now run SimplifyCFG to unswitch just before the vectorizer; if we didn't
vectorize the loop then the switch is added back afterwards.

Two new options have been added, the first is `-remove-switch-blocks` which
enables/disables this feature and is on by default. The second is
`-switch-removal-threshold`, which sets the threshold number of switch cases
which we will convert to branches & compares, above which we will not attempt
to convert the switch. If unspecified, the default value used here initially is 
4.

The following tests have been added:

- SimplifyCFG/remove-switches.ll: Tests the changes to SimplifyCFG to replace 
switch statments & ensures branch weights are updated correctly if provided.
- LoopVectorize/AArch64/sve-remove-switches.ll: Tests that we can vectorize 
loops with switch statements with scalable vectors. Also tests that where 
vectorization is not possible, that the switch statement is created again.
- LoopVectorize/remove-switches.ll: Ensures that we do not vectorize the loop 
if the target doesn't support masked loads & stores, where the cost would be 
too high.

Patch originally by David Sherwood


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108138

Files:
  clang/test/Frontend/optimization-remark-analysis.c
  llvm/include/llvm/Transforms/Utils/SimplifyCFGOptions.h
  llvm/lib/Passes/PassBuilder.cpp
  llvm/lib/Transforms/Scalar/SimplifyCFGPass.cpp
  llvm/lib/Transforms/Utils/SimplifyCFG.cpp
  llvm/test/Other/new-pm-defaults.ll
  llvm/test/Other/new-pm-lto-defaults.ll
  llvm/test/Other/new-pm-thinlto-defaults.ll
  llvm/test/Other/new-pm-thinlto-postlink-pgo-defaults.ll
  llvm/test/Other/new-pm-thinlto-postlink-samplepgo-defaults.ll
  llvm/test/Transforms/LoopVectorize/AArch64/sve-remove-switches.ll
  llvm/test/Transforms/LoopVectorize/remove-switches.ll
  llvm/test/Transforms/SimplifyCFG/nomerge.ll
  llvm/test/Transforms/SimplifyCFG/remove-switches.ll

Index: llvm/test/Transforms/SimplifyCFG/remove-switches.ll
===
--- /dev/null
+++ llvm/test/Transforms/SimplifyCFG/remove-switches.ll
@@ -0,0 +1,142 @@
+; RUN: opt < %s -simplifycfg -switch-removal-threshold=4 -S | FileCheck %s
+
+define void @unswitch(i32* nocapture %a, i32* nocapture readonly %b, i32* nocapture readonly %c, i64 %N){
+; CHECK-LABEL: @unswitch(
+; CHECK-NEXT:  entry:
+; CHECK-NEXT:br label [[FOR_BODY:%.*]]
+; CHECK:   for.body:
+; CHECK-NEXT:[[I:%.*]] = phi i64 [ [[INC:%.*]], [[L4:%.*]] ], [ 0, [[ENTRY:%.*]] ]
+; CHECK-NEXT:[[ARRAYIDX:%.*]] = getelementptr inbounds i32, i32* [[A:%.*]], i64 [[I]]
+; CHECK-NEXT:[[TMP0:%.*]] = load i32, i32* [[ARRAYIDX]], align 4
+; CHECK-NEXT:[[SWITCH:%.*]] = icmp eq i32 [[TMP0]], 4
+; CHECK-NEXT:br i1 [[SWITCH]], label [[L4]], label [[FOR_BODY_SWITCH:%.*]], !prof !0
+; CHECK:   for.body.switch:
+; CHECK-NEXT:[[SWITCH1:%.*]] = icmp eq i32 [[TMP0]], 2
+; CHECK-NEXT:br i1 [[SWITCH1]], label [[L2:%.*]], label [[FOR_BODY_SWITCH2:%.*]], !prof !1
+; CHECK:   for.body.switch2:
+; CHECK-NEXT:[[SWITCH3:%.*]] = icmp eq i32 [[TMP0]], 3
+; CHECK-NEXT:br i1 [[SWITCH3]], label [[L3:%.*]], label [[FOR_BODY_SWITCH4:%.*]], !prof !2
+; CHECK:   for.body.switch4:
+; CHECK-NEXT:[[ARRAYIDX5:%.*]] = getelementptr inbounds i32, i32* [[B:%.*]], i64 [[I]]
+; CHECK-NEXT:[[TMP1:%.*]] = load i32, i32* [[ARRAYIDX5]], align 4
+; CHECK-NEXT:[[MUL:%.*]] = mul nsw i32 [[TMP1]], [[TMP0]]
+; CHECK-NEXT:[[ADD:%.*]] = add nsw i32 [[MUL]], [[TMP0]]
+; CHECK-NEXT:store i32 [[ADD]], i32* [[ARRAYIDX]], align 4
+; CHECK-NEXT:br label [[L2]]
+entry:
+  br label %for.body
+
+for.body:
+  %i = phi i64 [ %inc, %L4 ], [ 0, %entry ]
+  %arrayidx = getelementptr inbounds i32, i32* %a, i64 %i
+  %0 = load i32, i32* %arrayidx
+  switch i32 %0, label %L1 [
+  i32 4, label %L4
+  i32 2, label %L2
+  i32 3, label %L3
+  ], !prof !0
+
+L1:
+  %arrayidx5 = getelementptr inbounds i32, i32* %b, i64 %i
+  %1 = load i32, i32* %arrayidx5
+  %mul = mul nsw i32 %1, %0
+  %add = add nsw i32 %mul, %0
+  store i32 %add, i32* %arrayidx
+  br label %L2
+
+L2:
+  %2 = phi i32 [ %0, %for.body ], [ %add, %L1 ]
+  %arrayidx7 = getelementptr inbounds i32, i32* %b, i64 %i
+  %3 = load i32, i32* %arrayidx7, align 4
+  %mul9 = mul nsw i32 %3, %3
+  %add11 

[PATCH] D107933: [clang] Expose unreachable fallthrough annotation warning

2021-08-16 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM, I think this is incremental progress.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107933

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


[PATCH] D108132: Add implicit map for a list item appears in a reduction clause.

2021-08-16 Thread Jennifer Yu via Phabricator via cfe-commits
jyu2 added a comment.

Hi ABataev,
Thanks for  reviedw.

In D108132#2946927 , @ABataev wrote:

> Why it can not be performed in codegen?

I am not sure I can do that.  Do you mean when generate map adding coding code 
to look though reduction clause and generate map for it?

Here is the runtime test, I am trying to find way on how to add runtime test in 
clang.  But in my added test reduction_implicit_map.cpp, I did checked IR for 
this.

The command line: without may change:
cmplrllvm-25845>clang -fopenmp -fopenmp-targets=x86_64-pc-linux-gnu o.cpp -g
cmplrllvm-25845>./a.out
Segmentation fault (core dumped)
with may change:
cmplrllvm-25845> ./a.out
Result=5050

test


extern "C" int printf(const char *,...);
void sum(int* input, int size, int* output)
{

  #pragma omp target teams distribute parallel for reduction(+:output[0]) 
map(to:input[0:size]) //map(output[0])
  for(int i=0; ihttps://reviews.llvm.org/D108132/new/

https://reviews.llvm.org/D108132

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


[PATCH] D108132: Add implicit map for a list item appears in a reduction clause.

2021-08-16 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

In D108132#2947053 , @jyu2 wrote:

> Hi ABataev,
> Thanks for  reviedw.
>
> In D108132#2946927 , @ABataev wrote:
>
>> Why it can not be performed in codegen?
>
> I am not sure I can do that.  Do you mean when generate map adding coding 
> code to look though reduction clause and generate map for it?

Yes, exactly.

> Here is the runtime test, I am trying to find way on how to add runtime test 
> in clang.  But in my added test reduction_implicit_map.cpp, I did checked IR 
> for this.

Add it to libomptarget.

> The command line: without may change:
> cmplrllvm-25845>clang -fopenmp -fopenmp-targets=x86_64-pc-linux-gnu o.cpp -g
> cmplrllvm-25845>./a.out
> Segmentation fault (core dumped)
> with may change:
> cmplrllvm-25845> ./a.out
> Result=5050
>
> test
> 
>
> extern "C" int printf(const char *,...);
> void sum(int* input, int size, int* output)
> {
>
>   #pragma omp target teams distribute parallel for reduction(+:output[0]) 
> map(to:input[0:size]) //map(output[0])
>   for(int i=0; i   output[0] += input[i];
>
> }
> int main()
> {
>
>   const int size = 100;
>   int *array = new int[size];
>   int result = 0;
>   for (int i = 0; i < size; i++)
>   array[i] = i + 1;
>   sum(array, size, &result);
>   printf("Result=%d\n", result);
>   delete[] array;
>   return 0;
>
> }




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108132

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


[PATCH] D108132: Add implicit map for a list item appears in a reduction clause.

2021-08-16 Thread Jennifer Yu via Phabricator via cfe-commits
jyu2 added a comment.

>> I am not sure I can do that. Do you mean when generate map adding coding 
>> code to look though reduction clause and generate map for it?



> Yes, exactly.

We are missing mappable checking for example:

#pragma omp target parallel for reduction(task, +: b[0:2][2:4][1])

In this, we should not add map clause, since the section is not contiguous 
storage.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108132

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


[PATCH] D108132: Add implicit map for a list item appears in a reduction clause.

2021-08-16 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

In D108132#2947080 , @jyu2 wrote:

>>> I am not sure I can do that. Do you mean when generate map adding coding 
>>> code to look though reduction clause and generate map for it?
>
>
>
>> Yes, exactly.
>
> We are missing mappable checking for example:
>
> #pragma omp target parallel for reduction(task, +: b[0:2][2:4][1])
>
> In this, we should not add map clause, since the section is not contiguous 
> storage.

.
OK, and what's the problem to check for this in codegen? Also, we can map 
non-contiguous storage, at least in some cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108132

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


[PATCH] D107719: [Clang][AST][NFC] Resolve FIXME: Remove unused QualType ElementType member from the ASTContext class.

2021-08-16 Thread Alf via Phabricator via cfe-commits
gAlfonso-bit added a comment.

In D107719#2946159 , @c-rhodes wrote:

> In D107719#2945656 , @gAlfonso-bit 
> wrote:
>
>> Not sure about the timing of base patch, but maybe this patch is also 
>> candidate for llvm 13 (backport)?
>
> What's the value in backporting it to 13? It's NFC

The less FIXME's, the better


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

https://reviews.llvm.org/D107719

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


[PATCH] D107717: [LLVM][CMake][NFC] Resolve FIXME: Rename LLVM_CMAKE_PATH to LLVM_CMAKE_DIR throughout the project

2021-08-16 Thread Alf via Phabricator via cfe-commits
gAlfonso-bit added a comment.

@ldionne can we land this please?


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

https://reviews.llvm.org/D107717

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


[PATCH] D106030: [Clang] add support for error+warning fn attrs

2021-08-16 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/test/Sema/attr-error.c:31-32
+
+__attribute__((error("foo"))) int bad5(void);   // expected-error {{'error' 
and 'warning' attributes are not compatible}}
+__attribute__((warning("foo"))) int bad5(void); // expected-note {{conflicting 
attribute is here}}
+

I think the diagnostic order is backwards here. The first declaration is where 
I'd expect the note and the second declaration is where I'd expect the error. 
(The idea is: the first declaration adds an attribute to the decl, so the 
redeclaration is what introduces the conflict and so that's where the error 
should live.) As an example: https://godbolt.org/z/bjGTWxYvh


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106030

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


[PATCH] D108138: [SimplifyCFG] Remove switch statements before vectorization

2021-08-16 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

I'm not sure i'm sold on this, even though i'm aware that selects hurt 
vectorization.
How does this Simplify the CFG? I think it would be best to teach LV selects,
or at worst do this in LV itself.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108138

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


[PATCH] D104285: [analyzer][AST] Retrieve value by direct index from list initialization of constant array declaration.

2021-08-16 Thread Denys Petrov via Phabricator via cfe-commits
ASDenysPetrov added a comment.

In D104285#2943449 , @aaron.ballman 
wrote:

> One thing I think is worth asking in this thread is whether what you're 
> analyzing is undefined behavior?

Technically you are right. Every exit out of an array extent is UB according to 
the Standard.
But in practice we can rely on the fact that multidimensional arrays have a 
continuous layout in memory on stack.
Also every compiler treats `int[2][2]` and `int**` differently. E.g.:

  int arr[6][7];
  arr[2][3]; // *(arr + (2*7 + 3)) = *(arr + 17)
  
  int *ptr = arr;
  ptr[17]; //  *(arr + 17)
  
  int **ptr;
  ptr[2][3] // *(*(ptr + 2) + 3)

Many engineers expoit this fact and treat multidimensional arrays on stack 
through a raw pointer (`(int*)arr`). We can foresee their intentions and treat 
a multidimensional array as a single one instead of a warning about UB.

> And when you turn some of these examples into constant expressions, we reject 
> them based on the bounds. e.g., https://godbolt.org/z/nYPcY14a8

Yes, when we use expicit constants there we can catch such a warning, because 
AST parser can timely recognize the issue. The parser is not smart enough to 
treat variables. Static Analyzer is in charge of this and executes after the 
parser. I think AST parser shall also ignore the Standard in this particular 
case with an eye on a real use cases and developers' intentions. As you can see 
there is a bit modified version which doesn't emit the warning 
https://godbolt.org/z/Mdhhe6Eo9.


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

https://reviews.llvm.org/D104285

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


[PATCH] D107296: Treat inttypes.h as a built-in header

2021-08-16 Thread Mark Rowe via Phabricator via cfe-commits
markrowe added a comment.

@dexonsmith Ping?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107296

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


[PATCH] D107775: [Clang][AST] Resolve FIXME: Remove ObjCObjectPointer from isSpecifierType

2021-08-16 Thread Alf via Phabricator via cfe-commits
gAlfonso-bit updated this revision to Diff 39.
gAlfonso-bit added a comment.

Rearranged if statements


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

https://reviews.llvm.org/D107775

Files:
  clang/lib/AST/DeclPrinter.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypePrinter.cpp


Index: clang/lib/AST/TypePrinter.cpp
===
--- clang/lib/AST/TypePrinter.cpp
+++ clang/lib/AST/TypePrinter.cpp
@@ -303,7 +303,6 @@
   SaveAndRestore PrevPHIsEmpty(HasEmptyPlaceHolder);
 
   // Print qualifiers as appropriate.
-
   bool CanPrefixQualifiers = false;
   bool NeedARCStrongQualifier = false;
   CanPrefixQualifiers = canPrefixQualifiers(T, NeedARCStrongQualifier);
Index: clang/lib/AST/Type.cpp
===
--- clang/lib/AST/Type.cpp
+++ clang/lib/AST/Type.cpp
@@ -2785,7 +2785,6 @@
   case DependentTemplateSpecialization:
   case ObjCInterface:
   case ObjCObject:
-  case ObjCObjectPointer: // FIXME: object pointers aren't really specifiers
 return true;
   default:
 return false;
Index: clang/lib/AST/DeclPrinter.cpp
===
--- clang/lib/AST/DeclPrinter.cpp
+++ clang/lib/AST/DeclPrinter.cpp
@@ -155,9 +155,12 @@
   BaseType = PTy->getPointeeType();
 else if (const BlockPointerType *BPy = BaseType->getAs())
   BaseType = BPy->getPointeeType();
-else if (const ArrayType* ATy = dyn_cast(BaseType))
+else if (const ObjCObjectPointerType *OPT =
+ BaseType->getAs())
+  BaseType = OPT->getPointeeType();
+else if (const ArrayType *ATy = dyn_cast(BaseType))
   BaseType = ATy->getElementType();
-else if (const FunctionType* FTy = BaseType->getAs())
+else if (const FunctionType *FTy = BaseType->getAs())
   BaseType = FTy->getReturnType();
 else if (const VectorType *VTy = BaseType->getAs())
   BaseType = VTy->getElementType();


Index: clang/lib/AST/TypePrinter.cpp
===
--- clang/lib/AST/TypePrinter.cpp
+++ clang/lib/AST/TypePrinter.cpp
@@ -303,7 +303,6 @@
   SaveAndRestore PrevPHIsEmpty(HasEmptyPlaceHolder);
 
   // Print qualifiers as appropriate.
-
   bool CanPrefixQualifiers = false;
   bool NeedARCStrongQualifier = false;
   CanPrefixQualifiers = canPrefixQualifiers(T, NeedARCStrongQualifier);
Index: clang/lib/AST/Type.cpp
===
--- clang/lib/AST/Type.cpp
+++ clang/lib/AST/Type.cpp
@@ -2785,7 +2785,6 @@
   case DependentTemplateSpecialization:
   case ObjCInterface:
   case ObjCObject:
-  case ObjCObjectPointer: // FIXME: object pointers aren't really specifiers
 return true;
   default:
 return false;
Index: clang/lib/AST/DeclPrinter.cpp
===
--- clang/lib/AST/DeclPrinter.cpp
+++ clang/lib/AST/DeclPrinter.cpp
@@ -155,9 +155,12 @@
   BaseType = PTy->getPointeeType();
 else if (const BlockPointerType *BPy = BaseType->getAs())
   BaseType = BPy->getPointeeType();
-else if (const ArrayType* ATy = dyn_cast(BaseType))
+else if (const ObjCObjectPointerType *OPT =
+ BaseType->getAs())
+  BaseType = OPT->getPointeeType();
+else if (const ArrayType *ATy = dyn_cast(BaseType))
   BaseType = ATy->getElementType();
-else if (const FunctionType* FTy = BaseType->getAs())
+else if (const FunctionType *FTy = BaseType->getAs())
   BaseType = FTy->getReturnType();
 else if (const VectorType *VTy = BaseType->getAs())
   BaseType = VTy->getElementType();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] b7425e9 - [NFC] Fix typos

2021-08-16 Thread Rong Xu via cfe-commits

Author: Rong Xu
Date: 2021-08-16T10:15:30-07:00
New Revision: b7425e956be60a73004d7ae5bb37da85872c29fb

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

LOG: [NFC] Fix typos

s/senstive/senstive/g

Added: 


Modified: 
clang/lib/StaticAnalyzer/Checkers/CheckObjCInstMethSignature.cpp
clang/lib/StaticAnalyzer/Checkers/NSErrorChecker.cpp
compiler-rt/test/profile/Linux/instrprof-cs.c
llvm/include/llvm/Transforms/Instrumentation.h
llvm/lib/ProfileData/SampleProfReader.cpp

Removed: 




diff  --git a/clang/lib/StaticAnalyzer/Checkers/CheckObjCInstMethSignature.cpp 
b/clang/lib/StaticAnalyzer/Checkers/CheckObjCInstMethSignature.cpp
index 175dfcef0df45..a13de306eac84 100644
--- a/clang/lib/StaticAnalyzer/Checkers/CheckObjCInstMethSignature.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/CheckObjCInstMethSignature.cpp
@@ -6,7 +6,7 @@
 //
 
//===--===//
 //
-//  This file defines a CheckObjCInstMethSignature, a flow-insenstive check
+//  This file defines a CheckObjCInstMethSignature, a flow-insensitive check
 //  that determines if an Objective-C class interface incorrectly redefines
 //  the method signature in a subclass.
 //

diff  --git a/clang/lib/StaticAnalyzer/Checkers/NSErrorChecker.cpp 
b/clang/lib/StaticAnalyzer/Checkers/NSErrorChecker.cpp
index 90c5583d89691..dcca8be55e337 100644
--- a/clang/lib/StaticAnalyzer/Checkers/NSErrorChecker.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/NSErrorChecker.cpp
@@ -6,7 +6,7 @@
 //
 
//===--===//
 //
-//  This file defines a CheckNSError, a flow-insenstive check
+//  This file defines a CheckNSError, a flow-insensitive check
 //  that determines if an Objective-C class interface correctly returns
 //  a non-void return type.
 //

diff  --git a/compiler-rt/test/profile/Linux/instrprof-cs.c 
b/compiler-rt/test/profile/Linux/instrprof-cs.c
index d825525a532db..0ad6f0350c560 100644
--- a/compiler-rt/test/profile/Linux/instrprof-cs.c
+++ b/compiler-rt/test/profile/Linux/instrprof-cs.c
@@ -8,7 +8,7 @@
 // RUN: %clang_profgen=%t.profraw -o %t.gen.cis -O2 %s
 // RUN: %run %t.gen.cis
 // RUN: llvm-profdata merge -o %t.cis.profdata %t.profraw
-// Check context insenstive profile
+// Check context insensitive profile
 // RUN: %clang_profuse=%t.cis.profdata  -O2 -emit-llvm -S %s -o - | FileCheck 
%s --check-prefix=CIS
 int g1 = 1;
 int volatile g2 = 2;

diff  --git a/llvm/include/llvm/Transforms/Instrumentation.h 
b/llvm/include/llvm/Transforms/Instrumentation.h
index 03108bacb0da5..0c822999aecf3 100644
--- a/llvm/include/llvm/Transforms/Instrumentation.h
+++ b/llvm/include/llvm/Transforms/Instrumentation.h
@@ -78,7 +78,7 @@ struct GCOVOptions {
 ModulePass *createGCOVProfilerPass(const GCOVOptions &Options =
GCOVOptions::getDefault());
 
-// PGO Instrumention. Parameter IsCS indicates if this is the context senstive
+// PGO Instrumention. Parameter IsCS indicates if this is the context sensitive
 // instrumentation.
 ModulePass *createPGOInstrumentationGenLegacyPass(bool IsCS = false);
 ModulePass *
@@ -138,7 +138,7 @@ struct InstrProfOptions {
 };
 
 /// Insert frontend instrumentation based profiling. Parameter IsCS indicates 
if
-// this is the context senstive instrumentation.
+// this is the context sensitive instrumentation.
 ModulePass *createInstrProfilingLegacyPass(
 const InstrProfOptions &Options = InstrProfOptions(), bool IsCS = false);
 

diff  --git a/llvm/lib/ProfileData/SampleProfReader.cpp 
b/llvm/lib/ProfileData/SampleProfReader.cpp
index 6058eddb13dc7..a801ca1ef36d7 100644
--- a/llvm/lib/ProfileData/SampleProfReader.cpp
+++ b/llvm/lib/ProfileData/SampleProfReader.cpp
@@ -53,7 +53,7 @@ using namespace sampleprof;
 // For ext-binary format profiles, the flag is set in the summary.
 static cl::opt ProfileIsFSDisciminator(
 "profile-isfs", cl::Hidden, cl::init(false),
-cl::desc("Profile uses flow senstive discriminators"));
+cl::desc("Profile uses flow sensitive discriminators"));
 
 /// Dump the function profile for \p FName.
 ///



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


[clang] 8bc72de - [Clang][AST][NFC] Resolve FIXME: Remove unused QualType ElementType member from the ASTContext class.

2021-08-16 Thread Simon Pilgrim via cfe-commits

Author: Alfsonso Gregory
Date: 2021-08-16T19:07:50+01:00
New Revision: 8bc72dede68ccbbf828c0421276d962d369ba70f

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

LOG: [Clang][AST][NFC] Resolve FIXME: Remove unused QualType ElementType member 
from the ASTContext class.

It is completely unused and not needed to be kept, so let us remove it.

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

Added: 


Modified: 
clang/include/clang/AST/Type.h

Removed: 




diff  --git a/clang/include/clang/AST/Type.h b/clang/include/clang/AST/Type.h
index 4238667b8b076..fc83c895afa2e 100644
--- a/clang/include/clang/AST/Type.h
+++ b/clang/include/clang/AST/Type.h
@@ -3455,10 +3455,6 @@ class ConstantMatrixType final : public MatrixType {
 protected:
   friend class ASTContext;
 
-  /// The element type of the matrix.
-  // FIXME: Appears to be unused? There is also MatrixType::ElementType...
-  QualType ElementType;
-
   /// Number of rows and columns.
   unsigned NumRows;
   unsigned NumColumns;



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


[PATCH] D107719: [Clang][AST][NFC] Resolve FIXME: Remove unused QualType ElementType member from the ASTContext class.

2021-08-16 Thread Simon Pilgrim via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG8bc72dede68c: [Clang][AST][NFC] Resolve FIXME: Remove unused 
QualType ElementType member from… (authored by gAlfonso-bit, committed by 
RKSimon).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107719

Files:
  clang/include/clang/AST/Type.h


Index: clang/include/clang/AST/Type.h
===
--- clang/include/clang/AST/Type.h
+++ clang/include/clang/AST/Type.h
@@ -3455,10 +3455,6 @@
 protected:
   friend class ASTContext;
 
-  /// The element type of the matrix.
-  // FIXME: Appears to be unused? There is also MatrixType::ElementType...
-  QualType ElementType;
-
   /// Number of rows and columns.
   unsigned NumRows;
   unsigned NumColumns;


Index: clang/include/clang/AST/Type.h
===
--- clang/include/clang/AST/Type.h
+++ clang/include/clang/AST/Type.h
@@ -3455,10 +3455,6 @@
 protected:
   friend class ASTContext;
 
-  /// The element type of the matrix.
-  // FIXME: Appears to be unused? There is also MatrixType::ElementType...
-  QualType ElementType;
-
   /// Number of rows and columns.
   unsigned NumRows;
   unsigned NumColumns;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 80ed75e - Revert "[NFC] Fix typos"

2021-08-16 Thread Kostya Kortchinsky via cfe-commits

Author: Kostya Kortchinsky
Date: 2021-08-16T11:13:05-07:00
New Revision: 80ed75e7fb45f9f5fc84ca7cbe258be036015384

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

LOG: Revert "[NFC] Fix typos"

This reverts commit b7425e956be60a73004d7ae5bb37da85872c29fb.

Added: 


Modified: 
clang/lib/StaticAnalyzer/Checkers/CheckObjCInstMethSignature.cpp
clang/lib/StaticAnalyzer/Checkers/NSErrorChecker.cpp
compiler-rt/test/profile/Linux/instrprof-cs.c
llvm/include/llvm/Transforms/Instrumentation.h
llvm/lib/ProfileData/SampleProfReader.cpp

Removed: 




diff  --git a/clang/lib/StaticAnalyzer/Checkers/CheckObjCInstMethSignature.cpp 
b/clang/lib/StaticAnalyzer/Checkers/CheckObjCInstMethSignature.cpp
index a13de306eac84..175dfcef0df45 100644
--- a/clang/lib/StaticAnalyzer/Checkers/CheckObjCInstMethSignature.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/CheckObjCInstMethSignature.cpp
@@ -6,7 +6,7 @@
 //
 
//===--===//
 //
-//  This file defines a CheckObjCInstMethSignature, a flow-insensitive check
+//  This file defines a CheckObjCInstMethSignature, a flow-insenstive check
 //  that determines if an Objective-C class interface incorrectly redefines
 //  the method signature in a subclass.
 //

diff  --git a/clang/lib/StaticAnalyzer/Checkers/NSErrorChecker.cpp 
b/clang/lib/StaticAnalyzer/Checkers/NSErrorChecker.cpp
index dcca8be55e337..90c5583d89691 100644
--- a/clang/lib/StaticAnalyzer/Checkers/NSErrorChecker.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/NSErrorChecker.cpp
@@ -6,7 +6,7 @@
 //
 
//===--===//
 //
-//  This file defines a CheckNSError, a flow-insensitive check
+//  This file defines a CheckNSError, a flow-insenstive check
 //  that determines if an Objective-C class interface correctly returns
 //  a non-void return type.
 //

diff  --git a/compiler-rt/test/profile/Linux/instrprof-cs.c 
b/compiler-rt/test/profile/Linux/instrprof-cs.c
index 0ad6f0350c560..d825525a532db 100644
--- a/compiler-rt/test/profile/Linux/instrprof-cs.c
+++ b/compiler-rt/test/profile/Linux/instrprof-cs.c
@@ -8,7 +8,7 @@
 // RUN: %clang_profgen=%t.profraw -o %t.gen.cis -O2 %s
 // RUN: %run %t.gen.cis
 // RUN: llvm-profdata merge -o %t.cis.profdata %t.profraw
-// Check context insensitive profile
+// Check context insenstive profile
 // RUN: %clang_profuse=%t.cis.profdata  -O2 -emit-llvm -S %s -o - | FileCheck 
%s --check-prefix=CIS
 int g1 = 1;
 int volatile g2 = 2;

diff  --git a/llvm/include/llvm/Transforms/Instrumentation.h 
b/llvm/include/llvm/Transforms/Instrumentation.h
index 0c822999aecf3..03108bacb0da5 100644
--- a/llvm/include/llvm/Transforms/Instrumentation.h
+++ b/llvm/include/llvm/Transforms/Instrumentation.h
@@ -78,7 +78,7 @@ struct GCOVOptions {
 ModulePass *createGCOVProfilerPass(const GCOVOptions &Options =
GCOVOptions::getDefault());
 
-// PGO Instrumention. Parameter IsCS indicates if this is the context sensitive
+// PGO Instrumention. Parameter IsCS indicates if this is the context senstive
 // instrumentation.
 ModulePass *createPGOInstrumentationGenLegacyPass(bool IsCS = false);
 ModulePass *
@@ -138,7 +138,7 @@ struct InstrProfOptions {
 };
 
 /// Insert frontend instrumentation based profiling. Parameter IsCS indicates 
if
-// this is the context sensitive instrumentation.
+// this is the context senstive instrumentation.
 ModulePass *createInstrProfilingLegacyPass(
 const InstrProfOptions &Options = InstrProfOptions(), bool IsCS = false);
 

diff  --git a/llvm/lib/ProfileData/SampleProfReader.cpp 
b/llvm/lib/ProfileData/SampleProfReader.cpp
index a801ca1ef36d7..6058eddb13dc7 100644
--- a/llvm/lib/ProfileData/SampleProfReader.cpp
+++ b/llvm/lib/ProfileData/SampleProfReader.cpp
@@ -53,7 +53,7 @@ using namespace sampleprof;
 // For ext-binary format profiles, the flag is set in the summary.
 static cl::opt ProfileIsFSDisciminator(
 "profile-isfs", cl::Hidden, cl::init(false),
-cl::desc("Profile uses flow sensitive discriminators"));
+cl::desc("Profile uses flow senstive discriminators"));
 
 /// Dump the function profile for \p FName.
 ///



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


[PATCH] D106891: [Remarks] Emit optimization remarks for atomics generating CAS loop

2021-08-16 Thread Stanislav Mekhanoshin via Phabricator via cfe-commits
rampitec added inline comments.



Comment at: llvm/lib/CodeGen/AtomicExpandPass.cpp:175
 
+  ORE = std::make_unique(&F);
   auto &TM = TPC->getTM();

Is there a reason to construct it upfront and not just use a local variable 
only when needed? Like in StackProtector.cpp for example.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106891

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


[PATCH] D106891: [Remarks] Emit optimization remarks for atomics generating CAS loop

2021-08-16 Thread Anshil Gandhi via Phabricator via cfe-commits
gandhi21299 added inline comments.



Comment at: llvm/lib/CodeGen/AtomicExpandPass.cpp:175
 
+  ORE = std::make_unique(&F);
   auto &TM = TPC->getTM();

rampitec wrote:
> Is there a reason to construct it upfront and not just use a local variable 
> only when needed? Like in StackProtector.cpp for example.
We can certainly implement it as a local variable as long as we have access to 
the function this pass is operating on. I was thinking of its potential use 
throughout this pass in the future.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106891

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


[PATCH] D107717: [LLVM][CMake][NFC] Resolve FIXME: Rename LLVM_CMAKE_PATH to LLVM_CMAKE_DIR throughout the project

2021-08-16 Thread Alf via Phabricator via cfe-commits
gAlfonso-bit updated this revision to Diff 366671.

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

https://reviews.llvm.org/D107717

Files:
  clang/CMakeLists.txt
  clang/lib/Basic/CMakeLists.txt
  compiler-rt/cmake/Modules/CompilerRTMockLLVMCMakeConfig.cmake
  compiler-rt/cmake/Modules/CompilerRTUtils.cmake
  flang/CMakeLists.txt
  libcxx/cmake/Modules/HandleOutOfTreeLLVM.cmake
  libunwind/CMakeLists.txt
  lld/CMakeLists.txt
  lld/Common/CMakeLists.txt
  lldb/cmake/modules/LLDBStandalone.cmake
  lldb/source/CMakeLists.txt
  llvm/CMakeLists.txt
  llvm/include/llvm/Support/CMakeLists.txt
  runtimes/CMakeLists.txt

Index: runtimes/CMakeLists.txt
===
--- runtimes/CMakeLists.txt
+++ runtimes/CMakeLists.txt
@@ -65,7 +65,7 @@
 
 # This variable makes sure that e.g. llvm-lit is found.
 set(LLVM_MAIN_SRC_DIR ${LLVM_BUILD_MAIN_SRC_DIR})
-set(LLVM_CMAKE_PATH ${LLVM_MAIN_SRC_DIR}/cmake/modules)
+set(LLVM_CMAKE_DIR ${LLVM_MAIN_SRC_DIR}/cmake/modules)
 
 # This variable is used by individual runtimes to locate LLVM files.
 set(LLVM_PATH ${LLVM_BUILD_MAIN_SRC_DIR})
Index: llvm/include/llvm/Support/CMakeLists.txt
===
--- llvm/include/llvm/Support/CMakeLists.txt
+++ llvm/include/llvm/Support/CMakeLists.txt
@@ -3,7 +3,7 @@
 # The VC revision include that we want to generate.
 set(version_inc "${CMAKE_CURRENT_BINARY_DIR}/VCSRevision.h")
 
-set(generate_vcs_version_script "${LLVM_CMAKE_PATH}/GenerateVersionFromVCS.cmake")
+set(generate_vcs_version_script "${LLVM_CMAKE_DIR}/GenerateVersionFromVCS.cmake")
 
 if(LLVM_APPEND_VC_REV)
   set(llvm_source_dir ${LLVM_MAIN_SRC_DIR})
Index: llvm/CMakeLists.txt
===
--- llvm/CMakeLists.txt
+++ llvm/CMakeLists.txt
@@ -295,8 +295,8 @@
 set(LLVM_MAIN_INCLUDE_DIR ${LLVM_MAIN_SRC_DIR}/include ) # --includedir
 set(LLVM_BINARY_DIR   ${CMAKE_CURRENT_BINARY_DIR}  ) # --prefix
 
-# Note: LLVM_CMAKE_PATH does not include generated files
-set(LLVM_CMAKE_PATH ${LLVM_MAIN_SRC_DIR}/cmake/modules)
+# Note: LLVM_CMAKE_DIR does not include generated files
+set(LLVM_CMAKE_DIR ${LLVM_MAIN_SRC_DIR}/cmake/modules)
 set(LLVM_EXAMPLES_BINARY_DIR ${LLVM_BINARY_DIR}/examples)
 set(LLVM_INCLUDE_DIR ${CMAKE_CURRENT_BINARY_DIR}/include)
 
Index: lldb/source/CMakeLists.txt
===
--- lldb/source/CMakeLists.txt
+++ lldb/source/CMakeLists.txt
@@ -8,7 +8,7 @@
 find_first_existing_vc_file("${LLDB_SOURCE_DIR}" lldb_vc)
 
 set(version_inc "${CMAKE_CURRENT_BINARY_DIR}/VCSVersion.inc")
-set(generate_vcs_version_script "${LLVM_CMAKE_PATH}/GenerateVersionFromVCS.cmake")
+set(generate_vcs_version_script "${LLVM_CMAKE_DIR}/GenerateVersionFromVCS.cmake")
 
 if(lldb_vc AND LLVM_APPEND_VC_REV)
   set(lldb_source_dir ${LLDB_SOURCE_DIR})
Index: lldb/cmake/modules/LLDBStandalone.cmake
===
--- lldb/cmake/modules/LLDBStandalone.cmake
+++ lldb/cmake/modules/LLDBStandalone.cmake
@@ -3,8 +3,8 @@
 find_package(LLVM REQUIRED CONFIG HINTS ${LLVM_DIR} NO_CMAKE_FIND_ROOT_PATH)
 find_package(Clang REQUIRED CONFIG HINTS ${Clang_DIR} ${LLVM_DIR}/../clang NO_CMAKE_FIND_ROOT_PATH)
 
-# We set LLVM_CMAKE_PATH so that GetSVN.cmake is found correctly when building SVNVersion.inc
-set(LLVM_CMAKE_PATH ${LLVM_CMAKE_DIR} CACHE PATH "Path to LLVM CMake modules")
+# We set LLVM_CMAKE_DIR so that GetSVN.cmake is found correctly when building SVNVersion.inc
+set(LLVM_CMAKE_DIR ${LLVM_CMAKE_DIR} CACHE PATH "Path to LLVM CMake modules")
 
 set(LLVM_MAIN_SRC_DIR ${LLVM_BUILD_MAIN_SRC_DIR} CACHE PATH "Path to LLVM source tree")
 set(LLVM_MAIN_INCLUDE_DIR ${LLVM_MAIN_INCLUDE_DIR} CACHE PATH "Path to llvm/include")
Index: lld/Common/CMakeLists.txt
===
--- lld/Common/CMakeLists.txt
+++ lld/Common/CMakeLists.txt
@@ -8,7 +8,7 @@
 find_first_existing_vc_file("${LLD_SOURCE_DIR}" lld_vc)
 
 set(version_inc "${CMAKE_CURRENT_BINARY_DIR}/VCSVersion.inc")
-set(generate_vcs_version_script "${LLVM_CMAKE_PATH}/GenerateVersionFromVCS.cmake")
+set(generate_vcs_version_script "${LLVM_CMAKE_DIR}/GenerateVersionFromVCS.cmake")
 
 if(lld_vc AND LLVM_APPEND_VC_REV)
   set(lld_source_dir ${LLD_SOURCE_DIR})
Index: lld/CMakeLists.txt
===
--- lld/CMakeLists.txt
+++ lld/CMakeLists.txt
@@ -27,7 +27,7 @@
 
   list(GET LLVM_CONFIG_OUTPUT 0 OBJ_ROOT)
   list(GET LLVM_CONFIG_OUTPUT 1 MAIN_INCLUDE_DIR)
-  list(GET LLVM_CONFIG_OUTPUT 2 LLVM_CMAKE_PATH)
+  list(GET LLVM_CONFIG_OUTPUT 2 LLVM_CMAKE_DIR)
   list(GET LLVM_CONFIG_OUTPUT 3 MAIN_SRC_DIR)
 
   set(LLVM_OBJ_ROOT ${OBJ_ROOT} CACHE PATH "path to LLVM build tree")
@@ -35,14 +35,14 @@
   set(LLVM_MAIN_SRC_DIR ${MAIN_SRC_DIR} CACHE PATH "Path to LLVM source tree")
 
   file(TO_CMAKE_P

[PATCH] D106891: [Remarks] Emit optimization remarks for atomics generating CAS loop

2021-08-16 Thread Anshil Gandhi via Phabricator via cfe-commits
gandhi21299 added inline comments.



Comment at: llvm/lib/CodeGen/AtomicExpandPass.cpp:175
 
+  ORE = std::make_unique(&F);
   auto &TM = TPC->getTM();

rampitec wrote:
> gandhi21299 wrote:
> > rampitec wrote:
> > > Is there a reason to construct it upfront and not just use a local 
> > > variable only when needed? Like in StackProtector.cpp for example.
> > We can certainly implement it as a local variable as long as we have access 
> > to the function this pass is operating on. I was thinking of its potential 
> > use throughout this pass in the future.
> You have access to the function, AI->getParent()->getParent().
> You also will not need to pass ORE everywhere in the subsequent patch, just 
> construct it in target in place.
Sounds like a plan!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106891

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


[PATCH] D106891: [Remarks] Emit optimization remarks for atomics generating CAS loop

2021-08-16 Thread Stanislav Mekhanoshin via Phabricator via cfe-commits
rampitec added inline comments.



Comment at: llvm/lib/CodeGen/AtomicExpandPass.cpp:175
 
+  ORE = std::make_unique(&F);
   auto &TM = TPC->getTM();

gandhi21299 wrote:
> rampitec wrote:
> > Is there a reason to construct it upfront and not just use a local variable 
> > only when needed? Like in StackProtector.cpp for example.
> We can certainly implement it as a local variable as long as we have access 
> to the function this pass is operating on. I was thinking of its potential 
> use throughout this pass in the future.
You have access to the function, AI->getParent()->getParent().
You also will not need to pass ORE everywhere in the subsequent patch, just 
construct it in target in place.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106891

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


[PATCH] D106030: [Clang] add support for error+warning fn attrs

2021-08-16 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers added inline comments.



Comment at: clang/test/Sema/attr-error.c:31-32
+
+__attribute__((error("foo"))) int bad5(void);   // expected-error {{'error' 
and 'warning' attributes are not compatible}}
+__attribute__((warning("foo"))) int bad5(void); // expected-note {{conflicting 
attribute is here}}
+

aaron.ballman wrote:
> I think the diagnostic order is backwards here. The first declaration is 
> where I'd expect the note and the second declaration is where I'd expect the 
> error. (The idea is: the first declaration adds an attribute to the decl, so 
> the redeclaration is what introduces the conflict and so that's where the 
> error should live.) As an example: https://godbolt.org/z/bjGTWxYvh
I'm not sure how to reconcile this. Looking at `bad4` above (different case 
than `bad5`), the diagnostic we get is:
```
/tmp/y.c:1:30: error: 'warning' and 'error' attributes are not compatible
__attribute__((error("foo"), warning("foo")))
 ^
/tmp/y.c:1:16: note: conflicting attribute is here
__attribute__((error("foo"), warning("foo")))
   ^
1 error generated.
```
which looks correct to me. If I flip the order these are diagnosed in, that 
fixes `bad5` but if I flip around the ordering:
```
--- a/clang/lib/Sema/SemaDeclAttr.cpp
+++ b/clang/lib/Sema/SemaDeclAttr.cpp
-  Diag(CI.getLoc(), diag::err_attributes_are_not_compatible) << CI << EA;
-  Diag(EA->getLocation(), diag::note_conflicting_attribute);
+  Diag(EA->getLocation(), diag::err_attributes_are_not_compatible)
+  << CI << EA;
+  Diag(CI.getLoc(), diag::note_conflicting_attribute);
```
Then `bad4` doesn't look quite correct.
```
/tmp/y.c:1:16: error: 'warning' and 'error' attributes are not compatible
__attribute__((error("foo"), warning("foo")))
   ^
/tmp/y.c:1:30: note: conflicting attribute is here
__attribute__((error("foo"), warning("foo")))
 ^
```
Perhaps in the callers of `handleErrorAttr` I'm confusing which `Decl` is the 
"new" vs the "old?"


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106030

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


[PATCH] D98061: [InstrProfiling] Generate runtime hook for Fuchsia

2021-08-16 Thread Kirsten Lee via Phabricator via cfe-commits
kile added a comment.

Hi Petr,

This looks to be the change that most likely broke a test on Windows Debug - 
would you mind taking a look? Here's the relevant test and stack trace:

FAIL: LLVM :: Instrumentation/InstrProfiling/linkage.ll (56524 of 77140)

- TEST 'LLVM :: Instrumentation/InstrProfiling/linkage.ll' FAILED 


Script:
---

: 'RUN: at line 3';   d:\a\_work\1\b\llvm\debug\bin\opt.exe < 
D:\a\_work\1\s\llvm-project\llvm\test\Instrumentation\InstrProfiling\linkage.ll 
-mtriple=x86_64-apple-macosx10.10.0 -instrprof -S | 
d:\a\_work\1\b\llvm\debug\bin\filecheck.exe 
D:\a\_work\1\s\llvm-project\llvm\test\Instrumentation\InstrProfiling\linkage.ll 
--check-prefixes=MACHO
: 'RUN: at line 4';   d:\a\_work\1\b\llvm\debug\bin\opt.exe < 
D:\a\_work\1\s\llvm-project\llvm\test\Instrumentation\InstrProfiling\linkage.ll 
-mtriple=x86_64-unknown-linux -instrprof -S | 
d:\a\_work\1\b\llvm\debug\bin\filecheck.exe 
D:\a\_work\1\s\llvm-project\llvm\test\Instrumentation\InstrProfiling\linkage.ll 
--check-prefixes=ELF
: 'RUN: at line 5';   d:\a\_work\1\b\llvm\debug\bin\opt.exe < 
D:\a\_work\1\s\llvm-project\llvm\test\Instrumentation\InstrProfiling\linkage.ll 
-mtriple=x86_64-unknown-fuchsia -instrprof -S | 
d:\a\_work\1\b\llvm\debug\bin\filecheck.exe 
D:\a\_work\1\s\llvm-project\llvm\test\Instrumentation\InstrProfiling\linkage.ll 
--check-prefixes=ELF
: 'RUN: at line 6';   d:\a\_work\1\b\llvm\debug\bin\opt.exe < 
D:\a\_work\1\s\llvm-project\llvm\test\Instrumentation\InstrProfiling\linkage.ll 
 -mtriple=x86_64-pc-win32-coff -instrprof -S | 
d:\a\_work\1\b\llvm\debug\bin\filecheck.exe 
D:\a\_work\1\s\llvm-project\llvm\test\Instrumentation\InstrProfiling\linkage.ll 
--check-prefixes=COFF
: 'RUN: at line 7';   d:\a\_work\1\b\llvm\debug\bin\opt.exe < 
D:\a\_work\1\s\llvm-project\llvm\test\Instrumentation\InstrProfiling\linkage.ll 
-mtriple=x86_64-apple-macosx10.10.0 -passes=instrprof -S | 
d:\a\_work\1\b\llvm\debug\bin\filecheck.exe 
D:\a\_work\1\s\llvm-project\llvm\test\Instrumentation\InstrProfiling\linkage.ll 
--check-prefixes=MACHO
: 'RUN: at line 8';   d:\a\_work\1\b\llvm\debug\bin\opt.exe < 
D:\a\_work\1\s\llvm-project\llvm\test\Instrumentation\InstrProfiling\linkage.ll 
-mtriple=x86_64-unknown-linux -passes=instrprof -S | 
d:\a\_work\1\b\llvm\debug\bin\filecheck.exe 
D:\a\_work\1\s\llvm-project\llvm\test\Instrumentation\InstrProfiling\linkage.ll 
--check-prefixes=ELF
: 'RUN: at line 9';   d:\a\_work\1\b\llvm\debug\bin\opt.exe < 
D:\a\_work\1\s\llvm-project\llvm\test\Instrumentation\InstrProfiling\linkage.ll 
-mtriple=x86_64-unknown-fuchsia -passes=instrprof -S | 
d:\a\_work\1\b\llvm\debug\bin\filecheck.exe 
D:\a\_work\1\s\llvm-project\llvm\test\Instrumentation\InstrProfiling\linkage.ll 
--check-prefixes=ELF
: 'RUN: at line 10';   d:\a\_work\1\b\llvm\debug\bin\opt.exe < 
D:\a\_work\1\s\llvm-project\llvm\test\Instrumentation\InstrProfiling\linkage.ll 
 -mtriple=x86_64-pc-win32-coff -passes=instrprof -S | 
d:\a\_work\1\b\llvm\debug\bin\filecheck.exe 
D:\a\_work\1\s\llvm-project\llvm\test\Instrumentation\InstrProfiling\linkage.ll 
--check-prefixes=COFF

-

Exit Code: 2

Command Output (stdout):


$ ":" "RUN: at line 3"
$ "d:\a\_work\1\b\llvm\debug\bin\opt.exe" "-mtriple=x86_64-apple-macosx10.10.0" 
"-instrprof" "-S"
$ "d:\a\_work\1\b\llvm\debug\bin\filecheck.exe" 
"D:\a\_work\1\s\llvm-project\llvm\test\Instrumentation\InstrProfiling\linkage.ll"
 "--check-prefixes=MACHO"
$ ":" "RUN: at line 4"
$ "d:\a\_work\1\b\llvm\debug\bin\opt.exe" "-mtriple=x86_64-unknown-linux" 
"-instrprof" "-S"
$ "d:\a\_work\1\b\llvm\debug\bin\filecheck.exe" 
"D:\a\_work\1\s\llvm-project\llvm\test\Instrumentation\InstrProfiling\linkage.ll"
 "--check-prefixes=ELF"
$ ":" "RUN: at line 5"
$ "d:\a\_work\1\b\llvm\debug\bin\opt.exe" "-mtriple=x86_64-unknown-fuchsia" 
"-instrprof" "-S"

command stderr:
===

PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash 
backtrace.

Stack dump:

0.  Program arguments: d:\\a\\_work\\1\\b\\llvm\\debug\\bin\\opt.exe 
-mtriple=x86_64-unknown-fuchsia -instrprof -S

#0 0x7ff6c05a6844 failwithmessage 
d:\agent\_work\4\s\src\vctools\crt\vcstartup\src\rtc\error.cpp:213:0

#1 0x7ff6c05a69e4 _RTC_UninitUse 
d:\agent\_work\4\s\src\vctools\crt\vcstartup\src\rtc\error.cpp:362:0

#2 0x7ff6be864982 llvm::InstrProfiling::run(class llvm::Module &, class 
std::function<(class llvm::Function &)>) 
D:\a\_work\1\s\llvm-project\llvm\lib\Transforms\Instrumentation\InstrProfiling.cpp:590:0

#3 0x7ff6be8644ad llvm::InstrProfiling::run(class llvm::Module &, class 
llvm::AnalysisManager &) 
D:\a\_work\1\s\llvm-project\llvm\lib\Transforms\Instrumentation\InstrProfiling.cpp:417:0

#4 0x7ff6bf82d229 llvm::detail::PassModel>::run(class llvm::Module &, class 
llvm::AnalysisManager &) 
D:\a\_work\1\s\llvm-project\llvm\include\llvm\IR\PassManagerInternal.h:85:0

#5 0x7ff6bc402b9e llvm::PassManager>::run(class llvm::Module &, class 
llvm::A

[PATCH] D108083: add sanitizer support to hexagon

2021-08-16 Thread Sid Manning via Phabricator via cfe-commits
sidneym added inline comments.



Comment at: 
compiler-rt/lib/sanitizer_common/sanitizer_syscall_linux_hexagon.inc:124
+
+bool internal_iserror(uptr retval, int *rverrno) {
+  if (retval == (uptr)-1) {

bcain wrote:
> @sidneym Can you confirm that this implementation looks correct?  I thought 
> the convention was -1 for failed syscalls.
Maybe it should be <0 instead.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108083

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


[clang] 0a03144 - [PassBuilder] Don't use MemorySSA for standalone LoopRotate passes

2021-08-16 Thread Nikita Popov via cfe-commits

Author: Nikita Popov
Date: 2021-08-16T20:34:18+02:00
New Revision: 0a031449b2c757400090b23bd6ddf4d896d32643

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

LOG: [PassBuilder] Don't use MemorySSA for standalone LoopRotate passes

Two standalone LoopRotate passes scheduled using
createFunctionToLoopPassAdaptor() currently enable MemorySSA.
However, while LoopRotate can preserve MemorySSA, it does not use
it, so requiring MemorySSA is unnecessary.

This change doesn't have a practical compile-time impact by itself,
because subsequent passes still request MemorySSA.

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

Added: 


Modified: 
clang/test/CodeGen/thinlto-distributed-newpm.ll
llvm/lib/Passes/PassBuilder.cpp

Removed: 




diff  --git a/clang/test/CodeGen/thinlto-distributed-newpm.ll 
b/clang/test/CodeGen/thinlto-distributed-newpm.ll
index c61a6ff7fbeb5..4651a5d282faf 100644
--- a/clang/test/CodeGen/thinlto-distributed-newpm.ll
+++ b/clang/test/CodeGen/thinlto-distributed-newpm.ll
@@ -134,7 +134,6 @@
 ; CHECK-O: Running pass: LoopSimplifyPass on main
 ; CHECK-O: Running analysis: LoopAnalysis on main
 ; CHECK-O: Running pass: LCSSAPass on main
-; CHECK-O: Running analysis: MemorySSAAnalysis on main
 ; CHECK-O: Running analysis: AAManager on main
 ; CHECK-O: Running analysis: BasicAA on main
 ; CHECK-O: Running analysis: ScalarEvolutionAnalysis on main
@@ -147,6 +146,7 @@
 ; CHECK-O: Running analysis: BranchProbabilityAnalysis on main
 ; CHECK-O: Running analysis: PostDominatorTreeAnalysis on main
 ; CHECK-O: Running analysis: DemandedBitsAnalysis on main
+; CHECK-O: Running analysis: MemorySSAAnalysis on main
 ; CHECK-O: Running pass: LoopLoadEliminationPass on main
 ; CHECK-O: Running pass: InstCombinePass on main
 ; CHECK-O: Running pass: SimplifyCFGPass on main

diff  --git a/llvm/lib/Passes/PassBuilder.cpp b/llvm/lib/Passes/PassBuilder.cpp
index 2972687274f52..cdf0a732e6708 100644
--- a/llvm/lib/Passes/PassBuilder.cpp
+++ b/llvm/lib/Passes/PassBuilder.cpp
@@ -923,7 +923,7 @@ void PassBuilder::addPGOInstrPasses(ModulePassManager &MPM,
   FunctionPassManager FPM;
   // Disable header duplication in loop rotation at -Oz.
   FPM.addPass(createFunctionToLoopPassAdaptor(
-  LoopRotatePass(Level != OptimizationLevel::Oz), EnableMSSALoopDependency,
+  LoopRotatePass(Level != OptimizationLevel::Oz), /*UseMemorySSA=*/false,
   /*UseBlockFrequencyInfo=*/false));
   MPM.addPass(createModuleToFunctionPassAdaptor(std::move(FPM)));
 
@@ -1399,8 +1399,7 @@ 
PassBuilder::buildModuleOptimizationPipeline(OptimizationLevel Level,
   // Disable header duplication at -Oz.
   OptimizePM.addPass(createFunctionToLoopPassAdaptor(
   LoopRotatePass(Level != OptimizationLevel::Oz, LTOPreLink),
-  EnableMSSALoopDependency,
-  /*UseBlockFrequencyInfo=*/false));
+  /*UseMemorySSA=*/false, /*UseBlockFrequencyInfo=*/false));
 
   // Distribute loops to allow partial vectorization.  I.e. isolate dependences
   // into separate loop that would otherwise inhibit vectorization.  This is



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


[PATCH] D108073: [PassBuilder] Don't use MemorySSA for standalone LoopRotate passes

2021-08-16 Thread Nikita Popov 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 rG0a031449b2c7: [PassBuilder] Don't use MemorySSA for 
standalone LoopRotate passes (authored by nikic).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108073

Files:
  clang/test/CodeGen/thinlto-distributed-newpm.ll
  llvm/lib/Passes/PassBuilder.cpp


Index: llvm/lib/Passes/PassBuilder.cpp
===
--- llvm/lib/Passes/PassBuilder.cpp
+++ llvm/lib/Passes/PassBuilder.cpp
@@ -923,7 +923,7 @@
   FunctionPassManager FPM;
   // Disable header duplication in loop rotation at -Oz.
   FPM.addPass(createFunctionToLoopPassAdaptor(
-  LoopRotatePass(Level != OptimizationLevel::Oz), EnableMSSALoopDependency,
+  LoopRotatePass(Level != OptimizationLevel::Oz), /*UseMemorySSA=*/false,
   /*UseBlockFrequencyInfo=*/false));
   MPM.addPass(createModuleToFunctionPassAdaptor(std::move(FPM)));
 
@@ -1399,8 +1399,7 @@
   // Disable header duplication at -Oz.
   OptimizePM.addPass(createFunctionToLoopPassAdaptor(
   LoopRotatePass(Level != OptimizationLevel::Oz, LTOPreLink),
-  EnableMSSALoopDependency,
-  /*UseBlockFrequencyInfo=*/false));
+  /*UseMemorySSA=*/false, /*UseBlockFrequencyInfo=*/false));
 
   // Distribute loops to allow partial vectorization.  I.e. isolate dependences
   // into separate loop that would otherwise inhibit vectorization.  This is
Index: clang/test/CodeGen/thinlto-distributed-newpm.ll
===
--- clang/test/CodeGen/thinlto-distributed-newpm.ll
+++ clang/test/CodeGen/thinlto-distributed-newpm.ll
@@ -134,7 +134,6 @@
 ; CHECK-O: Running pass: LoopSimplifyPass on main
 ; CHECK-O: Running analysis: LoopAnalysis on main
 ; CHECK-O: Running pass: LCSSAPass on main
-; CHECK-O: Running analysis: MemorySSAAnalysis on main
 ; CHECK-O: Running analysis: AAManager on main
 ; CHECK-O: Running analysis: BasicAA on main
 ; CHECK-O: Running analysis: ScalarEvolutionAnalysis on main
@@ -147,6 +146,7 @@
 ; CHECK-O: Running analysis: BranchProbabilityAnalysis on main
 ; CHECK-O: Running analysis: PostDominatorTreeAnalysis on main
 ; CHECK-O: Running analysis: DemandedBitsAnalysis on main
+; CHECK-O: Running analysis: MemorySSAAnalysis on main
 ; CHECK-O: Running pass: LoopLoadEliminationPass on main
 ; CHECK-O: Running pass: InstCombinePass on main
 ; CHECK-O: Running pass: SimplifyCFGPass on main


Index: llvm/lib/Passes/PassBuilder.cpp
===
--- llvm/lib/Passes/PassBuilder.cpp
+++ llvm/lib/Passes/PassBuilder.cpp
@@ -923,7 +923,7 @@
   FunctionPassManager FPM;
   // Disable header duplication in loop rotation at -Oz.
   FPM.addPass(createFunctionToLoopPassAdaptor(
-  LoopRotatePass(Level != OptimizationLevel::Oz), EnableMSSALoopDependency,
+  LoopRotatePass(Level != OptimizationLevel::Oz), /*UseMemorySSA=*/false,
   /*UseBlockFrequencyInfo=*/false));
   MPM.addPass(createModuleToFunctionPassAdaptor(std::move(FPM)));
 
@@ -1399,8 +1399,7 @@
   // Disable header duplication at -Oz.
   OptimizePM.addPass(createFunctionToLoopPassAdaptor(
   LoopRotatePass(Level != OptimizationLevel::Oz, LTOPreLink),
-  EnableMSSALoopDependency,
-  /*UseBlockFrequencyInfo=*/false));
+  /*UseMemorySSA=*/false, /*UseBlockFrequencyInfo=*/false));
 
   // Distribute loops to allow partial vectorization.  I.e. isolate dependences
   // into separate loop that would otherwise inhibit vectorization.  This is
Index: clang/test/CodeGen/thinlto-distributed-newpm.ll
===
--- clang/test/CodeGen/thinlto-distributed-newpm.ll
+++ clang/test/CodeGen/thinlto-distributed-newpm.ll
@@ -134,7 +134,6 @@
 ; CHECK-O: Running pass: LoopSimplifyPass on main
 ; CHECK-O: Running analysis: LoopAnalysis on main
 ; CHECK-O: Running pass: LCSSAPass on main
-; CHECK-O: Running analysis: MemorySSAAnalysis on main
 ; CHECK-O: Running analysis: AAManager on main
 ; CHECK-O: Running analysis: BasicAA on main
 ; CHECK-O: Running analysis: ScalarEvolutionAnalysis on main
@@ -147,6 +146,7 @@
 ; CHECK-O: Running analysis: BranchProbabilityAnalysis on main
 ; CHECK-O: Running analysis: PostDominatorTreeAnalysis on main
 ; CHECK-O: Running analysis: DemandedBitsAnalysis on main
+; CHECK-O: Running analysis: MemorySSAAnalysis on main
 ; CHECK-O: Running pass: LoopLoadEliminationPass on main
 ; CHECK-O: Running pass: InstCombinePass on main
 ; CHECK-O: Running pass: SimplifyCFGPass on main
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D108003: [Clang] Extend -Wbool-operation to warn about bitwise and of bools with side effects

2021-08-16 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks added a comment.

In D108003#2944714 , @xbolva00 wrote:

> In D108003#2944178 , @aeubanks 
> wrote:
>
>> I ran this over Chrome and ran into a use case that looks legitimate. It 
>> seems like the pattern in LLVM where we want to run a bunch of 
>> transformations and get if any of them changed anything.
>>
>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/api/audio/echo_canceller3_config.cc;drc=cbdbb8c1666fd08a094422905e73391706a05b03;l=111
>
> Maybe “res &= foo ();” would be better? “Changed |= foo();” is very typical 
> for LLVM.

Can we either emit that as a suggestion if the code looks like `a = a & foo()`? 
Or simply not emit a warning?


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

https://reviews.llvm.org/D108003

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


[clang] 570c9be - [MemorySSA] Remove unnecessary MSSA dependencies

2021-08-16 Thread Nikita Popov via cfe-commits

Author: Nikita Popov
Date: 2021-08-16T20:40:55+02:00
New Revision: 570c9beb8ebb4bdcc807101518cc36ad5e20797c

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

LOG: [MemorySSA] Remove unnecessary MSSA dependencies

LoopLoadElimination, LoopVersioning and LoopVectorize currently
fetch MemorySSA when construction LoopAccessAnalysis. However,
LoopAccessAnalysis does not actually use MemorySSA and we can pass
nullptr instead.

This saves one MemorySSA calculation in the default pipeline, and
thus improves compile-time.

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

Added: 


Modified: 
clang/test/CodeGen/thinlto-distributed-newpm.ll
llvm/lib/Transforms/Scalar/LoopLoadElimination.cpp
llvm/lib/Transforms/Utils/LoopVersioning.cpp
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
llvm/test/Transforms/LoopVectorize/novect-lcssa-cfg-invalidation.ll

Removed: 




diff  --git a/clang/test/CodeGen/thinlto-distributed-newpm.ll 
b/clang/test/CodeGen/thinlto-distributed-newpm.ll
index 4651a5d282faf..8f7fc5e9b8411 100644
--- a/clang/test/CodeGen/thinlto-distributed-newpm.ll
+++ b/clang/test/CodeGen/thinlto-distributed-newpm.ll
@@ -146,7 +146,6 @@
 ; CHECK-O: Running analysis: BranchProbabilityAnalysis on main
 ; CHECK-O: Running analysis: PostDominatorTreeAnalysis on main
 ; CHECK-O: Running analysis: DemandedBitsAnalysis on main
-; CHECK-O: Running analysis: MemorySSAAnalysis on main
 ; CHECK-O: Running pass: LoopLoadEliminationPass on main
 ; CHECK-O: Running pass: InstCombinePass on main
 ; CHECK-O: Running pass: SimplifyCFGPass on main

diff  --git a/llvm/lib/Transforms/Scalar/LoopLoadElimination.cpp 
b/llvm/lib/Transforms/Scalar/LoopLoadElimination.cpp
index aaf586173e442..9c4f18f8e2213 100644
--- a/llvm/lib/Transforms/Scalar/LoopLoadElimination.cpp
+++ b/llvm/lib/Transforms/Scalar/LoopLoadElimination.cpp
@@ -34,7 +34,6 @@
 #include "llvm/Analysis/LoopAccessAnalysis.h"
 #include "llvm/Analysis/LoopAnalysisManager.h"
 #include "llvm/Analysis/LoopInfo.h"
-#include "llvm/Analysis/MemorySSA.h"
 #include "llvm/Analysis/ProfileSummaryInfo.h"
 #include "llvm/Analysis/ScalarEvolution.h"
 #include "llvm/Analysis/ScalarEvolutionExpressions.h"
@@ -718,15 +717,12 @@ PreservedAnalyses LoopLoadEliminationPass::run(Function 
&F,
   auto *PSI = MAMProxy.getCachedResult(*F.getParent());
   auto *BFI = (PSI && PSI->hasProfileSummary()) ?
   &AM.getResult(F) : nullptr;
-  MemorySSA *MSSA = EnableMSSALoopDependency
-? &AM.getResult(F).getMSSA()
-: nullptr;
 
   auto &LAM = AM.getResult(F).getManager();
   bool Changed = eliminateLoadsAcrossLoops(
   F, LI, DT, BFI, PSI, &SE, &AC, [&](Loop &L) -> const LoopAccessInfo & {
 LoopStandardAnalysisResults AR = {AA,  AC,  DT,  LI,  SE,
-  TLI, TTI, nullptr, MSSA};
+  TLI, TTI, nullptr, nullptr};
 return LAM.getResult(L, AR);
   });
 

diff  --git a/llvm/lib/Transforms/Utils/LoopVersioning.cpp 
b/llvm/lib/Transforms/Utils/LoopVersioning.cpp
index 8a89158788cf8..14439796fb4ae 100644
--- a/llvm/lib/Transforms/Utils/LoopVersioning.cpp
+++ b/llvm/lib/Transforms/Utils/LoopVersioning.cpp
@@ -14,9 +14,9 @@
 
 #include "llvm/Transforms/Utils/LoopVersioning.h"
 #include "llvm/ADT/ArrayRef.h"
+#include "llvm/Analysis/AliasAnalysis.h"
 #include "llvm/Analysis/LoopAccessAnalysis.h"
 #include "llvm/Analysis/LoopInfo.h"
-#include "llvm/Analysis/MemorySSA.h"
 #include "llvm/Analysis/ScalarEvolution.h"
 #include "llvm/Analysis/TargetLibraryInfo.h"
 #include "llvm/IR/Dominators.h"
@@ -354,14 +354,11 @@ PreservedAnalyses LoopVersioningPass::run(Function &F,
   auto &TLI = AM.getResult(F);
   auto &AA = AM.getResult(F);
   auto &AC = AM.getResult(F);
-  MemorySSA *MSSA = EnableMSSALoopDependency
-? &AM.getResult(F).getMSSA()
-: nullptr;
 
   auto &LAM = AM.getResult(F).getManager();
   auto GetLAA = [&](Loop &L) -> const LoopAccessInfo & {
 LoopStandardAnalysisResults AR = {AA,  AC,  DT,  LI,  SE,
-  TLI, TTI, nullptr, MSSA};
+  TLI, TTI, nullptr, nullptr};
 return LAM.getResult(L, AR);
   };
 

diff  --git a/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp 
b/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
index aac382af50c2b..b842d15fe1874 100644
--- a/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
+++ b/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
@@ -87,7 +87,6 @@
 #include "llvm/Analysis/LoopAnalysisManager.h"
 #include "llvm/Analysis/LoopInfo.h"
 #include "llvm/Analysis/LoopIterator.h"
-#include "llvm/Analysis/MemorySSA.h"
 #include "llvm/Analysis/OptimizationRemarkEm

[PATCH] D108074: [MemorySSA] Remove unnecessary MSSA dependencies

2021-08-16 Thread Nikita Popov 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 rG570c9beb8ebb: [MemorySSA] Remove unnecessary MSSA 
dependencies (authored by nikic).
Herald added subscribers: cfe-commits, ormris, steven_wu.
Herald added a project: clang.

Changed prior to commit:
  https://reviews.llvm.org/D108074?vs=366439&id=366689#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108074

Files:
  clang/test/CodeGen/thinlto-distributed-newpm.ll
  llvm/lib/Transforms/Scalar/LoopLoadElimination.cpp
  llvm/lib/Transforms/Utils/LoopVersioning.cpp
  llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
  llvm/test/Transforms/LoopVectorize/novect-lcssa-cfg-invalidation.ll

Index: llvm/test/Transforms/LoopVectorize/novect-lcssa-cfg-invalidation.ll
===
--- llvm/test/Transforms/LoopVectorize/novect-lcssa-cfg-invalidation.ll
+++ llvm/test/Transforms/LoopVectorize/novect-lcssa-cfg-invalidation.ll
@@ -13,7 +13,6 @@
 ; CHECK-NOT:   Invalidating analysis: BranchProbabilityAnalysis on novect
 ; CHECK-NOT:   Invalidating analysis: BlockFrequencyAnalysis on novect
 ; CHECK:   Invalidating analysis: DemandedBitsAnalysis on novect
-; CHECK:   Invalidating analysis: MemorySSAAnalysis on novect
 ; CHECK:   Running pass: JumpThreadingPass on novect
 
 ; CHECK:   entry:
Index: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
===
--- llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
+++ llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
@@ -87,7 +87,6 @@
 #include "llvm/Analysis/LoopAnalysisManager.h"
 #include "llvm/Analysis/LoopInfo.h"
 #include "llvm/Analysis/LoopIterator.h"
-#include "llvm/Analysis/MemorySSA.h"
 #include "llvm/Analysis/OptimizationRemarkEmitter.h"
 #include "llvm/Analysis/ProfileSummaryInfo.h"
 #include "llvm/Analysis/ScalarEvolution.h"
@@ -10539,15 +10538,12 @@
 auto &AC = AM.getResult(F);
 auto &DB = AM.getResult(F);
 auto &ORE = AM.getResult(F);
-MemorySSA *MSSA = EnableMSSALoopDependency
-  ? &AM.getResult(F).getMSSA()
-  : nullptr;
 
 auto &LAM = AM.getResult(F).getManager();
 std::function GetLAA =
 [&](Loop &L) -> const LoopAccessInfo & {
   LoopStandardAnalysisResults AR = {AA,  AC,  DT,  LI,  SE,
-TLI, TTI, nullptr, MSSA};
+TLI, TTI, nullptr, nullptr};
   return LAM.getResult(L, AR);
 };
 auto &MAMProxy = AM.getResult(F);
Index: llvm/lib/Transforms/Utils/LoopVersioning.cpp
===
--- llvm/lib/Transforms/Utils/LoopVersioning.cpp
+++ llvm/lib/Transforms/Utils/LoopVersioning.cpp
@@ -14,9 +14,9 @@
 
 #include "llvm/Transforms/Utils/LoopVersioning.h"
 #include "llvm/ADT/ArrayRef.h"
+#include "llvm/Analysis/AliasAnalysis.h"
 #include "llvm/Analysis/LoopAccessAnalysis.h"
 #include "llvm/Analysis/LoopInfo.h"
-#include "llvm/Analysis/MemorySSA.h"
 #include "llvm/Analysis/ScalarEvolution.h"
 #include "llvm/Analysis/TargetLibraryInfo.h"
 #include "llvm/IR/Dominators.h"
@@ -354,14 +354,11 @@
   auto &TLI = AM.getResult(F);
   auto &AA = AM.getResult(F);
   auto &AC = AM.getResult(F);
-  MemorySSA *MSSA = EnableMSSALoopDependency
-? &AM.getResult(F).getMSSA()
-: nullptr;
 
   auto &LAM = AM.getResult(F).getManager();
   auto GetLAA = [&](Loop &L) -> const LoopAccessInfo & {
 LoopStandardAnalysisResults AR = {AA,  AC,  DT,  LI,  SE,
-  TLI, TTI, nullptr, MSSA};
+  TLI, TTI, nullptr, nullptr};
 return LAM.getResult(L, AR);
   };
 
Index: llvm/lib/Transforms/Scalar/LoopLoadElimination.cpp
===
--- llvm/lib/Transforms/Scalar/LoopLoadElimination.cpp
+++ llvm/lib/Transforms/Scalar/LoopLoadElimination.cpp
@@ -34,7 +34,6 @@
 #include "llvm/Analysis/LoopAccessAnalysis.h"
 #include "llvm/Analysis/LoopAnalysisManager.h"
 #include "llvm/Analysis/LoopInfo.h"
-#include "llvm/Analysis/MemorySSA.h"
 #include "llvm/Analysis/ProfileSummaryInfo.h"
 #include "llvm/Analysis/ScalarEvolution.h"
 #include "llvm/Analysis/ScalarEvolutionExpressions.h"
@@ -718,15 +717,12 @@
   auto *PSI = MAMProxy.getCachedResult(*F.getParent());
   auto *BFI = (PSI && PSI->hasProfileSummary()) ?
   &AM.getResult(F) : nullptr;
-  MemorySSA *MSSA = EnableMSSALoopDependency
-? &AM.getResult(F).getMSSA()
-: nullptr;
 
   auto &LAM = AM.getResult(F).getManager();
   bool Changed = eliminateLoadsAcrossLoops(
   F, LI, DT, BFI, PSI, &SE, &AC, [&](Loop &L) -> const LoopAcce

[PATCH] D106891: [Remarks] Emit optimization remarks for atomics generating CAS loop

2021-08-16 Thread Anshil Gandhi via Phabricator via cfe-commits
gandhi21299 updated this revision to Diff 366683.
gandhi21299 added a comment.

- ORE does not need to be a pointer anymore, it is constructed as local 
variable with this patch as requested by reviewer.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106891

Files:
  clang/test/CodeGenCUDA/atomics-remarks-gfx90a.cu
  clang/test/CodeGenOpenCL/atomics-remarks-gfx90a.cl
  llvm/lib/CodeGen/AtomicExpandPass.cpp
  llvm/test/CodeGen/AMDGPU/atomics-remarks-gfx90a.ll

Index: llvm/test/CodeGen/AMDGPU/atomics-remarks-gfx90a.ll
===
--- /dev/null
+++ llvm/test/CodeGen/AMDGPU/atomics-remarks-gfx90a.ll
@@ -0,0 +1,103 @@
+; RUN: llc -march=amdgcn -mcpu=gfx90a -verify-machineinstrs --pass-remarks=atomic-expand \
+; RUN:  %s -o - 2>&1 | FileCheck %s --check-prefix=GFX90A-CAS
+
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at system memory scope
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at agent memory scope
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at workgroup memory scope
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at wavefront memory scope
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at singlethread memory scope
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at one-as memory scope
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at agent-one-as memory scope
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at workgroup-one-as memory scope
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at wavefront-one-as memory scope
+; GFX90A-CAS: A compare and swap loop was generated for an atomic fadd operation at singlethread-one-as memory scope
+
+; GFX90A-CAS-LABEL: atomic_add_cas:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], v[4:5] glc
+; GFX90A-CAS: s_cbranch_execnz
+define dso_local void @atomic_add_cas(float* %p, float %q) {
+entry:
+  %ret = atomicrmw fadd float* %p, float %q monotonic, align 4
+  ret void
+}
+
+; GFX90A-CAS-LABEL: atomic_add_cas_agent:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], v[4:5] glc
+; GFX90A-CAS: s_cbranch_execnz
+define dso_local void @atomic_add_cas_agent(float* %p, float %q) {
+entry:
+  %ret = atomicrmw fadd float* %p, float %q syncscope("agent") monotonic, align 4
+  ret void
+}
+
+; GFX90A-CAS-LABEL: atomic_add_cas_workgroup:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], v[4:5] glc
+; GFX90A-CAS: s_cbranch_execnz
+define dso_local void @atomic_add_cas_workgroup(float* %p, float %q) {
+entry:
+  %ret = atomicrmw fadd float* %p, float %q syncscope("workgroup") monotonic, align 4
+  ret void
+}
+
+; GFX90A-CAS-LABEL: atomic_add_cas_wavefront:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], v[4:5] glc
+; GFX90A-CAS: s_cbranch_execnz
+define dso_local void @atomic_add_cas_wavefront(float* %p, float %q) {
+entry:
+  %ret = atomicrmw fadd float* %p, float %q syncscope("wavefront") monotonic, align 4
+  ret void
+}
+
+; GFX90A-CAS-LABEL: atomic_add_cas_singlethread:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], v[4:5] glc
+; GFX90A-CAS: s_cbranch_execnz
+define dso_local void @atomic_add_cas_singlethread(float* %p, float %q) {
+entry:
+  %ret = atomicrmw fadd float* %p, float %q syncscope("singlethread") monotonic, align 4
+  ret void
+}
+
+; GFX90A-CAS-LABEL: atomic_add_cas_one_as:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], v[4:5] glc
+; GFX90A-CAS: s_cbranch_execnz
+define dso_local void @atomic_add_cas_one_as(float* %p, float %q) {
+entry:
+  %ret = atomicrmw fadd float* %p, float %q syncscope("one-as") monotonic, align 4
+  ret void
+}
+
+; GFX90A-CAS-LABEL: atomic_add_cas_agent_one_as:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], v[4:5] glc
+; GFX90A-CAS: s_cbranch_execnz
+define dso_local void @atomic_add_cas_agent_one_as(float* %p, float %q) {
+entry:
+  %ret = atomicrmw fadd float* %p, float %q syncscope("agent-one-as") monotonic, align 4
+  ret void
+}
+
+; GFX90A-CAS-LABEL: atomic_add_cas_workgroup_one_as:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], v[4:5] glc
+; GFX90A-CAS: s_cbranch_execnz
+define dso_local void @atomic_add_cas_workgroup_one_as(float* %p, float %q) {
+entry:
+  %ret = atomicrmw fadd float* %p, float %q syncscope("workgroup-one-as") monotonic, align 4
+  ret void
+}
+
+; GFX90A-CAS-LABEL: atomic_add_cas_wavefront_one_as:
+; GFX90A-CAS: flat_atomic_cmpswap v3, v[0:1], v[4:5] glc
+; GFX90A-CAS: s_cbranch_execnz
+define dso_local void @atomic_add_cas_wavefront_one_as(float* %p, float %q) {
+entry:
+  %ret = atomicrmw fadd float* %p, float %q syncscope("wavefront-one-as") monotonic, align 4
+  ret void
+}
+
+; GFX90A-CAS-LABEL: atomic_add_cas_singlethread_one_as:
+; GFX90A-CAS: flat_atomic_cmp

[PATCH] D106891: [Remarks] Emit optimization remarks for atomics generating CAS loop

2021-08-16 Thread Stanislav Mekhanoshin via Phabricator via cfe-commits
rampitec accepted this revision.
rampitec added a comment.

LGTM, but please wait for others too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106891

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


[PATCH] D106891: [Remarks] Emit optimization remarks for atomics generating CAS loop

2021-08-16 Thread Anshil Gandhi via Phabricator via cfe-commits
gandhi21299 added a comment.

Will do, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106891

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


[PATCH] D108150: [Remarks] Emit optimization remarks for atomics generating hardware instructions

2021-08-16 Thread Anshil Gandhi via Phabricator via cfe-commits
gandhi21299 created this revision.
gandhi21299 added reviewers: rampitec, arsenm, b-sumner.
Herald added subscribers: foad, kerbowa, jfb, hiraditya, Anastasia, nhaehnle, 
jvesely.
gandhi21299 requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, wdng.
Herald added projects: clang, LLVM.

- produce remarks when atomic instructions are expanded into hardware 
instructions in SIISelLowering.cpp
- an OpenCL test containing both IR-level and ISA level checks
- currently only support for atomic fadd


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108150

Files:
  clang/test/CodeGenOpenCL/atomics-remarks-gfx90a.cl
  llvm/lib/Target/AMDGPU/SIISelLowering.cpp

Index: llvm/lib/Target/AMDGPU/SIISelLowering.cpp
===
--- llvm/lib/Target/AMDGPU/SIISelLowering.cpp
+++ llvm/lib/Target/AMDGPU/SIISelLowering.cpp
@@ -19,6 +19,7 @@
 #include "SIRegisterInfo.h"
 #include "llvm/ADT/Statistic.h"
 #include "llvm/Analysis/LegacyDivergenceAnalysis.h"
+#include "llvm/Analysis/OptimizationRemarkEmitter.h"
 #include "llvm/BinaryFormat/ELF.h"
 #include "llvm/CodeGen/Analysis.h"
 #include "llvm/CodeGen/FunctionLoweringInfo.h"
@@ -12118,6 +12119,26 @@
   return DenormMode == DenormalMode::getIEEE();
 }
 
+static TargetLowering::AtomicExpansionKind
+reportUnsafeHWInst(AtomicRMWInst *RMW,
+   TargetLowering::AtomicExpansionKind Kind) {
+  OptimizationRemarkEmitter ORE(RMW->getFunction());
+  LLVMContext &Ctx = RMW->getFunction()->getContext();
+  SmallVector SSNs;
+  Ctx.getSyncScopeNames(SSNs);
+  auto MemScope = SSNs[RMW->getSyncScopeID()].empty()
+  ? "system"
+  : SSNs[RMW->getSyncScopeID()];
+  ORE.emit([&]() {
+return OptimizationRemark(DEBUG_TYPE, "Passed", RMW->getFunction())
+   << "Hardware instruction generated for atomic "
+   << RMW->getOperationName(RMW->getOperation())
+   << " operation at memory scope " << MemScope
+   << " due to an unsafe request.";
+  });
+  return Kind;
+}
+
 TargetLowering::AtomicExpansionKind
 SITargetLowering::shouldExpandAtomicRMWInIR(AtomicRMWInst *RMW) const {
   switch (RMW->getOperation()) {
@@ -12154,14 +12175,15 @@
 SSID == RMW->getContext().getOrInsertSyncScopeID("one-as"))
   return AtomicExpansionKind::CmpXChg;
 
-return AtomicExpansionKind::None;
+return reportUnsafeHWInst(RMW, AtomicExpansionKind::None);
   }
 
   if (AS == AMDGPUAS::FLAT_ADDRESS)
 return AtomicExpansionKind::CmpXChg;
 
-  return RMW->use_empty() ? AtomicExpansionKind::None
-  : AtomicExpansionKind::CmpXChg;
+  return RMW->use_empty()
+ ? reportUnsafeHWInst(RMW, AtomicExpansionKind::None)
+ : AtomicExpansionKind::CmpXChg;
 }
 
 // DS FP atomics do repect the denormal mode, but the rounding mode is fixed
@@ -12169,13 +12191,13 @@
 // The only exception is DS_ADD_F64 which never flushes regardless of mode.
 if (AS == AMDGPUAS::LOCAL_ADDRESS && Subtarget->hasLDSFPAtomics()) {
   if (!Ty->isDoubleTy())
-return AtomicExpansionKind::None;
+return reportUnsafeHWInst(RMW, AtomicExpansionKind::None);
 
   return (fpModeMatchesGlobalFPAtomicMode(RMW) ||
   RMW->getFunction()
   ->getFnAttribute("amdgpu-unsafe-fp-atomics")
   .getValueAsString() == "true")
- ? AtomicExpansionKind::None
+ ? reportUnsafeHWInst(RMW, AtomicExpansionKind::None)
  : AtomicExpansionKind::CmpXChg;
 }
 
Index: clang/test/CodeGenOpenCL/atomics-remarks-gfx90a.cl
===
--- /dev/null
+++ clang/test/CodeGenOpenCL/atomics-remarks-gfx90a.cl
@@ -0,0 +1,46 @@
+// RUN: %clang_cc1 -cl-std=CL2.0 -O0 -triple=amdgcn-amd-amdhsa -target-cpu gfx90a \
+// RUN: -Rpass=si-lower -munsafe-fp-atomics %s -S -o - 2>&1 | \
+// RUN: FileCheck %s --check-prefix=GFX90A-HW-REMARK
+
+// RUN: %clang_cc1 %s -cl-std=CL2.0 -O0 -triple=amdgcn-amd-amdhsa -target-cpu gfx90a \
+// RUN: -Rpass=si-lower -S -emit-llvm -o - 2>&1 | \
+// RUN: FileCheck %s --check-prefix=GFX90A-HW
+
+// REQUIRES: amdgpu-registered-target
+
+typedef enum memory_order {
+  memory_order_relaxed = __ATOMIC_RELAXED,
+  memory_order_acquire = __ATOMIC_ACQUIRE,
+  memory_order_release = __ATOMIC_RELEASE,
+  memory_order_acq_rel = __ATOMIC_ACQ_REL,
+  memory_order_seq_cst = __ATOMIC_SEQ_CST
+} memory_order;
+
+typedef enum memory_scope {
+  memory_scope_work_item = __OPENCL_MEMORY_SCOPE_WORK_ITEM,
+  memory_scope_work_group = __OPENCL_MEMORY_SCOPE_WORK_GROUP,
+  memory_scope_device = __OPENCL_MEMORY_SCOPE_DEVICE,
+  memory_scope_all_svm_devices = __OPENCL_MEMORY_SCOPE_ALL_SVM_DEVICES,
+#if defined(cl_intel_subgroups) || defined(cl_khr_subgroups)
+  memory_scope_sub_group = __OPENCL_MEMO

[PATCH] D108151: [NFC][clang] Use X86 Features declaration from X86TargetParser

2021-08-16 Thread Andrei Elovikov via Phabricator via cfe-commits
a.elovikov created this revision.
a.elovikov added reviewers: erichkeane, craig.topper.
Herald added a subscriber: pengfei.
a.elovikov requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

...instead of redeclaring them in clang's own X86Target.def. They were already
required to be in sync (IIUC), so no reason to maintain two identical lists.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108151

Files:
  clang/include/clang/Basic/X86Target.def
  clang/lib/Basic/Targets/X86.cpp


Index: clang/lib/Basic/Targets/X86.cpp
===
--- clang/lib/Basic/Targets/X86.cpp
+++ clang/lib/Basic/Targets/X86.cpp
@@ -1057,17 +1057,13 @@
 
 static unsigned getFeaturePriority(llvm::X86::ProcessorFeatures Feat) {
   enum class FeatPriority {
-#define FEATURE(FEAT) FEAT,
-#include "clang/Basic/X86Target.def"
+#define X86_FEATURE_COMPAT(ENUM, STR) ENUM,
+#include "llvm/Support/X86TargetParser.def"
+MAX
   };
-  switch (Feat) {
-#define FEATURE(FEAT)  
\
-  case llvm::X86::FEAT:
\
-return static_cast(FeatPriority::FEAT);
-#include "clang/Basic/X86Target.def"
-  default:
-llvm_unreachable("No Feature Priority for non-CPUSupports Features");
-  }
+  assert(Feat < static_cast(FeatPriority::MAX) &&
+ "No Feature Priority for non-CPUSupports Features");
+  return static_cast(Feat);
 }
 
 unsigned X86TargetInfo::multiVersionSortPriority(StringRef Name) const {
Index: clang/include/clang/Basic/X86Target.def
===
--- clang/include/clang/Basic/X86Target.def
+++ clang/include/clang/Basic/X86Target.def
@@ -11,10 +11,6 @@
 //
 
//===--===//
 
-#ifndef FEATURE
-#define FEATURE(ENUM)
-#endif
-
 #ifndef CPU_SPECIFIC
 #define CPU_SPECIFIC(NAME, MANGLING, FEATURES)
 #endif
@@ -23,50 +19,6 @@
 #define CPU_SPECIFIC_ALIAS(NEW_NAME, NAME)
 #endif
 
-// List of CPU Supports features in order.  These need to remain in the order
-// required by attribute 'target' checking.  Note that not all are supported/
-// prioritized by GCC, so synchronization with GCC's implementation may require
-// changing some existing values.
-FEATURE(FEATURE_CMOV)
-FEATURE(FEATURE_MMX)
-FEATURE(FEATURE_SSE)
-FEATURE(FEATURE_SSE2)
-FEATURE(FEATURE_SSE3)
-FEATURE(FEATURE_SSSE3)
-FEATURE(FEATURE_SSE4_A)
-FEATURE(FEATURE_SSE4_1)
-FEATURE(FEATURE_SSE4_2)
-FEATURE(FEATURE_POPCNT)
-FEATURE(FEATURE_AES)
-FEATURE(FEATURE_PCLMUL)
-FEATURE(FEATURE_AVX)
-FEATURE(FEATURE_BMI)
-FEATURE(FEATURE_FMA4)
-FEATURE(FEATURE_XOP)
-FEATURE(FEATURE_FMA)
-FEATURE(FEATURE_BMI2)
-FEATURE(FEATURE_AVX2)
-FEATURE(FEATURE_AVX512F)
-FEATURE(FEATURE_AVX512VL)
-FEATURE(FEATURE_AVX512BW)
-FEATURE(FEATURE_AVX512DQ)
-FEATURE(FEATURE_AVX512CD)
-FEATURE(FEATURE_AVX512ER)
-FEATURE(FEATURE_AVX512PF)
-FEATURE(FEATURE_AVX512VBMI)
-FEATURE(FEATURE_AVX512IFMA)
-FEATURE(FEATURE_AVX5124VNNIW)
-FEATURE(FEATURE_AVX5124FMAPS)
-FEATURE(FEATURE_AVX512VPOPCNTDQ)
-FEATURE(FEATURE_AVX512VBMI2)
-FEATURE(FEATURE_GFNI)
-FEATURE(FEATURE_VPCLMULQDQ)
-FEATURE(FEATURE_AVX512VNNI)
-FEATURE(FEATURE_AVX512BITALG)
-FEATURE(FEATURE_AVX512BF16)
-FEATURE(FEATURE_AVX512VP2INTERSECT)
-
-
 // FIXME: When commented out features are supported in LLVM, enable them here.
 CPU_SPECIFIC("generic", 'A', "")
 CPU_SPECIFIC("pentium", 'B', "")
@@ -107,4 +59,3 @@
 #undef CPU_SPECIFIC
 #undef PROC_64_BIT
 #undef PROC_32_BIT
-#undef FEATURE


Index: clang/lib/Basic/Targets/X86.cpp
===
--- clang/lib/Basic/Targets/X86.cpp
+++ clang/lib/Basic/Targets/X86.cpp
@@ -1057,17 +1057,13 @@
 
 static unsigned getFeaturePriority(llvm::X86::ProcessorFeatures Feat) {
   enum class FeatPriority {
-#define FEATURE(FEAT) FEAT,
-#include "clang/Basic/X86Target.def"
+#define X86_FEATURE_COMPAT(ENUM, STR) ENUM,
+#include "llvm/Support/X86TargetParser.def"
+MAX
   };
-  switch (Feat) {
-#define FEATURE(FEAT)  \
-  case llvm::X86::FEAT:\
-return static_cast(FeatPriority::FEAT);
-#include "clang/Basic/X86Target.def"
-  default:
-llvm_unreachable("No Feature Priority for non-CPUSupports Features");
-  }
+  assert(Feat < static_cast(FeatPriority::MAX) &&
+ "No Feature Priority for non-CPUSupports Features");
+  return static_cast(Feat);
 }
 
 unsigned X86TargetInfo::multiVersionSortPriority(StringRef Name) const {
Index: clang/include/clang/Basic/X86Target.def
===
--- clang/include/clang/Basic/X86Target.def
+++ clang/include/clang/Basic/X86Target.def
@@ -11,10 +11,6 @@
 //
 //===--

[PATCH] D108151: [NFC][clang] Use X86 Features declaration from X86TargetParser

2021-08-16 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

Are these in the same order in X86TargetParser.Def?  Can we make some comment 
in that file to make sure that we keep them in the order (see comment in 
original x86Target.def)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108151

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


[PATCH] D106030: [Clang] add support for error+warning fn attrs

2021-08-16 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/test/Sema/attr-error.c:31-32
+
+__attribute__((error("foo"))) int bad5(void);   // expected-error {{'error' 
and 'warning' attributes are not compatible}}
+__attribute__((warning("foo"))) int bad5(void); // expected-note {{conflicting 
attribute is here}}
+

nickdesaulniers wrote:
> aaron.ballman wrote:
> > I think the diagnostic order is backwards here. The first declaration is 
> > where I'd expect the note and the second declaration is where I'd expect 
> > the error. (The idea is: the first declaration adds an attribute to the 
> > decl, so the redeclaration is what introduces the conflict and so that's 
> > where the error should live.) As an example: https://godbolt.org/z/bjGTWxYvh
> I'm not sure how to reconcile this. Looking at `bad4` above (different case 
> than `bad5`), the diagnostic we get is:
> ```
> /tmp/y.c:1:30: error: 'warning' and 'error' attributes are not compatible
> __attribute__((error("foo"), warning("foo")))
>  ^
> /tmp/y.c:1:16: note: conflicting attribute is here
> __attribute__((error("foo"), warning("foo")))
>^
> 1 error generated.
> ```
> which looks correct to me. If I flip the order these are diagnosed in, that 
> fixes `bad5` but if I flip around the ordering:
> ```
> --- a/clang/lib/Sema/SemaDeclAttr.cpp
> +++ b/clang/lib/Sema/SemaDeclAttr.cpp
> -  Diag(CI.getLoc(), diag::err_attributes_are_not_compatible) << CI << EA;
> -  Diag(EA->getLocation(), diag::note_conflicting_attribute);
> +  Diag(EA->getLocation(), diag::err_attributes_are_not_compatible)
> +  << CI << EA;
> +  Diag(CI.getLoc(), diag::note_conflicting_attribute);
> ```
> Then `bad4` doesn't look quite correct.
> ```
> /tmp/y.c:1:16: error: 'warning' and 'error' attributes are not compatible
> __attribute__((error("foo"), warning("foo")))
>^
> /tmp/y.c:1:30: note: conflicting attribute is here
> __attribute__((error("foo"), warning("foo")))
>  ^
> ```
> Perhaps in the callers of `handleErrorAttr` I'm confusing which `Decl` is the 
> "new" vs the "old?"
> which looks correct to me.

That also looks correct to me; the second attribute is the diagnostic and the 
first attribute is the note.

> Perhaps in the callers of handleErrorAttr I'm confusing which Decl is the 
> "new" vs the "old?"

Huh, this is rather strange. The logic you're using is basically the same as 
`checkAttrMutualExclusion()`, just with extra work to figure out which kind of 
attribute you're dealing with. I'm not seeing what's causing the order to be 
different when I reason my way through the code. Perhaps in the `bad4()` case, 
are we somehow processing the attributes in reverse order?

FWIW, at the end of the day, we can live with the diagnostic in either 
situation, even if they're a bit strange. I think the merge behavior (two 
different decls) is more important to get right because that's going to be the 
far more common scenario to see the diagnostic in. If it turns out that it's a 
systemic issue (or just gnarly to figure out), it won't block this review. We 
can always improve the behavior in a follow-up.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106030

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


[PATCH] D96033: [clang-repl] Land initial infrastructure for incremental parsing

2021-08-16 Thread Vassil Vassilev via Phabricator via cfe-commits
v.g.vassilev added a comment.

In D96033#2944625 , @phosek wrote:

> In D96033#298 , @leonardchan 
> wrote:
>
>> We're still hitting the OOMs when building clang-repl with LTO even with 
>> `-DLLVM_PARALLEL_LINK_JOBS=32`. While we don't build this target explicitly 
>> in our toolchain, it is built when running tests via `stage2-check-clang`. 
>> Is there perhaps a simple cmake flag that allows us to not run clang-repl 
>> tests so we don't build it?
>
> To clarify, this is on a machine with 512GB RAM.

@leonardchan, @phosek, I am not aware of such flag. Do you know how much memory 
does LTO + clang-repl consume and would it make sense to ping some of the LTO 
folks for their advice?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96033

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


[PATCH] D104285: [analyzer][AST] Retrieve value by direct index from list initialization of constant array declaration.

2021-08-16 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D104285#2947255 , @ASDenysPetrov 
wrote:

> In D104285#2943449 , @aaron.ballman 
> wrote:
>
>> One thing I think is worth asking in this thread is whether what you're 
>> analyzing is undefined behavior?
>
> Technically you are right. Every exit out of an array extent is UB according 
> to the Standard.

At least in C++; I'd have to double-check for C.

> But in practice we can rely on the fact that multidimensional arrays have a 
> continuous layout in memory on stack.

"But in practice we can rely on " is a very dangerous 
assumption for users to make, and I think we shouldn't codify that in the 
design of the static analyzer. We might be able to make that guarantee for 
*clang*, but we can't make that guarantee for all implementations. One of the 
big uses of a static analyzer is with pointing out UB due to portability 
concerns.

> Also every compiler treats `int[2][2]` and `int**` differently. E.g.:
>
>   int arr[6][7];
>   arr[2][3]; // *(arr + (2*7 + 3)) = *(arr + 17)
>   
>   int *ptr = arr;
>   ptr[17]; //  *(arr + 17)
>   
>   int **ptr;
>   ptr[2][3] // *(*(ptr + 2) + 3)
>
> Many engineers expoit this fact and treat multidimensional arrays on stack 
> through a raw pointer (`(int*)arr`). We can foresee their intentions and 
> treat a multidimensional array as a single one instead of a warning about UB.

We can do that only if we're convinced that's a sound static analysis (and I'm 
not convinced). Optimizers can optimize based on the inference that code must 
be UB free, so I worry that there are optimization situations where the 
analyzer will fail to warn the user because we're assuming this is safe based 
purely on memory layout. However, things like TBAA, vectorization, etc may have 
a different analysis than strictly the memory layout.

>> And when you turn some of these examples into constant expressions, we 
>> reject them based on the bounds. e.g., https://godbolt.org/z/nYPcY14a8
>
> Yes, when we use expicit constants there we can catch such a warning, because 
> AST parser can timely recognize the issue. The parser is not smart enough to 
> treat variables. Static Analyzer is in charge of this and executes after the 
> parser.

I'm aware.

> I think AST parser shall also ignore the Standard in this particular case 
> with an eye on a real use cases and developers' intentions.

It would be a bug in Clang to do so; the standard requires a diagnostic if a 
constant evaluation cannot be performed due to UB: 
http://eel.is/c++draft/expr.const#5.7

> As you can see there is a bit modified version which doesn't emit the warning 
> https://godbolt.org/z/Mdhhe6Eo9.

Correct; I would not expect Clang to diagnose that because it doesn't require 
constant evaluation. I was pointing out the `constexpr` diagnostics because it 
demonstrates that this code has undefined behavior and you're modelling it as 
though the behavior were concretely defined.


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

https://reviews.llvm.org/D104285

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


[PATCH] D108150: [Remarks] Emit optimization remarks for atomics generating hardware instructions

2021-08-16 Thread Stanislav Mekhanoshin via Phabricator via cfe-commits
rampitec added a comment.

- Add [AMDGPU] to the title.
- Rebase on top of D106891 .
- Add tests to atomics-remarks-gfx90a.ll as well, including LDS with matching 
and non-matching rounding mode.




Comment at: llvm/lib/Target/AMDGPU/SIISelLowering.cpp:12194
   if (!Ty->isDoubleTy())
-return AtomicExpansionKind::None;
+return reportUnsafeHWInst(RMW, AtomicExpansionKind::None);
 

This is safe.



Comment at: llvm/lib/Target/AMDGPU/SIISelLowering.cpp:12200
   .getValueAsString() == "true")
- ? AtomicExpansionKind::None
+ ? reportUnsafeHWInst(RMW, AtomicExpansionKind::None)
  : AtomicExpansionKind::CmpXChg;

This is safe if `fpModeMatchesGlobalFPAtomicMode(RMW)` returned true and unsafe 
if not.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108150

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


[PATCH] D106030: [Clang] add support for error+warning fn attrs

2021-08-16 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers updated this revision to Diff 366717.
nickdesaulniers added a comment.

- reorder diag vs note


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106030

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticFrontendKinds.td
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGen/attr-error.c
  clang/test/CodeGen/attr-warning.c
  clang/test/Frontend/backend-attribute-error-warning-optimize.c
  clang/test/Frontend/backend-attribute-error-warning.c
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/Misc/serialized-diags-driver.c
  clang/test/Sema/attr-error.c
  clang/test/Sema/attr-warning.c
  llvm/docs/LangRef.rst
  llvm/include/llvm/IR/DiagnosticInfo.h
  llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp
  llvm/lib/CodeGen/SelectionDAG/FastISel.cpp
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
  llvm/lib/IR/DiagnosticInfo.cpp
  llvm/test/CodeGen/X86/attr-dontcall.ll
  llvm/test/ThinLTO/X86/dontcall.ll

Index: llvm/test/ThinLTO/X86/dontcall.ll
===
--- /dev/null
+++ llvm/test/ThinLTO/X86/dontcall.ll
@@ -0,0 +1,33 @@
+; RUN: split-file %s %t
+; RUN: opt -module-summary %t/a.s -o %t/a.bc
+; RUN: opt -module-summary %t/b.s -o %t/b.bc
+; RUN: not llvm-lto2 run %t/a.bc %t/b.bc -o %t/out -save-temps 2>&1 \
+; RUN:   -r=%t/a.bc,callee,px \
+; RUN:   -r=%t/b.bc,callee,x  \
+; RUN:   -r=%t/b.bc,caller,px
+
+; TODO: As part of LTO, we check that types match, but *we don't yet check that
+; attributes match!!! What should happen if we remove "dontcall" from the
+; definition or declaration of @callee?
+
+; CHECK: call to callee marked "dontcall"
+
+;--- a.s
+target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+define i32 @callee() "dontcall" noinline {
+  ret i32 42
+}
+
+;--- b.s
+target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+declare i32 @callee() "dontcall"
+
+define i32 @caller() {
+entry:
+  %0 = call i32 @callee()
+  ret i32 %0
+}
Index: llvm/test/CodeGen/X86/attr-dontcall.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/attr-dontcall.ll
@@ -0,0 +1,11 @@
+; RUN: not llc -global-isel=0 -fast-isel=0 -stop-after=finalize-isel %s 2>&1 | FileCheck %s
+; RUN: not llc -global-isel=0 -fast-isel=1 -stop-after=finalize-isel %s 2>&1 | FileCheck %s
+; RUN: not llc -global-isel=1 -fast-isel=0 -stop-after=irtranslator %s 2>&1 | FileCheck %s
+
+declare void @foo() "dontcall"
+define void @bar() {
+  call void @foo()
+  ret void
+}
+
+; CHECK: error: call to foo marked "dontcall"
Index: llvm/lib/IR/DiagnosticInfo.cpp
===
--- llvm/lib/IR/DiagnosticInfo.cpp
+++ llvm/lib/IR/DiagnosticInfo.cpp
@@ -401,3 +401,7 @@
 
 void OptimizationRemarkAnalysisFPCommute::anchor() {}
 void OptimizationRemarkAnalysisAliasing::anchor() {}
+
+void DiagnosticInfoDontCall::print(DiagnosticPrinter &DP) const {
+  DP << "call to " << getFunctionName() << " marked \"dontcall\"";
+}
Index: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
===
--- llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
+++ llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
@@ -69,6 +69,7 @@
 #include "llvm/IR/DataLayout.h"
 #include "llvm/IR/DebugInfoMetadata.h"
 #include "llvm/IR/DerivedTypes.h"
+#include "llvm/IR/DiagnosticInfo.h"
 #include "llvm/IR/Function.h"
 #include "llvm/IR/GetElementPtrTypeIterator.h"
 #include "llvm/IR/InlineAsm.h"
@@ -7945,6 +7946,15 @@
   }
 
   if (Function *F = I.getCalledFunction()) {
+if (F->hasFnAttribute("dontcall")) {
+  unsigned LocCookie = 0;
+  if (MDNode *MD = I.getMetadata("srcloc"))
+LocCookie =
+mdconst::extract(MD->getOperand(0))->getZExtValue();
+  DiagnosticInfoDontCall D(F->getName(), LocCookie);
+  DAG.getContext()->diagnose(D);
+}
+
 if (F->isDeclaration()) {
   // Is this an LLVM intrinsic or a target-specific intrinsic?
   unsigned IID = F->getIntrinsicID();
Index: llvm/lib/CodeGen/SelectionDAG/FastISel.cpp
===
--- llvm/lib/CodeGen/SelectionDAG/FastISel.cpp
+++ llvm/lib/CodeGen/SelectionDAG/FastISel.cpp
@@ -75,6 +75,7 @@
 #include "llvm/IR/DebugInfo.h"
 #include "llvm/IR/DebugLoc.h"
 #include "llvm/IR/DerivedTypes.h"
+#include "llvm/IR/Di

[PATCH] D107933: [clang] Expose unreachable fallthrough annotation warning

2021-08-16 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

Patch description probably needs an update - looks like it's out of date ("Add 
-Wimplicit-fallthrough-unreachable, which is default enabled with 
-Wimplicit-fallthrough" should read, I guess "Add 
-Wunreachable-code-fallthrough, which is default enabled with 
-Wunreachable-code" - also, I might avoid using the "default enabled" as it may 
lead to some confusion/sound like it's suggesting that "this subwarning is on 
by default as it's grouped under this other on-by-default warning", which isn't 
the case - maybe "which is enabled with -Wunreachable-code" would suffice? or 
"which is part of the -Wunreachable-code group")


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107933

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


[PATCH] D106891: [Remarks] Emit optimization remarks for atomics generating CAS loop

2021-08-16 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm accepted this revision.
arsenm added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106891

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


[clang] 93d08ac - [clang-offload-wrapper] Add standard notes for ELF offload images

2021-08-16 Thread Vyacheslav Zakharin via cfe-commits

Author: Vyacheslav Zakharin
Date: 2021-08-16T13:09:01-07:00
New Revision: 93d08acaacec951dbb302f77eeae51974985b6b2

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

LOG: [clang-offload-wrapper] Add standard notes for ELF offload images

The patch adds ELF notes into SHT_NOTE sections of ELF offload images
passed to clang-offload-wrapper.

The new notes use a null-terminated "LLVMOMPOFFLOAD" note name.
There are currently three types of notes:

VERSION: a string (not null-terminated) representing the ELF offload
image structure. The current version '1.0' does not put any restrictions
on the structure of the image. If we ever need to come up with a common
structure for ELF offload images (e.g. to be able to analyze the images
in libomptarget in some standard way), then we will introduce new versions.

PRODUCER: a vendor specific name of the producing toolchain.
Upstream LLVM uses "LLVM" (not null-terminated).

PRODUCER_VERSION: a vendor specific version of the producing toolchain.
Upstream LLVM uses LLVM_VERSION_STRING with optional  LLVM_REVISION.

All three notes are not mandatory currently.

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

Added: 
clang/test/Driver/Inputs/empty-elf-template.yaml

Modified: 
clang/test/Driver/clang-offload-wrapper.c
clang/tools/clang-offload-wrapper/CMakeLists.txt
clang/tools/clang-offload-wrapper/ClangOffloadWrapper.cpp

Removed: 




diff  --git a/clang/test/Driver/Inputs/empty-elf-template.yaml 
b/clang/test/Driver/Inputs/empty-elf-template.yaml
new file mode 100644
index 0..f77de07a430f6
--- /dev/null
+++ b/clang/test/Driver/Inputs/empty-elf-template.yaml
@@ -0,0 +1,5 @@
+--- !ELF
+FileHeader:
+  Class: ELFCLASS[[BITS]]
+  Data:  ELFDATA2[[ENCODING]]
+  Type:  ET_REL

diff  --git a/clang/test/Driver/clang-offload-wrapper.c 
b/clang/test/Driver/clang-offload-wrapper.c
index 9a36559e34dd7..c671d88209744 100644
--- a/clang/test/Driver/clang-offload-wrapper.c
+++ b/clang/test/Driver/clang-offload-wrapper.c
@@ -19,9 +19,10 @@
 //
 // Check bitcode produced by the wrapper tool.
 //
-// RUN: clang-offload-wrapper -target=x86_64-pc-linux-gnu -o %t.wrapper.bc 
%t.tgt
+// RUN: clang-offload-wrapper -target=x86_64-pc-linux-gnu -o %t.wrapper.bc 
%t.tgt 2>&1 | FileCheck %s --check-prefix ELF-WARNING
 // RUN: llvm-dis %t.wrapper.bc -o - | FileCheck %s --check-prefix CHECK-IR
 
+// ELF-WARNING: is not an ELF image, so notes cannot be added to it.
 // CHECK-IR: target triple = "x86_64-pc-linux-gnu"
 
 // CHECK-IR-DAG: [[ENTTY:%.+]] = type { i8*, i8*, i{{32|64}}, i32, i32 }
@@ -53,3 +54,24 @@
 // CHECK-IR:   ret void
 
 // CHECK-IR: declare void @__tgt_unregister_lib([[DESCTY]]*)
+
+// Check that clang-offload-wrapper adds LLVMOMPOFFLOAD notes
+// into the ELF offload images:
+// RUN: yaml2obj %S/Inputs/empty-elf-template.yaml -o %t.64le -DBITS=64 
-DENCODING=LSB
+// RUN: clang-offload-wrapper -target=x86_64-pc-linux-gnu -o 
%t.wrapper.elf64le.bc %t.64le
+// RUN: llvm-dis %t.wrapper.elf64le.bc -o - | FileCheck %s --check-prefix 
OMPNOTES
+// RUN: yaml2obj %S/Inputs/empty-elf-template.yaml -o %t.64be -DBITS=64 
-DENCODING=MSB
+// RUN: clang-offload-wrapper -target=x86_64-pc-linux-gnu -o 
%t.wrapper.elf64be.bc %t.64be
+// RUN: llvm-dis %t.wrapper.elf64be.bc -o - | FileCheck %s --check-prefix 
OMPNOTES
+// RUN: yaml2obj %S/Inputs/empty-elf-template.yaml -o %t.32le -DBITS=32 
-DENCODING=LSB
+// RUN: clang-offload-wrapper -target=x86_64-pc-linux-gnu -o 
%t.wrapper.elf32le.bc %t.32le
+// RUN: llvm-dis %t.wrapper.elf32le.bc -o - | FileCheck %s --check-prefix 
OMPNOTES
+// RUN: yaml2obj %S/Inputs/empty-elf-template.yaml -o %t.32be -DBITS=32 
-DENCODING=MSB
+// RUN: clang-offload-wrapper -target=x86_64-pc-linux-gnu -o 
%t.wrapper.elf32be.bc %t.32be
+// RUN: llvm-dis %t.wrapper.elf32be.bc -o - | FileCheck %s --check-prefix 
OMPNOTES
+
+// There is no clean way for extracting the offload image
+// from the object file currently, so try to find
+// the inserted ELF notes in the device image variable's
+// initializer:
+// OMPNOTES: @{{.+}} = internal unnamed_addr constant [{{[0-9]+}} x i8] 
c"{{.*}}LLVMOMPOFFLOAD{{.*}}LLVMOMPOFFLOAD{{.*}}LLVMOMPOFFLOAD{{.*}}"

diff  --git a/clang/tools/clang-offload-wrapper/CMakeLists.txt 
b/clang/tools/clang-offload-wrapper/CMakeLists.txt
index 8bcb46267a37c..144edf5ab60c0 100644
--- a/clang/tools/clang-offload-wrapper/CMakeLists.txt
+++ b/clang/tools/clang-offload-wrapper/CMakeLists.txt
@@ -1,4 +1,4 @@
-set(LLVM_LINK_COMPONENTS BitWriter Core Support TransformUtils)
+set(LLVM_LINK_COMPONENTS BitWriter Core Object Support TransformUtils)
 
 add_clang_tool(clang-offload-wrapper
   ClangOffloadWrapper.cpp

diff  --git a/clang/tools/clang-offload-wrapper/ClangOffloadWrapper.cpp 
b/clang/tools/clang-offload-wrap

[PATCH] D99551: [clang-offload-wrapper] Add standard notes for ELF offload images

2021-08-16 Thread Vyacheslav Zakharin 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 rG93d08acaacec: [clang-offload-wrapper] Add standard notes for 
ELF offload images (authored by vzakhari).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99551

Files:
  clang/test/Driver/Inputs/empty-elf-template.yaml
  clang/test/Driver/clang-offload-wrapper.c
  clang/tools/clang-offload-wrapper/CMakeLists.txt
  clang/tools/clang-offload-wrapper/ClangOffloadWrapper.cpp

Index: clang/tools/clang-offload-wrapper/ClangOffloadWrapper.cpp
===
--- clang/tools/clang-offload-wrapper/ClangOffloadWrapper.cpp
+++ clang/tools/clang-offload-wrapper/ClangOffloadWrapper.cpp
@@ -17,27 +17,37 @@
 #include "clang/Basic/Version.h"
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/Triple.h"
+#include "llvm/BinaryFormat/ELF.h"
 #include "llvm/Bitcode/BitcodeWriter.h"
 #include "llvm/IR/Constants.h"
 #include "llvm/IR/GlobalVariable.h"
 #include "llvm/IR/IRBuilder.h"
 #include "llvm/IR/LLVMContext.h"
 #include "llvm/IR/Module.h"
+#include "llvm/Object/ELFObjectFile.h"
+#include "llvm/Object/ObjectFile.h"
 #include "llvm/Support/CommandLine.h"
+#include "llvm/Support/EndianStream.h"
 #include "llvm/Support/Errc.h"
 #include "llvm/Support/Error.h"
 #include "llvm/Support/ErrorOr.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/MemoryBuffer.h"
+#include "llvm/Support/Path.h"
+#include "llvm/Support/Program.h"
 #include "llvm/Support/Signals.h"
 #include "llvm/Support/ToolOutputFile.h"
+#include "llvm/Support/VCSRevision.h"
 #include "llvm/Support/WithColor.h"
 #include "llvm/Support/raw_ostream.h"
 #include "llvm/Transforms/Utils/ModuleUtils.h"
 #include 
 #include 
 
+#define OPENMP_OFFLOAD_IMAGE_VERSION "1.0"
+
 using namespace llvm;
+using namespace llvm::object;
 
 static cl::opt Help("h", cl::desc("Alias for -help"), cl::Hidden);
 
@@ -60,6 +70,12 @@
cl::desc("Target triple for the output module"),
cl::value_desc("triple"), cl::cat(ClangOffloadWrapperCategory));
 
+static cl::opt SaveTemps(
+"save-temps",
+cl::desc("Save temporary files that may be produced by the tool. "
+ "This option forces print-out of the temporary files' names."),
+cl::Hidden);
+
 namespace {
 
 class BinaryWrapper {
@@ -70,6 +86,15 @@
   StructType *ImageTy = nullptr;
   StructType *DescTy = nullptr;
 
+  std::string ToolName;
+  std::string ObjcopyPath;
+  // Temporary file names that may be created during adding notes
+  // to ELF offload images. Use -save-temps to keep them and also
+  // see their names. A temporary file's name includes the name
+  // of the original input ELF image, so you can easily match
+  // them, if you have multiple inputs.
+  std::vector TempFiles;
+
 private:
   IntegerType *getSizeTTy() {
 switch (M.getDataLayout().getPointerTypeSize(Type::getInt8PtrTy(C))) {
@@ -294,8 +319,61 @@
   }
 
 public:
-  BinaryWrapper(StringRef Target) : M("offload.wrapper.object", C) {
+  BinaryWrapper(StringRef Target, StringRef ToolName)
+  : M("offload.wrapper.object", C), ToolName(ToolName) {
 M.setTargetTriple(Target);
+// Look for llvm-objcopy in the same directory, from which
+// clang-offload-wrapper is invoked. This helps OpenMP offload
+// LIT tests.
+
+// This just needs to be some symbol in the binary; C++ doesn't
+// allow taking the address of ::main however.
+void *P = (void *)(intptr_t)&Help;
+std::string COWPath = sys::fs::getMainExecutable(ToolName.str().c_str(), P);
+if (!COWPath.empty()) {
+  auto COWDir = sys::path::parent_path(COWPath);
+  ErrorOr ObjcopyPathOrErr =
+  sys::findProgramByName("llvm-objcopy", {COWDir});
+  if (ObjcopyPathOrErr) {
+ObjcopyPath = *ObjcopyPathOrErr;
+return;
+  }
+
+  // Otherwise, look through PATH environment.
+}
+
+ErrorOr ObjcopyPathOrErr =
+sys::findProgramByName("llvm-objcopy");
+if (!ObjcopyPathOrErr) {
+  WithColor::warning(errs(), ToolName)
+  << "cannot find llvm-objcopy[.exe] in PATH; ELF notes cannot be "
+ "added.\n";
+  return;
+}
+
+ObjcopyPath = *ObjcopyPathOrErr;
+  }
+
+  ~BinaryWrapper() {
+if (TempFiles.empty())
+  return;
+
+StringRef ToolNameRef(ToolName);
+auto warningOS = [ToolNameRef]() -> raw_ostream & {
+  return WithColor::warning(errs(), ToolNameRef);
+};
+
+for (auto &F : TempFiles) {
+  if (SaveTemps) {
+warningOS() << "keeping temporary file " << F << "\n";
+continue;
+  }
+
+  auto EC = sys::fs::remove(F, false);
+  if (EC)
+warningOS() << "cannot remove temporary file " << F << ": "
+<< EC.message().c_str() << "\n";
+}
   }
 
   const Module &wrapBinaries(ArrayRef> Binari

Re: [clang] 80ed75e - Revert "[NFC] Fix typos"

2021-08-16 Thread David Blaikie via cfe-commits
Please include in the commit message a reason for a revert.

On Mon, Aug 16, 2021 at 11:14 AM Kostya Kortchinsky via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> Author: Kostya Kortchinsky
> Date: 2021-08-16T11:13:05-07:00
> New Revision: 80ed75e7fb45f9f5fc84ca7cbe258be036015384
>
> URL:
> https://github.com/llvm/llvm-project/commit/80ed75e7fb45f9f5fc84ca7cbe258be036015384
> DIFF:
> https://github.com/llvm/llvm-project/commit/80ed75e7fb45f9f5fc84ca7cbe258be036015384.diff
>
> LOG: Revert "[NFC] Fix typos"
>
> This reverts commit b7425e956be60a73004d7ae5bb37da85872c29fb.
>
> Added:
>
>
> Modified:
> clang/lib/StaticAnalyzer/Checkers/CheckObjCInstMethSignature.cpp
> clang/lib/StaticAnalyzer/Checkers/NSErrorChecker.cpp
> compiler-rt/test/profile/Linux/instrprof-cs.c
> llvm/include/llvm/Transforms/Instrumentation.h
> llvm/lib/ProfileData/SampleProfReader.cpp
>
> Removed:
>
>
>
>
> 
> diff  --git
> a/clang/lib/StaticAnalyzer/Checkers/CheckObjCInstMethSignature.cpp
> b/clang/lib/StaticAnalyzer/Checkers/CheckObjCInstMethSignature.cpp
> index a13de306eac84..175dfcef0df45 100644
> --- a/clang/lib/StaticAnalyzer/Checkers/CheckObjCInstMethSignature.cpp
> +++ b/clang/lib/StaticAnalyzer/Checkers/CheckObjCInstMethSignature.cpp
> @@ -6,7 +6,7 @@
>  //
>
>  
> //===--===//
>  //
> -//  This file defines a CheckObjCInstMethSignature, a flow-insensitive
> check
> +//  This file defines a CheckObjCInstMethSignature, a flow-insenstive
> check
>  //  that determines if an Objective-C class interface incorrectly
> redefines
>  //  the method signature in a subclass.
>  //
>
> diff  --git a/clang/lib/StaticAnalyzer/Checkers/NSErrorChecker.cpp
> b/clang/lib/StaticAnalyzer/Checkers/NSErrorChecker.cpp
> index dcca8be55e337..90c5583d89691 100644
> --- a/clang/lib/StaticAnalyzer/Checkers/NSErrorChecker.cpp
> +++ b/clang/lib/StaticAnalyzer/Checkers/NSErrorChecker.cpp
> @@ -6,7 +6,7 @@
>  //
>
>  
> //===--===//
>  //
> -//  This file defines a CheckNSError, a flow-insensitive check
> +//  This file defines a CheckNSError, a flow-insenstive check
>  //  that determines if an Objective-C class interface correctly returns
>  //  a non-void return type.
>  //
>
> diff  --git a/compiler-rt/test/profile/Linux/instrprof-cs.c
> b/compiler-rt/test/profile/Linux/instrprof-cs.c
> index 0ad6f0350c560..d825525a532db 100644
> --- a/compiler-rt/test/profile/Linux/instrprof-cs.c
> +++ b/compiler-rt/test/profile/Linux/instrprof-cs.c
> @@ -8,7 +8,7 @@
>  // RUN: %clang_profgen=%t.profraw -o %t.gen.cis -O2 %s
>  // RUN: %run %t.gen.cis
>  // RUN: llvm-profdata merge -o %t.cis.profdata %t.profraw
> -// Check context insensitive profile
> +// Check context insenstive profile
>  // RUN: %clang_profuse=%t.cis.profdata  -O2 -emit-llvm -S %s -o - |
> FileCheck %s --check-prefix=CIS
>  int g1 = 1;
>  int volatile g2 = 2;
>
> diff  --git a/llvm/include/llvm/Transforms/Instrumentation.h
> b/llvm/include/llvm/Transforms/Instrumentation.h
> index 0c822999aecf3..03108bacb0da5 100644
> --- a/llvm/include/llvm/Transforms/Instrumentation.h
> +++ b/llvm/include/llvm/Transforms/Instrumentation.h
> @@ -78,7 +78,7 @@ struct GCOVOptions {
>  ModulePass *createGCOVProfilerPass(const GCOVOptions &Options =
> GCOVOptions::getDefault());
>
> -// PGO Instrumention. Parameter IsCS indicates if this is the context
> sensitive
> +// PGO Instrumention. Parameter IsCS indicates if this is the context
> senstive
>  // instrumentation.
>  ModulePass *createPGOInstrumentationGenLegacyPass(bool IsCS = false);
>  ModulePass *
> @@ -138,7 +138,7 @@ struct InstrProfOptions {
>  };
>
>  /// Insert frontend instrumentation based profiling. Parameter IsCS
> indicates if
> -// this is the context sensitive instrumentation.
> +// this is the context senstive instrumentation.
>  ModulePass *createInstrProfilingLegacyPass(
>  const InstrProfOptions &Options = InstrProfOptions(), bool IsCS =
> false);
>
>
> diff  --git a/llvm/lib/ProfileData/SampleProfReader.cpp
> b/llvm/lib/ProfileData/SampleProfReader.cpp
> index a801ca1ef36d7..6058eddb13dc7 100644
> --- a/llvm/lib/ProfileData/SampleProfReader.cpp
> +++ b/llvm/lib/ProfileData/SampleProfReader.cpp
> @@ -53,7 +53,7 @@ using namespace sampleprof;
>  // For ext-binary format profiles, the flag is set in the summary.
>  static cl::opt ProfileIsFSDisciminator(
>  "profile-isfs", cl::Hidden, cl::init(false),
> -cl::desc("Profile uses flow sensitive discriminators"));
> +cl::desc("Profile uses flow senstive discriminators"));
>
>  /// Dump the function profile for \p FName.
>  ///
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
_

  1   2   >