date:20200318

[PATCH] D76229: [clang-tidy] Added PlacementNewStorageCheck

2020-03-18 Thread Karasev Nikita via Phabricator via cfe-commits

f00kat added a comment.

In D76229#1926818 , @Charusso wrote:

> In D76229#1925363 , @f00kat wrote:
>
> > In D76229#1925268 , @aaron.ballman 
> > wrote:
> >
> > > Have you considered making this a static analyzer check as opposed to a 
> > > clang-tidy check? I think using dataflow analysis will really reduce the 
> > > false positives because it will be able to track the allocation and 
> > > alignment data across control flow.
> >
> >
> > I have never try to write static analyzer before. Okay, I will look at 
> > examples of how to work with dataflow.
>
>
> To getting started with the Analyzer please visit @NoQ's (tiny bit outdated) 
> booklet: https://github.com/haoNoQ/clang-analyzer-guide
>
> Advertisement:
>  If D69726  lands we will have an arsenal of 
> APIs for helping dynamic size based checkers.
>  If D73521  lands it should be easier to 
> getting started with the Analyzer, but now you could visit what is our 
> current API.


Thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76229



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

[PATCH] D75579: Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime-registration

2020-03-18 Thread serge via Phabricator via cfe-commits

serge-sans-paille added a comment.

@modocache : thanks for the heads up, I'm investigating the issue.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75579



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

[PATCH] D76320: [clang] Fix crash on visiting null nestedNameSpecifier.

2020-03-18 Thread Haojian Wu via Phabricator via cfe-commits

hokein updated this revision to Diff 251006.
hokein marked an inline comment as done.
hokein added a comment.

address review comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76320

Files:
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/Parser/cxx-template-decl.cpp


Index: clang/test/Parser/cxx-template-decl.cpp
===
--- clang/test/Parser/cxx-template-decl.cpp
+++ clang/test/Parser/cxx-template-decl.cpp
@@ -273,3 +273,9 @@
 namespace PR45063 {
   template> struct X {}; // expected-error 
{{undeclared identifier 'a'}}
 }
+
+namespace NoCrashOnEmptyNestedNameSpecifier {
+  template ::template arg_t<0>> // 
expected-error {{no template named 'ABC'}}
+  void foo(FnT) {}
+}
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -5928,7 +5928,9 @@
 
 bool UnnamedLocalNoLinkageFinder::VisitDependentTemplateSpecializationType(
  const DependentTemplateSpecializationType* T) 
{
-  return VisitNestedNameSpecifier(T->getQualifier());
+  if (auto *Q = T->getQualifier())
+return VisitNestedNameSpecifier(Q);
+  return false;
 }
 
 bool UnnamedLocalNoLinkageFinder::VisitPackExpansionType(
@@ -5982,6 +5984,7 @@
 
 bool UnnamedLocalNoLinkageFinder::VisitNestedNameSpecifier(
 NestedNameSpecifier *NNS) {
+  assert(NNS);
   if (NNS->getPrefix() && VisitNestedNameSpecifier(NNS->getPrefix()))
 return true;
 


Index: clang/test/Parser/cxx-template-decl.cpp
===
--- clang/test/Parser/cxx-template-decl.cpp
+++ clang/test/Parser/cxx-template-decl.cpp
@@ -273,3 +273,9 @@
 namespace PR45063 {
   template> struct X {}; // expected-error {{undeclared identifier 'a'}}
 }
+
+namespace NoCrashOnEmptyNestedNameSpecifier {
+  template ::template arg_t<0>> // expected-error {{no template named 'ABC'}}
+  void foo(FnT) {}
+}
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -5928,7 +5928,9 @@
 
 bool UnnamedLocalNoLinkageFinder::VisitDependentTemplateSpecializationType(
  const DependentTemplateSpecializationType* T) {
-  return VisitNestedNameSpecifier(T->getQualifier());
+  if (auto *Q = T->getQualifier())
+return VisitNestedNameSpecifier(Q);
+  return false;
 }
 
 bool UnnamedLocalNoLinkageFinder::VisitPackExpansionType(
@@ -5982,6 +5984,7 @@
 
 bool UnnamedLocalNoLinkageFinder::VisitNestedNameSpecifier(
 NestedNameSpecifier *NNS) {
+  assert(NNS);
   if (NNS->getPrefix() && VisitNestedNameSpecifier(NNS->getPrefix()))
 return true;
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76320: [clang] Fix crash on visiting null nestedNameSpecifier.

2020-03-18 Thread Haojian Wu via Phabricator via cfe-commits

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



Comment at: clang/lib/Sema/SemaTemplate.cpp:5926
const DependentNameType* T) 
{
-  return VisitNestedNameSpecifier(T->getQualifier());
+  if (auto *Q = T->getQualifier())
+return VisitNestedNameSpecifier(Q);

sammccall wrote:
> Do you have an idea of how we're getting here with a null qualifier?
> AIUI DependentNameType is a type that's a name with a dependent qualifier. If 
> the qualifier doesn't exist, it's not dependent. Is this a recovery path, 
> where the qualifier doesn't exist because it contains an error? (Like the 
> ABC in your test where ABC can't be resolved).
> 
> (Docs do reference MSVC-compat cases where the qualifier need not be 
> dependent, and maybe need not exist, but neither the linked bug nor the test 
> use msvc-compat)
right, the crash only happens on `DependentTemplateSpecializationType`. I made 
this change initially when trying the fix the crash (they look quite 
suspicious).

It can be ran on a recovery path, but I just checked all call sides, qualifier 
can not be null for DependentNameType (even for the MSVC mode). Reverted the 
change here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76320



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

[PATCH] D71920: [AST] Refactor propagation of dependency bits. NFC

2020-03-18 Thread Alexey Sachkov via Phabricator via cfe-commits

AlexeySachkov added inline comments.



Comment at: clang/include/clang/AST/Type.h:1827-1830
+if (Dependent)
+  Deps |= TypeDependence::Dependent | TypeDependence::Instantiation;
+if (InstantiationDependent)
+  Deps |= TypeDependence::Instantiation;

sammccall wrote:
> AlexeySachkov wrote:
> > @ilya-biryukov, Is this code snippet correct?
> > 
> > It seems to be, that it should look like:
> > ```
> > if (Dependent)
> >   Deps |= TypeDependence::Dependent;
> > if (InstantiationDependent)
> >   Deps |= TypeDependence::Dependent | TypeDependence::Instantiation;
> > ```
> I agree that seems clearer, but ISTM they are equivalent because a dependent 
> type is always instantiation-dependent (right?)
> 
> Are you seeing related problems?
> Are you seeing related problems?

I though I was seeing a related problem, but it turned out that I wasn't.

Looking at the code again with a clear head, I believe that everything is 
correct here


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71920



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

[clang] bd763e2 - [clang] Fix crash on visiting null nestedNameSpecifier.

2020-03-18 Thread Haojian Wu via cfe-commits


Author: Haojian Wu
Date: 2020-03-18T09:15:02+01:00
New Revision: bd763e2cf7c1d84bab95064cc5cbe542b227b025

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

LOG: [clang] Fix crash on visiting null nestedNameSpecifier.

Summary: Fix https://github.com/clangd/clangd/issues/293

Reviewers: sammccall

Subscribers: ilya-biryukov, kadircet, usaxena95, cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang/lib/Sema/SemaTemplate.cpp
clang/test/Parser/cxx-template-decl.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaTemplate.cpp b/clang/lib/Sema/SemaTemplate.cpp
index 1ba66d4a976a..f95b16c1cbae 100755
--- a/clang/lib/Sema/SemaTemplate.cpp
+++ b/clang/lib/Sema/SemaTemplate.cpp
@@ -5928,7 +5928,9 @@ bool UnnamedLocalNoLinkageFinder::VisitDependentNameType(
 
 bool UnnamedLocalNoLinkageFinder::VisitDependentTemplateSpecializationType(
  const DependentTemplateSpecializationType* T) 
{
-  return VisitNestedNameSpecifier(T->getQualifier());
+  if (auto *Q = T->getQualifier())
+return VisitNestedNameSpecifier(Q);
+  return false;
 }
 
 bool UnnamedLocalNoLinkageFinder::VisitPackExpansionType(
@@ -5982,6 +5984,7 @@ bool UnnamedLocalNoLinkageFinder::VisitTagDecl(const 
TagDecl *Tag) {
 
 bool UnnamedLocalNoLinkageFinder::VisitNestedNameSpecifier(
 NestedNameSpecifier *NNS) {
+  assert(NNS);
   if (NNS->getPrefix() && VisitNestedNameSpecifier(NNS->getPrefix()))
 return true;
 

diff  --git a/clang/test/Parser/cxx-template-decl.cpp 
b/clang/test/Parser/cxx-template-decl.cpp
index 3d7a3dc14f4c..0d52ad8fb50f 100644
--- a/clang/test/Parser/cxx-template-decl.cpp
+++ b/clang/test/Parser/cxx-template-decl.cpp
@@ -273,3 +273,9 @@ namespace AnnotateAfterInvalidTemplateId {
 namespace PR45063 {
   template> struct X {}; // expected-error 
{{undeclared identifier 'a'}}
 }
+
+namespace NoCrashOnEmptyNestedNameSpecifier {
+  template ::template arg_t<0>> // 
expected-error {{no template named 'ABC'}}
+  void foo(FnT) {}
+}



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

[PATCH] D75360: [analyzer][NFC] Tie CheckerRegistry to CheckerManager, allow CheckerManager to be constructed for non-analysis purposes

2020-03-18 Thread Balogh, Ádám via Phabricator via cfe-commits

baloghadamsoftware added inline comments.
Herald added a subscriber: ASDenysPetrov.



Comment at: clang/include/clang/StaticAnalyzer/Frontend/CheckerRegistry.h:217
+mgr.template registerChecker();
   }
 

NoQ wrote:
> Szelethus wrote:
> > baloghadamsoftware wrote:
> > > Why do we need `MGR` here as template parameter? Is this function also 
> > > used for other class instances than `CheckerManager`? I fail to see such 
> > > invocation.
> > Include cycles :) `CheckerManager.h` includes `CheckerRegistry.h`, so we 
> > can only forward declare `CheckerManager`, hence the need for a template 
> > parameter.
> Maybe put the implementation into the cpp file instead?
+1 Using templates where only one template parameter is possible is overkill 
and makes the code difficult to understand.


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

https://reviews.llvm.org/D75360



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

[PATCH] D76125: [clangd] Decouple preambleworker from astworker, NFCI

2020-03-18 Thread Kadir Cetinkaya via Phabricator via cfe-commits

kadircet marked 16 inline comments as done.
kadircet added inline comments.



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:265
+  /// Updates the TUStatus and emits it. Only called in the worker thread.
+  void emitTUStatus(TUAction Action,
+const TUStatus::BuildDetails *Details = nullptr) {

sammccall wrote:
> as discussed a bit in chat, I think this part needs some more thought. 
> Currently the ASTWorker and PreambleWorker emit data for the same file with 
> some interleaving that's hard to reason about. The state needs an owner.
> 
> (e.g. consider a class that holds a TUStatus and exposes an Event, 
> with threadsafe setPreambleAction and setWorkerAction methods, or so)
sent out https://reviews.llvm.org/D76304



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:600
 Inputs, CompilerInvocationDiagConsumer, &CC1Args);
+auto OldPreamble = PW.getLatestBuiltPreamble();
+PW.requestBuild(Invocation.get(), Inputs);

sammccall wrote:
> kadircet wrote:
> > sammccall wrote:
> > > this doesn't seem correct (maybe ok in this patch because of the 
> > > blocking, but not in general). You're assuming the last available 
> > > preamble is the one that the last AST was built with.
> > > 
> > > I suppose you can't check the preamble of the current ParsedAST because 
> > > it might not be cached, and you nevertheless want to skip rebuild if the 
> > > diagnostics are going to be the same. I can't think of anything better 
> > > than continuing to hold the shared_ptr for PreambleForLastBuiltAST or 
> > > something like that.
> > right, this is just a "hack" to keep this change NFC.
> > 
> > in the follow-up patches i am planning to signal whether latest built 
> > preamble is reusable for a given `ParseInputs`, and also signal what the 
> > AST should be patched with.
> > 
> > diagnostics(ast) will only be built if preamble is re-usable.
> > right, this is just a "hack" to keep this change NFC.
> 
> can you add a comment about this? (In particular, why it's correct?)
> 
> > in the follow-up patches i am planning to signal whether latest built 
> > preamble is reusable for a given ParseInputs
> 
> Does "reusable" mean "completely valid" (current semantics), or usable with 
> some tweaks (e.g. added headers)? It would be good to define some precise 
> terminology around this.
> 
> > diagnostics(ast) will only be built if preamble is re-usable.
> 
> SG
reusable means completely valid.



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:412
 RanASTCallback = false;
-emitTUStatus({TUAction::BuildingPreamble, TaskName});
 log("ASTWorker building file {0} version {1} with command {2}\n[{3}]\n{4}",

sammccall wrote:
> why are we moving this?
it has been moved into PreambleThread instead, same as the one below handling 
the failure.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76125



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

[PATCH] D76320: [clang] Fix crash on visiting null nestedNameSpecifier.

2020-03-18 Thread Haojian Wu via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
hokein marked an inline comment as done.
Closed by commit rGbd763e2cf7c1: [clang] Fix crash on visiting null 
nestedNameSpecifier. (authored by hokein).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76320

Files:
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/Parser/cxx-template-decl.cpp


Index: clang/test/Parser/cxx-template-decl.cpp
===
--- clang/test/Parser/cxx-template-decl.cpp
+++ clang/test/Parser/cxx-template-decl.cpp
@@ -273,3 +273,9 @@
 namespace PR45063 {
   template> struct X {}; // expected-error 
{{undeclared identifier 'a'}}
 }
+
+namespace NoCrashOnEmptyNestedNameSpecifier {
+  template ::template arg_t<0>> // 
expected-error {{no template named 'ABC'}}
+  void foo(FnT) {}
+}
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -5928,7 +5928,9 @@
 
 bool UnnamedLocalNoLinkageFinder::VisitDependentTemplateSpecializationType(
  const DependentTemplateSpecializationType* T) 
{
-  return VisitNestedNameSpecifier(T->getQualifier());
+  if (auto *Q = T->getQualifier())
+return VisitNestedNameSpecifier(Q);
+  return false;
 }
 
 bool UnnamedLocalNoLinkageFinder::VisitPackExpansionType(
@@ -5982,6 +5984,7 @@
 
 bool UnnamedLocalNoLinkageFinder::VisitNestedNameSpecifier(
 NestedNameSpecifier *NNS) {
+  assert(NNS);
   if (NNS->getPrefix() && VisitNestedNameSpecifier(NNS->getPrefix()))
 return true;
 


Index: clang/test/Parser/cxx-template-decl.cpp
===
--- clang/test/Parser/cxx-template-decl.cpp
+++ clang/test/Parser/cxx-template-decl.cpp
@@ -273,3 +273,9 @@
 namespace PR45063 {
   template> struct X {}; // expected-error {{undeclared identifier 'a'}}
 }
+
+namespace NoCrashOnEmptyNestedNameSpecifier {
+  template ::template arg_t<0>> // expected-error {{no template named 'ABC'}}
+  void foo(FnT) {}
+}
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -5928,7 +5928,9 @@
 
 bool UnnamedLocalNoLinkageFinder::VisitDependentTemplateSpecializationType(
  const DependentTemplateSpecializationType* T) {
-  return VisitNestedNameSpecifier(T->getQualifier());
+  if (auto *Q = T->getQualifier())
+return VisitNestedNameSpecifier(Q);
+  return false;
 }
 
 bool UnnamedLocalNoLinkageFinder::VisitPackExpansionType(
@@ -5982,6 +5984,7 @@
 
 bool UnnamedLocalNoLinkageFinder::VisitNestedNameSpecifier(
 NestedNameSpecifier *NNS) {
+  assert(NNS);
   if (NNS->getPrefix() && VisitNestedNameSpecifier(NNS->getPrefix()))
 return true;
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76125: [clangd] Decouple preambleworker from astworker, NFCI

2020-03-18 Thread Kadir Cetinkaya via Phabricator via cfe-commits

kadircet updated this revision to Diff 251011.
kadircet marked 2 inline comments as done.
kadircet added a comment.

- Address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76125

Files:
  clang-tools-extra/clangd/Preamble.cpp
  clang-tools-extra/clangd/Preamble.h
  clang-tools-extra/clangd/TUScheduler.cpp

Index: clang-tools-extra/clangd/TUScheduler.cpp
===
--- clang-tools-extra/clangd/TUScheduler.cpp
+++ clang-tools-extra/clangd/TUScheduler.cpp
@@ -49,13 +49,16 @@
 #include "GlobalCompilationDatabase.h"
 #include "Logger.h"
 #include "ParsedAST.h"
+#include "Path.h"
 #include "Preamble.h"
+#include "Threading.h"
 #include "Trace.h"
 #include "index/CanonicalIncludes.h"
 #include "clang/Frontend/CompilerInvocation.h"
 #include "clang/Tooling/CompilationDatabase.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/ScopeExit.h"
+#include "llvm/ADT/StringRef.h"
 #include "llvm/Support/Errc.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/Threading.h"
@@ -149,6 +152,174 @@
 };
 
 namespace {
+/// Responsible for building and providing access to the preamble of a TU.
+/// Whenever the thread is idle and the preamble is outdated, it starts to build
+/// a fresh preamble from the latest inputs. If RunSync is true, preambles are
+/// built synchronously in update() instead.
+class PreambleThread {
+public:
+  PreambleThread(llvm::StringRef FileName, ParsingCallbacks &Callbacks,
+ bool StorePreambleInMemory, bool RunSync)
+  : FileName(FileName), Callbacks(Callbacks),
+StoreInMemory(StorePreambleInMemory), RunSync(RunSync) {}
+
+  size_t getUsedBytes() const {
+auto Preamble = latest();
+return Preamble ? Preamble->Preamble.getSize() : 0;
+  }
+
+  /// It isn't guaranteed that each requested version will be built. If there
+  /// are multiple update requests while building a preamble, only the last one
+  /// will be built.
+  void update(CompilerInvocation *CI, ParseInputs PI) {
+// If compiler invocation was broken, just fail out early.
+if (!CI) {
+  TUStatus::BuildDetails Details;
+  Details.BuildFailed = true;
+  std::string TaskName = llvm::formatv("Update ({0})", PI.Version);
+  emitTUStatus({TUAction::BuildingPreamble, std::move(TaskName)}, &Details);
+  // Make sure anyone waiting for the preamble gets notified it could not be
+  // built.
+  BuiltFirst.notify();
+  return;
+}
+// Make possibly expensive copy while not holding the lock.
+Request Req = {std::make_unique(*CI), std::move(PI)};
+if (RunSync) {
+  build(std::move(Req));
+  return;
+}
+{
+  std::lock_guard Lock(Mutex);
+  assert(!Done && "Build request to PreambleWorker after stop");
+  NextReq = std::move(Req);
+}
+// Let the worker thread know there's a request, notify_one is safe as there
+// should be a single worker thread waiting on it.
+ReqCV.notify_all();
+  }
+
+  /// Blocks until at least a single request has been processed. Note that it
+  /// will unblock even after an unsuccessful build.
+  void waitForFirst() const { BuiltFirst.wait(); }
+
+  /// Returns the latest built preamble, might be null if no preamble has been
+  /// built or latest attempt resulted in a failure.
+  std::shared_ptr latest() const {
+std::lock_guard Lock(Mutex);
+return LatestBuild;
+  }
+
+  void run() {
+dlog("Starting preamble worker for {0}", FileName);
+while (true) {
+  {
+std::unique_lock Lock(Mutex);
+assert(!CurrentReq && "Already processing a request?");
+// Wait until stop is called or there is a request.
+ReqCV.wait(Lock, [this] { return NextReq || Done; });
+if (Done)
+  break;
+CurrentReq = std::move(*NextReq);
+NextReq.reset();
+  }
+  // Build the preamble and let the waiters know about it.
+  build(std::move(*CurrentReq));
+}
+// We are no longer going to build any preambles, let the waiters know that.
+BuiltFirst.notify();
+dlog("Preamble worker for {0} finished", FileName);
+  }
+
+  /// Signals the run loop to exit.
+  void stop() {
+dlog("Stopping preamble worker for {0}", FileName);
+{
+  std::lock_guard Lock(Mutex);
+  Done = true;
+}
+// Let the worker thread know that it should stop.
+ReqCV.notify_all();
+  }
+
+  bool blockUntilIdle(Deadline Timeout) const {
+std::unique_lock Lock(Mutex);
+return wait(Lock, ReqCV, Timeout, [&] { return !NextReq && !CurrentReq; });
+  }
+
+private:
+  /// Holds inputs required for building a preamble. CI is guaranteed to be
+  /// non-null.
+  struct Request {
+std::unique_ptr CI;
+ParseInputs Inputs;
+  };
+
+  bool isDone() {
+std::lock_guard Lock(Mutex);
+return Done;
+  }
+
+  /// Updates the TUStatus and emits it. Only called in th

[PATCH] D69778: Make -fmodules-codegen and -fmodules-debuginfo work also with precompiled headers

2020-03-18 Thread Luboš Luňák via Phabricator via cfe-commits

llunak added a comment.

In D69778#1928111 , @dblaikie wrote:

> In D69778#1927761 , @llunak wrote:
>
> > It comes from 08c5a7b8fda1b97df9d027d1ac096f93edeb6c2f . AFAICT 
> > -fmodules-codegen is a superset of -building-pch-with-obj, the important 
> > difference is that -building-pch-with-obj decides which code will be shared 
> > while building TUs, while -fmodules-codegen decides while building the PCH.
>
>
> I'm not sure I follow - how would that be possible? building the object from 
> the PCH is done independently of any usage, so it can't depend on the way the 
> PCH is used by any TU that includes it, I think?


If a TU uses a PCH, it'll result in some code emitted in every TU that uses the 
same PCH (e.g. template instantiations from the PCH). And 
-building-pch-with-obj detects these and discards them in all TUs except the 
PCH's object file. That means that the code shared in the PCH's object file is 
only code that would be duplicated in all TUs using the PCH. This is 
fundamentally different from -fmodules-codegen, which decides what will be 
emitted and shared already when creating the PCH, which has the consequence 
that it selects also a lot of code that will be eventually unused, which causes 
problems like the -Wl,--gc-sections part or not being necessarily worth it 
(IIRC even your -fmodules-codegen commit says so). So while -fmodules-codegen 
should be generally superior, -building-pch-with-obj is trivial to use. That's 
my understanding of both the approaches (and I spent quite a lot of time 
looking at both when working on D69778  and 
D69585 ).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69778



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

[PATCH] D76030: [CUDA] Warn about unsupported CUDA SDK version only if it's used.

2020-03-18 Thread Hans Wennborg via Phabricator via cfe-commits

hans added a comment.

In D76030#1925445 , @tra wrote:

> @hans  -- this should be cherry-picked into 10 if it's not too late yet.


It's probably too late for 10.0.0, but sounds like a good candidate for 10.0.1.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76030



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

[PATCH] D76346: Build template declaration nodes

2020-03-18 Thread Marcel Hlopko via Phabricator via cfe-commits

hlopko created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
hlopko added a reviewer: gribozavr2.

Copy of https://reviews.llvm.org/D72334, submitting with Ilya's permission.

Handles template declaration of all kinds.

Also builds template declaration nodes for specializations and explicit
instantiations of classes.

Some missing things will be addressed in the follow-up patches:

specializations of functions and variables,
template parameters.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D76346

Files:
  clang/include/clang/Tooling/Syntax/Nodes.h
  clang/lib/Tooling/Syntax/BuildTree.cpp
  clang/lib/Tooling/Syntax/Nodes.cpp
  clang/unittests/Tooling/Syntax/TreeTest.cpp

Index: clang/unittests/Tooling/Syntax/TreeTest.cpp
===
--- clang/unittests/Tooling/Syntax/TreeTest.cpp
+++ clang/unittests/Tooling/Syntax/TreeTest.cpp
@@ -678,6 +678,212 @@
   `-;
 )txt"},
   {R"cpp(
+template  struct cls {};
+template  int var = 10;
+template  int fun() {}
+)cpp",
+   R"txt(
+*: TranslationUnit
+|-TemplateDeclaration
+| |-template
+| |-<
+| |-UnknownDeclaration
+| | |-class
+| | `-T
+| |->
+| `-SimpleDeclaration
+|   |-struct
+|   |-cls
+|   |-{
+|   |-}
+|   `-;
+|-TemplateDeclaration
+| |-template
+| |-<
+| |-UnknownDeclaration
+| | |-class
+| | `-T
+| |->
+| `-SimpleDeclaration
+|   |-int
+|   |-SimpleDeclarator
+|   | |-var
+|   | |-=
+|   | `-UnknownExpression
+|   |   `-10
+|   `-;
+`-TemplateDeclaration
+  |-template
+  |-<
+  |-UnknownDeclaration
+  | |-class
+  | `-T
+  |->
+  `-SimpleDeclaration
+|-int
+|-SimpleDeclarator
+| |-fun
+| `-ParametersAndQualifiers
+|   |-(
+|   `-)
+`-CompoundStatement
+  |-{
+  `-}
+)txt"},
+  {R"cpp(
+template 
+struct X {
+  template 
+  U foo();
+};
+)cpp",
+   R"txt(
+*: TranslationUnit
+`-TemplateDeclaration
+  |-template
+  |-<
+  |-UnknownDeclaration
+  | |-class
+  | `-T
+  |->
+  `-SimpleDeclaration
+|-struct
+|-X
+|-{
+|-TemplateDeclaration
+| |-template
+| |-<
+| |-UnknownDeclaration
+| | |-class
+| | `-U
+| |->
+| `-SimpleDeclaration
+|   |-U
+|   |-SimpleDeclarator
+|   | |-foo
+|   | `-ParametersAndQualifiers
+|   |   |-(
+|   |   `-)
+|   `-;
+|-}
+`-;
+)txt"},
+  {R"cpp(
+template  struct X {};
+template  struct X {};
+template <> struct X {};
+
+template struct X;
+extern template struct X;
+)cpp",
+   R"txt(
+*: TranslationUnit
+|-TemplateDeclaration
+| |-template
+| |-<
+| |-UnknownDeclaration
+| | |-class
+| | `-T
+| |->
+| `-SimpleDeclaration
+|   |-struct
+|   |-X
+|   |-{
+|   |-}
+|   `-;
+|-TemplateDeclaration
+| |-template
+| |-<
+| |-UnknownDeclaration
+| | |-class
+| | `-T
+| |->
+| `-SimpleDeclaration
+|   |-struct
+|   |-X
+|   |-<
+|   |-T
+|   |-*
+|   |->
+|   |-{
+|   |-}
+|   `-;
+|-TemplateDeclaration
+| |-template
+| |-<
+| |->
+| `-SimpleDeclaration
+|   |-struct
+|   |-X
+|   |-<
+|   |-int
+|   |->
+|   |-{
+|   |-}
+|   `-;
+|-ExplicitTemplateInstantiation
+| |-template
+| `-SimpleDeclaration
+|   |-struct
+|   |-X
+|   |-<
+|   |-double
+|   |->
+|   `-;
+`-ExplicitTemplateInstantiation
+  |-extern
+  |-template
+  `-SimpleDeclaration
+|-struct
+|-X
+|-<
+|-float
+|->
+`-;
+)txt"},
+  {R"cpp(
+template  struct X { struct Y; };
+template  struct X::Y {};
+)cpp",
+   R"txt(
+*: TranslationUnit
+|-TemplateDeclaration
+| |-template
+| |-<
+| |-UnknownDeclaration
+| | |-class
+| | `-T
+| |->
+| `-SimpleDeclaration
+|   |-struct
+|   |-X
+|   |-{
+|   |-SimpleDeclaration
+|   | |-struct
+|   | |-Y
+|   | `-;
+|   |-}
+|   `-;
+`-TemplateDeclaration
+  |-template
+  |-<
+  |-UnknownDeclaration
+  | |-class
+  | `-T
+  |->
+  `-SimpleDeclaration
+|-struct
+|-X
+|-<
+|-T
+|->
+|-::
+|-Y
+|-{
+|-}
+`-;
+   )txt"},
+  {R"cpp(
 namespace ns {}
 using namespace ::ns;
 )cpp",
@@ -726,7 +932,7 @@
 )cpp",
R"txt(
 *: TranslationUnit
-`-UnknownDeclaration
+`-TemplateDeclaration
   |-template
   |-<
   |-UnknownDeclaration
Index: clang/lib/Tooling/Syntax/Nodes.cpp
===
--- clang/lib/Tooling/Syntax/Nodes.cpp
+++ clang/lib/Tooling/Syntax/Nodes.cpp
@@ -58,6 +58,10 @@
 return OS << "LinkageSpecificationDeclaration";
   case NodeKind::SimpleDeclaration:
 return OS << "SimpleDeclaration";
+  case NodeKind::TemplateDeclaration:
+return OS << "TemplateDeclaration";
+  case NodeKind::ExplicitTemplateInstantiation:
+return OS << "ExplicitTemplateInstantiation";
   case NodeKind::NamespaceDefinition:
 return OS << "NamespaceDefinition";
   case NodeKind::NamespaceAliasDefinition:
@@ -118,6 +122,12 @@
 return OS << "StaticAssertDeclaration_message";
   case syntax::NodeRole::SimpleDeclaration_declarator:
 return OS <

[PATCH] D73891: [RISCV] Support experimental/unratified extensions

2020-03-18 Thread Lewis Revill via Phabricator via cfe-commits

lewis-revill accepted this revision.
lewis-revill added a comment.
This revision is now accepted and ready to land.

Thanks, this is looking in good shape now. As long as everyone agrees on this 
scheme I think the implementation is good to go (pending the bitmanip extension 
support).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73891



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

[PATCH] D73898: [analyzer] StdLibraryFunctionsChecker: Add argument constraints

2020-03-18 Thread Balázs Kéri via Phabricator via cfe-commits

balazske added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:191
+  ///   * a list of branches - a list of list of ranges -
+  /// i.e. a list of lists of lists of segments,
+  ///   * a list of argument constraints, that must be true on every branch.

martong wrote:
> martong wrote:
> > Szelethus wrote:
> > > I think that is a rather poor example to help understand what `list of 
> > > list of ranges` means :) -- Could you try to find something better?
> > Yeah, that part definitely should be reworded.
> I added an example with `isalpha`.
The "branches" are the structures that define relations between arguments and 
return values? This could be included in the description.



Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:112
   const Summary &Summary) const = 0;
+virtual ValueConstraintPtr negate() const {
+  llvm_unreachable("Not implemented");

Is it better done with `= 0`?



Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:297
+
+  void ReportBug(const CallEvent &Call, ExplodedNode *N, CheckerContext &C) 
const {
+if (!ChecksEnabled[CK_StdCLibraryFunctionArgsChecker])

This should be called `reportBug`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73898



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

[PATCH] D72334: [Syntax] Build nodes for template declarations.

2020-03-18 Thread Marcel Hlopko via Phabricator via cfe-commits

hlopko added a comment.

Let's continue the review at https://reviews.llvm.org/D76346.




Comment at: clang/lib/Tooling/Syntax/BuildTree.cpp:190
+  // Set role for the node that may or may not be delayed. Node must span
+  // exactly \p Range.
+  void markMaybeDelayedChild(llvm::ArrayRef Range, NodeRole R);

gribozavr2 wrote:
> Three slashes for docs.
Done.



Comment at: clang/lib/Tooling/Syntax/BuildTree.cpp:930
+Builder.markChildToken(TemplateKW, syntax::NodeRole::IntroducerKeyword);
+Builder.markMaybeDelayedChild(
+TemplatedDeclaration,

gribozavr2 wrote:
> Why is this range maybe-delayed?
E.g because `template  struct cls {};` is doesn't need delaying, but 
template  int var = 10;` does (SimpleDeclaration is processed before 
Declarator). I'll try to come up with a more fitting design after I submit this 
and https://reviews.llvm.org/D72446.



Comment at: clang/unittests/Tooling/Syntax/TreeTest.cpp:738
+  U foo();
+};
+)cpp",

gribozavr2 wrote:
> Could you also add an out-of-line definition of X::foo? It will have two 
> template parameter lists, which is a special case.
Example:

template 
 struct X {
   template 
   U foo();
 };

**template **
template 
U X::foo() {}

Discussed offline, RAV doesn't visit TemplateParameters and therefore  we're 
not creating a node for the first template parameter (in bold). We could 
overcome this in the BuildTree.cpp, but more principled solution would be to 
teach RAV to visit TemplateParameters. In a separate patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72334



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

[PATCH] D65591: [AST] Add a flag indicating if any subexpression had errors

2020-03-18 Thread Haojian Wu via Phabricator via cfe-commits

hokein updated this revision to Diff 251019.
hokein marked 5 inline comments as done.
hokein added a comment.

- address comments
- remove the placeholder errorbit in non-Expr dependence


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65591

Files:
  clang/include/clang/AST/ASTDumperUtils.h
  clang/include/clang/AST/DependenceFlags.h
  clang/include/clang/AST/Expr.h
  clang/include/clang/AST/Type.h
  clang/lib/AST/ComputeDependence.cpp
  clang/lib/AST/TextNodeDumper.cpp
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp

Index: clang/lib/Serialization/ASTWriterStmt.cpp
===
--- clang/lib/Serialization/ASTWriterStmt.cpp
+++ clang/lib/Serialization/ASTWriterStmt.cpp
@@ -540,6 +540,7 @@
   Record.push_back(E->isValueDependent());
   Record.push_back(E->isInstantiationDependent());
   Record.push_back(E->containsUnexpandedParameterPack());
+  Record.push_back(E->containsErrors());
   Record.push_back(E->getValueKind());
   Record.push_back(E->getObjectKind());
 }
Index: clang/lib/Serialization/ASTWriterDecl.cpp
===
--- clang/lib/Serialization/ASTWriterDecl.cpp
+++ clang/lib/Serialization/ASTWriterDecl.cpp
@@ -2280,6 +2280,7 @@
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); //ValueDependent
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); //InstantiationDependent
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); //UnexpandedParamPack
+  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // ContainsErrors
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); //GetValueKind
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); //GetObjectKind
   //DeclRefExpr
@@ -2303,6 +2304,7 @@
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); //ValueDependent
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); //InstantiationDependent
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); //UnexpandedParamPack
+  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // ContainsErrors
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); //GetValueKind
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); //GetObjectKind
   //Integer Literal
@@ -2321,6 +2323,7 @@
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); //ValueDependent
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); //InstantiationDependent
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); //UnexpandedParamPack
+  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // ContainsErrors
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); //GetValueKind
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); //GetObjectKind
   //Character Literal
@@ -2339,6 +2342,7 @@
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); //ValueDependent
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); //InstantiationDependent
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); //UnexpandedParamPack
+  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // ContainsErrors
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); //GetValueKind
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); //GetObjectKind
   // CastExpr
Index: clang/lib/Serialization/ASTReaderStmt.cpp
===
--- clang/lib/Serialization/ASTReaderStmt.cpp
+++ clang/lib/Serialization/ASTReaderStmt.cpp
@@ -106,7 +106,8 @@
 
 /// The number of record fields required for the Expr class
 /// itself.
-static const unsigned NumExprFields = NumStmtFields + 7;
+static const unsigned NumExprFields =
+NumStmtFields + ExprDependenceBits + 3;
 
 /// Read and initialize a ExplicitTemplateArgumentList structure.
 void ReadTemplateKWAndArgsInfo(ASTTemplateKWAndArgsInfo &Args,
@@ -517,6 +518,7 @@
   bool ValueDependent = Record.readInt();
   bool InstantiationDependent = Record.readInt();
   bool ContainsUnexpandedTemplateParameters = Record.readInt();
+  bool ContainsErrors = Record.readInt();
   auto Deps = ExprDependence::None;
   if (TypeDependent)
 Deps |= ExprDependence::Type;
@@ -526,6 +528,8 @@
 Deps |= ExprDependence::Instantiation;
   if (ContainsUnexpandedTemplateParameters)
 Deps |= ExprDependence::UnexpandedPack;
+  if (ContainsErrors)
+Deps |= ExprDependence::Error;
   E->setDependence(Deps);
 
   E->setValueKind(static_cast(Record.readInt()));
Index: clang/lib/AST/TextNodeDumper.cpp
===
--- clang/lib/AST/TextNodeDumper.cpp
+++ clang/lib/AST/TextNodeDumper.cpp
@@ -126,6 +126,11 @@
   if (const auto *E = dyn_cast(Node)) {
 dumpType(E->getType());
 
+if (E->containsErrors()) {
+  ColorScope Color(OS, ShowColors, ErrorsColor);
+  OS << " contains-e

[PATCH] D76125: [clangd] Decouple preambleworker from astworker, NFCI

2020-03-18 Thread Kadir Cetinkaya via Phabricator via cfe-commits

kadircet updated this revision to Diff 251021.
kadircet added a comment.

- Reset CurrentReq inside run loop, rather than inside build.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76125

Files:
  clang-tools-extra/clangd/Preamble.cpp
  clang-tools-extra/clangd/Preamble.h
  clang-tools-extra/clangd/TUScheduler.cpp

Index: clang-tools-extra/clangd/TUScheduler.cpp
===
--- clang-tools-extra/clangd/TUScheduler.cpp
+++ clang-tools-extra/clangd/TUScheduler.cpp
@@ -49,13 +49,16 @@
 #include "GlobalCompilationDatabase.h"
 #include "Logger.h"
 #include "ParsedAST.h"
+#include "Path.h"
 #include "Preamble.h"
+#include "Threading.h"
 #include "Trace.h"
 #include "index/CanonicalIncludes.h"
 #include "clang/Frontend/CompilerInvocation.h"
 #include "clang/Tooling/CompilationDatabase.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/ScopeExit.h"
+#include "llvm/ADT/StringRef.h"
 #include "llvm/Support/Errc.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/Threading.h"
@@ -149,6 +152,177 @@
 };
 
 namespace {
+/// Responsible for building and providing access to the preamble of a TU.
+/// Whenever the thread is idle and the preamble is outdated, it starts to build
+/// a fresh preamble from the latest inputs. If RunSync is true, preambles are
+/// built synchronously in update() instead.
+class PreambleThread {
+public:
+  PreambleThread(llvm::StringRef FileName, ParsingCallbacks &Callbacks,
+ bool StorePreambleInMemory, bool RunSync)
+  : FileName(FileName), Callbacks(Callbacks),
+StoreInMemory(StorePreambleInMemory), RunSync(RunSync) {}
+
+  size_t getUsedBytes() const {
+auto Preamble = latest();
+return Preamble ? Preamble->Preamble.getSize() : 0;
+  }
+
+  /// It isn't guaranteed that each requested version will be built. If there
+  /// are multiple update requests while building a preamble, only the last one
+  /// will be built.
+  void update(CompilerInvocation *CI, ParseInputs PI) {
+// If compiler invocation was broken, just fail out early.
+if (!CI) {
+  TUStatus::BuildDetails Details;
+  Details.BuildFailed = true;
+  std::string TaskName = llvm::formatv("Update ({0})", PI.Version);
+  emitTUStatus({TUAction::BuildingPreamble, std::move(TaskName)}, &Details);
+  // Make sure anyone waiting for the preamble gets notified it could not be
+  // built.
+  BuiltFirst.notify();
+  return;
+}
+// Make possibly expensive copy while not holding the lock.
+Request Req = {std::make_unique(*CI), std::move(PI)};
+if (RunSync) {
+  build(std::move(Req));
+  return;
+}
+{
+  std::lock_guard Lock(Mutex);
+  assert(!Done && "Build request to PreambleWorker after stop");
+  NextReq = std::move(Req);
+}
+// Let the worker thread know there's a request, notify_one is safe as there
+// should be a single worker thread waiting on it.
+ReqCV.notify_all();
+  }
+
+  /// Blocks until at least a single request has been processed. Note that it
+  /// will unblock even after an unsuccessful build.
+  void waitForFirst() const { BuiltFirst.wait(); }
+
+  /// Returns the latest built preamble, might be null if no preamble has been
+  /// built or latest attempt resulted in a failure.
+  std::shared_ptr latest() const {
+std::lock_guard Lock(Mutex);
+return LatestBuild;
+  }
+
+  void run() {
+dlog("Starting preamble worker for {0}", FileName);
+while (true) {
+  {
+std::unique_lock Lock(Mutex);
+assert(!CurrentReq && "Already processing a request?");
+// Wait until stop is called or there is a request.
+ReqCV.wait(Lock, [this] { return NextReq || Done; });
+if (Done)
+  break;
+CurrentReq = std::move(*NextReq);
+NextReq.reset();
+  }
+  // Build the preamble and let the waiters know about it.
+  build(std::move(*CurrentReq));
+  {
+std::lock_guard Lock(Mutex);
+CurrentReq.reset();
+  }
+  BuiltFirst.notify();
+  ReqCV.notify_all();
+}
+// We are no longer going to build any preambles, let the waiters know that.
+BuiltFirst.notify();
+dlog("Preamble worker for {0} finished", FileName);
+  }
+
+  /// Signals the run loop to exit.
+  void stop() {
+dlog("Stopping preamble worker for {0}", FileName);
+{
+  std::lock_guard Lock(Mutex);
+  Done = true;
+}
+// Let the worker thread know that it should stop.
+ReqCV.notify_all();
+  }
+
+  bool blockUntilIdle(Deadline Timeout) const {
+std::unique_lock Lock(Mutex);
+return wait(Lock, ReqCV, Timeout, [&] { return !NextReq && !CurrentReq; });
+  }
+
+private:
+  /// Holds inputs required for building a preamble. CI is guaranteed to be
+  /// non-null.
+  struct Request {
+std::unique_ptr CI;
+ParseInputs Inputs;
+  };

[PATCH] D76304: [clangd] Update TUStatus api to accommodate preamble thread

2020-03-18 Thread Kadir Cetinkaya via Phabricator via cfe-commits

kadircet added inline comments.



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:161
+/// update.
+class TUStatusManager {
+public:

sammccall wrote:
> nit: "manager" doesn't really explain what this is, and it's used both as the 
> class name and the main description in the comment.
> 
> Maybe TUStatusTracker or something - "Threadsafe holder for TUStatus..."
NAMNG !!! :(((



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:198
+
+  mutable std::mutex StatusMu;
+  TUStatus Status;

sammccall wrote:
> why mutable with  no const functions?
I had a readable version at some point, just leftover from those days :P



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:277
   build(std::move(*CurrentReq));
+  bool IsEmpty = false;
+  {

sammccall wrote:
> Seems clearer to do this immediately before blocking?
> 
> at the top:
> 
> ```
> if (!NextReq) {
>   Lock.unlock();
>   StatusManager.setPreambleAction(Idle);
>   Lock.lock();
>   ReqCV.wait(NextReq || Done);
> }
> if (Done)
>   break;
> ```
i agree, but I wanted to keep the current semantics. we only start emitting 
tustatuses after thread starts executing the first request.

happy to change *both* preamblethread and astworker to emit before blocking 
though. wdyt?



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:285
+StatusManager.setPreambleAction({TUAction::Idle, /*Name=*/""});
+  BuiltFirst.notify();
+  ReqCV.notify_all();

sammccall wrote:
> why this change?
this needs to happen after resetting `CurrentReq` and previously this was part 
of `build`. It makes more sense to hanlde this resetting as part of the worker 
thread, rather than as part of the preamble build logic.

but I suppose it doesn't belong into this patch. moving it to the 
https://reviews.llvm.org/D76125



Comment at: clang-tools-extra/clangd/TUScheduler.h:104
 struct TUStatus {
-  struct BuildDetails {
-/// Indicates whether clang failed to build the TU.
-bool BuildFailed = false;
-/// Indicates whether we reused the prebuilt AST.
-bool ReuseAST = false;
+  enum BuildStatus {
+/// Haven't run a built yet

sammccall wrote:
> What's the purpose of this change? It seems to make the build details harder 
> to maintain/extend.
> 
> (In particular, say we were going to add a "fallback command was used" bit, 
> where would it go after this change?)
this was to narrow down the interface. Currently builddetails is only being 
used to report buildstatus, and those cases are mutually exclusive(a build 
can't be both a reuse and failure). Therefore i wanted to make that more 
explicit.

if we decide to add more details, I would say we should rather get BuildDetails 
struct back, with a Status enum and a couple more state to signal any other 
information.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76304



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

[PATCH] D76304: [clangd] Update TUStatus api to accommodate preamble thread

2020-03-18 Thread Kadir Cetinkaya via Phabricator via cfe-commits

kadircet updated this revision to Diff 251022.
kadircet marked 8 inline comments as done.
kadircet added a comment.

- Address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76304

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/TUScheduler.cpp
  clang-tools-extra/clangd/TUScheduler.h
  clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp

Index: clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
===
--- clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
+++ clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
@@ -24,6 +24,7 @@
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 #include 
+#include 
 #include 
 #include 
 
@@ -40,13 +41,18 @@
 using ::testing::Pointee;
 using ::testing::UnorderedElementsAre;
 
-MATCHER_P2(TUState, State, ActionName, "") {
-  if (arg.Action.S != State) {
-*result_listener << "state is " << arg.Action.S;
+MATCHER_P3(TUState, PreambleState, ASTState, BS, "") {
+  if (arg.PreambleState != PreambleState) {
+*result_listener << "preamblestate is "
+ << static_cast(arg.PreambleState);
 return false;
   }
-  if (arg.Action.Name != ActionName) {
-*result_listener << "name is " << arg.Action.Name;
+  if (arg.ASTState.S != ASTState) {
+*result_listener << "aststate is " << arg.ASTState.S;
+return false;
+  }
+  if (arg.BS != BS) {
+*result_listener << "builddetail is " << arg.BS;
 return false;
   }
   return true;
@@ -732,14 +738,13 @@
 
   // Update the source contents, which should trigger an initial build with
   // the header file missing.
-  updateWithDiags(S, Source, Inputs, WantDiagnostics::Yes,
-  [](std::vector Diags) {
-EXPECT_THAT(
-Diags,
-ElementsAre(
-Field(&Diag::Message, "'foo.h' file not found"),
-Field(&Diag::Message, "use of undeclared identifier 'a'")));
-  });
+  updateWithDiags(
+  S, Source, Inputs, WantDiagnostics::Yes, [](std::vector Diags) {
+EXPECT_THAT(Diags,
+ElementsAre(Field(&Diag::Message, "'foo.h' file not found"),
+Field(&Diag::Message,
+  "use of undeclared identifier 'a'")));
+  });
 
   // Add the header file. We need to recreate the inputs since we changed a
   // file from underneath the test FS.
@@ -749,18 +754,17 @@
 
   // The addition of the missing header file shouldn't trigger a rebuild since
   // we don't track missing files.
-  updateWithDiags(S, Source, Inputs, WantDiagnostics::Yes,
-  [](std::vector Diags) {
-ADD_FAILURE() << "Did not expect diagnostics for missing header update";
-  });
+  updateWithDiags(
+  S, Source, Inputs, WantDiagnostics::Yes, [](std::vector Diags) {
+ADD_FAILURE() << "Did not expect diagnostics for missing header update";
+  });
 
   // Forcing the reload should should cause a rebuild which no longer has any
   // errors.
   Inputs.ForceRebuild = true;
-  updateWithDiags(S, Source, Inputs, WantDiagnostics::Yes,
-  [](std::vector Diags) {
-EXPECT_THAT(Diags, IsEmpty());
-  });
+  updateWithDiags(
+  S, Source, Inputs, WantDiagnostics::Yes,
+  [](std::vector Diags) { EXPECT_THAT(Diags, IsEmpty()); });
 
   ASSERT_TRUE(S.blockUntilIdle(timeoutSeconds(10)));
 }
@@ -846,16 +850,28 @@
 
   ASSERT_TRUE(Server.blockUntilIdleForTest());
 
-  EXPECT_THAT(CaptureTUStatus.allStatus(),
-  ElementsAre(
-  // Statuses of "Update" action.
-  TUState(TUAction::RunningAction, "Update (1)"),
-  TUState(TUAction::BuildingPreamble, "Update (1)"),
-  TUState(TUAction::BuildingFile, "Update (1)"),
-
-  // Statuses of "Definitions" action
-  TUState(TUAction::RunningAction, "Definitions"),
-  TUState(TUAction::Idle, /*No action*/ "")));
+  EXPECT_THAT(
+  CaptureTUStatus.allStatus(),
+  ElementsAre(
+  // Everything starts with ASTWorker starting to execute an
+  // update
+  TUState(PreambleAction::Idle, ASTAction::RunningAction,
+  TUStatus::None),
+  // We build the preamble
+  TUState(PreambleAction::Building, ASTAction::RunningAction,
+  TUStatus::None),
+  // Preamble worker goes idle
+  TUState(PreambleAction::Idle, ASTAction::RunningAction,
+  TUStatus::None),
+  // We start building the ast
+  TUState(PreambleAction::Idle, ASTAction::Building, TUStatus::None),
+  // Built finished succesffully
+  TUState(PreambleAction::Idle, ASTAction::Building, TUStatus::Built),
+  // Rnning go to def
+  TUState(PreambleAction::Idle, ASTAction::RunningAction,
+  TU

[PATCH] D65591: [AST] Add a flag indicating if any subexpression had errors

2020-03-18 Thread Haojian Wu via Phabricator via cfe-commits

hokein added a comment.

In D65591#1927076 , @sammccall wrote:

> This is nice and simple, I do wonder whether we're missing cases in 
> ComputeDependence.cpp for the new bit.
>
> Can you take a pass through to check? (Assuming you haven't since picking up 
> this patch from Ilya). I'll do the same.


will do it. unfortunately, we are missing tests in this patch -- most AST nodes 
are dropped when clang sees semantic errors, so it is hard to write tests. 
after https://reviews.llvm.org/D69330, it'd be better, I think we can add them 
afterwards.




Comment at: clang/include/clang/AST/ASTDumperUtils.h:65
 static const TerminalColor ObjectKindColor = {llvm::raw_ostream::CYAN, false};
+// contains-errors
+static const TerminalColor ErrorsColor = {llvm::raw_ostream::RED, true};

sammccall wrote:
> I wonder if coloring the whole subtree red is an overreaction, but it may not 
> be. Let's see :)
I used it for a while, didn't see any big issue about it, we only color the 
`contains errors` word.



Comment at: clang/include/clang/AST/DependenceFlags.h:46
 Instantiation = 2,
+/// Placeholder, and is not used in actual Type.
+Error = 4,

sammccall wrote:
> I'd like this comment to explain why it exists if not used in actual types.
> 
> Is this used for `decltype(some-error-expr)`? Is this used so 
> toTypeDependence() returns something meaningful?
> 
> If this is used to make the bitcasting hacks work, we should just stop doing 
> that.
yeah, the main purpose of it is for convenient bitcast. AFAIK, we don't have a 
plan to use the error bit except in `Expr`. removing it for now.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65591



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

[PATCH] D66332: [clang-format] Fix the bug that joins template closer and > or >>

2020-03-18 Thread Hans Wennborg via Phabricator via cfe-commits

hans added a comment.

This seems to have caused https://bugs.llvm.org/show_bug.cgi?id=45218
Please take a look.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66332



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

[PATCH] D76062: [PATCH] [ARM] ARMv8.6-a command-line + BFloat16 Asm Support

2020-03-18 Thread Ties Stuij via Phabricator via cfe-commits

stuij added a comment.

The failing test is not related to this ticket. It is caused by 
https://reviews.llvm.org/D70720/new/#1925184, Oliver Stannard is looking into 
it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76062



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

[PATCH] D75579: Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime-registration

2020-03-18 Thread serge via Phabricator via cfe-commits

serge-sans-paille added a comment.

@modocache: fixed by 8d019cda851a1031fbce3c50be0975438147f11d 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75579



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

[clang] 28c5d97 - [ARM, MVE] Add intrinsics and isel for MVE integer VMLA.

2020-03-18 Thread Simon Tatham via cfe-commits


Author: Simon Tatham
Date: 2020-03-18T10:55:04Z
New Revision: 28c5d97beec7a2582869f992f54a178c805e2e51

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

LOG: [ARM,MVE] Add intrinsics and isel for MVE integer VMLA.

Summary:
These instructions compute multiply+add in integers, with one of the
operands being a splat of a scalar. (VMLA and VMLAS differ in whether
the splat operand is a multiplier or the addend.)

I've represented these in IR using existing standard IR operations for
the unpredicated forms. The predicated forms are done with target-
specific intrinsics, as usual.

When operating on n-bit vector lanes, only the bottom n bits of the
i32 scalar operand are used. So we have to tell that to isel lowering,
to allow it to remove a pointless sign- or zero-extension instruction
on that input register. That's done in `PerformIntrinsicCombine`, but
first I had to enable `PerformIntrinsicCombine` for MVE targets
(previously all the intrinsics it handled were for NEON), and make it
a method of `ARMTargetLowering` so that it can get at
`SimplifyDemandedBits`.

Reviewers: dmgreen, MarkMurrayARM, miyuki, ostannard

Reviewed By: dmgreen

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

Tags: #clang

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

Added: 


Modified: 
clang/include/clang/Basic/arm_mve.td
clang/test/CodeGen/arm-mve-intrinsics/ternary.c
llvm/include/llvm/IR/IntrinsicsARM.td
llvm/lib/Target/ARM/ARMISelLowering.cpp
llvm/lib/Target/ARM/ARMISelLowering.h
llvm/lib/Target/ARM/ARMInstrMVE.td
llvm/test/CodeGen/Thumb2/mve-intrinsics/ternary.ll

Removed: 




diff  --git a/clang/include/clang/Basic/arm_mve.td 
b/clang/include/clang/Basic/arm_mve.td
index d2203d650301..5498a144c9e2 100644
--- a/clang/include/clang/Basic/arm_mve.td
+++ b/clang/include/clang/Basic/arm_mve.td
@@ -202,6 +202,24 @@ let params = T.Float in {
   defm vfms: FMA<0>;
 }
 
+let params = T.Int, pnt = PNT_NType in {
+  def vmlaq_n: Intrinsic<
+Vector, (args Vector:$addend, Vector:$m1, unpromoted:$m2_s),
+(add (mul $m1, (splat $m2_s)), $addend)>;
+  def vmlasq_n: Intrinsic<
+Vector, (args Vector:$m1, Vector:$m2, unpromoted:$addend_s),
+(add (mul $m1, $m2), (splat $addend_s))>;
+
+  def vmlaq_m_n: Intrinsic<
+Vector, (args Vector:$addend, Vector:$m1, Scalar:$m2_s, Predicate:$pred),
+(IRInt<"vmla_n_predicated", [Vector, Predicate]>
+$addend, $m1, $m2_s, $pred)>;
+  def vmlasq_m_n: Intrinsic<
+Vector, (args Vector:$m1, Vector:$m2, Scalar:$addend_s, Predicate:$pred),
+(IRInt<"vmlas_n_predicated", [Vector, Predicate]>
+$m1, $m2, $addend_s, $pred)>;
+}
+
 let params = !listconcat(T.Int16, T.Int32) in {
   let pnt = PNT_None in {
 def vmvnq_n: Intrinsic undef, i8 
[[C:%.*]], i32 0
+// CHECK-NEXT:[[DOTSPLAT:%.*]] = shufflevector <16 x i8> 
[[DOTSPLATINSERT]], <16 x i8> undef, <16 x i32> zeroinitializer
+// CHECK-NEXT:[[TMP0:%.*]] = mul <16 x i8> [[B:%.*]], [[DOTSPLAT]]
+// CHECK-NEXT:[[TMP1:%.*]] = add <16 x i8> [[TMP0]], [[A:%.*]]
+// CHECK-NEXT:ret <16 x i8> [[TMP1]]
+//
+int8x16_t test_vmlaq_n_s8(int8x16_t a, int8x16_t b, int8_t c) {
+#ifdef POLYMORPHIC
+  return vmlaq(a, b, c);
+#else  /* POLYMORPHIC */
+  return vmlaq_n_s8(a, b, c);
+#endif /* POLYMORPHIC */
+}
+
+// CHECK-LABEL: @test_vmlaq_n_s16(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DOTSPLATINSERT:%.*]] = insertelement <8 x i16> undef, i16 
[[C:%.*]], i32 0
+// CHECK-NEXT:[[DOTSPLAT:%.*]] = shufflevector <8 x i16> 
[[DOTSPLATINSERT]], <8 x i16> undef, <8 x i32> zeroinitializer
+// CHECK-NEXT:[[TMP0:%.*]] = mul <8 x i16> [[B:%.*]], [[DOTSPLAT]]
+// CHECK-NEXT:[[TMP1:%.*]] = add <8 x i16> [[TMP0]], [[A:%.*]]
+// CHECK-NEXT:ret <8 x i16> [[TMP1]]
+//
+int16x8_t test_vmlaq_n_s16(int16x8_t a, int16x8_t b, int16_t c) {
+#ifdef POLYMORPHIC
+  return vmlaq(a, b, c);
+#else  /* POLYMORPHIC */
+  return vmlaq_n_s16(a, b, c);
+#endif /* POLYMORPHIC */
+}
+
+// CHECK-LABEL: @test_vmlaq_n_s32(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DOTSPLATINSERT:%.*]] = insertelement <4 x i32> undef, i32 
[[C:%.*]], i32 0
+// CHECK-NEXT:[[DOTSPLAT:%.*]] = shufflevector <4 x i32> 
[[DOTSPLATINSERT]], <4 x i32> undef, <4 x i32> zeroinitializer
+// CHECK-NEXT:[[TMP0:%.*]] = mul <4 x i32> [[B:%.*]], [[DOTSPLAT]]
+// CHECK-NEXT:[[TMP1:%.*]] = add <4 x i32> [[TMP0]], [[A:%.*]]
+// CHECK-NEXT:ret <4 x i32> [[TMP1]]
+//
+int32x4_t test_vmlaq_n_s32(int32x4_t a, int32x4_t b, int32_t c) {
+#ifdef POLYMORPHIC
+  return vmlaq(a, b, c);
+#else  /* POLYMORPHIC */
+  return vmlaq_n_s32(a, b, c);
+#endif /* POLYMORPHIC */
+}
+
+// CHECK-LABEL: @test_vmlaq_n_u8(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DOTSPLATINSERT:%.*]] = insertelement <16 x

[clang] 928776d - [ARM,MVE] Add intrinsics for the VQDMLAH family.

2020-03-18 Thread Simon Tatham via cfe-commits


Author: Simon Tatham
Date: 2020-03-18T10:55:04Z
New Revision: 928776de9233be1487c1b56f90c90ed25b25e355

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

LOG: [ARM,MVE] Add intrinsics for the VQDMLAH family.

Summary:
These are complicated integer multiply+add instructions with extra
saturation, taking the high half of a double-width product, and
optional rounding. There's no sensible way to represent that in
standard IR, so I've converted the clang builtins directly to
target-specific intrinsics.

Reviewers: dmgreen, MarkMurrayARM, miyuki, ostannard

Reviewed By: miyuki

Subscribers: kristof.beyls, hiraditya, cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang/include/clang/Basic/arm_mve.td
clang/test/CodeGen/arm-mve-intrinsics/ternary.c
llvm/include/llvm/IR/IntrinsicsARM.td
llvm/lib/Target/ARM/ARMISelLowering.cpp
llvm/lib/Target/ARM/ARMInstrMVE.td
llvm/test/CodeGen/Thumb2/mve-intrinsics/ternary.ll

Removed: 




diff  --git a/clang/include/clang/Basic/arm_mve.td 
b/clang/include/clang/Basic/arm_mve.td
index 5498a144c9e2..ae6ce4837d76 100644
--- a/clang/include/clang/Basic/arm_mve.td
+++ b/clang/include/clang/Basic/arm_mve.td
@@ -220,6 +220,29 @@ let params = T.Int, pnt = PNT_NType in {
 $m1, $m2, $addend_s, $pred)>;
 }
 
+multiclass VQDMLA {
+  def hq_n: Intrinsic<
+Vector, (args Vector:$addend, Vector:$m1, Scalar:$m2_s),
+(IRInt $addend, $m1, $m2_s)>;
+  def shq_n: Intrinsic<
+Vector, (args Vector:$m1, Vector:$m2, Scalar:$addend_s),
+(IRInt $m1, $m2, $addend_s)>;
+
+  def hq_m_n: Intrinsic<
+Vector, (args Vector:$addend, Vector:$m1, Scalar:$m2_s, Predicate:$pred),
+(IRInt
+ $addend, $m1, $m2_s, $pred)>;
+  def shq_m_n: Intrinsic<
+Vector, (args Vector:$m1, Vector:$m2, Scalar:$addend_s, Predicate:$pred),
+(IRInt
+ $m1, $m2, $addend_s, $pred)>;
+}
+
+let params = T.Signed, pnt = PNT_NType in {
+  defm vqdmla: VQDMLA;
+  defm vqrdmla: VQDMLA;
+}
+
 let params = !listconcat(T.Int16, T.Int32) in {
   let pnt = PNT_None in {
 def vmvnq_n: Intrinsic 
@llvm.arm.mve.vqdmlah.v16i8(<16 x i8> [[B:%.*]], <16 x i8> [[A:%.*]], i32 
[[TMP0]])
+// CHECK-NEXT:ret <16 x i8> [[TMP1]]
+//
+int8x16_t test_vqdmlahq_n_s8(int8x16_t a, int8x16_t b, int8_t c) {
+#ifdef POLYMORPHIC
+  return vqdmlahq(a, b, c);
+#else  /* POLYMORPHIC */
+  return vqdmlahq_n_s8(a, b, c);
+#endif /* POLYMORPHIC */
+}
+
+// CHECK-LABEL: @test_vqdmlahq_n_s16(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[TMP0:%.*]] = zext i16 [[C:%.*]] to i32
+// CHECK-NEXT:[[TMP1:%.*]] = call <8 x i16> @llvm.arm.mve.vqdmlah.v8i16(<8 
x i16> [[B:%.*]], <8 x i16> [[A:%.*]], i32 [[TMP0]])
+// CHECK-NEXT:ret <8 x i16> [[TMP1]]
+//
+int16x8_t test_vqdmlahq_n_s16(int16x8_t a, int16x8_t b, int16_t c) {
+#ifdef POLYMORPHIC
+  return vqdmlahq(a, b, c);
+#else  /* POLYMORPHIC */
+  return vqdmlahq_n_s16(a, b, c);
+#endif /* POLYMORPHIC */
+}
+
+// CHECK-LABEL: @test_vqdmlahq_n_s32(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[TMP0:%.*]] = call <4 x i32> @llvm.arm.mve.vqdmlah.v4i32(<4 
x i32> [[B:%.*]], <4 x i32> [[A:%.*]], i32 [[C:%.*]])
+// CHECK-NEXT:ret <4 x i32> [[TMP0]]
+//
+int32x4_t test_vqdmlahq_n_s32(int32x4_t a, int32x4_t b, int32_t c) {
+#ifdef POLYMORPHIC
+  return vqdmlahq(a, b, c);
+#else  /* POLYMORPHIC */
+  return vqdmlahq_n_s32(a, b, c);
+#endif /* POLYMORPHIC */
+}
+
+// CHECK-LABEL: @test_vqrdmlahq_n_s8(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[TMP0:%.*]] = zext i8 [[C:%.*]] to i32
+// CHECK-NEXT:[[TMP1:%.*]] = call <16 x i8> 
@llvm.arm.mve.vqrdmlah.v16i8(<16 x i8> [[B:%.*]], <16 x i8> [[A:%.*]], i32 
[[TMP0]])
+// CHECK-NEXT:ret <16 x i8> [[TMP1]]
+//
+int8x16_t test_vqrdmlahq_n_s8(int8x16_t a, int8x16_t b, int8_t c) {
+#ifdef POLYMORPHIC
+  return vqrdmlahq(a, b, c);
+#else  /* POLYMORPHIC */
+  return vqrdmlahq_n_s8(a, b, c);
+#endif /* POLYMORPHIC */
+}
+
+// CHECK-LABEL: @test_vqrdmlahq_n_s16(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[TMP0:%.*]] = zext i16 [[C:%.*]] to i32
+// CHECK-NEXT:[[TMP1:%.*]] = call <8 x i16> 
@llvm.arm.mve.vqrdmlah.v8i16(<8 x i16> [[B:%.*]], <8 x i16> [[A:%.*]], i32 
[[TMP0]])
+// CHECK-NEXT:ret <8 x i16> [[TMP1]]
+//
+int16x8_t test_vqrdmlahq_n_s16(int16x8_t a, int16x8_t b, int16_t c) {
+#ifdef POLYMORPHIC
+  return vqrdmlahq(a, b, c);
+#else  /* POLYMORPHIC */
+  return vqrdmlahq_n_s16(a, b, c);
+#endif /* POLYMORPHIC */
+}
+
+// CHECK-LABEL: @test_vqrdmlahq_n_s32(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[TMP0:%.*]] = call <4 x i32> 
@llvm.arm.mve.vqrdmlah.v4i32(<4 x i32> [[B:%.*]], <4 x i32> [[A:%.*]], i32 
[[C:%.*]])
+// CHECK-NEXT:ret <4 x i32> [[TMP0]]
+//
+int32x4_t test_vqrdmlahq_n_s32(int32x4_t a, int32x4_t b,

[clang] c5b8146 - Reland D75470 [SVE] Auto-generate builtins and header for svld1.

2020-03-18 Thread Sander de Smalen via cfe-commits


Author: Sander de Smalen
Date: 2020-03-18T11:16:28Z
New Revision: c5b81466c2bcc194e5563f39f5be3638760b4849

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

LOG: Reland D75470 [SVE] Auto-generate builtins and header for svld1.

Reworked the patch to avoid sharing a header (SVETypeFlags.h) between
include/clang/Basic and utils/TableGen/SveEmitter.cpp. Now the patch
generates the enum/flags which is included in TargetBuiltins.h.

Also renamed one of the SveEmitter options to be in line with MVE.

Summary:

This is a first patch in a series for the SveEmitter to generate the arm_sve.h
header file and builtins.

I've tried my best to strip down this patch as best as I could, but there
are still a few changes that are not necessarily exercised by the load 
intrinsics
in this patch, mostly around the SVEType class which has some common logic to
represent types from a type and prototype string. I thought it didn't make
much sense to remove that from this patch and split it up.

Added: 
clang/include/clang/Basic/BuiltinsSVE.def

Modified: 
clang/include/clang/Basic/BuiltinsAArch64.def
clang/include/clang/Basic/CMakeLists.txt
clang/include/clang/Basic/TargetBuiltins.h
clang/include/clang/Basic/arm_sve.td
clang/lib/Basic/Targets/AArch64.cpp
clang/lib/CodeGen/CGBuiltin.cpp
clang/lib/CodeGen/CodeGenFunction.h
clang/utils/TableGen/SveEmitter.cpp
clang/utils/TableGen/TableGen.cpp
clang/utils/TableGen/TableGenBackends.h

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsAArch64.def 
b/clang/include/clang/Basic/BuiltinsAArch64.def
index 8f3a24c2e1f6..f07c567053de 100644
--- a/clang/include/clang/Basic/BuiltinsAArch64.def
+++ b/clang/include/clang/Basic/BuiltinsAArch64.def
@@ -99,19 +99,6 @@ BUILTIN(__builtin_arm_tcommit, "v", "n")
 BUILTIN(__builtin_arm_tcancel, "vWUIi", "n")
 BUILTIN(__builtin_arm_ttest, "WUi", "nc")
 
-// SVE
-BUILTIN(__builtin_sve_svld1_s16, "q8sq16bSsC*", "n")
-BUILTIN(__builtin_sve_svld1_s32, "q4iq16bSiC*", "n")
-BUILTIN(__builtin_sve_svld1_s64, "q2Wiq16bSWiC*", "n")
-BUILTIN(__builtin_sve_svld1_s8, "q16Scq16bScC*", "n")
-BUILTIN(__builtin_sve_svld1_u16, "q8Usq16bUsC*", "n")
-BUILTIN(__builtin_sve_svld1_u32, "q4Uiq16bUiC*", "n")
-BUILTIN(__builtin_sve_svld1_u64, "q2UWiq16bUWiC*", "n")
-BUILTIN(__builtin_sve_svld1_u8, "q16Ucq16bUcC*", "n")
-BUILTIN(__builtin_sve_svld1_f64, "q2dq16bdC*", "n")
-BUILTIN(__builtin_sve_svld1_f32, "q4fq16bfC*", "n")
-BUILTIN(__builtin_sve_svld1_f16, "q8hq16bhC*", "n")
-
 TARGET_HEADER_BUILTIN(_BitScanForward, "UcUNi*UNi", "nh", "intrin.h", 
ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_BitScanReverse, "UcUNi*UNi", "nh", "intrin.h", 
ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_BitScanForward64, "UcUNi*ULLi", "nh", "intrin.h", 
ALL_MS_LANGUAGES, "")

diff  --git a/clang/include/clang/Basic/BuiltinsSVE.def 
b/clang/include/clang/Basic/BuiltinsSVE.def
new file mode 100644
index ..2839ca992d98
--- /dev/null
+++ b/clang/include/clang/Basic/BuiltinsSVE.def
@@ -0,0 +1,20 @@
+//===--- BuiltinsSVE.def - SVE Builtin function database *- C++ 
-*-===//
+//
+//  Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+//  See https://llvm.org/LICENSE.txt for license information.
+//  SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file defines the SVE-specific builtin function database.  Users of
+// this file must define the BUILTIN macro to make use of this information.
+//
+//===--===//
+
+// The format of this database matches clang/Basic/Builtins.def.
+
+#define GET_SVE_BUILTINS
+#include "clang/Basic/arm_sve_builtins.inc"
+#undef GET_SVE_BUILTINS
+
+#undef BUILTIN

diff  --git a/clang/include/clang/Basic/CMakeLists.txt 
b/clang/include/clang/Basic/CMakeLists.txt
index ea011a8af177..5eda48e8f250 100644
--- a/clang/include/clang/Basic/CMakeLists.txt
+++ b/clang/include/clang/Basic/CMakeLists.txt
@@ -60,7 +60,15 @@ clang_tablegen(arm_mve_builtin_sema.inc 
-gen-arm-mve-builtin-sema
 clang_tablegen(arm_mve_builtin_aliases.inc -gen-arm-mve-builtin-aliases
   SOURCE arm_mve.td
   TARGET ClangARMMveBuiltinAliases)
-
+clang_tablegen(arm_sve_builtins.inc -gen-arm-sve-builtins
+  SOURCE arm_sve.td
+  TARGET ClangARMSveBuiltins)
+clang_tablegen(arm_sve_builtin_cg.inc -gen-arm-sve-builtin-codegen
+  SOURCE arm_sve.td
+  TARGET ClangARMSveBuiltinCG)
+clang_tablegen(arm_sve_typeflags.inc -gen-arm-sve-typeflags
+  SOURCE arm_sve.td
+  TARGET ClangARMSveTypeFlags)
 clang_tablegen(arm_cde_builtins.inc -gen-arm-cde-builtin-def
   SOURCE arm_cde.td
   TARGET ClangARMCdeBuiltinsDef)

diff  --git a/clang/include

[PATCH] D76032: [HIP] Fix duplicate clang -cc1 options on MSVC toolchain

2020-03-18 Thread Yaxun Liu via Phabricator via cfe-commits

yaxunl added a comment.

ping


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

https://reviews.llvm.org/D76032



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

[PATCH] D76062: [PATCH] [ARM] ARMv8.6-a command-line + BFloat16 Asm Support

2020-03-18 Thread Sjoerd Meijer via Phabricator via cfe-commits

SjoerdMeijer added inline comments.



Comment at: clang/lib/Basic/Targets/AArch64.cpp:184
+  // Also include the Armv8.5 defines
+  // FIXME: Armv8.6 makes some extensions mandatory. Handle them here.
+  getTargetDefinesARMV85A(Opts, Builder);

Can you be more specific, what are we missing here?

Hmm, now I see the same above: "FIXME: Armv8.5 makes some extensions mandatory. 
Handle them here."
While you're at it, can you also change that?



Comment at: llvm/include/llvm/Support/AArch64TargetParser.def:52
+  AArch64::AEK_RDM  | AArch64::AEK_RCPC | AArch64::AEK_DOTPROD |
+  AArch64::AEK_SM4  | AArch64::AEK_SHA3 | AArch64::AEK_BF16|
+  AArch64::AEK_SHA2 | AArch64::AEK_AES  | AArch64::AEK_I8MM))

just double checking (because I can't remember): BF16 is a mandatory extension?



Comment at: llvm/lib/Target/ARM/ARM.td:532
+   "Support ARM v8.6a instructions",
+   [HasV8_5aOps, FeatureBF16]>;
+

it's implied here, so looks mandatory.



Comment at: llvm/lib/Target/ARM/ARMSubtarget.h:260
 
+  /// HasBF16 - True if subtarget supports BFloat16 floating point
+  bool HasBF16 = false;

nit:  BFloat16 floating point ->  BFloat16 floating point operations


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76062



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

[PATCH] D76344: [hip] Revise `GlobalDecl` constructors. NFC.

2020-03-18 Thread Yaxun Liu via Phabricator via cfe-commits

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

LGTM. Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76344



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

[PATCH] D76291: [Support] Fix formatted_raw_ostream for UTF-8

2020-03-18 Thread Oliver Stannard (Linaro) via Phabricator via cfe-commits

ostannard marked 16 inline comments as done.
ostannard added inline comments.



Comment at: llvm/unittests/Support/formatted_raw_ostream_test.cpp:88
+
+TEST(formatted_raw_ostreamTest, Test_UTF8) {
+  SmallString<128> A;

hubert.reinterpretcast wrote:
> Should there be a test for combining characters?
This doesn't support combining characters, I don't think there's much point in 
adding a test for something which doesn't work.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76291



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

[PATCH] D76291: [Support] Fix formatted_raw_ostream for UTF-8

2020-03-18 Thread Oliver Stannard (Linaro) via Phabricator via cfe-commits

ostannard updated this revision to Diff 251030.
ostannard added a comment.

- I managed to reproduce the lsl-zero.s test failure on windows, this turned 
out to be because the test merges stdout and stderr, which can result in them 
being interleaved in ways which breaks tests. The test doesn't check anything 
in stderr, so fixed by redirecting that to /dev/null.
- The unit test was failing when built with MSVC, fixed by explicitly using 
UTF-8 string literals.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76291

Files:
  clang/test/Analysis/checker-plugins.c
  llvm/include/llvm/Support/FormattedStream.h
  llvm/lib/Support/FormattedStream.cpp
  llvm/test/MC/ARM/lsl-zero.s
  llvm/unittests/Support/formatted_raw_ostream_test.cpp

Index: llvm/unittests/Support/formatted_raw_ostream_test.cpp
===
--- llvm/unittests/Support/formatted_raw_ostream_test.cpp
+++ llvm/unittests/Support/formatted_raw_ostream_test.cpp
@@ -29,4 +29,143 @@
   }
 }
 
+TEST(formatted_raw_ostreamTest, Test_LineColumn) {
+  // Test tracking of line and column numbers in a stream.
+  SmallString<128> A;
+  raw_svector_ostream B(A);
+  formatted_raw_ostream C(B);
+
+  EXPECT_EQ(0U, C.getLine());
+  EXPECT_EQ(0U, C.getColumn());
+
+  C << "a";
+  EXPECT_EQ(0U, C.getLine());
+  EXPECT_EQ(1U, C.getColumn());
+
+  C << "bcdef";
+  EXPECT_EQ(0U, C.getLine());
+  EXPECT_EQ(6U, C.getColumn());
+
+  // '\n' increments line number, sets column to zero.
+  C << "\n";
+  EXPECT_EQ(1U, C.getLine());
+  EXPECT_EQ(0U, C.getColumn());
+
+  // '\r sets column to zero without changing line number
+  C << "foo\r";
+  EXPECT_EQ(1U, C.getLine());
+  EXPECT_EQ(0U, C.getColumn());
+
+  // '\t' advances column to the next multiple of 8.
+  // FIXME: If the column number is already a multiple of 8 this will do
+  // nothing, is this behaviour correct?
+  C << "1\t";
+  EXPECT_EQ(8U, C.getColumn());
+  C << "\t";
+  EXPECT_EQ(8U, C.getColumn());
+  C << "1234567\t";
+  EXPECT_EQ(16U, C.getColumn());
+  EXPECT_EQ(1U, C.getLine());
+}
+
+TEST(formatted_raw_ostreamTest, Test_Flush) {
+  // Flushing the buffer causes the characters in the buffer to be scanned
+  // before the buffer is emptied, so line and column numbers will still be
+  // tracked properly.
+  SmallString<128> A;
+  raw_svector_ostream B(A);
+  B.SetBufferSize(32);
+  formatted_raw_ostream C(B);
+
+  C << "\nabc";
+  EXPECT_EQ(4U, C.GetNumBytesInBuffer());
+  C.flush();
+  EXPECT_EQ(1U, C.getLine());
+  EXPECT_EQ(3U, C.getColumn());
+  EXPECT_EQ(0U, C.GetNumBytesInBuffer());
+}
+
+TEST(formatted_raw_ostreamTest, Test_UTF8) {
+  SmallString<128> A;
+  raw_svector_ostream B(A);
+  B.SetBufferSize(32);
+  formatted_raw_ostream C(B);
+
+  // U+00A0 Non-breaking space: encoded as two bytes, but only one column wide.
+  C << u8"\u00a0";
+  EXPECT_EQ(0U, C.getLine());
+  EXPECT_EQ(1U, C.getColumn());
+  EXPECT_EQ(2U, C.GetNumBytesInBuffer());
+
+  // U+2468 CIRCLED DIGIT NINE: encoded as three bytes, but only one column
+  // wide.
+  C << u8"\u2468";
+  EXPECT_EQ(0U, C.getLine());
+  EXPECT_EQ(2U, C.getColumn());
+  EXPECT_EQ(5U, C.GetNumBytesInBuffer());
+
+  // U+0001 LINEAR B SYLLABLE B008 A: encoded as four bytes, but only one
+  // column wide.
+  C << u8"\U0001";
+  EXPECT_EQ(0U, C.getLine());
+  EXPECT_EQ(3U, C.getColumn());
+  EXPECT_EQ(9U, C.GetNumBytesInBuffer());
+
+  // U+55B5, CJK character, encodes as three bytes, takes up two columns.
+  C << u8"\u55b5";
+  EXPECT_EQ(0U, C.getLine());
+  EXPECT_EQ(5U, C.getColumn());
+  EXPECT_EQ(12U, C.GetNumBytesInBuffer());
+
+  // U+200B, zero-width space, encoded as three bytes but has no effect on the
+  // column or line number.
+  C << u8"\u200b";
+  EXPECT_EQ(0U, C.getLine());
+  EXPECT_EQ(5U, C.getColumn());
+  EXPECT_EQ(15U, C.GetNumBytesInBuffer());
+}
+
+TEST(formatted_raw_ostreamTest, Test_UTF8Buffered) {
+  SmallString<128> A;
+  raw_svector_ostream B(A);
+  B.SetBufferSize(4);
+  formatted_raw_ostream C(B);
+
+  // This character encodes as three bytes, so will cause the buffer to be
+  // flushed after the first byte (4 byte buffer, 3 bytes already written). We
+  // need to save the first part of the UTF-8 encoding until after the buffer is
+  // cleared and the remaining two bytes are written, at which point we can
+  // check the display width. In this case the display width is 1, so we end at
+  // column 4, with 6 bytes written into total, 2 of which are in the buffer.
+  C << u8"123\u2468";
+  EXPECT_EQ(0U, C.getLine());
+  EXPECT_EQ(4U, C.getColumn());
+  EXPECT_EQ(2U, C.GetNumBytesInBuffer());
+  C.flush();
+  EXPECT_EQ(6U, A.size());
+
+  // Same as above, but with a CJK character which displays as two columns.
+  C << u8"123\u55b5";
+  EXPECT_EQ(0U, C.getLine());
+  EXPECT_EQ(9U, C.getColumn());
+  EXPECT_EQ(2U, C.GetNumBytesInBuffer());
+  C.flush();
+  EXPECT_EQ(12U, A.size());

[PATCH] D76122: [ARM,MVE] Add intrinsics and isel for MVE integer VMLA.

2020-03-18 Thread Simon Tatham via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
simon_tatham marked an inline comment as done.
Closed by commit rG28c5d97beec7: [ARM,MVE] Add intrinsics and isel for MVE 
integer VMLA. (authored by simon_tatham).

Changed prior to commit:
  https://reviews.llvm.org/D76122?vs=250174&id=251031#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76122

Files:
  clang/include/clang/Basic/arm_mve.td
  clang/test/CodeGen/arm-mve-intrinsics/ternary.c
  llvm/include/llvm/IR/IntrinsicsARM.td
  llvm/lib/Target/ARM/ARMISelLowering.cpp
  llvm/lib/Target/ARM/ARMISelLowering.h
  llvm/lib/Target/ARM/ARMInstrMVE.td
  llvm/test/CodeGen/Thumb2/mve-intrinsics/ternary.ll

Index: llvm/test/CodeGen/Thumb2/mve-intrinsics/ternary.ll
===
--- llvm/test/CodeGen/Thumb2/mve-intrinsics/ternary.ll
+++ llvm/test/CodeGen/Thumb2/mve-intrinsics/ternary.ll
@@ -101,6 +101,168 @@
   ret <4 x float> %1
 }
 
+define arm_aapcs_vfpcc <16 x i8> @test_vmlaq_n_s8(<16 x i8> %a, <16 x i8> %b, i8 signext %c) {
+; CHECK-LABEL: test_vmlaq_n_s8:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vmla.u8 q0, q1, r0
+; CHECK-NEXT:bx lr
+entry:
+  %.splatinsert = insertelement <16 x i8> undef, i8 %c, i32 0
+  %.splat = shufflevector <16 x i8> %.splatinsert, <16 x i8> undef, <16 x i32> zeroinitializer
+  %0 = mul <16 x i8> %.splat, %b
+  %1 = add <16 x i8> %0, %a
+  ret <16 x i8> %1
+}
+
+define arm_aapcs_vfpcc <8 x i16> @test_vmlaq_n_s16(<8 x i16> %a, <8 x i16> %b, i16 signext %c) {
+; CHECK-LABEL: test_vmlaq_n_s16:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vmla.u16 q0, q1, r0
+; CHECK-NEXT:bx lr
+entry:
+  %.splatinsert = insertelement <8 x i16> undef, i16 %c, i32 0
+  %.splat = shufflevector <8 x i16> %.splatinsert, <8 x i16> undef, <8 x i32> zeroinitializer
+  %0 = mul <8 x i16> %.splat, %b
+  %1 = add <8 x i16> %0, %a
+  ret <8 x i16> %1
+}
+
+define arm_aapcs_vfpcc <4 x i32> @test_vmlaq_n_s32(<4 x i32> %a, <4 x i32> %b, i32 %c) {
+; CHECK-LABEL: test_vmlaq_n_s32:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vmla.u32 q0, q1, r0
+; CHECK-NEXT:bx lr
+entry:
+  %.splatinsert = insertelement <4 x i32> undef, i32 %c, i32 0
+  %.splat = shufflevector <4 x i32> %.splatinsert, <4 x i32> undef, <4 x i32> zeroinitializer
+  %0 = mul <4 x i32> %.splat, %b
+  %1 = add <4 x i32> %0, %a
+  ret <4 x i32> %1
+}
+
+define arm_aapcs_vfpcc <16 x i8> @test_vmlaq_n_u8(<16 x i8> %a, <16 x i8> %b, i8 zeroext %c) {
+; CHECK-LABEL: test_vmlaq_n_u8:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vmla.u8 q0, q1, r0
+; CHECK-NEXT:bx lr
+entry:
+  %.splatinsert = insertelement <16 x i8> undef, i8 %c, i32 0
+  %.splat = shufflevector <16 x i8> %.splatinsert, <16 x i8> undef, <16 x i32> zeroinitializer
+  %0 = mul <16 x i8> %.splat, %b
+  %1 = add <16 x i8> %0, %a
+  ret <16 x i8> %1
+}
+
+define arm_aapcs_vfpcc <8 x i16> @test_vmlaq_n_u16(<8 x i16> %a, <8 x i16> %b, i16 zeroext %c) {
+; CHECK-LABEL: test_vmlaq_n_u16:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vmla.u16 q0, q1, r0
+; CHECK-NEXT:bx lr
+entry:
+  %.splatinsert = insertelement <8 x i16> undef, i16 %c, i32 0
+  %.splat = shufflevector <8 x i16> %.splatinsert, <8 x i16> undef, <8 x i32> zeroinitializer
+  %0 = mul <8 x i16> %.splat, %b
+  %1 = add <8 x i16> %0, %a
+  ret <8 x i16> %1
+}
+
+define arm_aapcs_vfpcc <4 x i32> @test_vmlaq_n_u32(<4 x i32> %a, <4 x i32> %b, i32 %c) {
+; CHECK-LABEL: test_vmlaq_n_u32:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vmla.u32 q0, q1, r0
+; CHECK-NEXT:bx lr
+entry:
+  %.splatinsert = insertelement <4 x i32> undef, i32 %c, i32 0
+  %.splat = shufflevector <4 x i32> %.splatinsert, <4 x i32> undef, <4 x i32> zeroinitializer
+  %0 = mul <4 x i32> %.splat, %b
+  %1 = add <4 x i32> %0, %a
+  ret <4 x i32> %1
+}
+
+define arm_aapcs_vfpcc <16 x i8> @test_vmlasq_n_s8(<16 x i8> %a, <16 x i8> %b, i8 signext %c) {
+; CHECK-LABEL: test_vmlasq_n_s8:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vmlas.u8 q1, q0, r0
+; CHECK-NEXT:vmov q0, q1
+; CHECK-NEXT:bx lr
+entry:
+  %0 = mul <16 x i8> %b, %a
+  %.splatinsert = insertelement <16 x i8> undef, i8 %c, i32 0
+  %.splat = shufflevector <16 x i8> %.splatinsert, <16 x i8> undef, <16 x i32> zeroinitializer
+  %1 = add <16 x i8> %.splat, %0
+  ret <16 x i8> %1
+}
+
+define arm_aapcs_vfpcc <8 x i16> @test_vmlasq_n_s16(<8 x i16> %a, <8 x i16> %b, i16 signext %c) {
+; CHECK-LABEL: test_vmlasq_n_s16:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vmlas.u16 q1, q0, r0
+; CHECK-NEXT:vmov q0, q1
+; CHECK-NEXT:bx lr
+entry:
+  %0 = mul <8 x i16> %b, %a
+  %.splatinsert = insertelement <8 x i16> undef, i16 %c, i32 0
+  %.splat = shufflevector <8 x i16> %.splatinsert, <8 x i16> undef, <8 x i32> zeroinitializer
+  %1 = add <8 x i16> %.splat, %0
+  ret <8 x i16> %1
+}
+
+define arm_aapcs_vfpcc <4 x i32> @test_v

[PATCH] D76123: [ARM,MVE] Add intrinsics for the VQDMLAH family.

2020-03-18 Thread Simon Tatham via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG928776de9233: [ARM,MVE] Add intrinsics for the VQDMLAH 
family. (authored by simon_tatham).

Changed prior to commit:
  https://reviews.llvm.org/D76123?vs=250157&id=251032#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76123

Files:
  clang/include/clang/Basic/arm_mve.td
  clang/test/CodeGen/arm-mve-intrinsics/ternary.c
  llvm/include/llvm/IR/IntrinsicsARM.td
  llvm/lib/Target/ARM/ARMISelLowering.cpp
  llvm/lib/Target/ARM/ARMInstrMVE.td
  llvm/test/CodeGen/Thumb2/mve-intrinsics/ternary.ll

Index: llvm/test/CodeGen/Thumb2/mve-intrinsics/ternary.ll
===
--- llvm/test/CodeGen/Thumb2/mve-intrinsics/ternary.ll
+++ llvm/test/CodeGen/Thumb2/mve-intrinsics/ternary.ll
@@ -263,6 +263,102 @@
   ret <4 x i32> %1
 }
 
+define arm_aapcs_vfpcc <16 x i8> @test_vqdmlahq_n_s8(<16 x i8> %a, <16 x i8> %b, i8 signext %c) {
+; CHECK-LABEL: test_vqdmlahq_n_s8:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vqdmlah.s8 q0, q1, r0
+; CHECK-NEXT:bx lr
+entry:
+  %0 = zext i8 %c to i32
+  %1 = tail call <16 x i8> @llvm.arm.mve.vqdmlah.v16i8(<16 x i8> %a, <16 x i8> %b, i32 %0)
+  ret <16 x i8> %1
+}
+
+define arm_aapcs_vfpcc <8 x i16> @test_vqdmlahq_n_s16(<8 x i16> %a, <8 x i16> %b, i16 signext %c) {
+; CHECK-LABEL: test_vqdmlahq_n_s16:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vqdmlah.s16 q0, q1, r0
+; CHECK-NEXT:bx lr
+entry:
+  %0 = zext i16 %c to i32
+  %1 = tail call <8 x i16> @llvm.arm.mve.vqdmlah.v8i16(<8 x i16> %a, <8 x i16> %b, i32 %0)
+  ret <8 x i16> %1
+}
+
+define arm_aapcs_vfpcc <4 x i32> @test_vqdmlahq_n_s32(<4 x i32> %a, <4 x i32> %b, i32 %c) {
+; CHECK-LABEL: test_vqdmlahq_n_s32:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vqdmlah.s32 q0, q1, r0
+; CHECK-NEXT:bx lr
+entry:
+  %0 = tail call <4 x i32> @llvm.arm.mve.vqdmlah.v4i32(<4 x i32> %a, <4 x i32> %b, i32 %c)
+  ret <4 x i32> %0
+}
+
+define arm_aapcs_vfpcc <16 x i8> @test_vqrdmlahq_n_s8(<16 x i8> %a, <16 x i8> %b, i8 signext %c) {
+; CHECK-LABEL: test_vqrdmlahq_n_s8:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vqrdmlah.s8 q0, q1, r0
+; CHECK-NEXT:bx lr
+entry:
+  %0 = zext i8 %c to i32
+  %1 = tail call <16 x i8> @llvm.arm.mve.vqrdmlah.v16i8(<16 x i8> %a, <16 x i8> %b, i32 %0)
+  ret <16 x i8> %1
+}
+
+define arm_aapcs_vfpcc <8 x i16> @test_vqrdmlahq_n_s16(<8 x i16> %a, <8 x i16> %b, i16 signext %c) {
+; CHECK-LABEL: test_vqrdmlahq_n_s16:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vqrdmlah.s16 q0, q1, r0
+; CHECK-NEXT:bx lr
+entry:
+  %0 = zext i16 %c to i32
+  %1 = tail call <8 x i16> @llvm.arm.mve.vqrdmlah.v8i16(<8 x i16> %a, <8 x i16> %b, i32 %0)
+  ret <8 x i16> %1
+}
+
+define arm_aapcs_vfpcc <4 x i32> @test_vqrdmlahq_n_s32(<4 x i32> %a, <4 x i32> %b, i32 %c) {
+; CHECK-LABEL: test_vqrdmlahq_n_s32:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vqrdmlah.s32 q0, q1, r0
+; CHECK-NEXT:bx lr
+entry:
+  %0 = tail call <4 x i32> @llvm.arm.mve.vqrdmlah.v4i32(<4 x i32> %a, <4 x i32> %b, i32 %c)
+  ret <4 x i32> %0
+}
+
+define arm_aapcs_vfpcc <16 x i8> @test_vqrdmlashq_n_s8(<16 x i8> %a, <16 x i8> %b, i8 signext %c) {
+; CHECK-LABEL: test_vqrdmlashq_n_s8:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vqrdmlash.s8 q0, q1, r0
+; CHECK-NEXT:bx lr
+entry:
+  %0 = zext i8 %c to i32
+  %1 = tail call <16 x i8> @llvm.arm.mve.vqrdmlash.v16i8(<16 x i8> %a, <16 x i8> %b, i32 %0)
+  ret <16 x i8> %1
+}
+
+define arm_aapcs_vfpcc <8 x i16> @test_vqrdmlashq_n_s16(<8 x i16> %a, <8 x i16> %b, i16 signext %c) {
+; CHECK-LABEL: test_vqrdmlashq_n_s16:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vqrdmlash.s16 q0, q1, r0
+; CHECK-NEXT:bx lr
+entry:
+  %0 = zext i16 %c to i32
+  %1 = tail call <8 x i16> @llvm.arm.mve.vqrdmlash.v8i16(<8 x i16> %a, <8 x i16> %b, i32 %0)
+  ret <8 x i16> %1
+}
+
+define arm_aapcs_vfpcc <4 x i32> @test_vqrdmlashq_n_s32(<4 x i32> %a, <4 x i32> %b, i32 %c) {
+; CHECK-LABEL: test_vqrdmlashq_n_s32:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vqrdmlash.s32 q0, q1, r0
+; CHECK-NEXT:bx lr
+entry:
+  %0 = tail call <4 x i32> @llvm.arm.mve.vqrdmlash.v4i32(<4 x i32> %a, <4 x i32> %b, i32 %c)
+  ret <4 x i32> %0
+}
+
 define arm_aapcs_vfpcc <8 x half> @test_vfmaq_m_f16(<8 x half> %a, <8 x half> %b, <8 x half> %c, i16 zeroext %p) {
 ; CHECK-LABEL: test_vfmaq_m_f16:
 ; CHECK:   @ %bb.0: @ %entry
@@ -571,6 +667,138 @@
   ret <4 x i32> %2
 }
 
+define arm_aapcs_vfpcc <16 x i8> @test_vqdmlahq_m_n_s8(<16 x i8> %a, <16 x i8> %b, i8 signext %c, i16 zeroext %p) {
+; CHECK-LABEL: test_vqdmlahq_m_n_s8:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vmsr p0, r1
+; CHECK-NEXT:vpst
+; CHECK-NEXT:vqdmlaht.s8 q0, q1, r0
+; CHECK-NEXT:bx lr
+entry:
+  %0 = zext i8 %c to i32
+  %1 = zext i16 %p to i32
+  %2 = tail call <16 x

[PATCH] D65591: [AST] Add a flag indicating if any subexpression had errors

2020-03-18 Thread Sam McCall via Phabricator via cfe-commits

sammccall added inline comments.

Comment at: clang/include/clang/AST/DependenceFlags.h:46
 Instantiation = 2,
+/// Placeholder, and is not used in actual Type.
+Error = 4,

hokein wrote:
> sammccall wrote:
> > I'd like this comment to explain why it exists if not used in actual types.
> > 
> > Is this used for `decltype(some-error-expr)`? Is this used so 
> > toTypeDependence() returns something meaningful?
> > 
> > If this is used to make the bitcasting hacks work, we should just stop 
> > doing that.
> yeah, the main purpose of it is for convenient bitcast. AFAIK, we don't have 
> a plan to use the error bit except in `Expr`. removing it for now.
> 
> 
I think we should plan to do this for Type too, though it's OK not to do so in 
this patch.

consider e.g. the expression `decltype(foo){}` where `foo` has errors. Today 
we're saying this has no errors, because the DeclTypeType node isn't 
error-dependent.

(This is true whether you add the enum value or not: the `Type` constructor 
takes a bunch of booleans in the constructor, it would need to be refactored to 
support `TypeDependence` and possibly the computeDependence pattern)

I think we should ensure that as far as possible, this code conceptually 
propagates error-dependence from types to expressions correctly, even if the 
error-dependence is not set in practice yet.
I'm not sure if this requires having the Error bit in `TypeDependence` now: if 
we never have to name it because we only blacklist bits, then it's probably OK.

Comment at: clang/lib/AST/ComputeDependence.cpp:124
   auto D = ExprDependence::None;
   if (E->getType()->isDependentType())
 D |= ExprDependence::Type;

we should be propagating more bits here:
 - error bit should be propagated from the type
 - type is already propagated
 - I think value/instantiation doesn't matter because if T is 
value/instantiation dependent we set both below
 - not sure why unexpanded-pack isn't propagated

so consider something like (unconditional)
```
// FIXME: why is unexpanded-pack not propagated?
D |= E->getType()->getDependence() & ~ExprDependence::UnexpandedPack
```

Comment at: clang/lib/AST/ComputeDependence.cpp:174
 ExprDependence clang::computeDependence(NoInitExpr *E) {
   return toExprDependence(E->getType()->getDependence()) &
  ExprDependence::Instantiation;

I'm not terribly sure of the implications of not propagating the error bit 
here. I tend to think that "contains errors" most closely follows 
instantiation-dependence (i.e. it's fairly strict/lexical), so I'd consider 
propagating it here.

BTW, DesignatedInitUpdateExpr seems to have totally broken dependence 
computations - it's always non-dependent! (Not introduced by this refactoring, 
I think). Any idea what's up there?

Comment at: clang/lib/AST/ComputeDependence.cpp:216
   auto D = turnTypeToValueDependence(E->getSubExpr()->getDependence());
   if (E->getType()->isDependentType())
 D |= ExprDependence::Type;

I believe if we're creating an initializer_list and T has errors, then the 
expr should have errors

Comment at: clang/lib/AST/ComputeDependence.cpp:376
   auto *Decl = E->getDecl();
   auto Type = E->getType();

I think we're missing error propagation from `Type`.

(we could also consider a declrefexpr to an `invalid` decl to be an error...)

Comment at: clang/lib/AST/ComputeDependence.cpp:500
   if (E->isResultDependent())
 return D | ExprDependence::TypeValueInstantiation;
   return D | (E->getResultExpr()->getDependence() &

this should be D |=... so that result expr errors propagate

Comment at: clang/lib/AST/ComputeDependence.cpp:582
 Deps |= toExprDependence(Q->getDependence());
   for (auto *D : E->decls()) {
 if (D->getDeclContext()->isDependentContext() ||

(if we decide to make referring to an `invalid` decl an error, this is another 
spot... there are probably lots :-(. Deferring this is probably best)

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65591

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

[PATCH] D76298: [ARM,CDE] Implement CDE S and D-register intrinsics

2020-03-18 Thread Mikhail Maltsev via Phabricator via cfe-commits

miyuki updated this revision to Diff 251038.
miyuki added a comment.

Fixed formatting


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

https://reviews.llvm.org/D76298

Files:
  clang/include/clang/Basic/arm_cde.td
  clang/test/CodeGen/arm-cde-vfp.c
  clang/test/Sema/arm-cde-immediates.c
  clang/utils/TableGen/MveEmitter.cpp
  llvm/include/llvm/IR/IntrinsicsARM.td
  llvm/lib/Target/ARM/ARMInstrCDE.td
  llvm/test/CodeGen/Thumb2/cde-vfp.ll

Index: llvm/test/CodeGen/Thumb2/cde-vfp.ll
===
--- /dev/null
+++ llvm/test/CodeGen/Thumb2/cde-vfp.ll
@@ -0,0 +1,198 @@
+; RUN: llc -mtriple=thumbv8.1m.main -mattr=+cdecp0 -mattr=+cdecp1 -mattr=+mve -verify-machineinstrs -o - %s | FileCheck %s
+; RUN: llc -mtriple=thumbv8m.main -mattr=+cdecp0 -mattr=+cdecp1 -mattr=+fp-armv8d16sp -verify-machineinstrs -o - %s | FileCheck %s
+
+declare float @llvm.arm.cde.vcx1.f32(i32 immarg, i32 immarg)
+declare float @llvm.arm.cde.vcx1a.f32(i32 immarg, float, i32 immarg)
+declare float @llvm.arm.cde.vcx2.f32(i32 immarg, float, i32 immarg)
+declare float @llvm.arm.cde.vcx2a.f32(i32 immarg, float, float, i32 immarg)
+declare float @llvm.arm.cde.vcx3.f32(i32 immarg, float, float, i32 immarg)
+declare float @llvm.arm.cde.vcx3a.f32(i32 immarg, float, float, float, i32 immarg)
+
+declare double @llvm.arm.cde.vcx1.f64(i32 immarg, i32 immarg)
+declare double @llvm.arm.cde.vcx1a.f64(i32 immarg, double, i32 immarg)
+declare double @llvm.arm.cde.vcx2.f64(i32 immarg, double, i32 immarg)
+declare double @llvm.arm.cde.vcx2a.f64(i32 immarg, double, double, i32 immarg)
+declare double @llvm.arm.cde.vcx3.f64(i32 immarg, double, double, i32 immarg)
+declare double @llvm.arm.cde.vcx3a.f64(i32 immarg, double, double, double, i32 immarg)
+
+define arm_aapcs_vfpcc i32 @test_vcx1_u32() {
+; CHECK-LABEL: test_vcx1_u32:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vcx1 p0, s0, #11
+; CHECK-NEXT:vmov r0, s0
+; CHECK-NEXT:bx lr
+entry:
+  %0 = call float @llvm.arm.cde.vcx1.f32(i32 0, i32 11)
+  %1 = bitcast float %0 to i32
+  ret i32 %1
+}
+
+define arm_aapcs_vfpcc i32 @test_vcx1a_u32(i32 %acc) {
+; CHECK-LABEL: test_vcx1a_u32:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vmov s0, r0
+; CHECK-NEXT:vcx1a p1, s0, #12
+; CHECK-NEXT:vmov r0, s0
+; CHECK-NEXT:bx lr
+entry:
+  %0 = bitcast i32 %acc to float
+  %1 = call float @llvm.arm.cde.vcx1a.f32(i32 1, float %0, i32 12)
+  %2 = bitcast float %1 to i32
+  ret i32 %2
+}
+
+define arm_aapcs_vfpcc i32 @test_vcx2_u32(i32 %n) {
+; CHECK-LABEL: test_vcx2_u32:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vmov s0, r0
+; CHECK-NEXT:vcx2 p0, s0, s0, #21
+; CHECK-NEXT:vmov r0, s0
+; CHECK-NEXT:bx lr
+entry:
+  %0 = bitcast i32 %n to float
+  %1 = call float @llvm.arm.cde.vcx2.f32(i32 0, float %0, i32 21)
+  %2 = bitcast float %1 to i32
+  ret i32 %2
+}
+
+define arm_aapcs_vfpcc i32 @test_vcx2a_u32(i32 %acc, i32 %n) {
+; CHECK-LABEL: test_vcx2a_u32:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vmov s0, r1
+; CHECK-NEXT:vmov s2, r0
+; CHECK-NEXT:vcx2a p0, s2, s0, #22
+; CHECK-NEXT:vmov r0, s2
+; CHECK-NEXT:bx lr
+entry:
+  %0 = bitcast i32 %acc to float
+  %1 = bitcast i32 %n to float
+  %2 = call float @llvm.arm.cde.vcx2a.f32(i32 0, float %0, float %1, i32 22)
+  %3 = bitcast float %2 to i32
+  ret i32 %3
+}
+
+define arm_aapcs_vfpcc i32 @test_vcx3_u32(i32 %n, i32 %m) {
+; CHECK-LABEL: test_vcx3_u32:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vmov s0, r1
+; CHECK-NEXT:vmov s2, r0
+; CHECK-NEXT:vcx3 p1, s0, s2, s0, #3
+; CHECK-NEXT:vmov r0, s0
+; CHECK-NEXT:bx lr
+entry:
+  %0 = bitcast i32 %n to float
+  %1 = bitcast i32 %m to float
+  %2 = call float @llvm.arm.cde.vcx3.f32(i32 1, float %0, float %1, i32 3)
+  %3 = bitcast float %2 to i32
+  ret i32 %3
+}
+
+define arm_aapcs_vfpcc i32 @test_vcx3a_u32(i32 %acc, i32 %n, i32 %m) {
+; CHECK-LABEL: test_vcx3a_u32:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vmov s0, r2
+; CHECK-NEXT:vmov s2, r1
+; CHECK-NEXT:vmov s4, r0
+; CHECK-NEXT:vcx3a p0, s4, s2, s0, #5
+; CHECK-NEXT:vmov r0, s4
+; CHECK-NEXT:bx lr
+entry:
+  %0 = bitcast i32 %acc to float
+  %1 = bitcast i32 %n to float
+  %2 = bitcast i32 %m to float
+  %3 = call float @llvm.arm.cde.vcx3a.f32(i32 0, float %0, float %1, float %2, i32 5)
+  %4 = bitcast float %3 to i32
+  ret i32 %4
+}
+
+define arm_aapcs_vfpcc i64 @test_vcx1d_u64() {
+; CHECK-LABEL: test_vcx1d_u64:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vcx1 p0, d0, #11
+; CHECK-NEXT:vmov r0, r1, d0
+; CHECK-NEXT:bx lr
+entry:
+  %0 = call double @llvm.arm.cde.vcx1.f64(i32 0, i32 11)
+  %1 = bitcast double %0 to i64
+  ret i64 %1
+}
+
+define arm_aapcs_vfpcc i64 @test_vcx1da_u64(i64 %acc) {
+; CHECK-LABEL: test_vcx1da_u64:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vmov d0, r0, r1
+; CHECK-NEXT:vcx1a p1, d0, #12
+; CHECK-NEXT:vmov r0,

[PATCH] D75842: [Analyzer] Bugfix for CheckerRegistry

2020-03-18 Thread Kristóf Umann via Phabricator via cfe-commits

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

LGTM, thanks!


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

https://reviews.llvm.org/D75842



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

[PATCH] D75360: [analyzer][NFC] Tie CheckerRegistry to CheckerManager, allow CheckerManager to be constructed for non-analysis purposes

2020-03-18 Thread Kristóf Umann via Phabricator via cfe-commits

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



Comment at: clang/include/clang/StaticAnalyzer/Frontend/CheckerRegistry.h:217
+mgr.template registerChecker();
   }
 

baloghadamsoftware wrote:
> NoQ wrote:
> > Szelethus wrote:
> > > baloghadamsoftware wrote:
> > > > Why do we need `MGR` here as template parameter? Is this function also 
> > > > used for other class instances than `CheckerManager`? I fail to see 
> > > > such invocation.
> > > Include cycles :) `CheckerManager.h` includes `CheckerRegistry.h`, so we 
> > > can only forward declare `CheckerManager`, hence the need for a template 
> > > parameter.
> > Maybe put the implementation into the cpp file instead?
> +1 Using templates where only one template parameter is possible is overkill 
> and makes the code difficult to understand.
Can't do, mind that the **checker** is a template parameter as well. I could 
add more comments tho!


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

https://reviews.llvm.org/D75360



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

[PATCH] D76299: [ARM,CDE] Implement CDE unpredicated Q-register intrinsics

2020-03-18 Thread Mikhail Maltsev via Phabricator via cfe-commits

miyuki updated this revision to Diff 251039.
miyuki added a comment.

Fixed formatting.


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

https://reviews.llvm.org/D76299

Files:
  clang/include/clang/Basic/arm_cde.td
  clang/test/CodeGen/arm-cde-vec.c
  clang/test/Sema/arm-cde-immediates.c
  clang/utils/TableGen/MveEmitter.cpp
  llvm/include/llvm/IR/IntrinsicsARM.td
  llvm/lib/Target/ARM/ARMInstrCDE.td
  llvm/test/CodeGen/Thumb2/cde-vec.ll

Index: llvm/test/CodeGen/Thumb2/cde-vec.ll
===
--- /dev/null
+++ llvm/test/CodeGen/Thumb2/cde-vec.ll
@@ -0,0 +1,114 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple=thumbv8.1m.main -mattr=+cdecp0 -mattr=+cdecp1 -mattr=+mve -verify-machineinstrs -o - %s | FileCheck %s
+
+declare <16 x i8> @llvm.arm.cde.vcx1q(i32 immarg, i32 immarg)
+declare <16 x i8> @llvm.arm.cde.vcx1qa(i32 immarg, <16 x i8>, i32 immarg)
+declare <16 x i8> @llvm.arm.cde.vcx2q(i32 immarg, <16 x i8>, i32 immarg)
+declare <16 x i8> @llvm.arm.cde.vcx2qa(i32 immarg, <16 x i8>, <16 x i8>, i32 immarg)
+declare <16 x i8> @llvm.arm.cde.vcx3q(i32 immarg, <16 x i8>, <16 x i8>, i32 immarg)
+declare <16 x i8> @llvm.arm.cde.vcx3qa(i32 immarg, <16 x i8>, <16 x i8>, <16 x i8>, i32 immarg)
+
+define arm_aapcs_vfpcc <16 x i8> @test_vcx1q_u8() {
+; CHECK-LABEL: test_vcx1q_u8:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vcx1 p0, q0, #
+; CHECK-NEXT:bx lr
+entry:
+  %0 = call <16 x i8> @llvm.arm.cde.vcx1q(i32 0, i32 )
+  ret <16 x i8> %0
+}
+
+define arm_aapcs_vfpcc <16 x i8> @test_vcx1qa_1(<16 x i8> %acc) {
+; CHECK-LABEL: test_vcx1qa_1:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vcx1a p1, q0, #1112
+; CHECK-NEXT:bx lr
+entry:
+  %0 = call <16 x i8> @llvm.arm.cde.vcx1qa(i32 1, <16 x i8> %acc, i32 1112)
+  ret <16 x i8> %0
+}
+
+define arm_aapcs_vfpcc <4 x i32> @test_vcx1qa_2(<4 x i32> %acc) {
+; CHECK-LABEL: test_vcx1qa_2:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vcx1a p0, q0, #1113
+; CHECK-NEXT:bx lr
+entry:
+  %0 = bitcast <4 x i32> %acc to <16 x i8>
+  %1 = call <16 x i8> @llvm.arm.cde.vcx1qa(i32 0, <16 x i8> %0, i32 1113)
+  %2 = bitcast <16 x i8> %1 to <4 x i32>
+  ret <4 x i32> %2
+}
+
+define arm_aapcs_vfpcc <16 x i8> @test_vcx2q_u8(<8 x half> %n) {
+; CHECK-LABEL: test_vcx2q_u8:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vcx2 p1, q0, q0, #111
+; CHECK-NEXT:bx lr
+entry:
+  %0 = bitcast <8 x half> %n to <16 x i8>
+  %1 = call <16 x i8> @llvm.arm.cde.vcx2q(i32 1, <16 x i8> %0, i32 111)
+  ret <16 x i8> %1
+}
+
+define arm_aapcs_vfpcc <4 x float> @test_vcx2q(<4 x float> %n) {
+; CHECK-LABEL: test_vcx2q:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vcx2 p1, q0, q0, #112
+; CHECK-NEXT:bx lr
+entry:
+  %0 = bitcast <4 x float> %n to <16 x i8>
+  %1 = call <16 x i8> @llvm.arm.cde.vcx2q(i32 1, <16 x i8> %0, i32 112)
+  %2 = bitcast <16 x i8> %1 to <4 x float>
+  ret <4 x float> %2
+}
+
+define arm_aapcs_vfpcc <4 x float> @test_vcx2qa(<4 x float> %acc, <2 x i64> %n) {
+; CHECK-LABEL: test_vcx2qa:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vcx2a p0, q0, q1, #113
+; CHECK-NEXT:bx lr
+entry:
+  %0 = bitcast <4 x float> %acc to <16 x i8>
+  %1 = bitcast <2 x i64> %n to <16 x i8>
+  %2 = call <16 x i8> @llvm.arm.cde.vcx2qa(i32 0, <16 x i8> %0, <16 x i8> %1, i32 113)
+  %3 = bitcast <16 x i8> %2 to <4 x float>
+  ret <4 x float> %3
+}
+
+define arm_aapcs_vfpcc <16 x i8> @test_vcx3q_u8(<8 x i16> %n, <4 x i32> %m) {
+; CHECK-LABEL: test_vcx3q_u8:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vcx3 p0, q0, q0, q1, #11
+; CHECK-NEXT:bx lr
+entry:
+  %0 = bitcast <8 x i16> %n to <16 x i8>
+  %1 = bitcast <4 x i32> %m to <16 x i8>
+  %2 = call <16 x i8> @llvm.arm.cde.vcx3q(i32 0, <16 x i8> %0, <16 x i8> %1, i32 11)
+  ret <16 x i8> %2
+}
+
+define arm_aapcs_vfpcc <2 x i64> @test_vcx3q(<2 x i64> %n, <4 x float> %m) {
+; CHECK-LABEL: test_vcx3q:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vcx3 p1, q0, q0, q1, #12
+; CHECK-NEXT:bx lr
+entry:
+  %0 = bitcast <2 x i64> %n to <16 x i8>
+  %1 = bitcast <4 x float> %m to <16 x i8>
+  %2 = call <16 x i8> @llvm.arm.cde.vcx3q(i32 1, <16 x i8> %0, <16 x i8> %1, i32 12)
+  %3 = bitcast <16 x i8> %2 to <2 x i64>
+  ret <2 x i64> %3
+}
+
+define arm_aapcs_vfpcc <16 x i8> @test_vcx3qa(<16 x i8> %acc, <8 x i16> %n, <4 x float> %m) {
+; CHECK-LABEL: test_vcx3qa:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vcx3a p1, q0, q1, q2, #13
+; CHECK-NEXT:bx lr
+entry:
+  %0 = bitcast <8 x i16> %n to <16 x i8>
+  %1 = bitcast <4 x float> %m to <16 x i8>
+  %2 = call <16 x i8> @llvm.arm.cde.vcx3qa(i32 1, <16 x i8> %acc, <16 x i8> %0, <16 x i8> %1, i32 13)
+  ret <16 x i8> %2
+}
Index: llvm/lib/Target/ARM/ARMInstrCDE.td
===
--- llvm/lib/Target/ARM/ARMInstrCDE.td
+++ llvm/lib/Target/ARM/ARMInstrCDE.td
@@

[PATCH] D75169: [ARM] Enforcing calling convention for half-precision FP arguments and returns for big-endian AArch32

2020-03-18 Thread Lucas Prates via Phabricator via cfe-commits

pratlucas added a comment.

> Oh, wait, AAPCS wants half values to be passed in the *least* significant 
> bits of a GPR, even on big-endian machines? That's certainly more convenient, 
> but it's a weird inconsistency with the otherwise iron rule of the calling 
> convention, which that it's exactly as if you laid all of the arguments out 
> in memory and then popped the first four 32-bit values off. We're talking 
> about a calling convention here that literally skips registers in order to 
> "align" arguments.
> 
> Can we not just coerce to i16? Will LLVM not pass an i16 in the 
> least-significant bits of a register?

Yes, AAPCS specifies that they should go into the LSBs:

> B.2 [...]  If the argument is a Half-precision Floating Point Type its size 
> is set to 4 bytes as if it had been copied to the least significant bits of a 
> 32-bit register and the remaining bits filled with unspecified values.

Coercing to i16 solves it for the general case, when the argumetns are going 
into GPRs, but is not suficient when those arguments are required to go into FP 
registers - e.g. `-mfloat-abi=hard`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75169



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

[PATCH] D76077: [ARM] Add __bf16 as new Bfloat16 C Type

2020-03-18 Thread Ties Stuij via Phabricator via cfe-commits

stuij added a comment.

Thanks for the feedback. We'll work on implementing a bfloat IR type.


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

https://reviews.llvm.org/D76077



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

[PATCH] D76304: [clangd] Update TUStatus api to accommodate preamble thread

2020-03-18 Thread Sam McCall via Phabricator via cfe-commits

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



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:277
   build(std::move(*CurrentReq));
+  bool IsEmpty = false;
+  {

kadircet wrote:
> sammccall wrote:
> > Seems clearer to do this immediately before blocking?
> > 
> > at the top:
> > 
> > ```
> > if (!NextReq) {
> >   Lock.unlock();
> >   StatusManager.setPreambleAction(Idle);
> >   Lock.lock();
> >   ReqCV.wait(NextReq || Done);
> > }
> > if (Done)
> >   break;
> > ```
> i agree, but I wanted to keep the current semantics. we only start emitting 
> tustatuses after thread starts executing the first request.
> 
> happy to change *both* preamblethread and astworker to emit before blocking 
> though. wdyt?
I think the difference is moot - we never create either the AST or preamble 
worker until there's something to do.

The code around scheduling/sleeping in the AST worker thread is way more 
complicated, and I'm not confident moving the status broadcast to the top of 
the loop would be clearer there.

Up to you: if you think both are clearer, move both. If you think the preamble 
is clearer at the top and AST worker at the bottom, then you can choose between 
consistency and clarity :-)



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:357
+
+  SynchronizedTUStatus &StatusManager;
 };

StatusManager -> Status



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:490
 
+  SynchronizedTUStatus StatusManager;
   PreambleThread PW;

StatusManager -> Status



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:698
+  // buildAST fails.
+  if (!(*AST)) {
+StatusManager.update(

(might be clearer to call once and make the logic conditional)



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:1053
+  llvm::SmallVector Result;
+  if (PA == PreambleAction::Building)
+Result.push_back("parsing includes");

nit: write this as a switch  for consistency plus the covered warning?



Comment at: clang-tools-extra/clangd/TUScheduler.h:122
 
-  TUAction Action;
-  BuildDetails Details;
+  /// Stores the status of preamble thread.
+  PreambleAction PreambleState = PreambleAction::Idle;

comment just repeats the declaration, drop it?



Comment at: clang-tools-extra/clangd/TUScheduler.h:123
+  /// Stores the status of preamble thread.
+  PreambleAction PreambleState = PreambleAction::Idle;
+  ASTAction ASTState;

I think these variables are still best described at a high level actions, not 
states. (Well, the state of the thread is that it is running this action, but 
that's a little roundabout. TUAction::State probably should have been called 
Kind instead).

Unfortunate that we need both a type name and a variable name though. 
`ASTAction ASTActivity; PreambleAction PreambleActivity;`?



Comment at: clang-tools-extra/clangd/TUScheduler.h:126
+  /// Stores status of the last build for the translation unit.
+  BuildStatus BS = None;
 };

If keeping the enum, this variable needs a real name.
I'd suggest `LastBuild` and dropping the comment.



Comment at: clang-tools-extra/clangd/TUScheduler.h:104
 struct TUStatus {
-  struct BuildDetails {
-/// Indicates whether clang failed to build the TU.
-bool BuildFailed = false;
-/// Indicates whether we reused the prebuilt AST.
-bool ReuseAST = false;
+  enum BuildStatus {
+/// Haven't run a built yet

kadircet wrote:
> sammccall wrote:
> > What's the purpose of this change? It seems to make the build details 
> > harder to maintain/extend.
> > 
> > (In particular, say we were going to add a "fallback command was used" bit, 
> > where would it go after this change?)
> this was to narrow down the interface. Currently builddetails is only being 
> used to report buildstatus, and those cases are mutually exclusive(a build 
> can't be both a reuse and failure). Therefore i wanted to make that more 
> explicit.
> 
> if we decide to add more details, I would say we should rather get 
> BuildDetails struct back, with a Status enum and a couple more state to 
> signal any other information.
OK, I understand but don't really agree - the fact that these are exclusive is 
a coincidence that we don't need to model APIs around. This doesn't seem 
related to the rest of this patch, either.

I think we're going around in circles on this though, will leave this up to you.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76304



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

[PATCH] D75682: [Analyzer][StreamChecker] Introduction of stream error handling.

2020-03-18 Thread Kristóf Umann via Phabricator via cfe-commits

Szelethus added a comment.
Herald added a subscriber: ASDenysPetrov.

In D75682#1926889 , @balazske wrote:

> In D75682#1926732 , @Szelethus wrote:
>
> > Rght I think I finally get it. You don't want to state split on 
> > `feof()` and `ferror()`, but rather on the stream operations!
>
>
> Yes the split is at the operations. I did not think even of splitting at 
> start of `feof()` to determine "backwards" the result of the previous 
> operation. This could be another approach. But the way of split depends on 
> the previous operation (to check if error is possible based on possible 
> constraints on its return value), probably not better (but less state split?).

This is probably why it took a bit for us to understand each other! :) 
Generally speaking, we try to avoid state splitting as much as possible, but 
you totally convinced me, this isn't the place where we should be conservative. 
One should always expect stream operations to potentially fail, and that really 
does introduce two separate paths of execution.

The main issue that remains is testability, and now that we are on the same 
page, I see why you were concerned about it. I have a couple ideas:

- For streams where the precise state is unknown (they are not tracked), start 
tracking. If we explicitly check whether a state is `foef()`, we can rightfully 
assume both of those possibilities.
- Add debug function similar to `clang_analyzer_express`, like 
`clang_analyzer_set_eof(FILE *)`, etc.
- Evalulate a less complicated stream modeling function that sets such flags, 
though I suspect the followup patch is supposed to be the one doing this.

What do you think?

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75682

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

[PATCH] D72742: Don't assume promotable integers are zero/sign-extended already in x86-64 ABI.

2020-03-18 Thread James Y Knight via Phabricator via cfe-commits

jyknight added a comment.

I wrote some stuff on https://bugs.llvm.org/show_bug.cgi?id=44228, probably 
best to continue the discussion there. I really don't think we should take this 
patch -- at least not without reopening the ABI discussion first.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72742



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

[PATCH] D76077: [ARM] Add __bf16 as new Bfloat16 C Type

2020-03-18 Thread Sjoerd Meijer via Phabricator via cfe-commits

SjoerdMeijer added a comment.

That sounds good and that seems to address the feedback given here, which I 
agree with. Just wanted to briefly add that while it already looks like most 
interested people are on this ticket, perhaps it good to also share the plan 
and design on the cfe dev list for visibility.


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

https://reviews.llvm.org/D76077



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

[PATCH] D75220: [clang-tidy] RenamerClangTidy now correctly renames `using namespace` decls

2020-03-18 Thread Nathan James via Phabricator via cfe-commits

njames93 added a comment.

Ping??


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75220



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

[PATCH] D76355: [Syntax] Build mapping from AST to syntax tree nodes

2020-03-18 Thread Marcel Hlopko via Phabricator via cfe-commits

hlopko created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
hlopko edited the summary of this revision.
hlopko added a parent revision: D76346: [Syntax] Build template declaration 
nodes.

Copy of https://reviews.llvm.org/D72446, submitting with Ilya's permission.

Only used to assign roles to child nodes for now. This is more efficient
than doing range-based queries.

In the future, will be exposed in the public API of syntax trees.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D76355

Files:
  clang/include/clang/Tooling/Syntax/Tree.h
  clang/lib/Tooling/Syntax/BuildTree.cpp
  clang/lib/Tooling/Syntax/Tree.cpp

Index: clang/lib/Tooling/Syntax/Tree.cpp
===
--- clang/lib/Tooling/Syntax/Tree.cpp
+++ clang/lib/Tooling/Syntax/Tree.cpp
@@ -66,14 +66,20 @@
 bool syntax::Tree::classof(const Node *N) { return N->kind() > NodeKind::Leaf; }
 
 void syntax::Tree::prependChildLowLevel(Node *Child, NodeRole Role) {
-  assert(Child->Parent == nullptr);
-  assert(Child->NextSibling == nullptr);
   assert(Child->role() == NodeRole::Detached);
   assert(Role != NodeRole::Detached);
 
+  Child->Role = static_cast(Role);
+  prependChildLowLevel(Child);
+}
+
+void syntax::Tree::prependChildLowLevel(Node *Child) {
+  assert(Child->Parent == nullptr);
+  assert(Child->NextSibling == nullptr);
+  assert(Child->role() != NodeRole::Detached);
+
   Child->Parent = this;
   Child->NextSibling = this->FirstChild;
-  Child->Role = static_cast(Role);
   this->FirstChild = Child;
 }
 
Index: clang/lib/Tooling/Syntax/BuildTree.cpp
===
--- clang/lib/Tooling/Syntax/BuildTree.cpp
+++ clang/lib/Tooling/Syntax/BuildTree.cpp
@@ -25,6 +25,8 @@
 #include "clang/Tooling/Syntax/Tokens.h"
 #include "clang/Tooling/Syntax/Tree.h"
 #include "llvm/ADT/ArrayRef.h"
+#include "llvm/ADT/DenseMap.h"
+#include "llvm/ADT/PointerUnion.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/ScopeExit.h"
 #include "llvm/ADT/SmallVector.h"
@@ -34,6 +36,7 @@
 #include "llvm/Support/FormatVariadic.h"
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/raw_ostream.h"
+#include 
 #include 
 
 using namespace clang;
@@ -145,6 +148,32 @@
   return SourceRange(Start, End);
 }
 
+namespace {
+/// All AST hierarchy roots that can be represented as pointers.
+using ASTPtr = llvm::PointerUnion;
+/// Maintains a mapping from AST to syntax tree nodes. This class will get more
+/// complicated as we support more kinds of AST nodes, e.g. TypeLocs.
+/// FIXME: expose this as public API.
+class ASTToSyntaxMapping {
+public:
+  void add(ASTPtr From, syntax::Tree *To) {
+assert(To != nullptr);
+
+bool Added = Nodes.insert({From.getOpaqueValue(), To}).second;
+(void)Added;
+assert(Added && "mapping added twice");
+  }
+
+  syntax::Tree *find(ASTPtr P) const {
+return Nodes.lookup(P.getOpaqueValue());
+  }
+
+private:
+  // Keys are either Stmt* or Decl*.
+  llvm::DenseMap Nodes;
+};
+} // namespace
+
 /// A helper class for constructing the syntax tree while traversing a clang
 /// AST.
 ///
@@ -172,7 +201,18 @@
 
   /// Populate children for \p New node, assuming it covers tokens from \p
   /// Range.
-  void foldNode(llvm::ArrayRef Range, syntax::Tree *New);
+  void foldNode(llvm::ArrayRef Range, syntax::Tree *New,
+ASTPtr From) {
+assert(New);
+Pending.foldChildren(Arena, Range, New);
+if (From)
+  Mapping.add(From, New);
+  }
+  void foldNode(llvm::ArrayRef Range, syntax::Tree *New,
+TypeLoc L) {
+// FIXME: add mapping for TypeLocs
+foldNode(Range, New, nullptr);
+  }
 
   /// Must be called with the range of each `DeclaratorDecl`. Ensures the
   /// corresponding declarator nodes are covered by `SimpleDeclaration`.
@@ -195,8 +235,10 @@
   /// Set role for \p T.
   void markChildToken(const syntax::Token *T, NodeRole R);
 
-  /// Set role for the node that spans exactly \p Range.
-  void markChild(llvm::ArrayRef Range, NodeRole R);
+  /// Set role for \p N.
+  void markChild(syntax::Node *N, NodeRole R);
+  /// Set role for the syntax node matching \p N.
+  void markChild(ASTPtr N, NodeRole R);
   /// Set role for the delayed node that spans exactly \p Range.
   void markDelayedChild(llvm::ArrayRef Range, NodeRole R);
   /// Set role for the node that may or may not be delayed. Node must span
@@ -290,6 +332,11 @@
 return Tokens;
   }
 
+  void setRole(syntax::Node *N, NodeRole R) {
+assert(N->role() == NodeRole::Detached);
+N->Role = static_cast(R);
+  }
+
   /// A collection of trees covering the input tokens.
   /// When created, each tree corresponds to a single token in the file.
   /// Clients call 'foldChildren' to attach one or more subtrees to a parent
@@ -306,7 +353,7 @@
 auto *L = new (A.allocator()) syntax::Leaf(&T);
 L->Original = true;
 L->CanModify = A.toke

[PATCH] D74619: [ARM] Enabling range checks on Neon intrinsics' lane arguments

2020-03-18 Thread Diogo N. Sampaio via Phabricator via cfe-commits

dnsampaio added a comment.

Hi,
thanks for looking into this.  The patch LGTM, but regarding the indentation, I 
don't know what would be the best practice here. We tend to like to preserve 
the line-git-history, but if we start ignoring the formater check, then it has 
no sense in they being here.
Perhaps @t.p.northover or @olista01 could share their thoughts here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74619



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

[clang] b09cce0 - [OPENMP50]Codegen for detach clause.

2020-03-18 Thread Alexey Bataev via cfe-commits


Author: Alexey Bataev
Date: 2020-03-18T09:01:17-04:00
New Revision: b09cce07c7ebd6d42c97f7144f5a2e7dd8fca19e

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

LOG: [OPENMP50]Codegen for detach clause.

Implemented codegen for detach clause in task directives.

Added: 


Modified: 
clang/lib/CodeGen/CGOpenMPRuntime.cpp
clang/test/OpenMP/task_codegen.c

Removed: 




diff  --git a/clang/lib/CodeGen/CGOpenMPRuntime.cpp 
b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
index fde42b1fe242..fa60221e8b59 100644
--- a/clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -765,6 +765,9 @@ enum OpenMPRTLFunction {
   // Call to void __tgt_push_mapper_component(void *rt_mapper_handle, void
   // *base, void *begin, int64_t size, int64_t type);
   OMPRTL__tgt_push_mapper_component,
+  // Call to kmp_event_t *__kmpc_task_allow_completion_event(ident_t *loc_ref,
+  // int gtid, kmp_task_t *task);
+  OMPRTL__kmpc_task_allow_completion_event,
 };
 
 /// A basic class for pre|post-action for advanced codegen sequence for OpenMP
@@ -2596,6 +2599,16 @@ llvm::FunctionCallee 
CGOpenMPRuntime::createRuntimeFunction(unsigned Function) {
 RTLFn = CGM.CreateRuntimeFunction(FnTy, "__tgt_push_mapper_component");
 break;
   }
+  case OMPRTL__kmpc_task_allow_completion_event: {
+// Build kmp_event_t *__kmpc_task_allow_completion_event(ident_t *loc_ref,
+// int gtid, kmp_task_t *task);
+auto *FnTy = llvm::FunctionType::get(
+CGM.VoidPtrTy, {getIdentTyPointerTy(), CGM.IntTy, CGM.VoidPtrTy},
+/*isVarArg=*/false);
+RTLFn =
+CGM.CreateRuntimeFunction(FnTy, "__kmpc_task_allow_completion_event");
+break;
+  }
   }
   assert(RTLFn && "Unable to find OpenMP runtime function");
   return RTLFn;
@@ -5083,7 +5096,8 @@ CGOpenMPRuntime::emitTaskInit(CodeGenFunction &CGF, 
SourceLocation Loc,
 TiedFlag = 0x1,
 FinalFlag = 0x2,
 DestructorsFlag = 0x8,
-PriorityFlag = 0x20
+PriorityFlag = 0x20,
+DetachableFlag = 0x40,
   };
   unsigned Flags = Data.Tied ? TiedFlag : 0;
   bool NeedsCleanup = false;
@@ -5094,6 +5108,8 @@ CGOpenMPRuntime::emitTaskInit(CodeGenFunction &CGF, 
SourceLocation Loc,
   }
   if (Data.Priority.getInt())
 Flags = Flags | PriorityFlag;
+  if (D.hasClausesOfKind())
+Flags = Flags | DetachableFlag;
   llvm::Value *TaskFlags =
   Data.Final.getPointer()
   ? CGF.Builder.CreateSelect(Data.Final.getPointer(),
@@ -5126,6 +5142,25 @@ CGOpenMPRuntime::emitTaskInit(CodeGenFunction &CGF, 
SourceLocation Loc,
 NewTask = CGF.EmitRuntimeCall(
   createRuntimeFunction(OMPRTL__kmpc_omp_task_alloc), AllocArgs);
   }
+  // Emit detach clause initialization.
+  // evt = (typeof(evt))__kmpc_task_allow_completion_event(loc, tid,
+  // task_descriptor);
+  if (const auto *DC = D.getSingleClause()) {
+const Expr *Evt = DC->getEventHandler()->IgnoreParenImpCasts();
+LValue EvtLVal = CGF.EmitLValue(Evt);
+
+// Build kmp_event_t *__kmpc_task_allow_completion_event(ident_t *loc_ref,
+// int gtid, kmp_task_t *task);
+llvm::Value *Loc = emitUpdateLocation(CGF, DC->getBeginLoc());
+llvm::Value *Tid = getThreadID(CGF, DC->getBeginLoc());
+Tid = CGF.Builder.CreateIntCast(Tid, CGF.IntTy, /*isSigned=*/false);
+llvm::Value *EvtVal = CGF.EmitRuntimeCall(
+createRuntimeFunction(OMPRTL__kmpc_task_allow_completion_event),
+{Loc, Tid, NewTask});
+EvtVal = CGF.EmitScalarConversion(EvtVal, C.VoidPtrTy, Evt->getType(),
+  Evt->getExprLoc());
+CGF.EmitStoreOfScalar(EvtVal, EvtLVal);
+  }
   llvm::Value *NewTaskNewTaskTTy =
   CGF.Builder.CreatePointerBitCastOrAddrSpaceCast(
   NewTask, KmpTaskTWithPrivatesPtrTy);

diff  --git a/clang/test/OpenMP/task_codegen.c 
b/clang/test/OpenMP/task_codegen.c
index c6b82193f194..d0bbe5670d69 100644
--- a/clang/test/OpenMP/task_codegen.c
+++ b/clang/test/OpenMP/task_codegen.c
@@ -11,18 +11,24 @@
 #define HEADER
 
 typedef void *omp_depend_t;
+typedef __UINTPTR_TYPE__ omp_event_handle_t;
 
 void foo();
 
 // CHECK-LABEL: @main
 int main() {
   omp_depend_t d, x;
+  omp_event_handle_t evt;
   int a;
   // CHECK: [[D_ADDR:%.+]] = alloca i8*,
   // CHECK: [[X_ADDR:%.+]] = alloca i8*,
+  // CHECK: [[EVT_ADDR:%.+]] = alloca i64,
   // CHECK: [[A_ADDR:%.+]] = alloca i32,
   // CHECK: [[GTID:%.+]] = call i32 @__kmpc_global_thread_num(
-  // CHECK: [[ALLOC:%.+]] = call i8* @__kmpc_omp_task_alloc(%struct.ident_t* 
@{{.+}}, i32 %0, i32 1, i64 40, i64 0, i32 (i32, i8*)* bitcast (i32 (i32, 
[[PRIVATES_TY:%.+]]*)* [[TASK_ENTRY:@.+]] to i32 (i32, i8*)*))
+  // CHECK: [[ALLOC:%.+]] = call i8* @__kmpc_omp_task_alloc(%struct.ident_t* 
@{{.+}}, i32 [[GTID]], i32 65, i64 48, i64 0, i32 (i32, i8*)*

[PATCH] D75063: [analyzer] StdLibraryFunctionsChecker: Add NotNull Arg Constraint

2020-03-18 Thread Gabor Marton via Phabricator via cfe-commits

martong marked 6 inline comments as done.
martong added inline comments.
Herald added a subscriber: ASDenysPetrov.



Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:175
+using ValueConstraint::ValueConstraint;
+bool CannotBeNull = true;
+

Szelethus wrote:
> What does this do? Is it ever used in the patch?
Yes, it is used. We use it in `apply` the value is passed to `assume`.
And in `negate` we flip the value.



Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:189
+ValueConstraintPtr negate() const override {
+  NotNullConstraint tmp(*this);
+  tmp.CannotBeNull = !this->CannotBeNull;

balazske wrote:
> Is `Tmp` better name?
Absolutely, yes, I should avoid lower case variables, will rename.



Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:684
+.Case({
+ReturnValueCondition(LessThanOrEq, ArgNo(2)),
+})

steakhal wrote:
> Two lines below you are using the `{0U}` initialization syntax, and here the 
> simple constructor call syntax.
> Shouldn't we pick one?
Yes, definitely. I think I am going to use brace initialization syntax 
everywhere.



Comment at: clang/test/Analysis/std-c-library-functions-arg-constraints.c:59
+fread(buf, sizeof(int), 10, fp); // expected-warning{{Function argument 
constraint is not satisfied}}
+}

balazske wrote:
> One difficulty is that `fread` can work if the `buf` is 0 and `count` is 0 
> too. There is for sure code that uses this feature.
My understanding is that in case of `fread`, if `buf` is 0 then that is an 
undefined behavior.

In the section in C11 describing the use of library functions (§7.1.4) it is 
stated that:



> If an argument to a function has an invalid value (such as a value outside 
> the domain of the function, or a pointer outside the address space of the 
> program, or a null pointer, or a pointer to non-modifiable storage when the 
> corresponding parameter is not const-qualified) or a type (after promotion) 
> not expected by a function with variable number of arguments, the behavior is 
> undefined. If a function argument is described as being an array, the pointer 
> actually passed to the function shall have a value such that all address 
> computations and accesses to objects (that would be valid if the pointer did 
> point to the first element of such an array) are in fact valid.

I've found more details in this StackOverflow post:
https://stackoverflow.com/questions/51779960/is-it-safe-to-fread-0-bytes-into-a-null-pointer

Also note that a sane libc implementation would not dereference `buf` if `size` 
is 0, but we may not rely on these implementation details, that is why this is 
declared as undefined behavior in the standard.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75063



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

[PATCH] D75360: [analyzer][NFC] Tie CheckerRegistry to CheckerManager, allow CheckerManager to be constructed for non-analysis purposes

2020-03-18 Thread Kristóf Umann via Phabricator via cfe-commits

Szelethus updated this revision to Diff 251053.
Szelethus added a comment.

Address inlines.


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

https://reviews.llvm.org/D75360

Files:
  clang/include/clang/StaticAnalyzer/Core/CheckerManager.h
  clang/include/clang/StaticAnalyzer/Frontend/AnalysisConsumer.h
  clang/include/clang/StaticAnalyzer/Frontend/AnalyzerHelpFlags.h
  clang/include/clang/StaticAnalyzer/Frontend/CheckerRegistration.h
  clang/include/clang/StaticAnalyzer/Frontend/CheckerRegistry.h
  clang/include/clang/StaticAnalyzer/Frontend/FrontendActions.h
  clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
  clang/lib/StaticAnalyzer/Core/CheckerManager.cpp
  clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
  clang/lib/StaticAnalyzer/Frontend/AnalyzerHelpFlags.cpp
  clang/lib/StaticAnalyzer/Frontend/CMakeLists.txt
  clang/lib/StaticAnalyzer/Frontend/CheckerRegistration.cpp
  clang/lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp

Index: clang/lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp
===
--- clang/lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp
+++ clang/lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp
@@ -109,9 +109,9 @@
 
 CheckerRegistry::CheckerRegistry(
 ArrayRef Plugins, DiagnosticsEngine &Diags,
-AnalyzerOptions &AnOpts, const LangOptions &LangOpts,
+AnalyzerOptions &AnOpts,
 ArrayRef> CheckerRegistrationFns)
-: Diags(Diags), AnOpts(AnOpts), LangOpts(LangOpts) {
+: Diags(Diags), AnOpts(AnOpts) {
 
   // Register builtin checkers.
 #define GET_CHECKERS
@@ -179,12 +179,16 @@
   addDependency(FULLNAME, DEPENDENCY);
 
 #define GET_CHECKER_OPTIONS
-#define CHECKER_OPTION(TYPE, FULLNAME, CMDFLAG, DESC, DEFAULT_VAL, DEVELOPMENT_STATUS, IS_HIDDEN)  \
-  addCheckerOption(TYPE, FULLNAME, CMDFLAG, DEFAULT_VAL, DESC, DEVELOPMENT_STATUS, IS_HIDDEN);
+#define CHECKER_OPTION(TYPE, FULLNAME, CMDFLAG, DESC, DEFAULT_VAL, \
+   DEVELOPMENT_STATUS, IS_HIDDEN)  \
+  addCheckerOption(TYPE, FULLNAME, CMDFLAG, DEFAULT_VAL, DESC, \
+   DEVELOPMENT_STATUS, IS_HIDDEN);
 
 #define GET_PACKAGE_OPTIONS
-#define PACKAGE_OPTION(TYPE, FULLNAME, CMDFLAG, DESC, DEFAULT_VAL, DEVELOPMENT_STATUS, IS_HIDDEN)  \
-  addPackageOption(TYPE, FULLNAME, CMDFLAG, DEFAULT_VAL, DESC, DEVELOPMENT_STATUS, IS_HIDDEN);
+#define PACKAGE_OPTION(TYPE, FULLNAME, CMDFLAG, DESC, DEFAULT_VAL, \
+   DEVELOPMENT_STATUS, IS_HIDDEN)  \
+  addPackageOption(TYPE, FULLNAME, CMDFLAG, DEFAULT_VAL, DESC, \
+   DEVELOPMENT_STATUS, IS_HIDDEN);
 
 #include "clang/StaticAnalyzer/Checkers/Checkers.inc"
 #undef CHECKER_DEPENDENCY
@@ -213,24 +217,53 @@
  : StateFromCmdLine::State_Disabled;
 }
   }
+  validateCheckerOptions();
+}
+
+/// Collects dependenies in \p enabledCheckers. Return None on failure.
+LLVM_NODISCARD
+static llvm::Optional
+collectDependencies(const CheckerRegistry::CheckerInfo &checker,
+const CheckerManager &Mgr);
+
+void CheckerRegistry::initializeRegistry(const CheckerManager &Mgr) {
+  for (const CheckerInfo &Checker : Checkers) {
+if (!Checker.isEnabled(Mgr.getLangOpts()))
+  continue;
+
+// Recursively enable its dependencies.
+llvm::Optional Deps = collectDependencies(Checker, Mgr);
+
+if (!Deps) {
+  // If we failed to enable any of the dependencies, don't enable this
+  // checker.
+  continue;
+}
+
+// Note that set_union also preserves the order of insertion.
+EnabledCheckers.set_union(*Deps);
+
+// Enable the checker.
+EnabledCheckers.insert(&Checker);
+  }
 }
 
 /// Collects dependencies in \p ret, returns false on failure.
 static bool
 collectDependenciesImpl(const CheckerRegistry::ConstCheckerInfoList &Deps,
-const LangOptions &LO,
+const CheckerManager &Mgr,
 CheckerRegistry::CheckerInfoSet &Ret);
 
 /// Collects dependenies in \p enabledCheckers. Return None on failure.
 LLVM_NODISCARD
 static llvm::Optional
 collectDependencies(const CheckerRegistry::CheckerInfo &checker,
-const LangOptions &LO) {
+const CheckerManager &Mgr) {
 
   CheckerRegistry::CheckerInfoSet Ret;
   // Add dependencies to the enabled checkers only if all of them can be
   // enabled.
-  if (!collectDependenciesImpl(checker.Dependencies, LO, Ret))
+  if (!collectDependenciesImpl(checker.Dependencies, Mgr, Ret))
 return None;
 
   return Ret;
@@ -238,16 +271,16 @@
 
 static bool
 collectDependenciesImpl(const CheckerRegistry::ConstCheckerInfoList &Deps,
-const LangOptions &LO,
+const CheckerManager &Mgr,
 CheckerRegistry::CheckerInfoSet &Ret) {
 
   for (const CheckerRegistry::Check

[PATCH] D74619: [ARM] Enabling range checks on Neon intrinsics' lane arguments

2020-03-18 Thread Oliver Stannard (Linaro) via Phabricator via cfe-commits

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

I agree with @dnsampaio here, it's better to match the existing style, and 
avoid irrelevant churn in the git history.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74619



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

[PATCH] D75360: [analyzer][NFC] Tie CheckerRegistry to CheckerManager, allow CheckerManager to be constructed for non-analysis purposes

2020-03-18 Thread Kristóf Umann via Phabricator via cfe-commits

Szelethus updated this revision to Diff 251056.
Szelethus added a comment.

Seems like D75171  didn't add const methods 
after all, here they are.


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

https://reviews.llvm.org/D75360

Files:
  clang/include/clang/StaticAnalyzer/Core/CheckerManager.h
  clang/include/clang/StaticAnalyzer/Frontend/AnalysisConsumer.h
  clang/include/clang/StaticAnalyzer/Frontend/AnalyzerHelpFlags.h
  clang/include/clang/StaticAnalyzer/Frontend/CheckerRegistration.h
  clang/include/clang/StaticAnalyzer/Frontend/CheckerRegistry.h
  clang/include/clang/StaticAnalyzer/Frontend/FrontendActions.h
  clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
  clang/lib/StaticAnalyzer/Core/CheckerManager.cpp
  clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
  clang/lib/StaticAnalyzer/Frontend/AnalyzerHelpFlags.cpp
  clang/lib/StaticAnalyzer/Frontend/CMakeLists.txt
  clang/lib/StaticAnalyzer/Frontend/CheckerRegistration.cpp
  clang/lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp

Index: clang/lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp
===
--- clang/lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp
+++ clang/lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp
@@ -109,9 +109,9 @@
 
 CheckerRegistry::CheckerRegistry(
 ArrayRef Plugins, DiagnosticsEngine &Diags,
-AnalyzerOptions &AnOpts, const LangOptions &LangOpts,
+AnalyzerOptions &AnOpts,
 ArrayRef> CheckerRegistrationFns)
-: Diags(Diags), AnOpts(AnOpts), LangOpts(LangOpts) {
+: Diags(Diags), AnOpts(AnOpts) {
 
   // Register builtin checkers.
 #define GET_CHECKERS
@@ -179,12 +179,16 @@
   addDependency(FULLNAME, DEPENDENCY);
 
 #define GET_CHECKER_OPTIONS
-#define CHECKER_OPTION(TYPE, FULLNAME, CMDFLAG, DESC, DEFAULT_VAL, DEVELOPMENT_STATUS, IS_HIDDEN)  \
-  addCheckerOption(TYPE, FULLNAME, CMDFLAG, DEFAULT_VAL, DESC, DEVELOPMENT_STATUS, IS_HIDDEN);
+#define CHECKER_OPTION(TYPE, FULLNAME, CMDFLAG, DESC, DEFAULT_VAL, \
+   DEVELOPMENT_STATUS, IS_HIDDEN)  \
+  addCheckerOption(TYPE, FULLNAME, CMDFLAG, DEFAULT_VAL, DESC, \
+   DEVELOPMENT_STATUS, IS_HIDDEN);
 
 #define GET_PACKAGE_OPTIONS
-#define PACKAGE_OPTION(TYPE, FULLNAME, CMDFLAG, DESC, DEFAULT_VAL, DEVELOPMENT_STATUS, IS_HIDDEN)  \
-  addPackageOption(TYPE, FULLNAME, CMDFLAG, DEFAULT_VAL, DESC, DEVELOPMENT_STATUS, IS_HIDDEN);
+#define PACKAGE_OPTION(TYPE, FULLNAME, CMDFLAG, DESC, DEFAULT_VAL, \
+   DEVELOPMENT_STATUS, IS_HIDDEN)  \
+  addPackageOption(TYPE, FULLNAME, CMDFLAG, DEFAULT_VAL, DESC, \
+   DEVELOPMENT_STATUS, IS_HIDDEN);
 
 #include "clang/StaticAnalyzer/Checkers/Checkers.inc"
 #undef CHECKER_DEPENDENCY
@@ -213,24 +217,53 @@
  : StateFromCmdLine::State_Disabled;
 }
   }
+  validateCheckerOptions();
+}
+
+/// Collects dependenies in \p enabledCheckers. Return None on failure.
+LLVM_NODISCARD
+static llvm::Optional
+collectDependencies(const CheckerRegistry::CheckerInfo &checker,
+const CheckerManager &Mgr);
+
+void CheckerRegistry::initializeRegistry(const CheckerManager &Mgr) {
+  for (const CheckerInfo &Checker : Checkers) {
+if (!Checker.isEnabled(Mgr.getLangOpts()))
+  continue;
+
+// Recursively enable its dependencies.
+llvm::Optional Deps = collectDependencies(Checker, Mgr);
+
+if (!Deps) {
+  // If we failed to enable any of the dependencies, don't enable this
+  // checker.
+  continue;
+}
+
+// Note that set_union also preserves the order of insertion.
+EnabledCheckers.set_union(*Deps);
+
+// Enable the checker.
+EnabledCheckers.insert(&Checker);
+  }
 }
 
 /// Collects dependencies in \p ret, returns false on failure.
 static bool
 collectDependenciesImpl(const CheckerRegistry::ConstCheckerInfoList &Deps,
-const LangOptions &LO,
+const CheckerManager &Mgr,
 CheckerRegistry::CheckerInfoSet &Ret);
 
 /// Collects dependenies in \p enabledCheckers. Return None on failure.
 LLVM_NODISCARD
 static llvm::Optional
 collectDependencies(const CheckerRegistry::CheckerInfo &checker,
-const LangOptions &LO) {
+const CheckerManager &Mgr) {
 
   CheckerRegistry::CheckerInfoSet Ret;
   // Add dependencies to the enabled checkers only if all of them can be
   // enabled.
-  if (!collectDependenciesImpl(checker.Dependencies, LO, Ret))
+  if (!collectDependenciesImpl(checker.Dependencies, Mgr, Ret))
 return None;
 
   return Ret;
@@ -238,16 +271,16 @@
 
 static bool
 collectDependenciesImpl(const CheckerRegistry::ConstCheckerInfoList &Deps,
-const LangOptions &LO,
+const CheckerManager &Mgr,

[PATCH] D76359: [ARM,MVE] Add intrinsics for the VQDMLAD family.

2020-03-18 Thread Simon Tatham via Phabricator via cfe-commits

simon_tatham created this revision.
simon_tatham added reviewers: dmgreen, MarkMurrayARM, miyuki, ostannard.
Herald added subscribers: cfe-commits, hiraditya, kristof.beyls.
Herald added a project: clang.

This is another set of instructions too complicated to be sensibly
expressed in IR by anything short of a target-specific intrinsic.
Given input vectors a,b, the instruction generates intermediate values
2*(a[0]*b[0]+a[1]+b[1]), 2*(a[2]*b[2]+a[3]+b[3]), etc; takes the high
half of each double-width values, and overwrites half the lanes in the
output vector c, which you therefore have to provide the input value
of. Optionally you can swap the elements of b so that the are things
like a[0]*b[1]+a[1]*b[0]; optionally you can round to nearest when
taking the high half; and optionally you can take the difference
rather than sum of the two products. Finally, saturation is applied
when converting back to a single-width vector lane.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D76359

Files:
  clang/include/clang/Basic/arm_mve.td
  clang/test/CodeGen/arm-mve-intrinsics/vqdmlad.c
  llvm/include/llvm/IR/IntrinsicsARM.td
  llvm/lib/Target/ARM/ARMInstrMVE.td
  llvm/test/CodeGen/Thumb2/mve-intrinsics/vqdmlad.ll

Index: llvm/test/CodeGen/Thumb2/mve-intrinsics/vqdmlad.ll
===
--- /dev/null
+++ llvm/test/CodeGen/Thumb2/mve-intrinsics/vqdmlad.ll
@@ -0,0 +1,589 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple=thumbv8.1m.main -mattr=+mve.fp -verify-machineinstrs -o - %s | FileCheck %s
+
+define arm_aapcs_vfpcc <16 x i8> @test_vqdmladhq_s8(<16 x i8> %inactive, <16 x i8> %a, <16 x i8> %b) {
+; CHECK-LABEL: test_vqdmladhq_s8:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vqdmladh.s8 q0, q1, q2
+; CHECK-NEXT:bx lr
+entry:
+  %0 = tail call <16 x i8> @llvm.arm.mve.vqdmlad.v16i8(<16 x i8> %inactive, <16 x i8> %a, <16 x i8> %b, i32 0, i32 0, i32 0)
+  ret <16 x i8> %0
+}
+
+define arm_aapcs_vfpcc <8 x i16> @test_vqdmladhq_s16(<8 x i16> %inactive, <8 x i16> %a, <8 x i16> %b) {
+; CHECK-LABEL: test_vqdmladhq_s16:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vqdmladh.s16 q0, q1, q2
+; CHECK-NEXT:bx lr
+entry:
+  %0 = tail call <8 x i16> @llvm.arm.mve.vqdmlad.v8i16(<8 x i16> %inactive, <8 x i16> %a, <8 x i16> %b, i32 0, i32 0, i32 0)
+  ret <8 x i16> %0
+}
+
+define arm_aapcs_vfpcc <4 x i32> @test_vqdmladhq_s32(<4 x i32> %inactive, <4 x i32> %a, <4 x i32> %b) {
+; CHECK-LABEL: test_vqdmladhq_s32:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vqdmladh.s32 q0, q1, q2
+; CHECK-NEXT:bx lr
+entry:
+  %0 = tail call <4 x i32> @llvm.arm.mve.vqdmlad.v4i32(<4 x i32> %inactive, <4 x i32> %a, <4 x i32> %b, i32 0, i32 0, i32 0)
+  ret <4 x i32> %0
+}
+
+define arm_aapcs_vfpcc <16 x i8> @test_vqdmladhxq_s8(<16 x i8> %inactive, <16 x i8> %a, <16 x i8> %b) {
+; CHECK-LABEL: test_vqdmladhxq_s8:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vqdmladhx.s8 q0, q1, q2
+; CHECK-NEXT:bx lr
+entry:
+  %0 = tail call <16 x i8> @llvm.arm.mve.vqdmlad.v16i8(<16 x i8> %inactive, <16 x i8> %a, <16 x i8> %b, i32 1, i32 0, i32 0)
+  ret <16 x i8> %0
+}
+
+define arm_aapcs_vfpcc <8 x i16> @test_vqdmladhxq_s16(<8 x i16> %inactive, <8 x i16> %a, <8 x i16> %b) {
+; CHECK-LABEL: test_vqdmladhxq_s16:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vqdmladhx.s16 q0, q1, q2
+; CHECK-NEXT:bx lr
+entry:
+  %0 = tail call <8 x i16> @llvm.arm.mve.vqdmlad.v8i16(<8 x i16> %inactive, <8 x i16> %a, <8 x i16> %b, i32 1, i32 0, i32 0)
+  ret <8 x i16> %0
+}
+
+define arm_aapcs_vfpcc <4 x i32> @test_vqdmladhxq_s32(<4 x i32> %inactive, <4 x i32> %a, <4 x i32> %b) {
+; CHECK-LABEL: test_vqdmladhxq_s32:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vqdmladhx.s32 q0, q1, q2
+; CHECK-NEXT:bx lr
+entry:
+  %0 = tail call <4 x i32> @llvm.arm.mve.vqdmlad.v4i32(<4 x i32> %inactive, <4 x i32> %a, <4 x i32> %b, i32 1, i32 0, i32 0)
+  ret <4 x i32> %0
+}
+
+define arm_aapcs_vfpcc <16 x i8> @test_vqdmlsdhq_s8(<16 x i8> %inactive, <16 x i8> %a, <16 x i8> %b) {
+; CHECK-LABEL: test_vqdmlsdhq_s8:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vqdmlsdh.s8 q0, q1, q2
+; CHECK-NEXT:bx lr
+entry:
+  %0 = tail call <16 x i8> @llvm.arm.mve.vqdmlad.v16i8(<16 x i8> %inactive, <16 x i8> %a, <16 x i8> %b, i32 0, i32 0, i32 1)
+  ret <16 x i8> %0
+}
+
+define arm_aapcs_vfpcc <8 x i16> @test_vqdmlsdhq_s16(<8 x i16> %inactive, <8 x i16> %a, <8 x i16> %b) {
+; CHECK-LABEL: test_vqdmlsdhq_s16:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vqdmlsdh.s16 q0, q1, q2
+; CHECK-NEXT:bx lr
+entry:
+  %0 = tail call <8 x i16> @llvm.arm.mve.vqdmlad.v8i16(<8 x i16> %inactive, <8 x i16> %a, <8 x i16> %b, i32 0, i32 0, i32 1)
+  ret <8 x i16> %0
+}
+
+define arm_aapcs_vfpcc <4 x i32> @test_vqdmlsdhq_s32(<4 x i32> %inactive, <4 x i32> %a, <4 x i32> %b) {
+; CHECK-LABEL: test_vqdmlsdhq_s32:
+; CHECK:   @ %bb.0:

[clang] 4cf01ed - [hip] Revise `GlobalDecl` constructors. NFC.

2020-03-18 Thread Michael Liao via cfe-commits


Author: Michael Liao
Date: 2020-03-18T09:33:39-04:00
New Revision: 4cf01ed75e35e7bd3ef8ef1a2192c7f4656ab545

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

LOG: [hip] Revise `GlobalDecl` constructors. NFC.

Summary:
- https://reviews.llvm.org/D68578 revises the `GlobalDecl` constructors
  to ensure all GPU kernels have `ReferenceKenelKind` initialized
  properly with an explicit constructor and static one. But, there are
  lots of places using the implicit constructor triggering the assertion
  on non-GPU kernels. That's found in compilation of many tests and
  workloads.
- Fixing all of them may change more code and, more importantly, all of
  them assumes the default kernel reference kind. This patch changes
  that constructor to tell `CUDAGlobalAttr` and construct `GlobalDecl`
  properly.

Reviewers: yaxunl

Subscribers: cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang/include/clang/AST/GlobalDecl.h
clang/lib/AST/Expr.cpp
clang/lib/AST/ItaniumMangle.cpp
clang/lib/AST/Mangle.cpp
clang/lib/CodeGen/CGDebugInfo.cpp
clang/lib/CodeGen/CGDecl.cpp
clang/lib/CodeGen/CGExpr.cpp
clang/lib/CodeGen/CodeGenModule.cpp
clang/lib/CodeGen/CodeGenModule.h

Removed: 




diff  --git a/clang/include/clang/AST/GlobalDecl.h 
b/clang/include/clang/AST/GlobalDecl.h
index d2b5566a4cfa..bf30d9b94235 100644
--- a/clang/include/clang/AST/GlobalDecl.h
+++ b/clang/include/clang/AST/GlobalDecl.h
@@ -68,7 +68,15 @@ class GlobalDecl {
   GlobalDecl(const VarDecl *D) { Init(D);}
   GlobalDecl(const FunctionDecl *D, unsigned MVIndex = 0)
   : MultiVersionIndex(MVIndex) {
-Init(D);
+if (!D->hasAttr()) {
+  Init(D);
+  return;
+}
+Value.setPointerAndInt(D, unsigned(getDefaultKernelReference(D)));
+  }
+  GlobalDecl(const FunctionDecl *D, KernelReferenceKind Kind)
+  : Value(D, unsigned(Kind)) {
+assert(D->hasAttr() && "Decl is not a GPU kernel!");
   }
   GlobalDecl(const NamedDecl *D) { Init(D); }
   GlobalDecl(const BlockDecl *D) { Init(D); }
@@ -80,10 +88,6 @@ class GlobalDecl {
   GlobalDecl(const CXXDestructorDecl *D, CXXDtorType Type) : Value(D, Type) {}
   GlobalDecl(const VarDecl *D, DynamicInitKind StubKind)
   : Value(D, unsigned(StubKind)) {}
-  GlobalDecl(const FunctionDecl *D, KernelReferenceKind Kind)
-  : Value(D, unsigned(Kind)) {
-assert(D->hasAttr() && "Decl is not a GPU kernel!");
-  }
 
   GlobalDecl getCanonicalDecl() const {
 GlobalDecl CanonGD;
@@ -145,10 +149,10 @@ class GlobalDecl {
 return GD;
   }
 
-  static GlobalDecl getDefaultKernelReference(const FunctionDecl *D) {
-return GlobalDecl(D, D->getASTContext().getLangOpts().CUDAIsDevice
- ? KernelReferenceKind::Kernel
- : KernelReferenceKind::Stub);
+  static KernelReferenceKind getDefaultKernelReference(const FunctionDecl *D) {
+return D->getASTContext().getLangOpts().CUDAIsDevice
+   ? KernelReferenceKind::Kernel
+   : KernelReferenceKind::Stub;
   }
 
   GlobalDecl getWithDecl(const Decl *D) {

diff  --git a/clang/lib/AST/Expr.cpp b/clang/lib/AST/Expr.cpp
index 1eb56c30283c..6591b0481d4b 100644
--- a/clang/lib/AST/Expr.cpp
+++ b/clang/lib/AST/Expr.cpp
@@ -567,7 +567,7 @@ std::string PredefinedExpr::ComputeName(IdentKind IK, const 
Decl *CurrentDecl) {
 else if (const CXXDestructorDecl *DD = dyn_cast(ND))
   GD = GlobalDecl(DD, Dtor_Base);
 else if (ND->hasAttr())
-  GD = GlobalDecl::getDefaultKernelReference(cast(ND));
+  GD = GlobalDecl(cast(ND));
 else
   GD = GlobalDecl(ND);
 MC->mangleName(GD, Out);

diff  --git a/clang/lib/AST/ItaniumMangle.cpp b/clang/lib/AST/ItaniumMangle.cpp
index 6deab2a95494..12e1fc589fdc 100644
--- a/clang/lib/AST/ItaniumMangle.cpp
+++ b/clang/lib/AST/ItaniumMangle.cpp
@@ -1575,14 +1575,8 @@ static GlobalDecl getParentOfLocalEntity(const 
DeclContext *DC) {
 GD = GlobalDecl(CD, Ctor_Complete);
   else if (auto *DD = dyn_cast(DC))
 GD = GlobalDecl(DD, Dtor_Complete);
-  else {
-auto *FD = cast(DC);
-// Local variables can only exist in real kernels.
-if (FD->hasAttr())
-  GD = GlobalDecl(FD, KernelReferenceKind::Kernel);
-else
-  GD = GlobalDecl(FD);
-  }
+  else
+GD = GlobalDecl(cast(DC));
   return GD;
 }
 

diff  --git a/clang/lib/AST/Mangle.cpp b/clang/lib/AST/Mangle.cpp
index cc46994c1003..30078fcb243d 100644
--- a/clang/lib/AST/Mangle.cpp
+++ b/clang/lib/AST/Mangle.cpp
@@ -444,7 +444,7 @@ class ASTNameGenerator::Implementation {
   else if (const auto *DtorD = dyn_cast(D))
 GD = GlobalDecl(DtorD, Dtor_Complete);
   else if (D->hasAttr())
-GD =

[PATCH] D76360: [PPC][AIX] Emit correct Vaarg for 32BIT-AIX in clang

2020-03-18 Thread Zarko Todorovski via Phabricator via cfe-commits

ZarkoCA created this revision.
Herald added subscribers: cfe-commits, kbarton, nemanjai.
Herald added a project: clang.
ZarkoCA added reviewers: jasonliu, sfertile, cebowleratibm.
Herald added a subscriber: wuzish.

This patch contains only the FE changes previously found in 
https://reviews.llvm.org/D76130. 
Currently all PPC32-bit targets take the PPC32SVRABI path, this patch branches 
within that path to consume the va_list emitted for AIX and emit the correct 
VAArg.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D76360

Files:
  clang/lib/Basic/Targets/PPC.h
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/aix-vararg.c


Index: clang/test/CodeGen/aix-vararg.c
===
--- /dev/null
+++ clang/test/CodeGen/aix-vararg.c
@@ -0,0 +1,30 @@
+// REQUIRES: powerpc-registered-target
+// REQUIRES: asserts
+// RUN: %clang_cc1 -triple powerpc-ibm-aix-xcoff -emit-llvm -o - %s | 
FileCheck %s --check-prefix=32BIT
+#include 
+
+void aix_varg(int a, ...) {
+  va_list arg;
+  va_start(arg, a);
+  va_arg(arg, int);
+  va_end(arg);
+}
+
+// 32BIT:   define void @aix_varg(i32 %a, ...) #0 {
+// 32BIT:   entry:
+// 32BIT-NEXT:%a.addr = alloca i32, align 4
+// 32BIT-NEXT:%arg = alloca i8*, align 4
+// 32BIT-NEXT:store i32 %a, i32* %a.addr, align 4
+// 32BIT-NEXT:%arg1 = bitcast i8** %arg to i8*
+// 32BIT-NEXT:call void @llvm.va_start(i8* %arg1)
+// 32BIT-NEXT:%argp.cur = load i8*, i8** %arg, align 4
+// 32BIT-NEXT:%argp.next = getelementptr inbounds i8, i8* %argp.cur, 
i32 4
+// 32BIT-NEXT:store i8* %argp.next, i8** %arg, align 4
+// 32BIT-NEXT:%0 = bitcast i8* %argp.cur to i32*
+// 32BIT-NEXT:%1 = load i32, i32* %0, align 4
+// 32BIT-NEXT:%arg2 = bitcast i8** %arg to i8*
+// 32BIT-NEXT:call void @llvm.va_end(i8* %arg2)
+// 32BIT-NEXT:ret void
+// 32BIT-NEXT:  }
+// 32BIT:declare void @llvm.va_start(i8*)
+// 32BIT:declare void @llvm.va_end(i8*)
Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ clang/lib/CodeGen/TargetInfo.cpp
@@ -4229,7 +4229,10 @@
 // DefaultABIInfo::EmitVAArg.
 Address PPC32_SVR4_ABIInfo::EmitVAArg(CodeGenFunction &CGF, Address VAList,
   QualType Ty) const {
-  if (getTarget().getTriple().isOSDarwin()) {
+  // TODO: Add AIX ABI Info.  Currently we are relying on PPC32_SVR4_ABIInfo to
+  // emit correct VAArg.
+  if (getTarget().getTriple().isOSDarwin() ||
+  getTarget().getTriple().isOSAIX()) {
 auto TI = getContext().getTypeInfoInChars(Ty);
 TI.second = getParamTypeAlignment(Ty);
 
Index: clang/lib/Basic/Targets/PPC.h
===
--- clang/lib/Basic/Targets/PPC.h
+++ clang/lib/Basic/Targets/PPC.h
@@ -369,7 +369,8 @@
   }
 
   BuiltinVaListKind getBuiltinVaListKind() const override {
-// This is the ELF definition, and is overridden by the Darwin sub-target
+// This is the ELF definition, and is overridden by the Darwin and AIX
+// sub-target.
 return TargetInfo::PowerABIBuiltinVaList;
   }
 };


Index: clang/test/CodeGen/aix-vararg.c
===
--- /dev/null
+++ clang/test/CodeGen/aix-vararg.c
@@ -0,0 +1,30 @@
+// REQUIRES: powerpc-registered-target
+// REQUIRES: asserts
+// RUN: %clang_cc1 -triple powerpc-ibm-aix-xcoff -emit-llvm -o - %s | FileCheck %s --check-prefix=32BIT
+#include 
+
+void aix_varg(int a, ...) {
+  va_list arg;
+  va_start(arg, a);
+  va_arg(arg, int);
+  va_end(arg);
+}
+
+// 32BIT:   define void @aix_varg(i32 %a, ...) #0 {
+// 32BIT:   entry:
+// 32BIT-NEXT:%a.addr = alloca i32, align 4
+// 32BIT-NEXT:%arg = alloca i8*, align 4
+// 32BIT-NEXT:store i32 %a, i32* %a.addr, align 4
+// 32BIT-NEXT:%arg1 = bitcast i8** %arg to i8*
+// 32BIT-NEXT:call void @llvm.va_start(i8* %arg1)
+// 32BIT-NEXT:%argp.cur = load i8*, i8** %arg, align 4
+// 32BIT-NEXT:%argp.next = getelementptr inbounds i8, i8* %argp.cur, i32 4
+// 32BIT-NEXT:store i8* %argp.next, i8** %arg, align 4
+// 32BIT-NEXT:%0 = bitcast i8* %argp.cur to i32*
+// 32BIT-NEXT:%1 = load i32, i32* %0, align 4
+// 32BIT-NEXT:%arg2 = bitcast i8** %arg to i8*
+// 32BIT-NEXT:call void @llvm.va_end(i8* %arg2)
+// 32BIT-NEXT:ret void
+// 32BIT-NEXT:  }
+// 32BIT:declare void @llvm.va_start(i8*)
+// 32BIT:declare void @llvm.va_end(i8*)
Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ clang/lib/CodeGen/TargetInfo.cpp
@@ -4229,7 +4229,10 @@
 // DefaultABIInfo::EmitVAArg.
 Address PPC32_SVR4_ABIInfo::Emit

[PATCH] D74144: [OPENMP50]Add basic support for array-shaping operation.

2020-03-18 Thread Alexey Bataev via Phabricator via cfe-commits

ABataev added a comment.

Ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74144



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

[PATCH] D76361: [Analyzer] Iterator Modeling - Model `std::advance()`, `std::prev()` and `std::next()`

2020-03-18 Thread Balogh, Ádám via Phabricator via cfe-commits

baloghadamsoftware added a comment.

Partially replacing D62895 .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76361



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

[PATCH] D76361: [Analyzer] Iterator Modeling - Model `std::advance()`, `std::prev()` and `std::next()`

2020-03-18 Thread Balogh, Ádám via Phabricator via cfe-commits

baloghadamsoftware created this revision.
baloghadamsoftware added reviewers: NoQ, Szelethus.
baloghadamsoftware added a project: clang.
Herald added subscribers: ASDenysPetrov, martong, steakhal, Charusso, 
gamesh411, dkrupp, donat.nagy, mikhail.ramalho, a.sidorin, rnkovacs, szepet, 
xazax.hun, whisperity.
baloghadamsoftware added a comment.

Partially replacing D62895 .


Whenever the analyzer budget runs out just at the point where `std::advance()`, 
`std::prev()` or `std::next()` is invoked the function are not inlined. This 
results in strange behavior such as `std::prev(v.end())` equals `v.end()`. To 
prevent this model these functions if they were not inlined. It may also 
happend that although `std::advance()` is inlined but a function it calls 
inside (e.g. `__advance()` in some implementations) is not. This case is also 
handled in this patch.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D76361

Files:
  clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
  clang/test/Analysis/Inputs/system-header-simulator-cxx.h
  clang/test/Analysis/iterator-modelling.cpp

Index: clang/test/Analysis/iterator-modelling.cpp
===
--- clang/test/Analysis/iterator-modelling.cpp
+++ clang/test/Analysis/iterator-modelling.cpp
@@ -2,6 +2,12 @@
 
 // RUN: %clang_analyze_cc1 -std=c++11 -analyzer-checker=core,cplusplus,debug.DebugIteratorModeling,debug.ExprInspection -analyzer-config aggressive-binary-operation-simplification=true -analyzer-config c++-container-inlining=true -DINLINE=1 %s -verify
 
+// RUN: %clang_analyze_cc1 -std=c++11 -analyzer-checker=core,cplusplus,debug.DebugIteratorModeling,debug.ExprInspection -analyzer-config aggressive-binary-operation-simplification=true -analyzer-config c++-container-inlining=true -DINLINE=1 -DSTD_ADVANCE_INLINE_LEVEL=0 %s -verify
+
+// RUN: %clang_analyze_cc1 -std=c++11 -analyzer-checker=core,cplusplus,debug.DebugIteratorModeling,debug.ExprInspection -analyzer-config aggressive-binary-operation-simplification=true -analyzer-config c++-container-inlining=true -DINLINE=1 -DSTD_ADVANCE_INLINE_LEVEL=1 %s -verify
+
+// RUN: %clang_analyze_cc1 -std=c++11 -analyzer-checker=core,cplusplus,debug.DebugIteratorModeling,debug.ExprInspection -analyzer-config aggressive-binary-operation-simplification=true -analyzer-config c++-container-inlining=true -DINLINE=1 -DSTD_ADVANCE_INLINE_LEVEL=2 %s -verify
+
 // RUN: %clang_analyze_cc1 -std=c++11 -analyzer-checker=core,cplusplus,alpha.cplusplus.IteratorModeling,debug.ExprInspection -analyzer-config aggressive-binary-operation-simplification=true %s 2>&1 | FileCheck %s
 
 #include "Inputs/system-header-simulator-cxx.h"
@@ -233,6 +239,68 @@
   clang_analyzer_express(clang_analyzer_iterator_position(i2)); //expected-warning{{$v.end() - 1}}
 }
 
+/// std::advance(), std::prev(), std::next()
+
+void std_advance_minus(const std::vector &v) {
+  auto i = v.end();
+
+  clang_analyzer_denote(clang_analyzer_container_end(v), "$v.end()");
+
+  std::advance(i, -1);
+
+  clang_analyzer_express(clang_analyzer_iterator_position(i)); //expected-warning{{$v.end() - 1}}
+}
+
+void std_advance_plus(const std::vector &v) {
+  auto i = v.begin();
+
+  clang_analyzer_denote(clang_analyzer_container_begin(v), "$v.begin()");
+
+  std::advance(i, 1);
+
+  clang_analyzer_express(clang_analyzer_iterator_position(i)); //expected-warning{{$v.begin() + 1}}
+}
+
+void std_prev(const std::vector &v) {
+  auto i = v.end();
+
+  clang_analyzer_denote(clang_analyzer_container_end(v), "$v.end()");
+
+  auto j = std::prev(i);
+
+  clang_analyzer_express(clang_analyzer_iterator_position(j)); //expected-warning{{$v.end() - 1}}
+}
+
+void std_prev2(const std::vector &v) {
+  auto i = v.end();
+
+  clang_analyzer_denote(clang_analyzer_container_end(v), "$v.end()");
+
+  auto j = std::prev(i, 2);
+
+  clang_analyzer_express(clang_analyzer_iterator_position(j)); //expected-warning{{$v.end() - 2}}
+}
+
+void std_next(const std::vector &v) {
+  auto i = v.begin();
+
+  clang_analyzer_denote(clang_analyzer_container_begin(v), "$v.begin()");
+
+  auto j = std::next(i);
+
+  clang_analyzer_express(clang_analyzer_iterator_position(j)); //expected-warning{{$v.begin() + 1}}
+}
+
+void std_next2(const std::vector &v) {
+  auto i = v.begin();
+
+  clang_analyzer_denote(clang_analyzer_container_begin(v), "$v.begin()");
+
+  auto j = std::next(i, 2);
+
+  clang_analyzer_express(clang_analyzer_iterator_position(j)); //expected-warning{{$v.begin() + 2}}
+}
+
 
 ///
 /// C O N T A I N E R   A S S I G N M E N T S
Index: clang/test/Analysis/Inputs/system-header-simulator-cxx.h
===
--- clang/test/Analysis/Inputs/system-header-simulator-cxx.h
+++ clang/test/Analysis/Inputs/system-header-simulator-cxx.h
@@ -758,30 +758,64 @@
 
 template 
 void __adv

[PATCH] D76130: [PPC][AIX] Implement variadic function handling in LowerFormalArguments_AIX

2020-03-18 Thread Zarko Todorovski via Phabricator via cfe-commits

ZarkoCA updated this revision to Diff 251065.
ZarkoCA retitled this revision from "[PPC][AIX] Implement variadic function 
handling in LowerFormalArguments_AIX in 32-bit mode." to "[PPC][AIX] Implement 
variadic function handling in LowerFormalArguments_AIX".
ZarkoCA edited the summary of this revision.
ZarkoCA added a reviewer: jasonliu.
ZarkoCA added a comment.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Addressed comments by Jason.
Re-added 64BIT changes for LLC.
Split clang changes and made a patch specific with them 
https://reviews.llvm.org/D76360


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76130

Files:
  llvm/lib/Target/PowerPC/PPCISelLowering.cpp
  llvm/test/CodeGen/PowerPC/aix-cc-abi-va_args-32.ll
  llvm/test/CodeGen/PowerPC/aix-cc-abi-va_args-64.ll

Index: llvm/test/CodeGen/PowerPC/aix-cc-abi-va_args-64.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/aix-cc-abi-va_args-64.ll
@@ -0,0 +1,316 @@
+; RUN: llc -O2 -mtriple powerpc64-ibm-aix-xcoff -stop-after=machine-cp -verify-machineinstrs < %s | \
+; RUN: FileCheck --check-prefixes=CHECK,64BIT %s
+
+; RUN: llc -O2 -verify-machineinstrs -mcpu=pwr4 -mattr=-altivec \
+; RUN:  -mtriple powerpc64-ibm-aix-xcoff < %s | \
+; RUN: FileCheck --check-prefixes=CHECKASM,ASM64PWR4 %s
+
+
+  @a = local_unnamed_addr global i32 1, align 4
+  @b = local_unnamed_addr global i32 2, align 4
+  @c = local_unnamed_addr global i32 3, align 4
+  @d = local_unnamed_addr global i32 4, align 4
+  @e = local_unnamed_addr global i32 5, align 4
+  @f = local_unnamed_addr global i32 6, align 4
+  @g = local_unnamed_addr global i32 7, align 4
+  @h = local_unnamed_addr global i32 8, align 4
+  @i = local_unnamed_addr global i32 9, align 4
+  @j = local_unnamed_addr global i32 10, align 4
+
+define signext i32 @va_arg1(i32 signext %a, ...) local_unnamed_addr {
+entry:
+  %arg = alloca i8*, align 8
+  %0 = bitcast i8** %arg to i8*
+  call void @llvm.lifetime.start.p0i8(i64 8, i8* nonnull %0)
+  call void @llvm.va_start(i8* nonnull %0)
+  %cmp7 = icmp sgt i32 %a, 0
+  br i1 %cmp7, label %for.body.preheader, label %for.end
+
+for.body.preheader:
+  %argp.cur.pre = load i8*, i8** %arg, align 8
+  %1 = add i32 %a, -1
+  %2 = zext i32 %1 to i64
+  %3 = add nuw nsw i64 %2, 1
+  %min.iters.check = icmp ult i32 %1, 8
+  br i1 %min.iters.check, label %for.body.preheader28, label %vector.memcheck
+
+vector.memcheck:
+  %uglygep = getelementptr inbounds i8, i8* %0, i64 1
+  %scevgep = getelementptr i8, i8* %argp.cur.pre, i64 4
+  %4 = shl nuw nsw i64 %2, 3
+  %5 = add nuw nsw i64 %4, 8
+  %scevgep11 = getelementptr i8, i8* %argp.cur.pre, i64 %5
+  %bound0 = icmp ugt i8* %scevgep11, %0
+  %bound1 = icmp ult i8* %scevgep, %uglygep
+  %found.conflict = and i1 %bound0, %bound1
+  br i1 %found.conflict, label %for.body.preheader28, label %vector.ph
+
+vector.ph:
+  %n.mod.vf = and i64 %3, 7
+  %6 = icmp eq i64 %n.mod.vf, 0
+  %7 = select i1 %6, i64 8, i64 %n.mod.vf
+  %n.vec = sub nsw i64 %3, %7
+  %8 = shl nsw i64 %n.vec, 3
+  %ind.end = getelementptr i8, i8* %argp.cur.pre, i64 %8
+  %ind.end13 = trunc i64 %n.vec to i32
+  %next.gep = getelementptr i8, i8* %argp.cur.pre, i64 4
+  %next.gep17 = getelementptr i8, i8* %argp.cur.pre, i64 4
+  %next.gep20 = getelementptr i8, i8* %argp.cur.pre, i64 8
+  br label %vector.body
+
+vector.body:
+  %index = phi i64 [ 0, %vector.ph ], [ %index.next, %vector.body ]
+  %vec.phi = phi <4 x i32> [ , %vector.ph ], [ %19, %vector.body ]
+  %vec.phi21 = phi <4 x i32> [ zeroinitializer, %vector.ph ], [ %20, %vector.body ]
+  %9 = shl i64 %index, 3
+  %10 = shl i64 %index, 3
+  %11 = or i64 %10, 32
+  %12 = shl i64 %index, 3
+  %13 = or i64 %12, 56
+  %14 = getelementptr inbounds i8, i8* %next.gep20, i64 %13
+  %15 = getelementptr inbounds i8, i8* %next.gep, i64 %9
+  %16 = getelementptr inbounds i8, i8* %next.gep17, i64 %11
+  %17 = bitcast i8* %15 to <8 x i32>*
+  %18 = bitcast i8* %16 to <8 x i32>*
+  %wide.vec = load <8 x i32>, <8 x i32>* %17, align 4
+  %wide.vec23 = load <8 x i32>, <8 x i32>* %18, align 4
+  %strided.vec = shufflevector <8 x i32> %wide.vec, <8 x i32> undef, <4 x i32> 
+  %strided.vec24 = shufflevector <8 x i32> %wide.vec23, <8 x i32> undef, <4 x i32> 
+  %19 = add <4 x i32> %strided.vec, %vec.phi
+  %20 = add <4 x i32> %strided.vec24, %vec.phi21
+  %index.next = add i64 %index, 8
+  %21 = icmp eq i64 %index.next, %n.vec
+  br i1 %21, label %middle.block, label %vector.body
+
+middle.block:
+  store i8* %14, i8** %arg, align 8
+  %bin.rdx = add <4 x i32> %20, %19
+  %rdx.shuf = shufflevector <4 x i32> %bin.rdx, <4 x i32> undef, <4 x i32> 
+  %bin.rdx25 = add <4 x i32> %bin.rdx, %rdx.shuf
+  %rdx.shuf26 = shufflevector <4 x i32> %bin.rdx25, <4 x i32> undef, <4 x i32> 
+  %bin.rdx27 = add <4 x i32> %bin.rdx25, %rdx.shuf26
+  %22 = extractelement <4 x i32> %bin.rdx27, i

[PATCH] D75220: [clang-tidy] RenamerClangTidy now correctly renames `using namespace` decls

2020-03-18 Thread Aaron Ballman via Phabricator via cfe-commits

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

LGTM aside from a commenting nit.




Comment at: clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp:276
+
+// fix using namespace decls
+if (const auto *UsingNS = dyn_cast(Decl)) {

Comments should be complete sentences with capitalization and punctuation (and 
you can remove the empty newline above).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75220



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

[PATCH] D76130: [PPC][AIX] Implement variadic function handling in LowerFormalArguments_AIX

2020-03-18 Thread Zarko Todorovski via Phabricator via cfe-commits

ZarkoCA marked 8 inline comments as done.
ZarkoCA added inline comments.



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:7088
+   GPRIndex < NumGPArgRegs; ++GPRIndex) {
+unsigned VReg = MF.getRegInfo().getLiveInVirtReg(
+IsPPC64 ? GPR_64[GPRIndex] : GPR_32[GPRIndex]);

jasonliu wrote:
> Just curious, in what scenario would we already have the GPR stored in a 
> virtual register before we store that GPR on that stack?
I don't think we need to include that, it was a remnant from an earlier 
prototype I had. Thanks for pointing it out. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76130



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

[PATCH] D67336: [analyzer][NFC] Introduce SuperChecker<>, a convenient alternative to Checker<> for storing subcheckers

2020-03-18 Thread Kristóf Umann via Phabricator via cfe-commits

Szelethus added a comment.
Herald added subscribers: ASDenysPetrov, martong, steakhal.

> I have mixed feelings. Removing boilerplate is good, but the very fact that 
> we're legalizing this pattern indicates that our checkers will keep bloating 
> up, while i always wanted to actually split them instead (like, make 
> sub-checkers into their own separate //classes//, possibly spread out into 
> different files, kinda micro checkers as opposed to monolithic checkers (?)).

The subchecker system as it works now is more diverse than that. Some systems 
use them purely for diagnostics (this patch is targeting those), while some 
affect the modeling as well. I think we should allow purely diagnostic 
checkers, because we can't really justify making an entire class for them, let 
alone an entire file, and they really are an integral part of the checker. 
However, we absolutely shouldn't promote adding further modeling into an 
existing checker whenever its avoidable.

The unfortunate truth is (at least the way I see it) is that we can't really 
force anyone to write better code. I like to think this patch neither legalizes 
nor prevents someone from bloating a file further, but rather introduces a new 
tool to split the giant checkers up, or make future additions more manageable.

The high level idea would be that when `CallDescriptionMap` is too simple, 
allow checkers to create their own events, and register subcheckers into them. 
This would for instance solve the problem of the unknown callback order of 
regular callbacks among checkers, which might be a better alternative then 
leaving this to `CheckerRegistry`.

Btw I tried to write this comment for literally months now, but I admit that I 
don't yet the where such a subsystem could be deployed in the already existing 
checkers. I always think of `MallocChecker`, but I don't see how we could do it 
there just yet.

@NoQ, in San José, you mentioned an example with `std::set` that would really 
demand a strong checker infrastructure, but I've since forgotten it. Could you 
explain it again please?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67336



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

[PATCH] D76344: [hip] Revise `GlobalDecl` constructors. NFC.

2020-03-18 Thread Michael Liao via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG4cf01ed75e35: [hip] Revise `GlobalDecl` constructors. NFC. 
(authored by hliao).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76344

Files:
  clang/include/clang/AST/GlobalDecl.h
  clang/lib/AST/Expr.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/Mangle.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGDecl.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenModule.h

Index: clang/lib/CodeGen/CodeGenModule.h
===
--- clang/lib/CodeGen/CodeGenModule.h
+++ clang/lib/CodeGen/CodeGenModule.h
@@ -711,9 +711,6 @@
   CtorList &getGlobalCtors() { return GlobalCtors; }
   CtorList &getGlobalDtors() { return GlobalDtors; }
 
-  /// get GlobalDecl for non-ctor/dtor functions.
-  GlobalDecl getGlobalDecl(const FunctionDecl *FD);
-
   /// getTBAATypeInfo - Get metadata used to describe accesses to objects of
   /// the given type.
   llvm::MDNode *getTBAATypeInfo(QualType QTy);
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -5302,7 +5302,7 @@
   case Decl::CXXConversion:
   case Decl::CXXMethod:
   case Decl::Function:
-EmitGlobal(getGlobalDecl(cast(D)));
+EmitGlobal(cast(D));
 // Always provide some coverage mapping
 // even for the functions that aren't emitted.
 AddDeferredUnusedCoverageMapping(D);
@@ -5964,10 +5964,3 @@
 "__translate_sampler_initializer"),
 {C});
 }
-
-GlobalDecl CodeGenModule::getGlobalDecl(const FunctionDecl *FD) {
-  if (FD->hasAttr())
-return GlobalDecl::getDefaultKernelReference(FD);
-  else
-return GlobalDecl(FD);
-}
Index: clang/lib/CodeGen/CGExpr.cpp
===
--- clang/lib/CodeGen/CGExpr.cpp
+++ clang/lib/CodeGen/CGExpr.cpp
@@ -4678,12 +4678,12 @@
   // Resolve direct calls.
   } else if (auto DRE = dyn_cast(E)) {
 if (auto FD = dyn_cast(DRE->getDecl())) {
-  return EmitDirectCallee(*this, CGM.getGlobalDecl(FD));
+  return EmitDirectCallee(*this, FD);
 }
   } else if (auto ME = dyn_cast(E)) {
 if (auto FD = dyn_cast(ME->getMemberDecl())) {
   EmitIgnoredExpr(ME->getBase());
-  return EmitDirectCallee(*this, CGM.getGlobalDecl(FD));
+  return EmitDirectCallee(*this, FD);
 }
 
   // Look through template substitutions.
Index: clang/lib/CodeGen/CGDecl.cpp
===
--- clang/lib/CodeGen/CGDecl.cpp
+++ clang/lib/CodeGen/CGDecl.cpp
@@ -297,7 +297,7 @@
   else if (const auto *DD = dyn_cast(DC))
 GD = GlobalDecl(DD, Dtor_Base);
   else if (const auto *FD = dyn_cast(DC))
-GD = getGlobalDecl(FD);
+GD = GlobalDecl(FD);
   else {
 // Don't do anything for Obj-C method decls or global closures. We should
 // never defer them.
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -3833,8 +3833,7 @@
   // create the one describing the function in order to have complete
   // call site debug info.
   if (!CalleeDecl->isStatic() && !CalleeDecl->isInlined())
-EmitFunctionDecl(CGM.getGlobalDecl(CalleeDecl), CalleeDecl->getLocation(),
- CalleeType, Func);
+EmitFunctionDecl(CalleeDecl, CalleeDecl->getLocation(), CalleeType, Func);
 }
 
 void CGDebugInfo::EmitInlineFunctionStart(CGBuilderTy &Builder, GlobalDecl GD) {
Index: clang/lib/AST/Mangle.cpp
===
--- clang/lib/AST/Mangle.cpp
+++ clang/lib/AST/Mangle.cpp
@@ -444,7 +444,7 @@
   else if (const auto *DtorD = dyn_cast(D))
 GD = GlobalDecl(DtorD, Dtor_Complete);
   else if (D->hasAttr())
-GD = GlobalDecl::getDefaultKernelReference(cast(D));
+GD = GlobalDecl(cast(D));
   else
 GD = GlobalDecl(D);
   MC->mangleName(GD, OS);
Index: clang/lib/AST/ItaniumMangle.cpp
===
--- clang/lib/AST/ItaniumMangle.cpp
+++ clang/lib/AST/ItaniumMangle.cpp
@@ -1575,14 +1575,8 @@
 GD = GlobalDecl(CD, Ctor_Complete);
   else if (auto *DD = dyn_cast(DC))
 GD = GlobalDecl(DD, Dtor_Complete);
-  else {
-auto *FD = cast(DC);
-// Local variables can only exist in real kernels.
-if (FD->hasAttr())
-  GD = GlobalDecl(FD, KernelReferenceKind::Kernel);
-else
-  GD = GlobalDecl(FD);
-  }
+  else
+GD = GlobalDecl(cast(DC));
   return GD;
 }
 
Index: clang/lib/AST/Expr.cpp
==

[PATCH] D73534: [DebugInfo] Enable the debug entry values feature by default

2020-03-18 Thread Djordje Todorovic via Phabricator via cfe-commits

djtodoro added a comment.

Since we landed the fix for the issue related to the D75036 
, I'll reland this again.


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

https://reviews.llvm.org/D73534



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

[PATCH] D75063: [analyzer] StdLibraryFunctionsChecker: Add NotNull Arg Constraint

2020-03-18 Thread Kristóf Umann via Phabricator via cfe-commits

Szelethus accepted this revision.
Szelethus added a comment.

LGTM! Please address the nits before commiting, but there is no need for 
another round of reviews. :)

edit: from my end, that is.




Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:175
+using ValueConstraint::ValueConstraint;
+bool CannotBeNull = true;
+

martong wrote:
> Szelethus wrote:
> > What does this do? Is it ever used in the patch?
> Yes, it is used. We use it in `apply` the value is passed to `assume`.
> And in `negate` we flip the value.
Forgot my eyes in the office. Woops. I would still prefer a line of comment 
here :)



Comment at: 
clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:889-890
   Read(LongLongTy, LongLongMax)}},
   {"fread", Summaries{Fread()}},
-  {"fwrite", Summaries{Fread()}},
+  {"fwrite", Summaries{Fwrite()}},
   // getline()-like functions either fail or read at least the delimiter.

Not super relevant to this specific revision, but shouldn't we leave these to 
`StreamChecker`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75063



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

[PATCH] D65591: [AST] Add a flag indicating if any subexpression had errors

2020-03-18 Thread Haojian Wu via Phabricator via cfe-commits

hokein updated this revision to Diff 251077.
hokein marked 10 inline comments as done.
hokein added a comment.

address comments, and add more missing-error-bit cases


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65591

Files:
  clang/include/clang/AST/ASTDumperUtils.h
  clang/include/clang/AST/ComputeDependence.h
  clang/include/clang/AST/DependenceFlags.h
  clang/include/clang/AST/Expr.h
  clang/include/clang/AST/ExprCXX.h
  clang/include/clang/AST/Type.h
  clang/lib/AST/ComputeDependence.cpp
  clang/lib/AST/TextNodeDumper.cpp
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp

Index: clang/lib/Serialization/ASTWriterStmt.cpp
===
--- clang/lib/Serialization/ASTWriterStmt.cpp
+++ clang/lib/Serialization/ASTWriterStmt.cpp
@@ -540,6 +540,7 @@
   Record.push_back(E->isValueDependent());
   Record.push_back(E->isInstantiationDependent());
   Record.push_back(E->containsUnexpandedParameterPack());
+  Record.push_back(E->containsErrors());
   Record.push_back(E->getValueKind());
   Record.push_back(E->getObjectKind());
 }
Index: clang/lib/Serialization/ASTWriterDecl.cpp
===
--- clang/lib/Serialization/ASTWriterDecl.cpp
+++ clang/lib/Serialization/ASTWriterDecl.cpp
@@ -2280,6 +2280,7 @@
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); //ValueDependent
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); //InstantiationDependent
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); //UnexpandedParamPack
+  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // ContainsErrors
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); //GetValueKind
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); //GetObjectKind
   //DeclRefExpr
@@ -2303,6 +2304,7 @@
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); //ValueDependent
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); //InstantiationDependent
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); //UnexpandedParamPack
+  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // ContainsErrors
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); //GetValueKind
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); //GetObjectKind
   //Integer Literal
@@ -2321,6 +2323,7 @@
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); //ValueDependent
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); //InstantiationDependent
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); //UnexpandedParamPack
+  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // ContainsErrors
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); //GetValueKind
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); //GetObjectKind
   //Character Literal
@@ -2339,6 +2342,7 @@
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); //ValueDependent
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); //InstantiationDependent
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); //UnexpandedParamPack
+  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // ContainsErrors
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); //GetValueKind
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); //GetObjectKind
   // CastExpr
Index: clang/lib/Serialization/ASTReaderStmt.cpp
===
--- clang/lib/Serialization/ASTReaderStmt.cpp
+++ clang/lib/Serialization/ASTReaderStmt.cpp
@@ -106,7 +106,8 @@
 
 /// The number of record fields required for the Expr class
 /// itself.
-static const unsigned NumExprFields = NumStmtFields + 7;
+static const unsigned NumExprFields =
+NumStmtFields + ExprDependenceBits + 3;
 
 /// Read and initialize a ExplicitTemplateArgumentList structure.
 void ReadTemplateKWAndArgsInfo(ASTTemplateKWAndArgsInfo &Args,
@@ -517,6 +518,7 @@
   bool ValueDependent = Record.readInt();
   bool InstantiationDependent = Record.readInt();
   bool ContainsUnexpandedTemplateParameters = Record.readInt();
+  bool ContainsErrors = Record.readInt();
   auto Deps = ExprDependence::None;
   if (TypeDependent)
 Deps |= ExprDependence::Type;
@@ -526,6 +528,8 @@
 Deps |= ExprDependence::Instantiation;
   if (ContainsUnexpandedTemplateParameters)
 Deps |= ExprDependence::UnexpandedPack;
+  if (ContainsErrors)
+Deps |= ExprDependence::Error;
   E->setDependence(Deps);
 
   E->setValueKind(static_cast(Record.readInt()));
Index: clang/lib/AST/TextNodeDumper.cpp
===
--- clang/lib/AST/TextNodeDumper.cpp
+++ clang/lib/AST/TextNodeDumper.cpp
@@ -126,6 +126,11 @@
   if (const auto *E = dyn_cast(Node)) {
 dumpType(E->getType());
 
+if (E->containsErrors()) {
+  ColorScope

[PATCH] D75660: Remove CompositeType class

2020-03-18 Thread Nicolai Hähnle via Phabricator via cfe-commits

nhaehnle accepted this revision.
nhaehnle added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75660



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

[PATCH] D65591: [AST] Add a flag indicating if any subexpression had errors

2020-03-18 Thread Haojian Wu via Phabricator via cfe-commits

hokein added inline comments.



Comment at: clang/include/clang/AST/DependenceFlags.h:46
 Instantiation = 2,
+/// Placeholder, and is not used in actual Type.
+Error = 4,

sammccall wrote:
> hokein wrote:
> > sammccall wrote:
> > > I'd like this comment to explain why it exists if not used in actual 
> > > types.
> > > 
> > > Is this used for `decltype(some-error-expr)`? Is this used so 
> > > toTypeDependence() returns something meaningful?
> > > 
> > > If this is used to make the bitcasting hacks work, we should just stop 
> > > doing that.
> > yeah, the main purpose of it is for convenient bitcast. AFAIK, we don't 
> > have a plan to use the error bit except in `Expr`. removing it for now.
> > 
> > 
> I think we should plan to do this for Type too, though it's OK not to do so 
> in this patch.
> 
> consider e.g. the expression `decltype(foo){}` where `foo` has errors. Today 
> we're saying this has no errors, because the DeclTypeType node isn't 
> error-dependent.
> 
> (This is true whether you add the enum value or not: the `Type` constructor 
> takes a bunch of booleans in the constructor, it would need to be refactored 
> to support `TypeDependence` and possibly the computeDependence pattern)
> 
> I think we should ensure that as far as possible, this code conceptually 
> propagates error-dependence from types to expressions correctly, even if the 
> error-dependence is not set in practice yet.
> I'm not sure if this requires having the Error bit in `TypeDependence` now: 
> if we never have to name it because we only blacklist bits, then it's 
> probably OK.
OK, I'd prefer to not expand the scope of this patch right now, because we 
don't have proper tests :( until the final recovery expression patch landed. 
and I think adding the error-bit to Type would probably require more effort 
(more code changes).

updated the code in `computeDependency` to make sure the error-bit will be 
propagated from type-dependence to err-dependence  even we don't have the error 
bit in TypeDependency now.


>(This is true whether you add the enum value or not: the Type constructor 
>takes a bunch of booleans in the constructor, it would need to be refactored 
>to support TypeDependence and possibly the computeDependence pattern)

agree, I think the same to the NestedNameSpecifierDependence, 
TemplateNameDependence, TemplateArgumentDependence.



Comment at: clang/lib/AST/ComputeDependence.cpp:174
 ExprDependence clang::computeDependence(NoInitExpr *E) {
   return toExprDependence(E->getType()->getDependence()) &
  ExprDependence::Instantiation;

sammccall wrote:
> I'm not terribly sure of the implications of not propagating the error bit 
> here. I tend to think that "contains errors" most closely follows 
> instantiation-dependence (i.e. it's fairly strict/lexical), so I'd consider 
> propagating it here.
> 
> BTW, DesignatedInitUpdateExpr seems to have totally broken dependence 
> computations - it's always non-dependent! (Not introduced by this 
> refactoring, I think). Any idea what's up there?
you mean `DesignatedInitExpr`? I didn't see any problem there, why it is always 
non-dependent?



Comment at: clang/lib/AST/ComputeDependence.cpp:500
   if (E->isResultDependent())
 return D | ExprDependence::TypeValueInstantiation;
   return D | (E->getResultExpr()->getDependence() &

sammccall wrote:
> this should be D |=... so that result expr errors propagate
getResultExpr() requires `! isResultDependent()`...

and `D |=` is not enough, for err-bit, I think we need to consider all 
subexpressions. 



Comment at: clang/lib/AST/ComputeDependence.cpp:582
 Deps |= toExprDependence(Q->getDependence());
   for (auto *D : E->decls()) {
 if (D->getDeclContext()->isDependentContext() ||

sammccall wrote:
> (if we decide to make referring to an `invalid` decl an error, this is 
> another spot... there are probably lots :-(. Deferring this is probably best)
deferred this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65591



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

[PATCH] D75661: Remove SequentialType from the type heirarchy.

2020-03-18 Thread Nicolai Hähnle via Phabricator via cfe-commits

nhaehnle added a comment.

The AMDGPU changes LGTM, modulo a stylistic nitpick.

As for the overall change, I'm perfectly fine with the general direction of 
SequentialType, though I don't know where we stand in terms of enough people 
having had a chance to look at it.

I'm concerned though about having getSequentialElementType and 
getSequentialNumElements apply to different sets of types. That's bound to lead 
to confusion which causes bugs. Can we have one name for all types that are 
homogenous sequences of the same element type, and a different name for all 
types which are *fixed-length* homogenous sequences?




Comment at: llvm/lib/Target/AMDGPU/AMDGPUPromoteAlloca.cpp:370-372
+if (VectorType::isValidElementType(ArrayTy->getElementType()) &&
+ArrayTy->getNumElements() > 0)
+  VectorTy = arrayTypeToVecType(ArrayTy);

Please put braces for the outer if (multi-line body).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75661



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

[PATCH] D73898: [analyzer] StdLibraryFunctionsChecker: Add argument constraints

2020-03-18 Thread Gabor Marton via Phabricator via cfe-commits

martong marked 11 inline comments as done.
martong added inline comments.



Comment at: clang/include/clang/StaticAnalyzer/Checkers/Checkers.td:298
 
+def StdCLibraryFunctionArgsChecker : Checker<"StdCLibraryFunctionArgs">,
+  HelpText<"Check constraints of arguments of C standard library functions, "

Szelethus wrote:
> Just noticed, this checker still lies in the `apiModeling` package. Could we 
> find a more appropriate place?
Technically speaking this is still api modeling. In midterm we'd like to add 
support for more libc functions, gnu and posix functions, they are all library 
functions i.e. they provide some api.
Of course in long term, we'd like to experiment by getting some constraints 
from IR/Attributor, but we are still far from there.



Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:191
+  ///   * a list of branches - a list of list of ranges -
+  /// i.e. a list of lists of lists of segments,
+  ///   * a list of argument constraints, that must be true on every branch.

balazske wrote:
> martong wrote:
> > martong wrote:
> > > Szelethus wrote:
> > > > I think that is a rather poor example to help understand what `list of 
> > > > list of ranges` means :) -- Could you try to find something better?
> > > Yeah, that part definitely should be reworded.
> > I added an example with `isalpha`.
> The "branches" are the structures that define relations between arguments and 
> return values? This could be included in the description.
Not exactly. A branch represents a path in the exploded graph of a function 
(which is a tree).
So, a branch is a series of assumptions. In other words, branches represent 
split states and additional assumptions on top of the splitting assumption. I 
added this explanation to the comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:112
   const Summary &Summary) const = 0;
+virtual ValueConstraintPtr negate() const {
+  llvm_unreachable("Not implemented");

balazske wrote:
> Is it better done with `= 0`?
Not all of the constraint classes must implement this. Right now, e.g. the 
`ComparisonConstraint` does not implement this, because there is no such 
summary (yet) that uses a `ComparisonConstraint` as an argument constraint.



Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:260
 
+  BugType BT{this, "Unsatisfied argument constraints", categories::LogicError};
+

Szelethus wrote:
> By passing `this`, the error message will be tied to the modeling checker, 
> not to the one you just added. `BugType` has a constructor that accepts a 
> string instead, pass `CheckNames[CK_StdCLibraryFunctionArgsChecker]` in there 
> :) Also, how about `BT_InvalidArgument` or something?
Thanks, good catch, I did not know about that. Please note that using 
`CheckNames` requires that we change the `BT` member to be lazily initialized. 
Because `CheckNames` is initialized only after the checker itself is created, 
thus we cannot initialize `BT` during the checkers construction, b/c that would 
be before `CheckNames` is set. So, I changed `BT` to be a unique_ptr and it is 
being lazily initialized in `reportBug`.



Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:297
+
+  void ReportBug(const CallEvent &Call, ExplodedNode *N, CheckerContext &C) 
const {
+if (!ChecksEnabled[CK_StdCLibraryFunctionArgsChecker])

balazske wrote:
> This should be called `reportBug`.
Yeah, can't get used to this strange naming convention that LLVM uses. Fixed it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73898



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

[PATCH] D73898: [analyzer] StdLibraryFunctionsChecker: Add argument constraints

2020-03-18 Thread Gabor Marton via Phabricator via cfe-commits

martong updated this revision to Diff 251083.
martong marked 5 inline comments as done.
martong added a comment.

- Add comments about what is a branch
- Do not use 'this' for BugType
- Lazily init BT and BT -> BT_InvalidArg
- ReportBug -> reportBug


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73898

Files:
  clang/include/clang/StaticAnalyzer/Checkers/Checkers.td
  clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
  clang/test/Analysis/analyzer-enabled-checkers.c
  clang/test/Analysis/std-c-library-functions-arg-constraints-bug-path.c
  clang/test/Analysis/std-c-library-functions-arg-constraints.c
  clang/test/Analysis/std-c-library-functions.c

Index: clang/test/Analysis/std-c-library-functions.c
===
--- clang/test/Analysis/std-c-library-functions.c
+++ clang/test/Analysis/std-c-library-functions.c
@@ -1,8 +1,34 @@
-// RUN: %clang_analyze_cc1 -analyzer-checker=apiModeling.StdCLibraryFunctions,debug.ExprInspection -verify -analyzer-config eagerly-assume=false %s
-// RUN: %clang_analyze_cc1 -triple i686-unknown-linux -analyzer-checker=apiModeling.StdCLibraryFunctions,debug.ExprInspection -verify -analyzer-config eagerly-assume=false %s
-// RUN: %clang_analyze_cc1 -triple x86_64-unknown-linux -analyzer-checker=apiModeling.StdCLibraryFunctions,debug.ExprInspection -verify -analyzer-config eagerly-assume=false %s
-// RUN: %clang_analyze_cc1 -triple armv7-a15-linux -analyzer-checker=apiModeling.StdCLibraryFunctions,debug.ExprInspection -verify -analyzer-config eagerly-assume=false %s
-// RUN: %clang_analyze_cc1 -triple thumbv7-a15-linux -analyzer-checker=apiModeling.StdCLibraryFunctions,debug.ExprInspection -verify -analyzer-config eagerly-assume=false %s
+// RUN: %clang_analyze_cc1 %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=apiModeling.StdCLibraryFunctions \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   -analyzer-config eagerly-assume=false \
+// RUN:   -triple i686-unknown-linux \
+// RUN:   -verify
+
+// RUN: %clang_analyze_cc1 %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=apiModeling.StdCLibraryFunctions \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   -analyzer-config eagerly-assume=false \
+// RUN:   -triple x86_64-unknown-linux \
+// RUN:   -verify
+
+// RUN: %clang_analyze_cc1 %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=apiModeling.StdCLibraryFunctions \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   -analyzer-config eagerly-assume=false \
+// RUN:   -triple armv7-a15-linux \
+// RUN:   -verify
+
+// RUN: %clang_analyze_cc1 %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=apiModeling.StdCLibraryFunctions \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   -analyzer-config eagerly-assume=false \
+// RUN:   -triple thumbv7-a15-linux \
+// RUN:   -verify
 
 void clang_analyzer_eval(int);
 
Index: clang/test/Analysis/std-c-library-functions-arg-constraints.c
===
--- /dev/null
+++ clang/test/Analysis/std-c-library-functions-arg-constraints.c
@@ -0,0 +1,44 @@
+// RUN: %clang_analyze_cc1 %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=apiModeling.StdCLibraryFunctions \
+// RUN:   -analyzer-checker=apiModeling.StdCLibraryFunctionArgs \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   -triple x86_64-unknown-linux-gnu \
+// RUN:   -verify
+
+void clang_analyzer_eval(int);
+
+int glob;
+
+#define EOF -1
+
+int isalnum(int);
+
+void test_alnum_concrete(int v) {
+  int ret = isalnum(256); // expected-warning{{Function argument constraint is not satisfied}}
+  (void)ret;
+}
+
+void test_alnum_symbolic(int x) {
+  int ret = isalnum(x);
+  (void)ret;
+  clang_analyzer_eval(EOF <= x && x <= 255); // expected-warning{{TRUE}}
+}
+
+void test_alnum_symbolic2(int x) {
+  if (x > 255) {
+int ret = isalnum(x); // expected-warning{{Function argument constraint is not satisfied}}
+(void)ret;
+  }
+}
+
+void test_alnum_infeasible_path(int x, int y) {
+  int ret = isalnum(x);
+  y = 0;
+  clang_analyzer_eval(EOF <= x && x <= 255); // expected-warning{{TRUE}}
+
+  if (x > 255) // This path is no longer feasible.
+ret = x / y; // No warning here
+
+  ret = x / y; // expected-warning{{Division by zero}}
+}
Index: clang/test/Analysis/std-c-library-functions-arg-constraints-bug-path.c
===
--- /dev/null
+++ clang/test/Analysis/std-c-library-functions-arg-constraints-bug-path.c
@@ -0,0 +1,29 @@
+// RUN: %clang_analyze_cc1 %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=apiModeling.StdCLibraryFunctions \
+// RUN:   -analyzer-checker=apiModeling.StdCLibraryFunctionArgs \
+// RUN:   -analyzer-checker=debug.ExprInspection \

[PATCH] D72334: [Syntax] Build nodes for template declarations.

2020-03-18 Thread Dmitri Gribenko via Phabricator via cfe-commits

gribozavr2 added a comment.

Superseded by https://reviews.llvm.org/D76346.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72334



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

[PATCH] D76360: [PPC][AIX] Emit correct Vaarg for 32BIT-AIX in clang

2020-03-18 Thread Hubert Tong via Phabricator via cfe-commits

hubert.reinterpretcast added inline comments.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:4232
   QualType Ty) const {
-  if (getTarget().getTriple().isOSDarwin()) {
+  // TODO: Add AIX ABI Info.  Currently we are relying on PPC32_SVR4_ABIInfo to
+  // emit correct VAArg.

No need for two spaces. Add comma after "Currently".



Comment at: clang/test/CodeGen/aix-vararg.c:4
+// RUN: %clang_cc1 -triple powerpc-ibm-aix-xcoff -emit-llvm -o - %s | 
FileCheck %s --check-prefix=32BIT
+#include 
+

Can we use built-in types and functions in place of a header inclusion?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76360



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

[PATCH] D76360: [PPC][AIX] Emit correct Vaarg for 32BIT-AIX in clang

2020-03-18 Thread Sean Fertile via Phabricator via cfe-commits

sfertile added inline comments.



Comment at: clang/lib/Basic/Targets/PPC.h:373
+// This is the ELF definition, and is overridden by the Darwin and AIX
+// sub-target.
 return TargetInfo::PowerABIBuiltinVaList;

Minor nit: `target` --> `targets`.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:4175
 namespace {
 /// PPC32_SVR4_ABIInfo - The 32-bit PowerPC ELF (SVR4) ABI information.
 class PPC32_SVR4_ABIInfo : public DefaultABIInfo {

This name and comment is misleading, the class is used for both SVR4 and 
Darwin, and after this patch AIX. We need to fix the name comment to reflect 
that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76360



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

[PATCH] D76365: [cuda][hip] Add CUDA builtin surface/texture reference support.

2020-03-18 Thread Michael Liao via Phabricator via cfe-commits

hliao created this revision.
hliao added reviewers: tra, rjmccall, yaxunl.
Herald added a reviewer: a.sidorin.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

- Even though the bindless surface/texture interfaces are promoted, there are 
still code using surface/texture references. For example, PR#26400 
 reports the compilation issue for 
code using `tex2D` with texture references. For better compatibility, this 
patch proposes the support of surface/texture references.
- Due to the absent documentation and magic headers, it's believed that `nvcc` 
does use builtins for texture support. From the limited NVVM 
documentation[^nvvm] and NVPTX backend texture/surface related tests[^test], 
it's believed that surface/texture references are supported by replacing their 
reference types, which are annotated with 
`device_builtin_surface_type`/`device_builtin_texture_type`, with the 
corresponding handle-like object types, `cudaSurfaceObject_t` or 
`cudaTextureObject_t`, in the device-side compilation. On the host side, that 
global handle variables are registered and will be established and updated 
later when corresponding binding/unbinding APIs are called[^bind]. 
Surface/texture references are most like device global variables but 
represented in different types on the host and device sides.
- In this patch, the following changes are proposed to support that behavior: + 
Refine `device_builtin_surface_type` and `device_builtin_texture_type` 
attributes to be applied on `Type` decl only to check whether a variable is of 
the surface/texture reference type. + Add hooks in code generation to replace 
that reference types with the correponding object types as well as all accesses 
to them. In particular, `nvvm.texsurf.handle.internal` should be used to load 
object handles from global reference variables[^texsurf] as well as metadata 
annotations. + Generate host-side registration with proper template argument 
parsing.

---

[^nvvm]: https://docs.nvidia.com/cuda/pdf/NVVM_IR_Specification.pdf
[^test]: 
https://raw.githubusercontent.com/llvm/llvm-project/master/llvm/test/CodeGen/NVPTX/tex-read-cuda.ll
[^bind]: See section 3.2.11.1.2 ``Texture reference API` in CUDA C Programming 
Guide .
[^texsurf]: According to NVVM IR, `nvvm.texsurf.handle` should be used.  But, 
the current backend doesn't have that supported. We may revise that later.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D76365

Files:
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/lib/AST/Type.cpp
  clang/lib/CodeGen/CGCUDANV.cpp
  clang/lib/CodeGen/CGCUDARuntime.h
  clang/lib/CodeGen/CGExprAgg.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenTypes.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/CodeGen/TargetInfo.h
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGenCUDA/surface.cu
  clang/test/CodeGenCUDA/texture.cu
  clang/test/SemaCUDA/attr-declspec.cu
  clang/test/SemaCUDA/attributes-on-non-cuda.cu
  llvm/include/llvm/IR/Operator.h

Index: llvm/include/llvm/IR/Operator.h
===
--- llvm/include/llvm/IR/Operator.h
+++ llvm/include/llvm/IR/Operator.h
@@ -599,6 +599,29 @@
   }
 };
 
+class AddrSpaceCastOperator
+: public ConcreteOperator {
+  friend class AddrSpaceCastInst;
+  friend class ConstantExpr;
+
+public:
+  Value *getPointerOperand() {
+return getOperand(0);
+  }
+
+  const Value *getPointerOperand() const {
+return getOperand(0);
+  }
+
+  unsigned getSrcAddressSpace() const {
+return getPointerOperand()->getType()->getPointerAddressSpace();
+  }
+
+  unsigned getDestAddressSpace() const {
+return getType()->getPointerAddressSpace();
+  }
+};
+
 } // end namespace llvm
 
 #endif // LLVM_IR_OPERATOR_H
Index: clang/test/SemaCUDA/attributes-on-non-cuda.cu
===
--- clang/test/SemaCUDA/attributes-on-non-cuda.cu
+++ clang/test/SemaCUDA/attributes-on-non-cuda.cu
@@ -7,16 +7,21 @@
 // RUN: %clang_cc1 -DEXPECT_WARNINGS -fsyntax-only -verify -x c %s
 
 #if defined(EXPECT_WARNINGS)
-// expected-warning@+12 {{'device' attribute ignored}}
-// expected-warning@+12 {{'global' attribute ignored}}
-// expected-warning@+12 {{'constant' attribute ignored}}
-// expected-warning@+12 {{'shared' attribute ignored}}
-// expected-warning@+12 {{'host' attribute ignored}}
+// expected-warning@+17 {{'device' attribute ignored}}
+// expected-warning@+17 {{'global' attribute ignored}}
+// expected-warning@+17 {{'constant' attribute ignored}}
+// expected-warning@+17 {{'shared' attribute ignored}}
+// expected-warning@+17 {{'host' attribute ignored}}
+// expected-warning@+23 {{'device_builtin_surface_type' attribute ignored}}
+// expected-warning@+23 {{'device_builtin_texture_type' at

[PATCH] D76366: [Syntax] Split syntax tests

2020-03-18 Thread Marcel Hlopko via Phabricator via cfe-commits

hlopko created this revision.
hlopko added a reviewer: gribozavr2.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
hlopko added a parent revision: D76346: [Syntax] Build template declaration 
nodes.

This patch split Basic test into multple individual tests to allow simpler
filtering and clearer signal into what's broken when it's broken.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D76366

Files:
  clang/unittests/Tooling/Syntax/TreeTest.cpp

Index: clang/unittests/Tooling/Syntax/TreeTest.cpp
===
--- clang/unittests/Tooling/Syntax/TreeTest.cpp
+++ clang/unittests/Tooling/Syntax/TreeTest.cpp
@@ -120,6 +120,16 @@
 return Root;
   }
 
+  void expectTreeDumpEqual(StringRef code, StringRef tree) {
+SCOPED_TRACE(code);
+
+auto *Root = buildTree(code);
+std::string Expected = tree.trim().str();
+std::string Actual =
+std::string(llvm::StringRef(Root->dump(*Arena)).trim());
+EXPECT_EQ(Expected, Actual) << "the resulting dump is:\n" << Actual;
+  }
+
   // Adds a file to the test VFS.
   void addFile(llvm::StringRef Path, llvm::StringRef Contents) {
 if (!FS->addFile(Path, time_t(),
@@ -163,14 +173,13 @@
   std::unique_ptr Arena;
 };
 
-TEST_F(SyntaxTreeTest, Basic) {
-  std::pair Cases[] = {
-  {
-  R"cpp(
+TEST_F(SyntaxTreeTest, Simple) {
+  expectTreeDumpEqual(
+  R"cpp(
 int main() {}
 void foo() {}
 )cpp",
-  R"txt(
+  R"txt(
 *: TranslationUnit
 |-SimpleDeclaration
 | |-int
@@ -192,16 +201,18 @@
   `-CompoundStatement
 |-{
 `-}
-)txt"},
-  // if.
-  {
-  R"cpp(
+)txt");
+}
+
+TEST_F(SyntaxTreeTest, If) {
+  expectTreeDumpEqual(
+  R"cpp(
 int main() {
   if (true) {}
   if (true) {} else if (false) {}
 }
 )cpp",
-  R"txt(
+  R"txt(
 *: TranslationUnit
 `-SimpleDeclaration
   |-int
@@ -241,14 +252,17 @@
 | |-{
 | `-}
 `-}
-)txt"},
-  // for.
-  {R"cpp(
+)txt");
+}
+
+TEST_F(SyntaxTreeTest, For) {
+  expectTreeDumpEqual(
+  R"cpp(
 void test() {
   for (;;)  {}
 }
 )cpp",
-   R"txt(
+  R"txt(
 *: TranslationUnit
 `-SimpleDeclaration
   |-void
@@ -269,10 +283,18 @@
 |   |-{
 |   `-}
 `-}
-)txt"},
-  // declaration statement.
-  {"void test() { int a = 10; }",
-   R"txt(
+)txt");
+}
+
+TEST_F(SyntaxTreeTest, RangeBasedFor) {
+  expectTreeDumpEqual(
+  R"cpp(
+void test() {
+  int a[3];
+  for (int x : a) ;
+}
+  )cpp",
+  R"txt(
 *: TranslationUnit
 `-SimpleDeclaration
   |-void
@@ -288,13 +310,32 @@
 | | |-int
 | | `-SimpleDeclarator
 | |   |-a
-| |   |-=
-| |   `-UnknownExpression
-| | `-10
+| |   `-ArraySubscript
+| | |-[
+| | |-UnknownExpression
+| | | `-3
+| | `-]
 | `-;
+|-RangeBasedForStatement
+| |-for
+| |-(
+| |-SimpleDeclaration
+| | |-int
+| | |-SimpleDeclarator
+| | | `-x
+| | `-:
+| |-UnknownExpression
+| | `-a
+| |-)
+| `-EmptyStatement
+|   `-;
 `-}
-)txt"},
-  {"void test() { ; }", R"txt(
+   )txt");
+}
+
+TEST_F(SyntaxTreeTest, DeclarationStatement) {
+  expectTreeDumpEqual("void test() { int a = 10; }",
+  R"txt(
 *: TranslationUnit
 `-SimpleDeclaration
   |-void
@@ -305,12 +346,22 @@
   |   `-)
   `-CompoundStatement
 |-{
-|-EmptyStatement
+|-DeclarationStatement
+| |-SimpleDeclaration
+| | |-int
+| | `-SimpleDeclarator
+| |   |-a
+| |   |-=
+| |   `-UnknownExpression
+| | `-10
 | `-;
 `-}
-)txt"},
-  // switch, case and default.
-  {R"cpp(
+)txt");
+}
+
+TEST_F(SyntaxTreeTest, Switch) {
+  expectTreeDumpEqual(
+  R"cpp(
 void test() {
   switch (true) {
 case 0:
@@ -318,7 +369,7 @@
   }
 }
 )cpp",
-   R"txt(
+  R"txt(
 *: TranslationUnit
 `-SimpleDeclaration
   |-void
@@ -349,14 +400,17 @@
 |   | `-;
 |   `-}
 `-}
-)txt"},
-  // while.
-  {R"cpp(
+)txt");
+}
+
+TEST_F(SyntaxTreeTest, While) {
+  expectTreeDumpEqual(
+  R"cpp(
 void test() {
   while (true) { continue; break; }
 }
 )cpp",
-   R"txt(
+  R"txt(
 *: TranslationUnit
 `-SimpleDeclaration
   |-void
@@ -383,77 +437,15 @@
 |   | `-;
 |   `-}
 `-}
-)txt"},
-  // return.
-  {R"cpp(
-int test() { return 1; }
-  )cpp",
-   R"txt(
-*: TranslationUnit
-`-SimpleDeclaration
-  |-int
-  |-SimpleDeclarator
-  | |-test
-  | `-ParametersAndQualifiers
-  |   |-(
-  |   `-)
-  `-CompoundStatement
-|-{
-|-ReturnStatement
-| |-return
-| |-UnknownExpression
-| | `-1
-| `-;
-`-}
-)txt"},
-  // Range-based for.
-  {R"cpp(
-void test() {
-  int a[3];
-  for (int x : a) ;
+)txt");
 }
-  )cpp",
-   R"txt(
-*: TranslationUnit
-`-SimpleDeclaration
-  |-void
-  |-SimpleDeclarator
-  | |-test
-  | `-Para

[PATCH] D75682: [Analyzer][StreamChecker] Introduction of stream error handling.

2020-03-18 Thread Balázs Kéri via Phabricator via cfe-commits

balazske added a comment.

In D75682#1928716 , @Szelethus wrote:

> - For streams where the precise state is unknown (they are not tracked), 
> start tracking. If we explicitly check whether a state is `foef()`, we can 
> rightfully assume both of those possibilities.

This can follow in a later revision only. The new stream should have every 
error state possible, so when it is introduced 3 new states are required (with 
the error types), or an "unknown error" is needed that will be added later.

> - Add debug function similar to `clang_analyzer_express`, like 
> `clang_analyzer_set_eof(FILE *)`, etc.

How to add this? Probably it is too much work and I do not like if separate 
such debug functions are there for "every" checker (or many of).

> - Evalulate a less complicated stream modeling function that sets such flags, 
> though I suspect the followup patch is supposed to be the one doing this.

The `fseek` patch can do this.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75682

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

[clang] dd12826 - [Syntax] Build template declaration nodes

2020-03-18 Thread Dmitri Gribenko via cfe-commits


Author: Marcel Hlopko
Date: 2020-03-18T16:16:59+01:00
New Revision: dd12826808f9079e164b82e64b0697a077379241

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

LOG: [Syntax] Build template declaration nodes

Summary:
Copy of https://reviews.llvm.org/D72334, submitting with Ilya's permission.

Handles template declaration of all kinds.

Also builds template declaration nodes for specializations and explicit
instantiations of classes.

Some missing things will be addressed in the follow-up patches:

specializations of functions and variables,
template parameters.

Reviewers: gribozavr2

Reviewed By: gribozavr2

Subscribers: cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang/include/clang/Tooling/Syntax/Nodes.h
clang/lib/Tooling/Syntax/BuildTree.cpp
clang/lib/Tooling/Syntax/Nodes.cpp
clang/unittests/Tooling/Syntax/TreeTest.cpp

Removed: 




diff  --git a/clang/include/clang/Tooling/Syntax/Nodes.h 
b/clang/include/clang/Tooling/Syntax/Nodes.h
index 82fcac33f99b..f4d482bb848c 100644
--- a/clang/include/clang/Tooling/Syntax/Nodes.h
+++ b/clang/include/clang/Tooling/Syntax/Nodes.h
@@ -64,6 +64,8 @@ enum class NodeKind : uint16_t {
   StaticAssertDeclaration,
   LinkageSpecificationDeclaration,
   SimpleDeclaration,
+  TemplateDeclaration,
+  ExplicitTemplateInstantiation,
   NamespaceDefinition,
   NamespaceAliasDefinition,
   UsingNamespaceDirective,
@@ -112,6 +114,9 @@ enum class NodeRole : uint8_t {
   StaticAssertDeclaration_condition,
   StaticAssertDeclaration_message,
   SimpleDeclaration_declarator,
+  TemplateDeclaration_declaration,
+  ExplicitTemplateInstantiation_externKeyword,
+  ExplicitTemplateInstantiation_declaration,
   ArraySubscript_sizeExpression,
   TrailingReturnType_arrow,
   TrailingReturnType_declarator,
@@ -396,6 +401,34 @@ class SimpleDeclaration final : public Declaration {
   std::vector declarators();
 };
 
+/// template  
+class TemplateDeclaration final : public Declaration {
+public:
+  TemplateDeclaration() : Declaration(NodeKind::TemplateDeclaration) {}
+  static bool classof(const Node *N) {
+return N->kind() == NodeKind::TemplateDeclaration;
+  }
+  syntax::Leaf *templateKeyword();
+  syntax::Declaration *declaration();
+};
+
+/// template 
+/// Examples:
+/// template struct X
+/// template void foo()
+/// template int var
+class ExplicitTemplateInstantiation final : public Declaration {
+public:
+  ExplicitTemplateInstantiation()
+  : Declaration(NodeKind::ExplicitTemplateInstantiation) {}
+  static bool classof(const Node *N) {
+return N->kind() == NodeKind::ExplicitTemplateInstantiation;
+  }
+  syntax::Leaf *templateKeyword();
+  syntax::Leaf *externKeyword();
+  syntax::Declaration *declaration();
+};
+
 /// namespace  {  }
 class NamespaceDefinition final : public Declaration {
 public:

diff  --git a/clang/lib/Tooling/Syntax/BuildTree.cpp 
b/clang/lib/Tooling/Syntax/BuildTree.cpp
index 9ebf7d29d8ed..a09ac1c53e34 100644
--- a/clang/lib/Tooling/Syntax/BuildTree.cpp
+++ b/clang/lib/Tooling/Syntax/BuildTree.cpp
@@ -18,6 +18,7 @@
 #include "clang/Basic/LLVM.h"
 #include "clang/Basic/SourceLocation.h"
 #include "clang/Basic/SourceManager.h"
+#include "clang/Basic/Specifiers.h"
 #include "clang/Basic/TokenKinds.h"
 #include "clang/Lex/Lexer.h"
 #include "clang/Tooling/Syntax/Nodes.h"
@@ -189,7 +190,6 @@ class syntax::TreeBuilder {
   /// Should be called for expressions in non-statement position to avoid
   /// wrapping into expression statement.
   void markExprChild(Expr *Child, NodeRole Role);
-
   /// Set role for a token starting at \p Loc.
   void markChildToken(SourceLocation Loc, NodeRole R);
   /// Set role for \p T.
@@ -199,6 +199,9 @@ class syntax::TreeBuilder {
   void markChild(llvm::ArrayRef Range, NodeRole R);
   /// Set role for the delayed node that spans exactly \p Range.
   void markDelayedChild(llvm::ArrayRef Range, NodeRole R);
+  /// Set role for the node that may or may not be delayed. Node must span
+  /// exactly \p Range.
+  void markMaybeDelayedChild(llvm::ArrayRef Range, NodeRole R);
 
   /// Finish building the tree and consume the root node.
   syntax::TranslationUnit *finalize() && {
@@ -215,6 +218,9 @@ class syntax::TreeBuilder {
 return TU;
   }
 
+  /// Finds a token starting at \p L. The token must exist if \p L is valid.
+  const syntax::Token *findToken(SourceLocation L) const;
+
   /// getRange() finds the syntax tokens corresponding to the passed source
   /// locations.
   /// \p First is the start position of the first token and \p Last is the 
start
@@ -227,15 +233,22 @@ class syntax::TreeBuilder {
Arena.sourceManager().isBeforeInTranslationUnit(First, Last));
 return llvm::makeArrayRef(findT

[PATCH] D76360: [PPC][AIX] Emit correct Vaarg for 32BIT-AIX in clang

2020-03-18 Thread Jason Liu via Phabricator via cfe-commits

jasonliu added inline comments.



Comment at: clang/test/CodeGen/aix-vararg.c:10
+  va_arg(arg, int);
+  va_end(arg);
+}

As part of a "va_..." family, do we also want to test va_copy? 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76360



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

[PATCH] D74918: Add method to TargetInfo to get CPU cache line size

2020-03-18 Thread Zoe Carver via Phabricator via cfe-commits

zoecarver added a comment.

@kristof.beyls I'll try to bring that up in my libc++ patch, thanks.

I'm planning on committing this today unless anyone still has concerns. 
@jyknight is this path OK with you?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74918



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

[PATCH] D67336: [analyzer][NFC] Introduce SuperChecker<>, a convenient alternative to Checker<> for storing subcheckers

2020-03-18 Thread Gabor Marton via Phabricator via cfe-commits

martong added a comment.

The way I see perhaps we need a 3rd class of checkers (beside super and sub). 
And that would be those checkers which are not dependent closely on any super 
checker but they do emit diagnostics. E.g. the PlacementNewChecker is 
implemented in it's own, it emits some diagnostics, and does not model. 
However, it depends on MallocChecker's modeling when we are interested in 
dynamically allocated buffers sizes. Or would you add PlacementNewChecker as 
MallocChecker's subchecker? That seems a bit overkill to me.

On the other hand I see that e.g. MallocChecker should have several subcheckers 
(doubleDelete, etc). And these subcheckers do closely operate on the data 
stored in their super checker. 
(Another approach could be if we have a global data storage where every 
modeling checker puts its own data, and other checkers can access this, 
actually Regions is one example to this.)

What is a `CallDescriptionMap`? Could you please explain further?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67336



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

[PATCH] D76291: [Support] Fix formatted_raw_ostream for UTF-8

2020-03-18 Thread Hubert Tong via Phabricator via cfe-commits

hubert.reinterpretcast added inline comments.



Comment at: llvm/lib/Support/FormattedStream.cpp:59
+size_t NumBytes = getNumBytesForUTF8(PartialUTF8Char[0]);
+if (NumBytes > (PartialUTF8Char.size() + Size)) {
+  // If we still don't have enough bytes for a complete code point, just

The overflow-free version should be preferred: `Size < NumBytes - 
PartialUTF8Char.size()`

Considering that `NumBytes - PartialUTF8Char.size()` is already used in the 
`else`, this might as well be named `NumBytesNeededFromBuffer` first (at which 
point it would be the only use of `NumBytes`, so we can get rid of `NumBytes`):

```
  size_t NumBytesNeededFromBuffer =
  getNumBytesForUTF8(PartialUTF8Char[0]) - PartialUTF8Char.size();
  if (Size < NumBytesNeededFromBuffer) {
```



Comment at: llvm/lib/Support/FormattedStream.cpp:87
+// even if the buffer is being flushed.
+if ((Ptr + NumBytes) > End) {
+  PartialUTF8Char = StringRef(Ptr, End - Ptr);

Prefer the overflow-free version:  `End - Ptr < NumBytes`. If inclined to name 
`End - Ptr` (it would occur twice), `BytesAvailable` makes sense.



Comment at: llvm/unittests/Support/formatted_raw_ostream_test.cpp:88
+
+TEST(formatted_raw_ostreamTest, Test_UTF8) {
+  SmallString<128> A;

ostannard wrote:
> hubert.reinterpretcast wrote:
> > Should there be a test for combining characters?
> This doesn't support combining characters, I don't think there's much point 
> in adding a test for something which doesn't work.
Got it; thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76291



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

[PATCH] D76367: [clang-format] Handle C# generic type constraints

2020-03-18 Thread Jonathan B Coe via Phabricator via cfe-commits

jbcoe created this revision.
jbcoe added a reviewer: krasimir.
jbcoe added a project: clang-format.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Treat each C# generic type constraint, `where T: ...`, as a line.

  

Add C# keyword: where

  

Add Token Types: CSharpGenericTypeConstraint, CSharpGenericTypeConstraintColon, 
CSharpGenericTypeConstraintComma.

This patch does not wrap generic type constraints well, that will be addressed 
in a follow up patch.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D76367

Files:
  clang/lib/Format/FormatToken.h
  clang/lib/Format/TokenAnnotator.cpp
  clang/lib/Format/UnwrappedLineFormatter.cpp
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/lib/Format/UnwrappedLineParser.h
  clang/unittests/Format/FormatTestCSharp.cpp

Index: clang/unittests/Format/FormatTestCSharp.cpp
===
--- clang/unittests/Format/FormatTestCSharp.cpp
+++ clang/unittests/Format/FormatTestCSharp.cpp
@@ -628,7 +628,6 @@
   verifyFormat(R"(catch (TestException) when (innerFinallyExecuted))", Style);
   verifyFormat(R"(private float[,] Values;)", Style);
   verifyFormat(R"(Result this[Index x] => Foo(x);)", Style);
-  verifyFormat(R"(class ItemFactory where T : new() {})", Style);
 
   Style.SpacesInSquareBrackets = true;
   verifyFormat(R"(private float[ , ] Values;)", Style);
@@ -673,5 +672,18 @@
Style);
 }
 
+TEST_F(FormatTestCSharp, CSharpGenericTypeConstraints) {
+  FormatStyle Style = getGoogleStyle(FormatStyle::LK_CSharp);
+
+  verifyFormat(R"(//
+class Dictionary
+where TKey : IComparable
+where TVal : IMyInterface {
+  public void MyMethod(T t)
+  where T : IMyInterface { doThing(); }
+})",
+   Style);
+}
+
 } // namespace format
 } // end namespace clang
Index: clang/lib/Format/UnwrappedLineParser.h
===
--- clang/lib/Format/UnwrappedLineParser.h
+++ clang/lib/Format/UnwrappedLineParser.h
@@ -126,6 +126,11 @@
   void parseJavaScriptEs6ImportExport();
   void parseStatementMacro();
   void parseCSharpAttribute();
+  // Parse a C# generic type constraint: `where T : IComparable`.
+  // See:
+  // https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/where-generic-type-constraint
+  // If `ConsumeBrace` is true then the terminating brace is consumed.
+  void parseCSharpGenericTypeConstraint(bool ConsumeBrace = true);
   bool tryToParseLambda();
   bool tryToParseLambdaIntroducer();
   void tryToParseJSFunction();
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -323,6 +323,28 @@
   addUnwrappedLine();
 }
 
+void UnwrappedLineParser::parseCSharpGenericTypeConstraint(bool ConsumeBrace) {
+  do {
+switch (FormatTok->Tok.getKind()) {
+case tok::l_brace:
+  if (ConsumeBrace) {
+nextToken();
+addUnwrappedLine();
+  }
+  return;
+default:
+  if (FormatTok->is(Keywords.kw_where)) {
+addUnwrappedLine();
+nextToken();
+parseCSharpGenericTypeConstraint(ConsumeBrace);
+break;
+  }
+  nextToken();
+  break;
+}
+  } while (!eof());
+}
+
 void UnwrappedLineParser::parseCSharpAttribute() {
   int UnpairedSquareBrackets = 1;
   do {
@@ -1344,6 +1366,12 @@
   parseTryCatch();
   return;
 case tok::identifier: {
+  if (Style.isCSharp() && FormatTok->is(Keywords.kw_where) &&
+  Line->MustBeDeclaration) {
+addUnwrappedLine();
+parseCSharpGenericTypeConstraint(/*ConsumeBrace=*/false);
+break;
+  }
   if (FormatTok->is(TT_MacroBlockEnd)) {
 addUnwrappedLine();
 return;
@@ -2283,6 +2311,10 @@
 continue;
   }
 }
+if (Style.isCSharp() && FormatTok->is(Keywords.kw_where)) {
+  addUnwrappedLine();
+  parseCSharpGenericTypeConstraint();
+}
 bool IsNonMacroIdentifier =
 FormatTok->is(tok::identifier) &&
 FormatTok->TokenText != FormatTok->TokenText.upper();
Index: clang/lib/Format/UnwrappedLineFormatter.cpp
===
--- clang/lib/Format/UnwrappedLineFormatter.cpp
+++ clang/lib/Format/UnwrappedLineFormatter.cpp
@@ -64,6 +64,8 @@
 }
 if (static_cast(Indent) + Offset >= 0)
   Indent += Offset;
+if (Line.First->is(TT_CSharpGenericTypeConstraint))
+  Indent = Line.Level * Style.IndentWidth + Style.ContinuationIndentWidth;
   }
 
   /// Update the indent state given that \p Line indent should be
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -1047,6 +1047,11 @@
Keywords.kw___ha

[PATCH] D75579: Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime-registration

2020-03-18 Thread Brian Gesiak via Phabricator via cfe-commits

modocache added a comment.

Awesome, thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75579



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

[PATCH] D76346: [Syntax] Build template declaration nodes

2020-03-18 Thread Marcel Hlopko via Phabricator via cfe-commits

hlopko updated this revision to Diff 251095.
hlopko added a comment.

Clang tidy


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76346

Files:
  clang/include/clang/Tooling/Syntax/Nodes.h
  clang/lib/Tooling/Syntax/BuildTree.cpp
  clang/lib/Tooling/Syntax/Nodes.cpp
  clang/unittests/Tooling/Syntax/TreeTest.cpp

Index: clang/unittests/Tooling/Syntax/TreeTest.cpp
===
--- clang/unittests/Tooling/Syntax/TreeTest.cpp
+++ clang/unittests/Tooling/Syntax/TreeTest.cpp
@@ -678,6 +678,212 @@
   `-;
 )txt"},
   {R"cpp(
+template  struct cls {};
+template  int var = 10;
+template  int fun() {}
+)cpp",
+   R"txt(
+*: TranslationUnit
+|-TemplateDeclaration
+| |-template
+| |-<
+| |-UnknownDeclaration
+| | |-class
+| | `-T
+| |->
+| `-SimpleDeclaration
+|   |-struct
+|   |-cls
+|   |-{
+|   |-}
+|   `-;
+|-TemplateDeclaration
+| |-template
+| |-<
+| |-UnknownDeclaration
+| | |-class
+| | `-T
+| |->
+| `-SimpleDeclaration
+|   |-int
+|   |-SimpleDeclarator
+|   | |-var
+|   | |-=
+|   | `-UnknownExpression
+|   |   `-10
+|   `-;
+`-TemplateDeclaration
+  |-template
+  |-<
+  |-UnknownDeclaration
+  | |-class
+  | `-T
+  |->
+  `-SimpleDeclaration
+|-int
+|-SimpleDeclarator
+| |-fun
+| `-ParametersAndQualifiers
+|   |-(
+|   `-)
+`-CompoundStatement
+  |-{
+  `-}
+)txt"},
+  {R"cpp(
+template 
+struct X {
+  template 
+  U foo();
+};
+)cpp",
+   R"txt(
+*: TranslationUnit
+`-TemplateDeclaration
+  |-template
+  |-<
+  |-UnknownDeclaration
+  | |-class
+  | `-T
+  |->
+  `-SimpleDeclaration
+|-struct
+|-X
+|-{
+|-TemplateDeclaration
+| |-template
+| |-<
+| |-UnknownDeclaration
+| | |-class
+| | `-U
+| |->
+| `-SimpleDeclaration
+|   |-U
+|   |-SimpleDeclarator
+|   | |-foo
+|   | `-ParametersAndQualifiers
+|   |   |-(
+|   |   `-)
+|   `-;
+|-}
+`-;
+)txt"},
+  {R"cpp(
+template  struct X {};
+template  struct X {};
+template <> struct X {};
+
+template struct X;
+extern template struct X;
+)cpp",
+   R"txt(
+*: TranslationUnit
+|-TemplateDeclaration
+| |-template
+| |-<
+| |-UnknownDeclaration
+| | |-class
+| | `-T
+| |->
+| `-SimpleDeclaration
+|   |-struct
+|   |-X
+|   |-{
+|   |-}
+|   `-;
+|-TemplateDeclaration
+| |-template
+| |-<
+| |-UnknownDeclaration
+| | |-class
+| | `-T
+| |->
+| `-SimpleDeclaration
+|   |-struct
+|   |-X
+|   |-<
+|   |-T
+|   |-*
+|   |->
+|   |-{
+|   |-}
+|   `-;
+|-TemplateDeclaration
+| |-template
+| |-<
+| |->
+| `-SimpleDeclaration
+|   |-struct
+|   |-X
+|   |-<
+|   |-int
+|   |->
+|   |-{
+|   |-}
+|   `-;
+|-ExplicitTemplateInstantiation
+| |-template
+| `-SimpleDeclaration
+|   |-struct
+|   |-X
+|   |-<
+|   |-double
+|   |->
+|   `-;
+`-ExplicitTemplateInstantiation
+  |-extern
+  |-template
+  `-SimpleDeclaration
+|-struct
+|-X
+|-<
+|-float
+|->
+`-;
+)txt"},
+  {R"cpp(
+template  struct X { struct Y; };
+template  struct X::Y {};
+)cpp",
+   R"txt(
+*: TranslationUnit
+|-TemplateDeclaration
+| |-template
+| |-<
+| |-UnknownDeclaration
+| | |-class
+| | `-T
+| |->
+| `-SimpleDeclaration
+|   |-struct
+|   |-X
+|   |-{
+|   |-SimpleDeclaration
+|   | |-struct
+|   | |-Y
+|   | `-;
+|   |-}
+|   `-;
+`-TemplateDeclaration
+  |-template
+  |-<
+  |-UnknownDeclaration
+  | |-class
+  | `-T
+  |->
+  `-SimpleDeclaration
+|-struct
+|-X
+|-<
+|-T
+|->
+|-::
+|-Y
+|-{
+|-}
+`-;
+   )txt"},
+  {R"cpp(
 namespace ns {}
 using namespace ::ns;
 )cpp",
@@ -726,7 +932,7 @@
 )cpp",
R"txt(
 *: TranslationUnit
-`-UnknownDeclaration
+`-TemplateDeclaration
   |-template
   |-<
   |-UnknownDeclaration
Index: clang/lib/Tooling/Syntax/Nodes.cpp
===
--- clang/lib/Tooling/Syntax/Nodes.cpp
+++ clang/lib/Tooling/Syntax/Nodes.cpp
@@ -58,6 +58,10 @@
 return OS << "LinkageSpecificationDeclaration";
   case NodeKind::SimpleDeclaration:
 return OS << "SimpleDeclaration";
+  case NodeKind::TemplateDeclaration:
+return OS << "TemplateDeclaration";
+  case NodeKind::ExplicitTemplateInstantiation:
+return OS << "ExplicitTemplateInstantiation";
   case NodeKind::NamespaceDefinition:
 return OS << "NamespaceDefinition";
   case NodeKind::NamespaceAliasDefinition:
@@ -118,6 +122,12 @@
 return OS << "StaticAssertDeclaration_message";
   case syntax::NodeRole::SimpleDeclaration_declarator:
 return OS << "SimpleDeclaration_declarator";
+  case syntax::NodeRole::TemplateDeclaration_declaration:
+return OS << "TemplateDeclaration_declaration";
+  case syntax::NodeRole::ExplicitTemplateInstantiation_externKeyword:
+return OS << "ExplicitTemplateInstantiation_externKeyword";
+  case syntax::NodeRole::ExplicitTemplateInstantiation_decla

[PATCH] D75470: [SVE] Auto-generate builtins and header for svld1.

2020-03-18 Thread Nico Weber via Phabricator via cfe-commits

thakis added inline comments.



Comment at: clang/utils/TableGen/TableGen.cpp:196
+clEnumValN(GenArmSveCodeGenMap, "gen-arm-sve-codegenmap",
+   "Generate arm_sve_codegenmap.inc for clang"),
 clEnumValN(GenArmMveHeader, "gen-arm-mve-header",

sdesmalen wrote:
> thakis wrote:
> > Any reason these aren't called `-gen-arm-sve-builtin-def` and 
> > `-gen-arm-sve-builtin-codegen` for consistency with CDE and MVE?
> Not really, I can change that.
Looks like you renamed the files to be consistent (thanks!), but not the flag 
names. Can you make those consistent too?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75470



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

[PATCH] D76366: [Syntax] Split syntax tests

2020-03-18 Thread Dmitri Gribenko via Phabricator via cfe-commits

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



Comment at: clang/unittests/Tooling/Syntax/TreeTest.cpp:642
+
+TEST_F(SyntaxTreeTest, UsingNamespaces) {
+  expectTreeDumpEqual(

"using directive"



Comment at: clang/unittests/Tooling/Syntax/TreeTest.cpp:664
+
+TEST_F(SyntaxTreeTest, UsingNamespaces2) {
+  expectTreeDumpEqual(

The construct in this test is called a "using declaration".



Comment at: clang/unittests/Tooling/Syntax/TreeTest.cpp:1419
+
+TEST_F(SyntaxTreeTest, ExceptionSPecification) {
+  expectTreeDumpEqual(

SP -> Sp



Comment at: clang/unittests/Tooling/Syntax/TreeTest.cpp:1648
+
+TEST_F(SyntaxTreeTest, Complex1) {
+  expectTreeDumpEqual(

"Complex declarator"?



Comment at: clang/unittests/Tooling/Syntax/TreeTest.cpp:1684
+
+TEST_F(SyntaxTreeTest, Complex2) {
+  expectTreeDumpEqual(

"Complex declarator"?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76366



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

[PATCH] D76346: [Syntax] Build template declaration nodes

2020-03-18 Thread Dmitri Gribenko via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGdd12826808f9: [Syntax] Build template declaration nodes 
(authored by hlopko, committed by gribozavr).

Changed prior to commit:
  https://reviews.llvm.org/D76346?vs=251095&id=251100#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76346

Files:
  clang/include/clang/Tooling/Syntax/Nodes.h
  clang/lib/Tooling/Syntax/BuildTree.cpp
  clang/lib/Tooling/Syntax/Nodes.cpp
  clang/unittests/Tooling/Syntax/TreeTest.cpp

Index: clang/unittests/Tooling/Syntax/TreeTest.cpp
===
--- clang/unittests/Tooling/Syntax/TreeTest.cpp
+++ clang/unittests/Tooling/Syntax/TreeTest.cpp
@@ -678,6 +678,212 @@
   `-;
 )txt"},
   {R"cpp(
+template  struct cls {};
+template  int var = 10;
+template  int fun() {}
+)cpp",
+   R"txt(
+*: TranslationUnit
+|-TemplateDeclaration
+| |-template
+| |-<
+| |-UnknownDeclaration
+| | |-class
+| | `-T
+| |->
+| `-SimpleDeclaration
+|   |-struct
+|   |-cls
+|   |-{
+|   |-}
+|   `-;
+|-TemplateDeclaration
+| |-template
+| |-<
+| |-UnknownDeclaration
+| | |-class
+| | `-T
+| |->
+| `-SimpleDeclaration
+|   |-int
+|   |-SimpleDeclarator
+|   | |-var
+|   | |-=
+|   | `-UnknownExpression
+|   |   `-10
+|   `-;
+`-TemplateDeclaration
+  |-template
+  |-<
+  |-UnknownDeclaration
+  | |-class
+  | `-T
+  |->
+  `-SimpleDeclaration
+|-int
+|-SimpleDeclarator
+| |-fun
+| `-ParametersAndQualifiers
+|   |-(
+|   `-)
+`-CompoundStatement
+  |-{
+  `-}
+)txt"},
+  {R"cpp(
+template 
+struct X {
+  template 
+  U foo();
+};
+)cpp",
+   R"txt(
+*: TranslationUnit
+`-TemplateDeclaration
+  |-template
+  |-<
+  |-UnknownDeclaration
+  | |-class
+  | `-T
+  |->
+  `-SimpleDeclaration
+|-struct
+|-X
+|-{
+|-TemplateDeclaration
+| |-template
+| |-<
+| |-UnknownDeclaration
+| | |-class
+| | `-U
+| |->
+| `-SimpleDeclaration
+|   |-U
+|   |-SimpleDeclarator
+|   | |-foo
+|   | `-ParametersAndQualifiers
+|   |   |-(
+|   |   `-)
+|   `-;
+|-}
+`-;
+)txt"},
+  {R"cpp(
+template  struct X {};
+template  struct X {};
+template <> struct X {};
+
+template struct X;
+extern template struct X;
+)cpp",
+   R"txt(
+*: TranslationUnit
+|-TemplateDeclaration
+| |-template
+| |-<
+| |-UnknownDeclaration
+| | |-class
+| | `-T
+| |->
+| `-SimpleDeclaration
+|   |-struct
+|   |-X
+|   |-{
+|   |-}
+|   `-;
+|-TemplateDeclaration
+| |-template
+| |-<
+| |-UnknownDeclaration
+| | |-class
+| | `-T
+| |->
+| `-SimpleDeclaration
+|   |-struct
+|   |-X
+|   |-<
+|   |-T
+|   |-*
+|   |->
+|   |-{
+|   |-}
+|   `-;
+|-TemplateDeclaration
+| |-template
+| |-<
+| |->
+| `-SimpleDeclaration
+|   |-struct
+|   |-X
+|   |-<
+|   |-int
+|   |->
+|   |-{
+|   |-}
+|   `-;
+|-ExplicitTemplateInstantiation
+| |-template
+| `-SimpleDeclaration
+|   |-struct
+|   |-X
+|   |-<
+|   |-double
+|   |->
+|   `-;
+`-ExplicitTemplateInstantiation
+  |-extern
+  |-template
+  `-SimpleDeclaration
+|-struct
+|-X
+|-<
+|-float
+|->
+`-;
+)txt"},
+  {R"cpp(
+template  struct X { struct Y; };
+template  struct X::Y {};
+)cpp",
+   R"txt(
+*: TranslationUnit
+|-TemplateDeclaration
+| |-template
+| |-<
+| |-UnknownDeclaration
+| | |-class
+| | `-T
+| |->
+| `-SimpleDeclaration
+|   |-struct
+|   |-X
+|   |-{
+|   |-SimpleDeclaration
+|   | |-struct
+|   | |-Y
+|   | `-;
+|   |-}
+|   `-;
+`-TemplateDeclaration
+  |-template
+  |-<
+  |-UnknownDeclaration
+  | |-class
+  | `-T
+  |->
+  `-SimpleDeclaration
+|-struct
+|-X
+|-<
+|-T
+|->
+|-::
+|-Y
+|-{
+|-}
+`-;
+   )txt"},
+  {R"cpp(
 namespace ns {}
 using namespace ::ns;
 )cpp",
@@ -726,7 +932,7 @@
 )cpp",
R"txt(
 *: TranslationUnit
-`-UnknownDeclaration
+`-TemplateDeclaration
   |-template
   |-<
   |-UnknownDeclaration
Index: clang/lib/Tooling/Syntax/Nodes.cpp
===
--- clang/lib/Tooling/Syntax/Nodes.cpp
+++ clang/lib/Tooling/Syntax/Nodes.cpp
@@ -58,6 +58,10 @@
 return OS << "LinkageSpecificationDeclaration";
   case NodeKind::SimpleDeclaration:
 return OS << "SimpleDeclaration";
+  case NodeKind::TemplateDeclaration:
+return OS << "TemplateDeclaration";
+  case NodeKind::ExplicitTemplateInstantiation:
+return OS << "ExplicitTemplateInstantiation";
   case NodeKind::NamespaceDefinition:
 return OS << "NamespaceDefinition";
   case NodeKind::NamespaceAliasDefinition:
@@ -118,6 +122,12 @@
 return OS << "StaticAssertDeclaration_message";
   case syntax::NodeRole::SimpleDeclaration_declarator:
 return OS << "SimpleDeclaration_declarator";
+  case syntax::NodeRole::TemplateDeclaration_declaration:
+return OS << "TemplateDeclaration_declaration";

[PATCH] D76366: [Syntax] Split syntax tests

2020-03-18 Thread Marcel Hlopko via Phabricator via cfe-commits

hlopko updated this revision to Diff 251102.
hlopko marked 5 inline comments as done.
hlopko added a comment.

Renaming some tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76366

Files:
  clang/unittests/Tooling/Syntax/TreeTest.cpp

Index: clang/unittests/Tooling/Syntax/TreeTest.cpp
===
--- clang/unittests/Tooling/Syntax/TreeTest.cpp
+++ clang/unittests/Tooling/Syntax/TreeTest.cpp
@@ -120,6 +120,16 @@
 return Root;
   }
 
+  void expectTreeDumpEqual(StringRef code, StringRef tree) {
+SCOPED_TRACE(code);
+
+auto *Root = buildTree(code);
+std::string Expected = tree.trim().str();
+std::string Actual =
+std::string(llvm::StringRef(Root->dump(*Arena)).trim());
+EXPECT_EQ(Expected, Actual) << "the resulting dump is:\n" << Actual;
+  }
+
   // Adds a file to the test VFS.
   void addFile(llvm::StringRef Path, llvm::StringRef Contents) {
 if (!FS->addFile(Path, time_t(),
@@ -163,14 +173,13 @@
   std::unique_ptr Arena;
 };
 
-TEST_F(SyntaxTreeTest, Basic) {
-  std::pair Cases[] = {
-  {
-  R"cpp(
+TEST_F(SyntaxTreeTest, Simple) {
+  expectTreeDumpEqual(
+  R"cpp(
 int main() {}
 void foo() {}
 )cpp",
-  R"txt(
+  R"txt(
 *: TranslationUnit
 |-SimpleDeclaration
 | |-int
@@ -192,16 +201,18 @@
   `-CompoundStatement
 |-{
 `-}
-)txt"},
-  // if.
-  {
-  R"cpp(
+)txt");
+}
+
+TEST_F(SyntaxTreeTest, If) {
+  expectTreeDumpEqual(
+  R"cpp(
 int main() {
   if (true) {}
   if (true) {} else if (false) {}
 }
 )cpp",
-  R"txt(
+  R"txt(
 *: TranslationUnit
 `-SimpleDeclaration
   |-int
@@ -241,14 +252,17 @@
 | |-{
 | `-}
 `-}
-)txt"},
-  // for.
-  {R"cpp(
+)txt");
+}
+
+TEST_F(SyntaxTreeTest, For) {
+  expectTreeDumpEqual(
+  R"cpp(
 void test() {
   for (;;)  {}
 }
 )cpp",
-   R"txt(
+  R"txt(
 *: TranslationUnit
 `-SimpleDeclaration
   |-void
@@ -269,10 +283,18 @@
 |   |-{
 |   `-}
 `-}
-)txt"},
-  // declaration statement.
-  {"void test() { int a = 10; }",
-   R"txt(
+)txt");
+}
+
+TEST_F(SyntaxTreeTest, RangeBasedFor) {
+  expectTreeDumpEqual(
+  R"cpp(
+void test() {
+  int a[3];
+  for (int x : a) ;
+}
+  )cpp",
+  R"txt(
 *: TranslationUnit
 `-SimpleDeclaration
   |-void
@@ -288,13 +310,32 @@
 | | |-int
 | | `-SimpleDeclarator
 | |   |-a
-| |   |-=
-| |   `-UnknownExpression
-| | `-10
+| |   `-ArraySubscript
+| | |-[
+| | |-UnknownExpression
+| | | `-3
+| | `-]
 | `-;
+|-RangeBasedForStatement
+| |-for
+| |-(
+| |-SimpleDeclaration
+| | |-int
+| | |-SimpleDeclarator
+| | | `-x
+| | `-:
+| |-UnknownExpression
+| | `-a
+| |-)
+| `-EmptyStatement
+|   `-;
 `-}
-)txt"},
-  {"void test() { ; }", R"txt(
+   )txt");
+}
+
+TEST_F(SyntaxTreeTest, DeclarationStatement) {
+  expectTreeDumpEqual("void test() { int a = 10; }",
+  R"txt(
 *: TranslationUnit
 `-SimpleDeclaration
   |-void
@@ -305,12 +346,22 @@
   |   `-)
   `-CompoundStatement
 |-{
-|-EmptyStatement
+|-DeclarationStatement
+| |-SimpleDeclaration
+| | |-int
+| | `-SimpleDeclarator
+| |   |-a
+| |   |-=
+| |   `-UnknownExpression
+| | `-10
 | `-;
 `-}
-)txt"},
-  // switch, case and default.
-  {R"cpp(
+)txt");
+}
+
+TEST_F(SyntaxTreeTest, Switch) {
+  expectTreeDumpEqual(
+  R"cpp(
 void test() {
   switch (true) {
 case 0:
@@ -318,7 +369,7 @@
   }
 }
 )cpp",
-   R"txt(
+  R"txt(
 *: TranslationUnit
 `-SimpleDeclaration
   |-void
@@ -349,14 +400,17 @@
 |   | `-;
 |   `-}
 `-}
-)txt"},
-  // while.
-  {R"cpp(
+)txt");
+}
+
+TEST_F(SyntaxTreeTest, While) {
+  expectTreeDumpEqual(
+  R"cpp(
 void test() {
   while (true) { continue; break; }
 }
 )cpp",
-   R"txt(
+  R"txt(
 *: TranslationUnit
 `-SimpleDeclaration
   |-void
@@ -383,77 +437,15 @@
 |   | `-;
 |   `-}
 `-}
-)txt"},
-  // return.
-  {R"cpp(
-int test() { return 1; }
-  )cpp",
-   R"txt(
-*: TranslationUnit
-`-SimpleDeclaration
-  |-int
-  |-SimpleDeclarator
-  | |-test
-  | `-ParametersAndQualifiers
-  |   |-(
-  |   `-)
-  `-CompoundStatement
-|-{
-|-ReturnStatement
-| |-return
-| |-UnknownExpression
-| | `-1
-| `-;
-`-}
-)txt"},
-  // Range-based for.
-  {R"cpp(
-void test() {
-  int a[3];
-  for (int x : a) ;
+)txt");
 }
-  )cpp",
-   R"txt(
-*: TranslationUnit
-`-SimpleDeclaration
-  |-void
-  |-SimpleDeclarator
-  | |-test
-  | `-ParametersAndQualifiers
-  |   |-(
-  |   `-)
-  `-CompoundStatement
-|-{
-|-DeclarationStatement
-| |-SimpleDeclaration
-| | |-int
-| | `-SimpleDecla

[PATCH] D76366: [Syntax] Split syntax tests

2020-03-18 Thread Marcel Hlopko via Phabricator via cfe-commits

hlopko added a comment.

Addressed comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76366



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

[PATCH] D76365: [cuda][hip] Add CUDA builtin surface/texture reference support.

2020-03-18 Thread Michael Liao via Phabricator via cfe-commits

hliao updated this revision to Diff 251101.
hliao added a comment.

Reformatting with clang-format.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76365

Files:
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/lib/AST/Type.cpp
  clang/lib/CodeGen/CGCUDANV.cpp
  clang/lib/CodeGen/CGCUDARuntime.h
  clang/lib/CodeGen/CGExprAgg.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenTypes.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/CodeGen/TargetInfo.h
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGenCUDA/surface.cu
  clang/test/CodeGenCUDA/texture.cu
  clang/test/SemaCUDA/attr-declspec.cu
  clang/test/SemaCUDA/attributes-on-non-cuda.cu
  llvm/include/llvm/IR/Operator.h

Index: llvm/include/llvm/IR/Operator.h
===
--- llvm/include/llvm/IR/Operator.h
+++ llvm/include/llvm/IR/Operator.h
@@ -599,6 +599,25 @@
   }
 };
 
+class AddrSpaceCastOperator
+: public ConcreteOperator {
+  friend class AddrSpaceCastInst;
+  friend class ConstantExpr;
+
+public:
+  Value *getPointerOperand() { return getOperand(0); }
+
+  const Value *getPointerOperand() const { return getOperand(0); }
+
+  unsigned getSrcAddressSpace() const {
+return getPointerOperand()->getType()->getPointerAddressSpace();
+  }
+
+  unsigned getDestAddressSpace() const {
+return getType()->getPointerAddressSpace();
+  }
+};
+
 } // end namespace llvm
 
 #endif // LLVM_IR_OPERATOR_H
Index: clang/test/SemaCUDA/attributes-on-non-cuda.cu
===
--- clang/test/SemaCUDA/attributes-on-non-cuda.cu
+++ clang/test/SemaCUDA/attributes-on-non-cuda.cu
@@ -7,16 +7,21 @@
 // RUN: %clang_cc1 -DEXPECT_WARNINGS -fsyntax-only -verify -x c %s
 
 #if defined(EXPECT_WARNINGS)
-// expected-warning@+12 {{'device' attribute ignored}}
-// expected-warning@+12 {{'global' attribute ignored}}
-// expected-warning@+12 {{'constant' attribute ignored}}
-// expected-warning@+12 {{'shared' attribute ignored}}
-// expected-warning@+12 {{'host' attribute ignored}}
+// expected-warning@+17 {{'device' attribute ignored}}
+// expected-warning@+17 {{'global' attribute ignored}}
+// expected-warning@+17 {{'constant' attribute ignored}}
+// expected-warning@+17 {{'shared' attribute ignored}}
+// expected-warning@+17 {{'host' attribute ignored}}
+// expected-warning@+23 {{'device_builtin_surface_type' attribute ignored}}
+// expected-warning@+23 {{'device_builtin_texture_type' attribute ignored}}
+// expected-warning@+23 {{'device_builtin_surface_type' attribute ignored}}
+// expected-warning@+23 {{'device_builtin_texture_type' attribute ignored}}
 //
 // NOTE: IgnoredAttr in clang which is used for the rest of
 // attributes ignores LangOpts, so there are no warnings.
 #else
-// expected-no-diagnostics
+// expected-warning@+15 {{'device_builtin_surface_type' attribute only applies to types}}
+// expected-warning@+15 {{'device_builtin_texture_type' attribute only applies to types}}
 #endif
 
 __attribute__((device)) void f_device();
@@ -32,3 +37,5 @@
 __attribute__((nv_weak)) void f_nv_weak();
 __attribute__((device_builtin_surface_type)) unsigned long long surface_var;
 __attribute__((device_builtin_texture_type)) unsigned long long texture_var;
+struct __attribute__((device_builtin_surface_type)) surf_ref {};
+struct __attribute__((device_builtin_texture_type)) tex_ref {};
Index: clang/test/SemaCUDA/attr-declspec.cu
===
--- clang/test/SemaCUDA/attr-declspec.cu
+++ clang/test/SemaCUDA/attr-declspec.cu
@@ -6,16 +6,21 @@
 // RUN: %clang_cc1 -DEXPECT_WARNINGS -fms-extensions -fsyntax-only -verify -x c %s
 
 #if defined(EXPECT_WARNINGS)
-// expected-warning@+12 {{'__device__' attribute ignored}}
-// expected-warning@+12 {{'__global__' attribute ignored}}
-// expected-warning@+12 {{'__constant__' attribute ignored}}
-// expected-warning@+12 {{'__shared__' attribute ignored}}
-// expected-warning@+12 {{'__host__' attribute ignored}}
+// expected-warning@+17 {{'__device__' attribute ignored}}
+// expected-warning@+17 {{'__global__' attribute ignored}}
+// expected-warning@+17 {{'__constant__' attribute ignored}}
+// expected-warning@+17 {{'__shared__' attribute ignored}}
+// expected-warning@+17 {{'__host__' attribute ignored}}
+// expected-warning@+22 {{'__device_builtin_surface_type__' attribute ignored}}
+// expected-warning@+22 {{'__device_builtin_texture_type__' attribute ignored}}
+// expected-warning@+22 {{'__device_builtin_surface_type__' attribute ignored}}
+// expected-warning@+22 {{'__device_builtin_texture_type__' attribute ignored}}
 //
 // (Currently we don't for the other attributes. They are implemented with
 // IgnoredAttr, which is ignored irrespective of any LangOpts.)
 #else
-// expected-no-diagnostics
+// expec

[PATCH] D74918: Add method to TargetInfo to get CPU cache line size

2020-03-18 Thread Roman Lebedev via Phabricator via cfe-commits

lebedev.ri added a comment.

This seems misplaced - why is this in clang and not LLVM?




Comment at: clang/include/clang/Basic/TargetInfo.h:1192
+  // Get the cache line size of a given cpu. This method switches over
+  // the given cpu and returns `0` if the CPU is not found.
+  virtual Optional getCPUCacheLineSize() const { return None; }

Comment is no longer valid - returns `None` instead.
Also, might it be worth explicitly calling out that there is zero guarantees of 
stability of the returned values?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74918



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

[PATCH] D76346: [Syntax] Build template declaration nodes

2020-03-18 Thread Nico Weber via Phabricator via cfe-commits

thakis added a comment.

Breaks tests on Windows: http://45.33.8.238/win/10716/step_7.txt

Please take a look and revert if it takes a while to fix.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76346



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

[PATCH] D76287: [analysis][analyzer] Introduce the skeleton of a reaching definitions calculator

2020-03-18 Thread Kristóf Umann via Phabricator via cfe-commits

Szelethus marked 9 inline comments as done.
Szelethus added a comment.

In D76287#1927340 , @xazax.hun wrote:

> I think it is very crucial to make the intentions clear, how do you define 
> `definition` and `variable`?
>  Other than assignments we might include pre/postfix increment/decrement, 
> non-const by-ref function arguments and so on as `definitions`.
>  Also, it would be great to have some proposal upfront how indirect writes 
> should behave.

You're totally right. The thing that I wanted to achieve, partly, is to make 
the implementation flexible for things I may have forgotten, or will need to 
add for future standards/languages. As you can see from D64991 
, I did make a lot more progress than what is 
shown here, so I'll explain some of my long-term plans based on the experience 
I gathered:

> I think it is very crucial to make the intentions clear, how do you define 
> [...] `variable`?

//Variable// could be practically anything that can be written, but due to the 
nature of what we can work this, we have to make severe restrictions.

- We don't really have a good points-to-analysis. This discards pointees of any 
kind pretty much immediately. I don't have long term plans to add support for 
them.
- Arrays are strongly related, and while there are studies on indexed variables 
(the last paper in my summary talks about such an approach), I think the way 
C++ complicates things on an uncomfortable level. I do have confidence however 
adding support for it in the future for the cases where the index is known 
compile time (possibly with the help of the RD algorithm itself) should be 
doable by modifying the `Variable` class.

So this leaves the most obvious: `VarDecl`s, and for record objects a 
`(VarDecl, FieldChain)` pair (for `s.x.a`, this would be `(s, [x,a])`). Setting 
the `VarDecl` part of the pair to `nullptr` could refer to the implicit this 
during the analysis of a C++ methods.

The plan was to represent each field with a separate `Variable` object, so for 
this code

  struct A {
struct B {
  int x, y;
};
B b;
  };

  void foo() { A a };

The following list of `Variable` objects would be created:

  a
  a.b
  a.b.x
  a.b.y

The reason behind this seemingly wasteful storage is that the eventual set 
operations would be difficult if not impossible to implement, if a single 
`Variable` object were to hold the information about its fields. Mind that each 
of them could have a totally different definition associated with it. I hope 
that by emloying immutable data structures these wouldn't be terribly expensive 
memory-wise.

> I think it is very crucial to make the intentions clear, how do you define 
> `definition`[...]?
>  Other than assignments we might include pre/postfix increment/decrement, 
> non-const by-ref function arguments and so on as `definitions`.

//Definition// is a statement, more specifically a `CFGStmt` (an element of a 
`CFGBlock`), that either writes, or could potentially write a variable. The 
proposed definition finding stage should be very flexible for future additions.

> Also, it would be great to have some proposal upfront how indirect writes 
> should behave.

I wrote a mail about this during my GSoC project: 
http://lists.llvm.org/pipermail/cfe-dev/2019-July/062975.html.

> Basically, this algorithm is not very useful on its own, but it can be used 
> as a building block for other kind of analyses. So it would make sense to try 
> to look for potential users and use cases and see if they have the same 
> requirements or do you need to introduce configurations?

The Static Analyzer would be the number one user of the RD algorithm, as 
described in the summary, so I guess that you referred to the users of GEN/KILL 
sets? What do you mean under configurations?

> Trying to rewrite some existing algorithms in terms of these sets and see if 
> the tests pass might be a good experiment if it is not too much work. (In 
> case we can validate the performance we could even replace the original 
> implementations if this makes things easier.)

I'm not too sure how much work it would take (I suspect an unreasonable 
quantity, but I might be wrong), so I'll take a look. This is a great idea to 
gain a lot more knowledge about this topic, even if it eventually fails.

> I think having a reaching definition set per basic block makes perfect sense, 
> as it should be relatively easy to calculate the reaching definition of an 
> instruction given the set and the basic block. So maybe it is more efficient 
> to calculate the reaching definition sets on demand for instruction rather 
> than computing it for every single instruction.
> 
> Regarding ASTMatchers, I think they might be great for now for prototyping 
> but I think once you want to make this more robust covering every corner case 
> in the matcher expression will be at least as hard as writing a visitor if 
> not harder

[PATCH] D76359: [ARM,MVE] Add intrinsics for the VQDMLAD family.

2020-03-18 Thread Mikhail Maltsev via Phabricator via cfe-commits

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

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76359



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

[PATCH] D76291: [Support] Fix formatted_raw_ostream for UTF-8

2020-03-18 Thread Oliver Stannard (Linaro) via Phabricator via cfe-commits

ostannard updated this revision to Diff 251105.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76291

Files:
  clang/test/Analysis/checker-plugins.c
  llvm/include/llvm/Support/FormattedStream.h
  llvm/lib/Support/FormattedStream.cpp
  llvm/test/MC/ARM/lsl-zero.s
  llvm/unittests/Support/formatted_raw_ostream_test.cpp

Index: llvm/unittests/Support/formatted_raw_ostream_test.cpp
===
--- llvm/unittests/Support/formatted_raw_ostream_test.cpp
+++ llvm/unittests/Support/formatted_raw_ostream_test.cpp
@@ -29,4 +29,143 @@
   }
 }
 
+TEST(formatted_raw_ostreamTest, Test_LineColumn) {
+  // Test tracking of line and column numbers in a stream.
+  SmallString<128> A;
+  raw_svector_ostream B(A);
+  formatted_raw_ostream C(B);
+
+  EXPECT_EQ(0U, C.getLine());
+  EXPECT_EQ(0U, C.getColumn());
+
+  C << "a";
+  EXPECT_EQ(0U, C.getLine());
+  EXPECT_EQ(1U, C.getColumn());
+
+  C << "bcdef";
+  EXPECT_EQ(0U, C.getLine());
+  EXPECT_EQ(6U, C.getColumn());
+
+  // '\n' increments line number, sets column to zero.
+  C << "\n";
+  EXPECT_EQ(1U, C.getLine());
+  EXPECT_EQ(0U, C.getColumn());
+
+  // '\r sets column to zero without changing line number
+  C << "foo\r";
+  EXPECT_EQ(1U, C.getLine());
+  EXPECT_EQ(0U, C.getColumn());
+
+  // '\t' advances column to the next multiple of 8.
+  // FIXME: If the column number is already a multiple of 8 this will do
+  // nothing, is this behaviour correct?
+  C << "1\t";
+  EXPECT_EQ(8U, C.getColumn());
+  C << "\t";
+  EXPECT_EQ(8U, C.getColumn());
+  C << "1234567\t";
+  EXPECT_EQ(16U, C.getColumn());
+  EXPECT_EQ(1U, C.getLine());
+}
+
+TEST(formatted_raw_ostreamTest, Test_Flush) {
+  // Flushing the buffer causes the characters in the buffer to be scanned
+  // before the buffer is emptied, so line and column numbers will still be
+  // tracked properly.
+  SmallString<128> A;
+  raw_svector_ostream B(A);
+  B.SetBufferSize(32);
+  formatted_raw_ostream C(B);
+
+  C << "\nabc";
+  EXPECT_EQ(4U, C.GetNumBytesInBuffer());
+  C.flush();
+  EXPECT_EQ(1U, C.getLine());
+  EXPECT_EQ(3U, C.getColumn());
+  EXPECT_EQ(0U, C.GetNumBytesInBuffer());
+}
+
+TEST(formatted_raw_ostreamTest, Test_UTF8) {
+  SmallString<128> A;
+  raw_svector_ostream B(A);
+  B.SetBufferSize(32);
+  formatted_raw_ostream C(B);
+
+  // U+00A0 Non-breaking space: encoded as two bytes, but only one column wide.
+  C << u8"\u00a0";
+  EXPECT_EQ(0U, C.getLine());
+  EXPECT_EQ(1U, C.getColumn());
+  EXPECT_EQ(2U, C.GetNumBytesInBuffer());
+
+  // U+2468 CIRCLED DIGIT NINE: encoded as three bytes, but only one column
+  // wide.
+  C << u8"\u2468";
+  EXPECT_EQ(0U, C.getLine());
+  EXPECT_EQ(2U, C.getColumn());
+  EXPECT_EQ(5U, C.GetNumBytesInBuffer());
+
+  // U+0001 LINEAR B SYLLABLE B008 A: encoded as four bytes, but only one
+  // column wide.
+  C << u8"\U0001";
+  EXPECT_EQ(0U, C.getLine());
+  EXPECT_EQ(3U, C.getColumn());
+  EXPECT_EQ(9U, C.GetNumBytesInBuffer());
+
+  // U+55B5, CJK character, encodes as three bytes, takes up two columns.
+  C << u8"\u55b5";
+  EXPECT_EQ(0U, C.getLine());
+  EXPECT_EQ(5U, C.getColumn());
+  EXPECT_EQ(12U, C.GetNumBytesInBuffer());
+
+  // U+200B, zero-width space, encoded as three bytes but has no effect on the
+  // column or line number.
+  C << u8"\u200b";
+  EXPECT_EQ(0U, C.getLine());
+  EXPECT_EQ(5U, C.getColumn());
+  EXPECT_EQ(15U, C.GetNumBytesInBuffer());
+}
+
+TEST(formatted_raw_ostreamTest, Test_UTF8Buffered) {
+  SmallString<128> A;
+  raw_svector_ostream B(A);
+  B.SetBufferSize(4);
+  formatted_raw_ostream C(B);
+
+  // This character encodes as three bytes, so will cause the buffer to be
+  // flushed after the first byte (4 byte buffer, 3 bytes already written). We
+  // need to save the first part of the UTF-8 encoding until after the buffer is
+  // cleared and the remaining two bytes are written, at which point we can
+  // check the display width. In this case the display width is 1, so we end at
+  // column 4, with 6 bytes written into total, 2 of which are in the buffer.
+  C << u8"123\u2468";
+  EXPECT_EQ(0U, C.getLine());
+  EXPECT_EQ(4U, C.getColumn());
+  EXPECT_EQ(2U, C.GetNumBytesInBuffer());
+  C.flush();
+  EXPECT_EQ(6U, A.size());
+
+  // Same as above, but with a CJK character which displays as two columns.
+  C << u8"123\u55b5";
+  EXPECT_EQ(0U, C.getLine());
+  EXPECT_EQ(9U, C.getColumn());
+  EXPECT_EQ(2U, C.GetNumBytesInBuffer());
+  C.flush();
+  EXPECT_EQ(12U, A.size());
+}
+
+TEST(formatted_raw_ostreamTest, Test_UTF8TinyBuffer) {
+  SmallString<128> A;
+  raw_svector_ostream B(A);
+  B.SetBufferSize(1);
+  formatted_raw_ostream C(B);
+
+  // The stream has a one-byte buffer, so it gets flushed multiple times while
+  // printing a single Unicode character.
+  C << u8"\u2468";
+  EXPECT_EQ(0U, C.getLine());
+  EXPECT_EQ(1U, C.getColumn());
+  EXPECT_EQ(0U, C.GetNumBytesInBuffer());

[PATCH] D65591: [AST] Add a flag indicating if any subexpression had errors

2020-03-18 Thread Sam McCall via Phabricator via cfe-commits

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



Comment at: clang/lib/AST/ComputeDependence.cpp:174
 ExprDependence clang::computeDependence(NoInitExpr *E) {
   return toExprDependence(E->getType()->getDependence()) &
  ExprDependence::Instantiation;

hokein wrote:
> sammccall wrote:
> > I'm not terribly sure of the implications of not propagating the error bit 
> > here. I tend to think that "contains errors" most closely follows 
> > instantiation-dependence (i.e. it's fairly strict/lexical), so I'd consider 
> > propagating it here.
> > 
> > BTW, DesignatedInitUpdateExpr seems to have totally broken dependence 
> > computations - it's always non-dependent! (Not introduced by this 
> > refactoring, I think). Any idea what's up there?
> you mean `DesignatedInitExpr`? I didn't see any problem there, why it is 
> always non-dependent?
no, DesignatedInitUpdateExpr. There's no computeDependence function, it just 
marks itself as non-dependent in the constructor.



Comment at: clang/lib/AST/ComputeDependence.cpp:662
+if (C)
+  D |= C->getDependence() & ExprDependence::Error;
+  }

rather than whitelisting the error bit, blacklist the UnexpandedPack bit?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65591



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

[PATCH] D75682: [Analyzer][StreamChecker] Introduction of stream error handling.

2020-03-18 Thread Kristóf Umann via Phabricator via cfe-commits

Szelethus added a subscriber: steakhal.
Szelethus added a comment.

In D75682#1929093 , @balazske wrote:

> In D75682#1928716 , @Szelethus wrote:
>
> > - For streams where the precise state is unknown (they are not tracked), 
> > start tracking. If we explicitly check whether a state is `foef()`, we can 
> > rightfully assume both of those possibilities.
>
>
> This can follow in a later revision only. The new stream should have every 
> error state possible, so when it is introduced 3 new states are required 
> (with the error types), or an "unknown error" is needed that will be added 
> later.
>
> > - Evalulate a less complicated stream modeling function that sets such 
> > flags, though I suspect the followup patch is supposed to be the one doing 
> > this.
>
> The `fseek` patch can do this.


Very well.

>> - Add debug function similar to `clang_analyzer_express`, like 
>> `clang_analyzer_set_eof(FILE *)`, etc.
> 
> How to add this? Probably it is too much work and I do not like if separate 
> such debug functions are there for "every" checker (or many of).

@steakhal recently made a patch that contained that and not much else: D74131 
. I share you dislike with the debug function, 
but I suspect that it wouldn't be too much work, especially compared to my 
other suggestions that would introduce testability, unless you have some other 
ideas (to which I'd be open to!).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75682



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

[PATCH] D76130: [PPC][AIX] Implement variadic function handling in LowerFormalArguments_AIX

2020-03-18 Thread Zarko Todorovski via Phabricator via cfe-commits

ZarkoCA updated this revision to Diff 25.
ZarkoCA marked an inline comment as done.
ZarkoCA added a comment.

Fixed testcase breakages.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76130

Files:
  llvm/lib/Target/PowerPC/PPCISelLowering.cpp
  llvm/test/CodeGen/PowerPC/aix-cc-abi-va_args-32.ll
  llvm/test/CodeGen/PowerPC/aix-cc-abi-va_args-64.ll

Index: llvm/test/CodeGen/PowerPC/aix-cc-abi-va_args-64.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/aix-cc-abi-va_args-64.ll
@@ -0,0 +1,316 @@
+; RUN: llc -O2 -mtriple powerpc64-ibm-aix-xcoff -stop-after=machine-cp -verify-machineinstrs < %s | \
+; RUN: FileCheck --check-prefixes=CHECK,64BIT %s
+
+; RUN: llc -O2 -verify-machineinstrs -mcpu=pwr4 -mattr=-altivec \
+; RUN:  -mtriple powerpc64-ibm-aix-xcoff < %s | \
+; RUN: FileCheck --check-prefixes=CHECKASM,ASM64PWR4 %s
+
+
+  @a = local_unnamed_addr global i32 1, align 4
+  @b = local_unnamed_addr global i32 2, align 4
+  @c = local_unnamed_addr global i32 3, align 4
+  @d = local_unnamed_addr global i32 4, align 4
+  @e = local_unnamed_addr global i32 5, align 4
+  @f = local_unnamed_addr global i32 6, align 4
+  @g = local_unnamed_addr global i32 7, align 4
+  @h = local_unnamed_addr global i32 8, align 4
+  @i = local_unnamed_addr global i32 9, align 4
+  @j = local_unnamed_addr global i32 10, align 4
+
+define signext i32 @va_arg1(i32 signext %a, ...) local_unnamed_addr {
+entry:
+  %arg = alloca i8*, align 8
+  %0 = bitcast i8** %arg to i8*
+  call void @llvm.lifetime.start.p0i8(i64 8, i8* nonnull %0)
+  call void @llvm.va_start(i8* nonnull %0)
+  %cmp7 = icmp sgt i32 %a, 0
+  br i1 %cmp7, label %for.body.preheader, label %for.end
+
+for.body.preheader:
+  %argp.cur.pre = load i8*, i8** %arg, align 8
+  %1 = add i32 %a, -1
+  %2 = zext i32 %1 to i64
+  %3 = add nuw nsw i64 %2, 1
+  %min.iters.check = icmp ult i32 %1, 8
+  br i1 %min.iters.check, label %for.body.preheader28, label %vector.memcheck
+
+vector.memcheck:
+  %uglygep = getelementptr inbounds i8, i8* %0, i64 1
+  %scevgep = getelementptr i8, i8* %argp.cur.pre, i64 4
+  %4 = shl nuw nsw i64 %2, 3
+  %5 = add nuw nsw i64 %4, 8
+  %scevgep11 = getelementptr i8, i8* %argp.cur.pre, i64 %5
+  %bound0 = icmp ugt i8* %scevgep11, %0
+  %bound1 = icmp ult i8* %scevgep, %uglygep
+  %found.conflict = and i1 %bound0, %bound1
+  br i1 %found.conflict, label %for.body.preheader28, label %vector.ph
+
+vector.ph:
+  %n.mod.vf = and i64 %3, 7
+  %6 = icmp eq i64 %n.mod.vf, 0
+  %7 = select i1 %6, i64 8, i64 %n.mod.vf
+  %n.vec = sub nsw i64 %3, %7
+  %8 = shl nsw i64 %n.vec, 3
+  %ind.end = getelementptr i8, i8* %argp.cur.pre, i64 %8
+  %ind.end13 = trunc i64 %n.vec to i32
+  %next.gep = getelementptr i8, i8* %argp.cur.pre, i64 4
+  %next.gep17 = getelementptr i8, i8* %argp.cur.pre, i64 4
+  %next.gep20 = getelementptr i8, i8* %argp.cur.pre, i64 8
+  br label %vector.body
+
+vector.body:
+  %index = phi i64 [ 0, %vector.ph ], [ %index.next, %vector.body ]
+  %vec.phi = phi <4 x i32> [ , %vector.ph ], [ %19, %vector.body ]
+  %vec.phi21 = phi <4 x i32> [ zeroinitializer, %vector.ph ], [ %20, %vector.body ]
+  %9 = shl i64 %index, 3
+  %10 = shl i64 %index, 3
+  %11 = or i64 %10, 32
+  %12 = shl i64 %index, 3
+  %13 = or i64 %12, 56
+  %14 = getelementptr inbounds i8, i8* %next.gep20, i64 %13
+  %15 = getelementptr inbounds i8, i8* %next.gep, i64 %9
+  %16 = getelementptr inbounds i8, i8* %next.gep17, i64 %11
+  %17 = bitcast i8* %15 to <8 x i32>*
+  %18 = bitcast i8* %16 to <8 x i32>*
+  %wide.vec = load <8 x i32>, <8 x i32>* %17, align 4
+  %wide.vec23 = load <8 x i32>, <8 x i32>* %18, align 4
+  %strided.vec = shufflevector <8 x i32> %wide.vec, <8 x i32> undef, <4 x i32> 
+  %strided.vec24 = shufflevector <8 x i32> %wide.vec23, <8 x i32> undef, <4 x i32> 
+  %19 = add <4 x i32> %strided.vec, %vec.phi
+  %20 = add <4 x i32> %strided.vec24, %vec.phi21
+  %index.next = add i64 %index, 8
+  %21 = icmp eq i64 %index.next, %n.vec
+  br i1 %21, label %middle.block, label %vector.body
+
+middle.block:
+  store i8* %14, i8** %arg, align 8
+  %bin.rdx = add <4 x i32> %20, %19
+  %rdx.shuf = shufflevector <4 x i32> %bin.rdx, <4 x i32> undef, <4 x i32> 
+  %bin.rdx25 = add <4 x i32> %bin.rdx, %rdx.shuf
+  %rdx.shuf26 = shufflevector <4 x i32> %bin.rdx25, <4 x i32> undef, <4 x i32> 
+  %bin.rdx27 = add <4 x i32> %bin.rdx25, %rdx.shuf26
+  %22 = extractelement <4 x i32> %bin.rdx27, i32 0
+  br label %for.body.preheader28
+
+for.body.preheader28:
+  %argp.cur.ph = phi i8* [ %argp.cur.pre, %vector.memcheck ], [ %argp.cur.pre, %for.body.preheader ], [ %ind.end, %middle.block ]
+  %total.09.ph = phi i32 [ undef, %vector.memcheck ], [ undef, %for.body.preheader ], [ %22, %middle.block ]
+  %i.08.ph = phi i32 [ 0, %vector.memcheck ], [ 0, %for.body.preheader ], [ %ind.end13, %middle.block ]
+  br label %for.body
+
+for.body:
+

1 2 3 >

1 - 100 of 206 matches

Mail list logo