[clang] 96c4ec8 - Remove extra whitespace. NFC.

[Michael Liao via cfe-commits]

Author: Michael Liao
Date: 2020-04-10T03:22:01-04:00
New Revision: 96c4ec8fdbd95048114cf058679bd8fc08ab76b3

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

LOG: Remove extra whitespace. NFC.

Added: 


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

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticDriverKinds.td 
b/clang/include/clang/Basic/DiagnosticDriverKinds.td
index e35ca843ff56..cba59cb3b66d 100644
--- a/clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ b/clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -50,14 +50,14 @@ def warn_drv_avr_stdlib_not_linked: Warning<
   InGroup;
 def err_drv_cuda_bad_gpu_arch : Error<"Unsupported CUDA gpu architecture: %0">;
 def err_drv_no_cuda_installation : Error<
-  "cannot find CUDA installation.  Provide its path via --cuda-path, or pass "
+  "cannot find CUDA installation. Provide its path via --cuda-path, or pass "
   "-nocudainc to build without CUDA includes.">;
 def err_drv_no_cuda_libdevice : Error<
   "cannot find libdevice for %0. Provide path to 
diff erent CUDA installation "
   "via --cuda-path, or pass -nocudalib to build without linking with 
libdevice.">;
 def err_drv_cuda_version_unsupported : Error<
   "GPU arch %0 is supported by CUDA versions between %1 and %2 (inclusive), "
-  "but installation at %3 is %4.  Use --cuda-path to specify a 
diff erent CUDA "
+  "but installation at %3 is %4. Use --cuda-path to specify a 
diff erent CUDA "
   "install, pass a 
diff erent GPU arch with --cuda-gpu-arch, or pass "
   "--no-cuda-version-check.">;
 def warn_drv_unknown_cuda_version: Warning<



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

[PATCH] D77341: [DomTree] Replace ChildrenGetter with GraphTraits over GraphDiff.

[David Blaikie via Phabricator via cfe-commits]

dblaikie added inline comments.



Comment at: llvm/include/llvm/Support/GenericDomTree.h:32
 #include "llvm/ADT/SmallVector.h"
+#include "llvm/IR/CFGDiff.h"
 #include "llvm/Support/CFGUpdate.h"

mehdi_amini wrote:
> This looks like a layering violation to me here: I wouldn't expect a generic 
> utility in Support to introduce a dependency on IR.
> 
> I speculatively reverted in 
> https://github.com/llvm/llvm-project/commit/57d2d48399b63c0ef1dda490fdaf28efbb80c2c0
>  while we can figure it out.
Yep - agreed on the layering violation. Thanks for the catch/revert!

I /think/ CFGDiff.h is independent of IR & shouldn't include IR/CFG.h and then 
can move into Support. Ah, yeah, when I did 
30804d0a3fb23325c4b455108e59d00213b83891 & related work, that's what made it 
independent of IR.

Moved it over to Support in a838aadae3f20b9644e2ad553d3d558a91fd8fd7


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77341



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

[clang] 0445c64 - [DomTree] Replace ChildrenGetter with GraphTraits over GraphDiff.

[Mehdi Amini via cfe-commits]

Author: Alina Sbirlea
Date: 2020-04-10T07:38:53Z
New Revision: 0445c64998d14b81f0d3a3182011fc5eae47fa71

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

LOG: [DomTree] Replace ChildrenGetter with GraphTraits over GraphDiff.

This replaces the ChildrenGetter inside the DominatorTree with
GraphTraits over a GraphDiff object, an object which encapsulated the
view of the previous CFG.
This also simplifies the extentions in clang which use DominatorTree, as
GraphDiff also filters nullptrs.

Re-land a90374988e4eb8c50d91e11f4e61cdbd5debb235 after moving CFGDiff.h
to Support.

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

Added: 


Modified: 
clang/include/clang/Analysis/Analyses/Dominators.h
llvm/include/llvm/IR/Dominators.h
llvm/include/llvm/Support/CFGDiff.h
llvm/include/llvm/Support/GenericDomTree.h
llvm/include/llvm/Support/GenericDomTreeConstruction.h
llvm/lib/IR/Dominators.cpp

Removed: 




diff  --git a/clang/include/clang/Analysis/Analyses/Dominators.h 
b/clang/include/clang/Analysis/Analyses/Dominators.h
index 061c98137da2..c0cfc186c365 100644
--- a/clang/include/clang/Analysis/Analyses/Dominators.h
+++ b/clang/include/clang/Analysis/Analyses/Dominators.h
@@ -275,76 +275,6 @@ class ControlDependencyCalculator : public ManagedAnalysis 
{
 
 namespace llvm {
 
-/// Clang's CFG contains nullpointers for unreachable succesors, e.g. when an
-/// if statement's condition is always false, it's 'then' branch is represented
-/// with a nullptr. This however will result in a nullpointer derefernece for
-/// dominator tree calculation.
-///
-/// To circumvent this, let's just crudely specialize the children getters
-/// used in LLVM's dominator tree builder.
-namespace DomTreeBuilder {
-
-using ClangCFGDomChildrenGetter =
-SemiNCAInfo::ChildrenGetter<
- 
/*Inverse=*/false>;
-
-template <>
-template <>
-inline ClangCFGDomChildrenGetter::ResultTy ClangCFGDomChildrenGetter::Get(
-clang::CFGBlock *N, std::integral_constant) {
-  auto RChildren = reverse(children(N));
-  ResultTy Ret(RChildren.begin(), RChildren.end());
-  Ret.erase(std::remove(Ret.begin(), Ret.end(), nullptr), Ret.end());
-  return Ret;
-}
-
-using ClangCFGDomReverseChildrenGetter =
-SemiNCAInfo::ChildrenGetter<
-  
/*Inverse=*/true>;
-
-template <>
-template <>
-inline ClangCFGDomReverseChildrenGetter::ResultTy
-ClangCFGDomReverseChildrenGetter::Get(
-clang::CFGBlock *N, std::integral_constant) {
-  auto IChildren = inverse_children(N);
-  ResultTy Ret(IChildren.begin(), IChildren.end());
-  Ret.erase(std::remove(Ret.begin(), Ret.end(), nullptr), Ret.end());
-  return Ret;
-}
-
-using ClangCFGPostDomChildrenGetter =
-SemiNCAInfo::ChildrenGetter<
- 
/*Inverse=*/false>;
-
-template <>
-template <>
-inline ClangCFGPostDomChildrenGetter::ResultTy
-ClangCFGPostDomChildrenGetter::Get(
-clang::CFGBlock *N, std::integral_constant) {
-  auto RChildren = reverse(children(N));
-  ResultTy Ret(RChildren.begin(), RChildren.end());
-  Ret.erase(std::remove(Ret.begin(), Ret.end(), nullptr), Ret.end());
-  return Ret;
-}
-
-using ClangCFGPostDomReverseChildrenGetter =
-SemiNCAInfo::ChildrenGetter<
-  
/*Inverse=*/true>;
-
-template <>
-template <>
-inline ClangCFGPostDomReverseChildrenGetter::ResultTy
-ClangCFGPostDomReverseChildrenGetter::Get(
-clang::CFGBlock *N, std::integral_constant) {
-  auto IChildren = inverse_children(N);
-  ResultTy Ret(IChildren.begin(), IChildren.end());
-  Ret.erase(std::remove(Ret.begin(), Ret.end(), nullptr), Ret.end());
-  return Ret;
-}
-
-} // end of namespace DomTreeBuilder
-
 //===-
 /// DominatorTree GraphTraits specialization so the DominatorTree can be
 /// iterable by generic graph iterators.

diff  --git a/llvm/include/llvm/IR/Dominators.h 
b/llvm/include/llvm/IR/Dominators.h
index 6a14785a6cc3..0c98902c72c8 100644
--- a/llvm/include/llvm/IR/Dominators.h
+++ b/llvm/include/llvm/IR/Dominators.h
@@ -44,6 +44,9 @@ using BBPostDomTree = PostDomTreeBase;
 
 using BBUpdates = ArrayRef>;
 
+using BBDomTreeGraphDiff = GraphDiff;
+using BBPostDomTreeGraphDiff = GraphDiff;
+
 extern template void Calculate(BBDomTree &DT);
 extern template void CalculateWithUpdates(BBDomTree &DT,
  BBUpdates U);
@@ -62,8 +65,10 @@ extern template void DeleteEdge(BBPostDomTree 
&DT,
BasicBlock *From,
BasicBlock *To);
 
-extern template void ApplyUpdates(BBDomTree

[clang] bbeeb35 - Revert "[DomTree] Replace ChildrenGetter with GraphTraits over GraphDiff."

[Mehdi Amini via cfe-commits]

Author: Mehdi Amini
Date: 2020-04-10T07:44:06Z
New Revision: bbeeb35c1ffaf7aeb3241bdfcb69bf4708370ac1

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

LOG: Revert "[DomTree] Replace ChildrenGetter with GraphTraits over GraphDiff."

This reverts commit 0445c64998d14b81f0d3a3182011fc5eae47fa71.

MLIR Build is broken by this change at the moment.

Added: 


Modified: 
clang/include/clang/Analysis/Analyses/Dominators.h
llvm/include/llvm/IR/Dominators.h
llvm/include/llvm/Support/CFGDiff.h
llvm/include/llvm/Support/GenericDomTree.h
llvm/include/llvm/Support/GenericDomTreeConstruction.h
llvm/lib/IR/Dominators.cpp

Removed: 




diff  --git a/clang/include/clang/Analysis/Analyses/Dominators.h 
b/clang/include/clang/Analysis/Analyses/Dominators.h
index c0cfc186c365..061c98137da2 100644
--- a/clang/include/clang/Analysis/Analyses/Dominators.h
+++ b/clang/include/clang/Analysis/Analyses/Dominators.h
@@ -275,6 +275,76 @@ class ControlDependencyCalculator : public ManagedAnalysis 
{
 
 namespace llvm {
 
+/// Clang's CFG contains nullpointers for unreachable succesors, e.g. when an
+/// if statement's condition is always false, it's 'then' branch is represented
+/// with a nullptr. This however will result in a nullpointer derefernece for
+/// dominator tree calculation.
+///
+/// To circumvent this, let's just crudely specialize the children getters
+/// used in LLVM's dominator tree builder.
+namespace DomTreeBuilder {
+
+using ClangCFGDomChildrenGetter =
+SemiNCAInfo::ChildrenGetter<
+ 
/*Inverse=*/false>;
+
+template <>
+template <>
+inline ClangCFGDomChildrenGetter::ResultTy ClangCFGDomChildrenGetter::Get(
+clang::CFGBlock *N, std::integral_constant) {
+  auto RChildren = reverse(children(N));
+  ResultTy Ret(RChildren.begin(), RChildren.end());
+  Ret.erase(std::remove(Ret.begin(), Ret.end(), nullptr), Ret.end());
+  return Ret;
+}
+
+using ClangCFGDomReverseChildrenGetter =
+SemiNCAInfo::ChildrenGetter<
+  
/*Inverse=*/true>;
+
+template <>
+template <>
+inline ClangCFGDomReverseChildrenGetter::ResultTy
+ClangCFGDomReverseChildrenGetter::Get(
+clang::CFGBlock *N, std::integral_constant) {
+  auto IChildren = inverse_children(N);
+  ResultTy Ret(IChildren.begin(), IChildren.end());
+  Ret.erase(std::remove(Ret.begin(), Ret.end(), nullptr), Ret.end());
+  return Ret;
+}
+
+using ClangCFGPostDomChildrenGetter =
+SemiNCAInfo::ChildrenGetter<
+ 
/*Inverse=*/false>;
+
+template <>
+template <>
+inline ClangCFGPostDomChildrenGetter::ResultTy
+ClangCFGPostDomChildrenGetter::Get(
+clang::CFGBlock *N, std::integral_constant) {
+  auto RChildren = reverse(children(N));
+  ResultTy Ret(RChildren.begin(), RChildren.end());
+  Ret.erase(std::remove(Ret.begin(), Ret.end(), nullptr), Ret.end());
+  return Ret;
+}
+
+using ClangCFGPostDomReverseChildrenGetter =
+SemiNCAInfo::ChildrenGetter<
+  
/*Inverse=*/true>;
+
+template <>
+template <>
+inline ClangCFGPostDomReverseChildrenGetter::ResultTy
+ClangCFGPostDomReverseChildrenGetter::Get(
+clang::CFGBlock *N, std::integral_constant) {
+  auto IChildren = inverse_children(N);
+  ResultTy Ret(IChildren.begin(), IChildren.end());
+  Ret.erase(std::remove(Ret.begin(), Ret.end(), nullptr), Ret.end());
+  return Ret;
+}
+
+} // end of namespace DomTreeBuilder
+
 //===-
 /// DominatorTree GraphTraits specialization so the DominatorTree can be
 /// iterable by generic graph iterators.

diff  --git a/llvm/include/llvm/IR/Dominators.h 
b/llvm/include/llvm/IR/Dominators.h
index 0c98902c72c8..6a14785a6cc3 100644
--- a/llvm/include/llvm/IR/Dominators.h
+++ b/llvm/include/llvm/IR/Dominators.h
@@ -44,9 +44,6 @@ using BBPostDomTree = PostDomTreeBase;
 
 using BBUpdates = ArrayRef>;
 
-using BBDomTreeGraphDiff = GraphDiff;
-using BBPostDomTreeGraphDiff = GraphDiff;
-
 extern template void Calculate(BBDomTree &DT);
 extern template void CalculateWithUpdates(BBDomTree &DT,
  BBUpdates U);
@@ -65,10 +62,8 @@ extern template void DeleteEdge(BBPostDomTree 
&DT,
BasicBlock *From,
BasicBlock *To);
 
-extern template void ApplyUpdates(BBDomTree &DT,
- BBDomTreeGraphDiff &);
-extern template void ApplyUpdates(BBPostDomTree &DT,
- BBPostDomTreeGraphDiff &);
+extern template void ApplyUpdates(BBDomTree &DT, BBUpdates);
+extern template 

[PATCH] D77341: [DomTree] Replace ChildrenGetter with GraphTraits over GraphDiff.

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini added inline comments.



Comment at: llvm/include/llvm/Support/GenericDomTree.h:32
 #include "llvm/ADT/SmallVector.h"
+#include "llvm/IR/CFGDiff.h"
 #include "llvm/Support/CFGUpdate.h"

dblaikie wrote:
> mehdi_amini wrote:
> > This looks like a layering violation to me here: I wouldn't expect a 
> > generic utility in Support to introduce a dependency on IR.
> > 
> > I speculatively reverted in 
> > https://github.com/llvm/llvm-project/commit/57d2d48399b63c0ef1dda490fdaf28efbb80c2c0
> >  while we can figure it out.
> Yep - agreed on the layering violation. Thanks for the catch/revert!
> 
> I /think/ CFGDiff.h is independent of IR & shouldn't include IR/CFG.h and 
> then can move into Support. Ah, yeah, when I did 
> 30804d0a3fb23325c4b455108e59d00213b83891 & related work, that's what made it 
> independent of IR.
> 
> Moved it over to Support in a838aadae3f20b9644e2ad553d3d558a91fd8fd7
Thanks! Re-landed in 0445c64998d14b81f0d3a3182011fc5eae47fa71


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77341



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

[PATCH] D77682: [clang-format] Always break line after enum opening brace

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay accepted this revision.
MyDeveloperDay 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/D77682/new/

https://reviews.llvm.org/D77682



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

[PATCH] D77341: [DomTree] Replace ChildrenGetter with GraphTraits over GraphDiff.

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini added inline comments.



Comment at: llvm/include/llvm/Support/GenericDomTree.h:32
 #include "llvm/ADT/SmallVector.h"
+#include "llvm/IR/CFGDiff.h"
 #include "llvm/Support/CFGUpdate.h"

mehdi_amini wrote:
> dblaikie wrote:
> > mehdi_amini wrote:
> > > This looks like a layering violation to me here: I wouldn't expect a 
> > > generic utility in Support to introduce a dependency on IR.
> > > 
> > > I speculatively reverted in 
> > > https://github.com/llvm/llvm-project/commit/57d2d48399b63c0ef1dda490fdaf28efbb80c2c0
> > >  while we can figure it out.
> > Yep - agreed on the layering violation. Thanks for the catch/revert!
> > 
> > I /think/ CFGDiff.h is independent of IR & shouldn't include IR/CFG.h and 
> > then can move into Support. Ah, yeah, when I did 
> > 30804d0a3fb23325c4b455108e59d00213b83891 & related work, that's what made 
> > it independent of IR.
> > 
> > Moved it over to Support in a838aadae3f20b9644e2ad553d3d558a91fd8fd7
> Thanks! Re-landed in 0445c64998d14b81f0d3a3182011fc5eae47fa71
Actually reverted again as it breaks the MLIR build in a different way, I won't 
be able to look into this in more details right now.

(I ran `ninja check` but I forgot that `check` is not `check-all`...)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77341



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

[PATCH] D77806: [analyzer] Do not report CFError null dereference for nonnull params

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko marked 4 inline comments as done.
vsavchenko added a comment.

In D77806#1973616 , @NoQ wrote:

> We're doing much more here than just fixing the CFError behavior; we're 
> actually making the whole analyzer respect these annotations in top frame.
>
> Let's add checker-inspecific tests. We have a test checker 
> `debug.ExprInspection` just for that:
>
>   // RUN: %clang_analyze_cc1 ... -analyzer-checker=debug.ExprInspection ...
>   void clang_analyzer_eval(bool);
>  
>   void foo(void *x) __attribute__((nonnull)) {
> clang_analyzer_eval(x != nullptr); // expected-warning{{TRUE}}
>   }
>


Cool, I didn't know about that! I'll add a group of tests for user annotations 
then.




Comment at: clang/lib/StaticAnalyzer/Checkers/NonNullParamChecker.cpp:218
 
+/// We want to trust developer annotations and consider all 'nonnul' parameters
+/// as non-null indeed. Each marked parameter will get a corresponding

NoQ wrote:
> Typo :p
Whoops! It even got me a full minute or two to spot it now!



Comment at: clang/lib/StaticAnalyzer/Checkers/NonNullParamChecker.cpp:234
+/// \endcode
+void NonNullParamChecker::checkBeginFunction(CheckerContext &Context) const {
+  const LocationContext *LocContext = Context.getLocationContext();

NoQ wrote:
> As far as i understand, you should only do all this for //top-level// 
> functions, i.e. the ones from which we've started the analysis. You can skip 
> inlined functions here because a similar assumption is already made for their 
> parameters in `checkPreCall`.
> 
> You can figure out if you're in top frame via `Context.inTopFrame()`.
Gotcha!



Comment at: clang/lib/StaticAnalyzer/Checkers/NonNullParamChecker.cpp:238-239
+  const Decl *FD = LocContext->getDecl();
+  // AnyCall helps us here to avoid checking for FunctionDecl and 
ObjCMethodDecl
+  // separately and aggregates interfaces of these classes.
+  auto AbstractCall = AnyCall::forDecl(FD);

NoQ wrote:
> Nice! Should we add new tests for ObjC method calls as well then?
Good catch!



Comment at: clang/test/Analysis/nonnull.cpp:28
+int globalVar = 15;
+void moreParamsThanArgs [[gnu::nonnull(2, 4)]] (int a, int *p, int b = 42, int 
*q = &globalVar);
+

NoQ wrote:
> C-style variadic functions are the real problem. Variadic templates are easy; 
> they're just duplicated in the AST as many times as necessary and all the 
> parameter declarations are in place. Default arguments are also easy; the 
> argument expression is still present in the AST even if it's not explicitly 
> written down at the call site. C-style variadic functions are hard because 
> they actually have more arguments than they have parameters.
C-style variadic functions are already covered in `nonnull.m`. I added here 
C++-specific cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77806



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

[PATCH] D77777: [nvptx] Add `nvvm.texsurf.handle` internalizer.

[Michael Liao via Phabricator via cfe-commits]

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

Fix a clang-tidy warning.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D7

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGenCUDA/surface.cu
  clang/test/CodeGenCUDA/texture.cu
  llvm/lib/Target/NVPTX/CMakeLists.txt
  llvm/lib/Target/NVPTX/NVPTX.h
  llvm/lib/Target/NVPTX/NVPTXTargetMachine.cpp
  llvm/lib/Target/NVPTX/NVPTXTexSurfHandleInternalizer.cpp
  llvm/test/CodeGen/NVPTX/tex-read-cuda.ll

Index: llvm/test/CodeGen/NVPTX/tex-read-cuda.ll
===
--- llvm/test/CodeGen/NVPTX/tex-read-cuda.ll
+++ llvm/test/CodeGen/NVPTX/tex-read-cuda.ll
@@ -6,6 +6,7 @@
 
 declare { float, float, float, float } @llvm.nvvm.tex.unified.1d.v4f32.s32(i64, i32)
 declare i64 @llvm.nvvm.texsurf.handle.internal.p1i64(i64 addrspace(1)*)
+declare i64 @llvm.nvvm.texsurf.handle.p1i64(metadata, i64 addrspace(1)*)
 
 ; SM20-LABEL: .entry foo
 ; SM30-LABEL: .entry foo
@@ -28,7 +29,7 @@
 ; SM20-LABEL: .entry bar
 ; SM30-LABEL: .entry bar
 define void @bar(float* %red, i32 %idx) {
-; SM30: mov.u64 %rd[[TEXHANDLE:[0-9]+]], tex0 
+; SM30: mov.u64 %rd[[TEXHANDLE:[0-9]+]], tex0
   %texHandle = tail call i64 @llvm.nvvm.texsurf.handle.internal.p1i64(i64 addrspace(1)* @tex0)
 ; SM20: tex.1d.v4.f32.s32 {%f[[RED:[0-9]+]], %f[[GREEN:[0-9]+]], %f[[BLUE:[0-9]+]], %f[[ALPHA:[0-9]+]]}, [tex0, {%r{{[0-9]+}}}]
 ; SM30: tex.1d.v4.f32.s32 {%f[[RED:[0-9]+]], %f[[GREEN:[0-9]+]], %f[[BLUE:[0-9]+]], %f[[ALPHA:[0-9]+]]}, [%rd[[TEXHANDLE]], {%r{{[0-9]+}}}]
@@ -40,7 +41,24 @@
   ret void
 }
 
-!nvvm.annotations = !{!1, !2, !3}
+; SM20-LABEL: .entry bax
+; SM30-LABEL: .entry bax
+define void @bax(float* %red, i32 %idx) {
+; SM30: mov.u64 %rd[[TEXHANDLE:[0-9]+]], tex0
+  %texHandle = tail call i64 @llvm.nvvm.texsurf.handle.p1i64(metadata !5, i64 addrspace(1)* @tex0)
+; SM20: tex.1d.v4.f32.s32 {%f[[RED:[0-9]+]], %f[[GREEN:[0-9]+]], %f[[BLUE:[0-9]+]], %f[[ALPHA:[0-9]+]]}, [tex0, {%r{{[0-9]+}}}]
+; SM30: tex.1d.v4.f32.s32 {%f[[RED:[0-9]+]], %f[[GREEN:[0-9]+]], %f[[BLUE:[0-9]+]], %f[[ALPHA:[0-9]+]]}, [%rd[[TEXHANDLE]], {%r{{[0-9]+}}}]
+  %val = tail call { float, float, float, float } @llvm.nvvm.tex.unified.1d.v4f32.s32(i64 %texHandle, i32 %idx)
+  %ret = extractvalue { float, float, float, float } %val, 0
+; SM20: st.global.f32 [%r{{[0-9]+}}], %f[[RED]]
+; SM30: st.global.f32 [%r{{[0-9]+}}], %f[[RED]]
+  store float %ret, float* %red
+  ret void
+}
+
+!nvvm.annotations = !{!1, !2, !3, !4}
 !1 = !{void (i64, float*, i32)* @foo, !"kernel", i32 1}
 !2 = !{void (float*, i32)* @bar, !"kernel", i32 1}
-!3 = !{i64 addrspace(1)* @tex0, !"texture", i32 1}
+!3 = !{void (float*, i32)* @bax, !"kernel", i32 1}
+!4 = !{i64 addrspace(1)* @tex0, !"texture", i32 1}
+!5 = !{i64 addrspace(1)* @tex0}
Index: llvm/lib/Target/NVPTX/NVPTXTexSurfHandleInternalizer.cpp
===
--- /dev/null
+++ llvm/lib/Target/NVPTX/NVPTXTexSurfHandleInternalizer.cpp
@@ -0,0 +1,91 @@
+//===- NVPTXLowerAggrCopies.cpp - --*- C++ -*--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// \file
+//
+// According to [NVVM IR Spec][1], `nvvm.texsurf.handle` should be used to
+// access texture/surface memory. The first argument to that intrinsic is a
+// metadata holding the texture or surface variable. The second argument to
+// that intrinsic is the texture or surface variable itself. However, the first
+// metadata argument cannot be handled directly by the NVPTX backend, which
+// only handle its internal version, i.e., `nvvm.texsurf.handle.internal`. This
+// pass, arranged just before the code selection, replaces
+// `nvvm.texsurf.handle` intrinsics with their internal version, i.e.,
+// `nvvm.texsurf.handle.internal`.
+// ---
+// [1]: https://docs.nvidia.com/cuda/nvvm-ir-spec/index.html
+//
+//===--===//
+
+#include "NVPTX.h"
+#include "llvm/IR/BasicBlock.h"
+#include "llvm/IR/Function.h"
+#include "llvm/IR/IRBuilder.h"
+#include "llvm/IR/IntrinsicInst.h"
+#include "llvm/IR/IntrinsicsNVPTX.h"
+#include "llvm/Pass.h"
+
+using namespace llvm;
+
+#define DEBUG_TYPE "nvptx-texsurf-handle-internalizer"
+
+namespace llvm {
+void initializeTexSurfHandleInternalizerPass(PassRegistry &);
+} // namespace llvm
+
+namespace {
+
+class TexSurfHandleInternalizer : public FunctionPass {
+public:
+  static char ID;
+
+  TexSurfHandleInternalizer() : FunctionPass(ID) {
+initializeTexSurfHandleInternalizerPass(*PassRegistry::getPassRegistry());
+  }
+
+  StringRef getPassName() const override {
+

[PATCH] D77571: [clang-tidy] Add check to find calls to NSInvocation methods under ARC that don't have proper object argument lifetimes.

[Michael Wyman via Phabricator via cfe-commits]

mwyman updated this revision to Diff 256521.
mwyman added a comment.

Added struct member reference from local variable, per review comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77571

Files:
  clang-tools-extra/clang-tidy/objc/CMakeLists.txt
  clang-tools-extra/clang-tidy/objc/NSInvocationArgumentLifetimeCheck.cpp
  clang-tools-extra/clang-tidy/objc/NSInvocationArgumentLifetimeCheck.h
  clang-tools-extra/clang-tidy/objc/ObjCTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/docs/clang-tidy/checks/objc-nsinvocation-argument-lifetime.rst
  
clang-tools-extra/test/clang-tidy/checkers/objc-nsinvocation-argument-lifetime.m

Index: clang-tools-extra/test/clang-tidy/checkers/objc-nsinvocation-argument-lifetime.m
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/objc-nsinvocation-argument-lifetime.m
@@ -0,0 +1,103 @@
+// RUN: %check_clang_tidy %s objc-nsinvocation-argument-lifetime %t
+
+__attribute__((objc_root_class))
+@interface NSObject
+@end
+
+@interface NSInvocation : NSObject
+- (void)getArgument:(void *)Arg atIndex:(int)Index;
+- (void)getReturnValue:(void *)ReturnValue;
+@end
+
+@interface OtherClass : NSObject
+- (void)getArgument:(void *)Arg atIndex:(int)Index;
+@end
+
+struct Foo {
+  __unsafe_unretained id Field1;
+  id Field2;
+  int IntField;
+};
+
+void foo(NSInvocation *Invocation) {
+  __unsafe_unretained id Arg2;
+  id Arg3;
+  // CHECK-FIXES: __unsafe_unretained id Arg3;
+  NSObject __strong *Arg4;
+  // CHECK-FIXES: NSObject __unsafe_unretained *Arg4;
+  __weak id Arg5;
+  // CHECK-FIXES: __unsafe_unretained id Arg5;
+  id ReturnValue;
+  // CHECK-FIXES: __unsafe_unretained id ReturnValue;
+  void (^BlockArg1)();
+  // CHECK-FIXES: __unsafe_unretained void (^BlockArg1)();
+  __unsafe_unretained void (^BlockArg2)();
+  int IntVar;
+  struct Foo Bar;
+
+  [Invocation getArgument:&Arg2 atIndex:2];
+  [Invocation getArgument:&IntVar atIndex:2];
+
+  [Invocation getArgument:&Arg3 atIndex:3];
+  // CHECK-MESSAGES: :[[@LINE-1]]:27: warning: NSInvocation '-getArgument:atIndex:' should only pass pointers to objects with ownership __unsafe_unretained [objc-nsinvocation-argument-lifetime]
+
+  [Invocation getArgument:&Arg4 atIndex:4];
+  // CHECK-MESSAGES: :[[@LINE-1]]:27: warning: NSInvocation '-getArgument:atIndex:' should only pass pointers to objects with ownership __unsafe_unretained [objc-nsinvocation-argument-lifetime]
+
+  [Invocation getArgument:&Arg5 atIndex:5];
+  // CHECK-MESSAGES: :[[@LINE-1]]:27: warning: NSInvocation '-getArgument:atIndex:' should only pass pointers to objects with ownership __unsafe_unretained [objc-nsinvocation-argument-lifetime]
+
+  [Invocation getArgument:&BlockArg1 atIndex:6];
+  // CHECK-MESSAGES: :[[@LINE-1]]:27: warning: NSInvocation '-getArgument:atIndex:' should only pass pointers to objects with ownership __unsafe_unretained [objc-nsinvocation-argument-lifetime]
+
+  [Invocation getArgument:&BlockArg2 atIndex:6];
+
+  [Invocation getReturnValue:&ReturnValue];
+  // CHECK-MESSAGES: :[[@LINE-1]]:30: warning: NSInvocation '-getReturnValue:' should only pass pointers to objects with ownership __unsafe_unretained [objc-nsinvocation-argument-lifetime]
+
+  [Invocation getArgument:(void *)0 atIndex:6];
+
+  [Invocation getArgument:&Bar.Field1 atIndex:2];
+  [Invocation getArgument:&Bar.Field2 atIndex:2];
+  // CHECK-MESSAGES: :[[@LINE-1]]:27: warning: NSInvocation '-getArgument:atIndex:' should only pass pointers to objects with ownership __unsafe_unretained [objc-nsinvocation-argument-lifetime]
+  [Invocation getArgument:&Bar.IntField atIndex:2];
+}
+
+void bar(OtherClass *OC) {
+  id Arg;
+  [OC getArgument:&Arg atIndex:2];
+}
+
+@interface TestClass : NSObject {
+@public
+  id Argument1;
+  __unsafe_unretained id Argument2;
+  struct Foo Bar;
+  int IntIvar;
+}
+@end
+
+@implementation TestClass
+
+- (void)processInvocation:(NSInvocation *)Invocation {
+  [Invocation getArgument:&Argument1 atIndex:2];
+  // CHECK-MESSAGES: :[[@LINE-1]]:27: warning: NSInvocation '-getArgument:atIndex:' should only pass pointers to objects with ownership __unsafe_unretained [objc-nsinvocation-argument-lifetime]
+  [Invocation getArgument:&self->Argument1 atIndex:2];
+  // CHECK-MESSAGES: :[[@LINE-1]]:27: warning: NSInvocation '-getArgument:atIndex:' should only pass pointers to objects with ownership __unsafe_unretained [objc-nsinvocation-argument-lifetime]
+  [Invocation getArgument:&Argument2 atIndex:2];
+  [Invocation getArgument:&self->Argument2 atIndex:2];
+  [Invocation getArgument:&self->IntIvar atIndex:2];
+
+  [Invocation getReturnValue:&(self->Bar.Field1)];
+  [Invocation getReturnValue:&(self->Bar.Field2)];
+  // CHECK-MESSAGES: :[[@LINE-1]]:30: warning: NSInvocation '-getReturnValue:' should only pass pointers to objects

[PATCH] D77341: [DomTree] Replace ChildrenGetter with GraphTraits over GraphDiff.

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

This change causes a 2.5% compile-time regression across the board, see 
http://llvm-compile-time-tracker.com/compare.php?from=37bcf2df01cfa47e4509a5d225a23e2ca95005e6&to=a90374988e4eb8c50d91e11f4e61cdbd5debb235&stat=instructions.
 Can you please try to find a cheaper way to approach this issue?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77341



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

[PATCH] D77632: [TLI] Per-function fveclib for math library used for vectorization

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

This change causes a ~0.5% compile-time regressions: 
http://llvm-compile-time-tracker.com/compare.php?from=5b18b6e9a84d985c0a907009fb71de7c1943bc88&to=60c642e74be6af86906d9f3d982728be7bd4329f&stat=instructions
 This is quite a lot as these things go, so it would be great if you could 
double check if there's any optimization potential here. In particular I'm 
wondering why this affects normal builds so much, even though they 
(presumably?) don't use any veclib at all.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77632



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

[libunwind] 9107594 - [libunwind] add hexagon support

[Brian Cain via cfe-commits]

Author: Brian Cain
Date: 2020-04-10T04:24:10-05:00
New Revision: 9107594f376e37e99c71881404c686b306f93ad2

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

LOG: [libunwind] add hexagon support

Added: 


Modified: 
libunwind/include/__libunwind_config.h
libunwind/include/libunwind.h
libunwind/src/Registers.hpp
libunwind/src/UnwindCursor.hpp
libunwind/src/UnwindRegistersRestore.S
libunwind/src/UnwindRegistersSave.S
libunwind/src/assembly.h
libunwind/src/config.h
libunwind/src/libunwind.cpp

Removed: 




diff  --git a/libunwind/include/__libunwind_config.h 
b/libunwind/include/__libunwind_config.h
index 4d03bd83d8c6..71d77ca65118 100644
--- a/libunwind/include/__libunwind_config.h
+++ b/libunwind/include/__libunwind_config.h
@@ -23,6 +23,7 @@
 #define _LIBUNWIND_HIGHEST_DWARF_REGISTER_OR1K  32
 #define _LIBUNWIND_HIGHEST_DWARF_REGISTER_MIPS  65
 #define _LIBUNWIND_HIGHEST_DWARF_REGISTER_SPARC 31
+#define _LIBUNWIND_HIGHEST_DWARF_REGISTER_HEXAGON   34
 #define _LIBUNWIND_HIGHEST_DWARF_REGISTER_RISCV 64
 
 #if defined(_LIBUNWIND_IS_NATIVE_ONLY)
@@ -82,6 +83,12 @@
 #  define _LIBUNWIND_CONTEXT_SIZE 16
 #  define _LIBUNWIND_CURSOR_SIZE 24
 #  define _LIBUNWIND_HIGHEST_DWARF_REGISTER 
_LIBUNWIND_HIGHEST_DWARF_REGISTER_OR1K
+# elif defined(__hexagon__)
+#  define _LIBUNWIND_TARGET_HEXAGON 1
+// Values here change when : Registers.hpp - hexagon_thread_state_t change
+#  define _LIBUNWIND_CONTEXT_SIZE 18
+#  define _LIBUNWIND_CURSOR_SIZE 24
+#  define _LIBUNWIND_HIGHEST_DWARF_REGISTER 
_LIBUNWIND_HIGHEST_DWARF_REGISTER_HEXAGON
 # elif defined(__mips__)
 #  if defined(_ABIO32) && _MIPS_SIM == _ABIO32
 #define _LIBUNWIND_TARGET_MIPS_O32 1
@@ -142,6 +149,7 @@
 # define _LIBUNWIND_TARGET_MIPS_O32 1
 # define _LIBUNWIND_TARGET_MIPS_NEWABI 1
 # define _LIBUNWIND_TARGET_SPARC 1
+# define _LIBUNWIND_TARGET_HEXAGON 1
 # define _LIBUNWIND_TARGET_RISCV 1
 # define _LIBUNWIND_CONTEXT_SIZE 167
 # define _LIBUNWIND_CURSOR_SIZE 179

diff  --git a/libunwind/include/libunwind.h b/libunwind/include/libunwind.h
index 1a501b867dda..23ef47f4ac83 100644
--- a/libunwind/include/libunwind.h
+++ b/libunwind/include/libunwind.h
@@ -832,6 +832,44 @@ enum {
   UNW_SPARC_I7 = 31,
 };
 
+// Hexagon register numbers
+enum {
+  UNW_HEXAGON_R0,
+  UNW_HEXAGON_R1,
+  UNW_HEXAGON_R2,
+  UNW_HEXAGON_R3,
+  UNW_HEXAGON_R4,
+  UNW_HEXAGON_R5,
+  UNW_HEXAGON_R6,
+  UNW_HEXAGON_R7,
+  UNW_HEXAGON_R8,
+  UNW_HEXAGON_R9,
+  UNW_HEXAGON_R10,
+  UNW_HEXAGON_R11,
+  UNW_HEXAGON_R12,
+  UNW_HEXAGON_R13,
+  UNW_HEXAGON_R14,
+  UNW_HEXAGON_R15,
+  UNW_HEXAGON_R16,
+  UNW_HEXAGON_R17,
+  UNW_HEXAGON_R18,
+  UNW_HEXAGON_R19,
+  UNW_HEXAGON_R20,
+  UNW_HEXAGON_R21,
+  UNW_HEXAGON_R22,
+  UNW_HEXAGON_R23,
+  UNW_HEXAGON_R24,
+  UNW_HEXAGON_R25,
+  UNW_HEXAGON_R26,
+  UNW_HEXAGON_R27,
+  UNW_HEXAGON_R28,
+  UNW_HEXAGON_R29,
+  UNW_HEXAGON_R30,
+  UNW_HEXAGON_R31,
+  UNW_HEXAGON_P3_0,
+  UNW_HEXAGON_PC,
+};
+
 // RISC-V registers. These match the DWARF register numbers defined by section
 // 4 of the RISC-V ELF psABI specification, which can be found at:
 //

diff  --git a/libunwind/src/Registers.hpp b/libunwind/src/Registers.hpp
index ffc75eee6bf8..26a0fa8f338e 100644
--- a/libunwind/src/Registers.hpp
+++ b/libunwind/src/Registers.hpp
@@ -34,6 +34,7 @@ enum {
   REGISTERS_MIPS_O32,
   REGISTERS_MIPS_NEWABI,
   REGISTERS_SPARC,
+  REGISTERS_HEXAGON,
   REGISTERS_RISCV,
 };
 
@@ -3528,6 +3529,187 @@ inline const char *Registers_sparc::getRegisterName(int 
regNum) {
 }
 #endif // _LIBUNWIND_TARGET_SPARC
 
+#if defined(_LIBUNWIND_TARGET_HEXAGON)
+/// Registers_hexagon holds the register state of a thread in a Hexagon QDSP6
+/// process.
+class _LIBUNWIND_HIDDEN Registers_hexagon {
+public:
+  Registers_hexagon();
+  Registers_hexagon(const void *registers);
+
+  boolvalidRegister(int num) const;
+  uint32_tgetRegister(int num) const;
+  voidsetRegister(int num, uint32_t value);
+  boolvalidFloatRegister(int num) const;
+  double  getFloatRegister(int num) const;
+  voidsetFloatRegister(int num, double value);
+  boolvalidVectorRegister(int num) const;
+  v128getVectorRegister(int num) const;
+  voidsetVectorRegister(int num, v128 value);
+  const char *getRegisterName(int num);
+  voidjumpto();
+  static int  lastDwarfRegNum() { return 
_LIBUNWIND_HIGHEST_DWARF_REGISTER_HEXAGON; }
+  static int  getArch() { return REGISTERS_HEXAGON; }
+
+  uint32_t  getSP() const { return _registers.__r[UNW_HEXAGON_R29]; }
+  void  setSP(uint32_t value) { _registers.__r[UNW_HEXAGON_R29] = value; }
+  uint32_t  getIP() const { return _registers.__r[UNW_HEXAGON_PC]; }
+  void  setIP(uint32_t value) { _registers.__r[

[PATCH] D77806: [analyzer] Do not report CFError null dereference for nonnull params

[Valeriy Savchenko via Phabricator via cfe-commits]

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

Fix review remarks


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77806

Files:
  clang/lib/StaticAnalyzer/Checkers/NonNullParamChecker.cpp
  clang/test/Analysis/CheckNSError.m
  clang/test/Analysis/UserNullabilityAnnotations.m
  clang/test/Analysis/nonnull.cpp

Index: clang/test/Analysis/nonnull.cpp
===
--- /dev/null
+++ clang/test/Analysis/nonnull.cpp
@@ -0,0 +1,34 @@
+// RUN: %clang_analyze_cc1 -std=c++11 -analyzer-checker=core -verify %s
+
+void nonnull [[gnu::nonnull]] (int *q);
+
+void f1(int *p) {
+  if (p)
+return;
+  nonnull(p); //expected-warning{{nonnull}}
+}
+
+void f2(int *p) {
+  if (p)
+return;
+  auto lambda = [](int *q) __attribute__((nonnull)){};
+  lambda(p); //expected-warning{{nonnull}}
+}
+
+template 
+void variadicNonnull(ARGS... args) __attribute__((nonnull));
+
+void f3(int a, float b, int *p) {
+  if (p)
+return;
+  variadicNonnull(a, b, p); //expected-warning{{nonnull}}
+}
+
+int globalVar = 15;
+void moreParamsThanArgs [[gnu::nonnull(2, 4)]] (int a, int *p, int b = 42, int *q = &globalVar);
+
+void f4(int a, int *p) {
+  if (p)
+return;
+  moreParamsThanArgs(a, p); //expected-warning{{nonnull}}
+}
Index: clang/test/Analysis/UserNullabilityAnnotations.m
===
--- /dev/null
+++ clang/test/Analysis/UserNullabilityAnnotations.m
@@ -0,0 +1,36 @@
+// RUN: %clang_analyze_cc1 -verify -Wno-objc-root-class %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=nullability \
+// RUN:   -analyzer-checker=debug.ExprInspection
+
+void clang_analyzer_eval(int);
+
+@interface TestFunctionLevelAnnotations
+- (void)method1:(int *_Nonnull)x;
+- (void)method2:(int *)x __attribute__((nonnull));
+@end
+
+@implementation TestFunctionLevelAnnotations
+- (void)method1:(int *_Nonnull)x {
+  clang_analyzer_eval(x != 0); // expected-warning{{TRUE}}
+}
+
+- (void)method2:(int *)x {
+  clang_analyzer_eval(x != 0); // expected-warning{{TRUE}}
+}
+@end
+
+typedef struct NestedNonnullMember {
+  struct NestedNonnullMember *Child;
+  int *_Nonnull Value;
+} NestedNonnullMember;
+
+NestedNonnullMember *foo();
+
+void f1(NestedNonnullMember *Root) {
+  NestedNonnullMember *Grandson = Root->Child->Child;
+
+  clang_analyzer_eval(Root->Value != 0); // expected-warning{{TRUE}}
+  clang_analyzer_eval(Grandson->Value != 0); // expected-warning{{TRUE}}
+  clang_analyzer_eval(foo()->Child->Value != 0); // expected-warning{{TRUE}}
+}
Index: clang/test/Analysis/CheckNSError.m
===
--- clang/test/Analysis/CheckNSError.m
+++ clang/test/Analysis/CheckNSError.m
@@ -22,6 +22,7 @@
 - (void)myMethodWhichMayFail:(NSError **)error;
 - (BOOL)myMethodWhichMayFail2:(NSError **)error;
 - (BOOL)myMethodWhichMayFail3:(NSError **_Nonnull)error;
+- (BOOL)myMethodWhichMayFail4:(NSError **)error __attribute__((nonnull));
 @end
 
 @implementation A
@@ -38,6 +39,11 @@
   *error = [NSError errorWithDomain:@"domain" code:1 userInfo:0]; // no-warning
   return 0;
 }
+
+- (BOOL)myMethodWhichMayFail4:(NSError **)error { // no-warning
+  *error = [NSError errorWithDomain:@"domain" code:1 userInfo:0]; // no-warning
+  return 0;
+}
 @end
 
 struct __CFError {};
@@ -62,4 +68,17 @@
   return 0;
 }
 
+int __attribute__((nonnull)) f4(CFErrorRef *error) {
+  *error = 0; // no-warning
+  return 0;
+}
 
+int __attribute__((nonnull(1))) f5(int *x, CFErrorRef *error) {
+  *error = 0; // expected-warning {{Potential null dereference}}
+  return 0;
+}
+
+int __attribute__((nonnull(2))) f6(int *x, CFErrorRef *error) {
+  *error = 0; // no-warning
+  return 0;
+}
Index: clang/lib/StaticAnalyzer/Checkers/NonNullParamChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/NonNullParamChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/NonNullParamChecker.cpp
@@ -14,8 +14,9 @@
 //
 //===--===//
 
-#include "clang/StaticAnalyzer/Checkers/BuiltinCheckerRegistration.h"
 #include "clang/AST/Attr.h"
+#include "clang/Analysis/AnyCall.h"
+#include "clang/StaticAnalyzer/Checkers/BuiltinCheckerRegistration.h"
 #include "clang/StaticAnalyzer/Core/BugReporter/BugType.h"
 #include "clang/StaticAnalyzer/Core/Checker.h"
 #include "clang/StaticAnalyzer/Core/CheckerManager.h"
@@ -28,44 +29,82 @@
 
 namespace {
 class NonNullParamChecker
-  : public Checker< check::PreCall, EventDispatcher > {
+: public Checker> {
   mutable std::unique_ptr BTAttrNonNull;
   mutable std::unique_ptr BTNullRefArg;
 
 public:
-
   void checkPreCall(const CallEvent &Call, CheckerContext &C) const;
+  void checkBeginFunction(CheckerContext &C) const;
 
   std::unique_ptr

[PATCH] D76768: [analyzer] Added support of scan-build and exploded-graph-rewriter regression tests for Windows

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

In D76768#1971420 , @ASDenysPetrov 
wrote:

> @thakis
>
> > 'perl' is not recognized as an internal or external command,
>
> I think you got another problem, that Perl isn't just presented in your PATH. 
> It is not the case for buildbot logs.


I tried again in a `git bash` shell where perl is present. With that, I get 
this error: http://codepad.org/t6ZhaCXI

"Can't find scan-build on PATH."

I guess that means that the bat file runs, but the perl -s scan-build therein 
fails? scan-build is right next to the bat file, but the perl process can't 
know the directory the .bat file is in. With this change it gets a bit farther:

  -perl -S scan-build %*
  +perl -S %~dp0\scan-build %*

(Since it works for others I probably misunderstood how things are supposed to 
work, and this change might be wrong.)

New error:

"""

command stderr:
===

Can't find c:\src\llvm-project\clang\tools\scan-build\bin\\scan-build on PATH, 
'.' not in PATH.
"""

If I also remove the `-S` switch, that goes away (what's supposed to add 
clang\tools\scan-build\bin to path? Or is it supposed to be copied to bin\ in 
the out dir? It looks like clang\tools\scan-build\CMakeList.txt has logic to 
copy the script around, but clang\test\CMakeLists.txt doesn't have a dependency 
on the scan-build target, so building `check-clang` doesn't guarantee that the 
script is copied. Maybe it's just this dependency that's missing?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76768



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

[PATCH] D76768: [analyzer] Added support of scan-build and exploded-graph-rewriter regression tests for Windows

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

If I add scan-build to clang/test/CMakeLists.txt and undo my other changes, the 
test passes for me. I guess you always build that target, which is why you 
didn't see this problem. But I wonder why this isn't needed on non-Windows.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76768



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

[PATCH] D76768: [analyzer] Added support of scan-build and exploded-graph-rewriter regression tests for Windows

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

(Also, that dep should only be added if CLANG_INSTALL_SCANBUILD isn't set to 
OFF, and I suppose the tests should only run if it isn't off too.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76768



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

[PATCH] D77766: [clangd] Set up machinery for gtests of ClangdLSPServer.

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added inline comments.



Comment at: clang-tools-extra/clangd/unittests/LSPClient.cpp:65
+
+  void reply(llvm::json::Value ID,
+ llvm::Expected V) override {

sammccall wrote:
> kadircet wrote:
> > put methods before fields
> Done - I don't care much, but curious where this guideline comes from?
> My impression is LLVM puts members at the very top of the class or at the 
> very bottom (like google-style).
> DependentSizedArrayType is a random example.
i believe most of the code in LLVM puts the members at the top of the class. 
but my impression was in clangd code we tend to put members at the very bottom, 
hence i suggested that. personally i actually find having members at the top 
more useful.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77766



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

[clang] 1bd70bc - [gn build] add scan-build target

[Nico Weber via cfe-commits]

Author: Nico Weber
Date: 2020-04-10T06:18:41-04:00
New Revision: 1bd70bcd50be3c55e714350e3aadfd48040581f1

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

LOG: [gn build] add scan-build target

Added: 
llvm/utils/gn/secondary/clang/tools/scan-build/BUILD.gn

Modified: 
clang/tools/scan-build/CMakeLists.txt
llvm/utils/gn/secondary/BUILD.gn

Removed: 




diff  --git a/clang/tools/scan-build/CMakeLists.txt 
b/clang/tools/scan-build/CMakeLists.txt
index 28241245fcb7..ec0702d76f18 100644
--- a/clang/tools/scan-build/CMakeLists.txt
+++ b/clang/tools/scan-build/CMakeLists.txt
@@ -5,21 +5,26 @@ include(GNUInstallDirs)
 if (WIN32 AND NOT CYGWIN)
   set(BinFiles
 scan-build
-scan-build.bat)
+scan-build.bat
+   )
   set(LibexecFiles
 ccc-analyzer
 c++-analyzer
 ccc-analyzer.bat
-c++-analyzer.bat)
+c++-analyzer.bat
+   )
 else()
   set(BinFiles
-scan-build)
+scan-build
+   )
   set(LibexecFiles
 ccc-analyzer
-c++-analyzer)
+c++-analyzer
+   )
   if (APPLE)
 list(APPEND BinFiles
-   set-xcode-analyzer)
+   set-xcode-analyzer
+  )
   endif()
 endif()
 

diff  --git a/llvm/utils/gn/secondary/BUILD.gn 
b/llvm/utils/gn/secondary/BUILD.gn
index c38d626e1b79..43c5b8a186ae 100644
--- a/llvm/utils/gn/secondary/BUILD.gn
+++ b/llvm/utils/gn/secondary/BUILD.gn
@@ -7,6 +7,7 @@ group("default") {
 "//clang-tools-extra/clangd/test",
 "//clang-tools-extra/test",
 "//clang/test",
+"//clang/tools/scan-build",
 "//compiler-rt/include",
 "//compiler-rt/lib/scudo",
 "//lld/test",

diff  --git a/llvm/utils/gn/secondary/clang/tools/scan-build/BUILD.gn 
b/llvm/utils/gn/secondary/clang/tools/scan-build/BUILD.gn
new file mode 100644
index ..df65d461b741
--- /dev/null
+++ b/llvm/utils/gn/secondary/clang/tools/scan-build/BUILD.gn
@@ -0,0 +1,45 @@
+group("scan-build") {
+  deps = [
+":bin",
+":libexec",
+":man",
+":share",
+  ]
+}
+
+copy("bin") {
+  sources = [ "bin/scan-build" ]
+  if (host_os == "mac") {
+sources += [ "bin/set-xcode-analyzer" ]
+  } else if (host_os == "win") {
+sources += [ "bin/scan-build.bat" ]
+  }
+  outputs = [ "$root_build_dir/bin/{{source_file_part}}" ]
+}
+
+copy("libexec") {
+  sources = [
+"libexec/ccc-analyzer",
+"libexec/c++-analyzer",
+  ]
+  if (host_os == "win") {
+sources += [
+  "libexec/ccc-analyzer.bat",
+  "libexec/c++-analyzer.bat",
+]
+  }
+  outputs = [ "$root_build_dir/libexec/{{source_file_part}}" ]
+}
+
+copy("man") {
+  sources = [ "man/scan-build.1" ]
+  outputs = [ "$root_build_dir/share/man/man1/{{source_file_part}}" ]
+}
+
+copy("share") {
+  sources = [
+"share/scan-build/sorttable.js",
+"share/scan-build/scanview.css",
+  ]
+  outputs = [ "$root_build_dir/share/scan-build/{{source_file_part}}" ]
+}



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

[clang] 562bc30 - [Driver] Improve help message for -ffixed-xX flags

[Simon Cook via cfe-commits]

Author: Simon Cook
Date: 2020-04-10T11:30:24+01:00
New Revision: 562bc307c03de86dc083a019f358cd36c48488b0

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

LOG: [Driver] Improve help message for -ffixed-xX flags

This improves the message by adding the missing 'x' prefix in register
names, such that the messages say for example 'Reserve the x10 register',
instead of 'Reserve the 10 register'.

Added: 


Modified: 
clang/include/clang/Driver/Options.td

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 5becd52dae80..02875f68ebfe 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -2374,7 +2374,7 @@ def mno_fix_cortex_a53_835769 : Flag<["-"], 
"mno-fix-cortex-a53-835769">,
   HelpText<"Don't workaround Cortex-A53 erratum 835769 (AArch64 only)">;
 foreach i = {1-31} in
   def ffixed_x#i : Flag<["-"], "ffixed-x"#i>, Group,
-HelpText<"Reserve the "#i#" register (AArch64/RISC-V only)">;
+HelpText<"Reserve the x"#i#" register (AArch64/RISC-V only)">;
 
 foreach i = {8-15,18} in
   def fcall_saved_x#i : Flag<["-"], "fcall-saved-x"#i>, 
Group,



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

[PATCH] D63616: Implement `-fsanitize-coverage-whitelist` and `-fsanitize-coverage-blacklist` for clang

[Yannis Juglaret via Phabricator via cfe-commits]

tuktuk updated this revision to Diff 256546.
tuktuk added a comment.

I was indeed able to run the test again after changing its name to //.cpp//, 
thank you for your help. I have restored XFAIL lines from the original 
//sanitizer_coverage_no_prune.cpp// that I should not have deleted. Now the 
test passes again. Also the test now uses %t to work in a subdirectory like 
//sanitizer_coverage_symbolize.cpp// does.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63616

Files:
  clang/docs/SanitizerCoverage.rst
  clang/include/clang/Basic/CodeGenOptions.h
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/include/clang/Driver/SanitizerArgs.h
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/SanitizerArgs.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  
compiler-rt/test/sanitizer_common/TestCases/sanitizer_coverage_whitelist_blacklist.cpp
  llvm/include/llvm/Transforms/Instrumentation/SanitizerCoverage.h
  llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp

Index: llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
===
--- llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
+++ llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
@@ -35,6 +35,8 @@
 #include "llvm/InitializePasses.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/Debug.h"
+#include "llvm/Support/SpecialCaseList.h"
+#include "llvm/Support/VirtualFileSystem.h"
 #include "llvm/Support/raw_ostream.h"
 #include "llvm/Transforms/Instrumentation.h"
 #include "llvm/Transforms/Utils/BasicBlockUtils.h"
@@ -198,8 +200,11 @@
 class ModuleSanitizerCoverage {
 public:
   ModuleSanitizerCoverage(
-  const SanitizerCoverageOptions &Options = SanitizerCoverageOptions())
-  : Options(OverrideFromCL(Options)) {}
+  const SanitizerCoverageOptions &Options = SanitizerCoverageOptions(),
+  const SpecialCaseList *Whitelist = nullptr,
+  const SpecialCaseList *Blacklist = nullptr)
+  : Options(OverrideFromCL(Options)), Whitelist(Whitelist),
+Blacklist(Blacklist) {}
   bool instrumentModule(Module &M, DomTreeCallback DTCallback,
 PostDomTreeCallback PDTCallback);
 
@@ -263,18 +268,32 @@
   SmallVector GlobalsToAppendToCompilerUsed;
 
   SanitizerCoverageOptions Options;
+
+  const SpecialCaseList *Whitelist;
+  const SpecialCaseList *Blacklist;
 };
 
 class ModuleSanitizerCoverageLegacyPass : public ModulePass {
 public:
   ModuleSanitizerCoverageLegacyPass(
-  const SanitizerCoverageOptions &Options = SanitizerCoverageOptions())
+  const SanitizerCoverageOptions &Options = SanitizerCoverageOptions(),
+  const std::vector &WhitelistFiles =
+  std::vector(),
+  const std::vector &BlacklistFiles =
+  std::vector())
   : ModulePass(ID), Options(Options) {
+if (WhitelistFiles.size() > 0)
+  Whitelist = SpecialCaseList::createOrDie(WhitelistFiles,
+   *vfs::getRealFileSystem());
+if (BlacklistFiles.size() > 0)
+  Blacklist = SpecialCaseList::createOrDie(BlacklistFiles,
+   *vfs::getRealFileSystem());
 initializeModuleSanitizerCoverageLegacyPassPass(
 *PassRegistry::getPassRegistry());
   }
   bool runOnModule(Module &M) override {
-ModuleSanitizerCoverage ModuleSancov(Options);
+ModuleSanitizerCoverage ModuleSancov(Options, Whitelist.get(),
+ Blacklist.get());
 auto DTCallback = [this](Function &F) -> const DominatorTree * {
   return &this->getAnalysis(F).getDomTree();
 };
@@ -295,6 +314,9 @@
 
 private:
   SanitizerCoverageOptions Options;
+
+  std::unique_ptr Whitelist;
+  std::unique_ptr Blacklist;
 };
 
 } // namespace
@@ -374,6 +396,12 @@
 Module &M, DomTreeCallback DTCallback, PostDomTreeCallback PDTCallback) {
   if (Options.CoverageType == SanitizerCoverageOptions::SCK_None)
 return false;
+  if (Whitelist &&
+  !Whitelist->inSection("coverage", "src", M.getSourceFileName()))
+return false;
+  if (Blacklist &&
+  Blacklist->inSection("coverage", "src", M.getSourceFileName()))
+return false;
   C = &(M.getContext());
   DL = &M.getDataLayout();
   CurModule = &M;
@@ -611,6 +639,10 @@
   if (F.hasPersonalityFn() &&
   isAsynchronousEHPersonality(classifyEHPersonality(F.getPersonalityFn(
 return;
+  if (Whitelist && !Whitelist->inSection("coverage", "fun", F.getName()))
+return;
+  if (Blacklist && Blacklist->inSection("coverage", "fun", F.getName()))
+return;
   if (Options.CoverageType >= SanitizerCoverageOptions::SCK_Edge)
 SplitAllCriticalEdges(F, CriticalEdgeSplittingOptions().setIgnoreUnreachableDests());
   SmallVector IndirCalls;
@@ -976,6 +1008,9 @@
 "Pass for instrumenting coverage on fu

[PATCH] D77866: [analyzer][CallAndMessage] Add checker options for each bug category

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus created this revision.
Szelethus added reviewers: NoQ, baloghadamsoftware, xazax.hun, rnkovacs, 
dcoughlin, martong, balazske.
Szelethus added a project: clang.
Herald added subscribers: cfe-commits, ASDenysPetrov, steakhal, Charusso, 
gamesh411, dkrupp, donat.nagy, mikhail.ramalho, a.sidorin, szepet, whisperity.
Szelethus added a parent revision: D77846: [analyzer][CallAndMessage][NFC] 
Split up checkPreCall.

As listed in the summary D77846 , we have 5 
different categories of bugs we're checking for in CallAndMessage. I think the 
documentation placed in the code explains my thought process behind my 
decisions quite well.

A non-obvious change I had here is removing the entry for 
CallAndMessageUnInitRefArg. In fact, I removed the `CheckerNameRef` typed field 
back in D77845  (it was dead code), so that 
checker didn't really exist in any meaningful way anyways.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D77866

Files:
  clang/include/clang/StaticAnalyzer/Checkers/Checkers.td
  clang/include/clang/StaticAnalyzer/Core/BugReporter/BugType.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h
  clang/lib/StaticAnalyzer/Checkers/CallAndMessageChecker.cpp
  clang/test/Analysis/PR40625.cpp
  clang/test/Analysis/analyzer-config.c
  clang/test/Analysis/analyzer-enabled-checkers.c
  clang/test/Analysis/call-and-message.c
  clang/test/Analysis/call-and-message.cpp
  clang/test/Analysis/call-and-message.m
  clang/test/Analysis/call-and-message.mm
  clang/test/Analysis/exercise-ps.c
  clang/test/Analysis/reference.mm
  clang/test/Analysis/uninit-const.c
  clang/test/Analysis/uninit-const.cpp
  clang/test/Analysis/uninit-msg-expr.m

Index: clang/test/Analysis/uninit-msg-expr.m
===
--- clang/test/Analysis/uninit-msg-expr.m
+++ /dev/null
@@ -1,56 +0,0 @@
-// RUN: %clang_analyze_cc1 -analyzer-checker=core -analyzer-store=region -verify %s
-
-//===--===//
-// The following code is reduced using delta-debugging from
-// Foundation.h (Mac OS X).
-//
-// It includes the basic definitions for the test cases below.
-// Not directly including Foundation.h directly makes this test case 
-// both svelte and portable to non-Mac platforms.
-//===--===//
-
-typedef signed char BOOL;
-typedef unsigned int NSUInteger;
-typedef struct _NSZone NSZone;
-@class NSInvocation, NSMethodSignature, NSCoder, NSString, NSEnumerator;
-@protocol NSObject  - (BOOL)isEqual:(id)object; @end
-@protocol NSCopying  - (id)copyWithZone:(NSZone *)zone; @end
-@protocol NSMutableCopying  - (id)mutableCopyWithZone:(NSZone *)zone; @end
-@protocol NSCoding  - (void)encodeWithCoder:(NSCoder *)aCoder; @end
-@interface NSObject  {} @end
-@class NSString, NSData;
-@class NSString, NSData, NSMutableData, NSMutableDictionary, NSMutableArray;
-typedef struct {} NSFastEnumerationState;
-@protocol NSFastEnumeration
-- (NSUInteger)countByEnumeratingWithState:(NSFastEnumerationState *)state objects:(id *)stackbuf count:(NSUInteger)len;
-@end
-@class NSData, NSIndexSet, NSString, NSURL;
-@interface NSArray : NSObject 
-- (NSUInteger)count;
-@end
-@interface NSArray (NSArrayCreation)
-+ (id)array;
-- (NSUInteger)length;
-- (void)addObject:(id)object;
-@end
-extern NSString * const NSUndoManagerCheckpointNotification;
-
-//===--===//
-// Test cases.
-//===--===//
-
-unsigned f1() {
-  NSString *aString;
-  return [aString length]; // expected-warning {{Receiver in message expression is an uninitialized value}}
-}
-
-unsigned f2() {
-  NSString *aString = 0;
-  return [aString length]; // no-warning
-}
-
-void f3() {
-  NSMutableArray *aArray = [NSArray array];
-  NSString *aString;
-  [aArray addObject:aString]; // expected-warning {{1st argument in message expression is an uninitialized value}}
-}
Index: clang/test/Analysis/uninit-const.cpp
===
--- clang/test/Analysis/uninit-const.cpp
+++ clang/test/Analysis/uninit-const.cpp
@@ -1,5 +1,14 @@
-// RUN: %clang_analyze_cc1 -analyzer-checker=cplusplus.NewDelete,core,alpha.core.CallAndMessageUnInitRefArg -analyzer-output=text -verify %s
-// RUN: %clang_analyze_cc1 -analyzer-checker=cplusplus.NewDelete,core,alpha.core.CallAndMessageUnInitRefArg -analyzer-output=text -DTEST_INLINABLE_ALLOCATORS -verify %s
+// RUN: %clang_analyze_cc1 -analyzer-output=text -verify %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=cplusplus.NewDelete \
+// RUN:   -analyzer-config core.CallAndMessage:ArgPointeeInitializedness=true
+
+// RUN: %clang_analyze_cc1 -analyzer-output=text -verify %s \
+// RUN:   -DTEST_INLINAB

[PATCH] D77847: [clangd] Rebuild dependent files when a header is saved.

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

should we also have a unittest for checking ast caching works as expected?

ClangdServer::getUsedBytesPerFile should allow us to do that.

We can set cache size to one, send 3 updates in respective order to foo, bar 
and baz, we record usedbytesperfile.
Then we perform adddocument with same contents to foo and bar and check 
usedbytesperfile are still the same?




Comment at: clang-tools-extra/clangd/ClangdLSPServer.cpp:575
+ {"change", (int)TextDocumentSyncKind::Incremental},
+ {"save", true},
+ }},

spec also specifies this as `property name (optional): 
textDocumentSync.didSave` near didSave notification (in addition to defining it 
as `save` in the struct). :(

it also says textDocumentSync can also be a number for backward compat reasons, 
but doesn't say when the struct was added. I hope it is not recent and we don't 
end up breaking clients with our capab response :/

no action needed just complaining ...



Comment at: clang-tools-extra/clangd/ClangdLSPServer.cpp:1587
   // Reparse only opened files that were modified.
   for (const Path &FilePath : DraftMgr.getActiveFiles())
+if (Filter(FilePath))

nit: while here, braces and early exit.

```
for (..) {
  if(!Filter())
continue;
  if(auto draft...) server->AddDoc();
}
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77847



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

[PATCH] D77792: [analyzer] Extend constraint manager to be able to compare simple SymSymExprs

[Balázs Benics via Phabricator via cfe-commits]

steakhal updated this revision to Diff 256551.
steakhal added a comment.

- rewritten the `RangeSet::compare` function and checked the assumptions on 
WolframAlpha
- moved the `RangeSet::compare` function to a cpp file
- added comments to the `RangeSet::compare` function
- fixed the comment in `RangeConstraintManager::canReasonAbout` function
- introduced the `RangeSet::CompareResult::identical` enum value to be complete
- updated the `RangeConstraintManager::tryAssumeSymSymOp` accoding the 
`identical` CompareResult.
- omited testing the `[2,5] < [5,10]` testcase, since that is covered by `[0,5] 
< [5,10]`


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

https://reviews.llvm.org/D77792

Files:
  
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/lib/StaticAnalyzer/Core/RangedConstraintManager.cpp
  clang/test/Analysis/constraint-manager-sym-sym.c

Index: clang/test/Analysis/constraint-manager-sym-sym.c
===
--- /dev/null
+++ clang/test/Analysis/constraint-manager-sym-sym.c
@@ -0,0 +1,189 @@
+// RUN: %clang_analyze_cc1 -verify -analyzer-checker=core,debug.ExprInspection \
+// RUN:   -analyzer-config eagerly-assume=false %s
+
+void clang_analyzer_eval(int);
+
+extern void __assert_fail(__const char *__assertion, __const char *__file,
+  unsigned int __line, __const char *__function)
+__attribute__((__noreturn__));
+#define assert(expr) \
+  ((expr) ? (void)(0) : __assert_fail(#expr, __FILE__, __LINE__, __func__))
+
+// Given [a1,a2] and [b1,b2] intervals.
+// Pin the [b1,b2] interval to eg. [5,10]
+// Choose the a1,a2 points from 0,2,5,7,10,12 where a1 < a2.
+// There will be 5+4+3+2+1 cases.
+
+// [0,2] and [5,10]
+void test_range1(int l, int r) {
+  assert(5 <= r && r <= 10);
+  assert(0 <= l && l <= 2);
+  clang_analyzer_eval(l < r);  // expected-warning{{TRUE}}
+  clang_analyzer_eval(l <= r); // expected-warning{{TRUE}}
+  clang_analyzer_eval(l > r);  // expected-warning{{FALSE}}
+  clang_analyzer_eval(l >= r); // expected-warning{{FALSE}}
+}
+
+// [0,5] and [5,10]
+void test_range2(int l, int r) {
+  assert(5 <= r && r <= 10);
+  assert(0 <= l && l <= 5);
+  clang_analyzer_eval(l < r);  // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(l <= r); // expected-warning{{TRUE}}
+  clang_analyzer_eval(l > r);  // expected-warning{{FALSE}}
+  clang_analyzer_eval(l >= r); // expected-warning{{UNKNOWN}}
+}
+
+// [0,7] and [5,10]
+void test_range3(int l, int r) {
+  assert(5 <= r && r <= 10);
+  assert(0 <= l && l <= 7);
+  clang_analyzer_eval(l < r);  // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(l <= r); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(l > r);  // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(l >= r); // expected-warning{{UNKNOWN}}
+}
+
+// [0,10] and [5,10]
+void test_range4(int l, int r) {
+  assert(5 <= r && r <= 10);
+  assert(0 <= l && l <= 10);
+  clang_analyzer_eval(l < r);  // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(l <= r); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(l > r);  // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(l >= r); // expected-warning{{UNKNOWN}}
+}
+
+// [0,12] and [5,10]
+void test_range5(int l, int r) {
+  assert(5 <= r && r <= 10);
+  assert(0 <= l && l <= 12);
+  clang_analyzer_eval(l < r);  // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(l <= r); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(l > r);  // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(l >= r); // expected-warning{{UNKNOWN}}
+}
+
+// [2,5] and [5,10] omitted because it is the same as the '[0,5] and [5,10]'
+
+// [2,7] and [5,10]
+void test_range7(int l, int r) {
+  assert(5 <= r && r <= 10);
+  assert(2 <= l && l <= 7);
+  clang_analyzer_eval(l < r);  // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(l <= r); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(l > r);  // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(l >= r); // expected-warning{{UNKNOWN}}
+}
+
+// [2,10] and [5,10]
+void test_range8(int l, int r) {
+  assert(5 <= r && r <= 10);
+  assert(2 <= l && l <= 10);
+  clang_analyzer_eval(l < r);  // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(l <= r); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(l > r);  // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(l >= r); // expected-warning{{UNKNOWN}}
+}
+
+// [2,12] and [5,10]
+void test_range9(int l, int r) {
+  assert(5 <= r && r <= 10);
+  assert(2 <= l && l <= 12);
+  clang_analyzer_eval(l < r);  // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(l <= r); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(l > r);  // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(l >= r); // expected-warning{{UNKNOWN}}
+}
+
+// [5,7] and [5,10]
+void test_range10(int l, int r) {
+  assert(5 <= r && r <= 10);
+  assert(5 <= l && l <= 7);
+  clang_analyz

Re: [PATCH] D63194: [clangd] Link and initialize target infos

[Filipe Cabecinhas via cfe-commits]

Hi Kadir,

Can you fix the target_info.test clangd test you committed in this
revision, please?
I see you've tried fixing it later by adding `REQUIRES:
x86-registered-target`, but now it's never running because that feature
isn't (ever) set.
Here's a buildbot run showing it as unsupported (x86 target is built):
http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/26746/steps/test-check-all/logs/stdio

I saw you tried to fix the test in r364413 ([clangd] Disable failing
unittest on non-x86 platforms) because it was always failing. The problem
is that, even though the feature check is needed, the test still isn't
working well. I just ran it manually and didn't get the target changed from
my host one.

Here's a diff for the feature check that you can apply to propagate the
feature. But we still need to get the clangd code fixed so it picks up the
target:

```
diff --git a/clang-tools-extra/clangd/test/lit.cfg.py
b/clang-tools-extra/clangd/test/lit.cfg.py
index 5030ca356ef..54406498af0 100644
--- a/clang-tools-extra/clangd/test/lit.cfg.py
+++ b/clang-tools-extra/clangd/test/lit.cfg.py
@@ -3,6 +3,19 @@ import lit.llvm
 lit.llvm.initialize(lit_config, config)
 lit.llvm.llvm_config.use_clang()

+# required for target_info.test
+def calculate_arch_features(arch_string):
+features = []
+for arch in arch_string.split():
+features.append(arch.lower() + '-registered-target')
+return features
+
+lit.llvm.llvm_config.feature_config(
+[('--assertion-mode', {'ON': 'asserts'}),
+ ('--cxxflags', {r'-D_GLIBCXX_DEBUG\b': 'libstdcxx-safe-mode'}),
+ ('--targets-built', calculate_arch_features)
+ ])
+
 config.name = 'Clangd'
 config.suffixes = ['.test']
 config.excludes = ['Inputs']
```

Thank you,

  Filipe

  Filipe


On Wed, Jun 26, 2019 at 8:48 AM Kadir Cetinkaya via Phabricator via
cfe-commits  wrote:

> kadircet closed this revision.
> kadircet added a comment.
>
> Landed as rL364387 
>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D63194/new/
>
> https://reviews.llvm.org/D63194
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D77385: [clangd] Add index export to dexp

[Mark Nauwelaerts via Phabricator via cfe-commits]

mnauw updated this revision to Diff 256557.
mnauw edited the summary of this revision.

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

https://reviews.llvm.org/D77385

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


Index: clang-tools-extra/clangd/index/dex/dexp/Dexp.cpp
===
--- clang-tools-extra/clangd/index/dex/dexp/Dexp.cpp
+++ clang-tools-extra/clangd/index/dex/dexp/Dexp.cpp
@@ -259,6 +259,56 @@
   }
 };
 
+class Export : public Command {
+  llvm::cl::opt Format{
+  "format",
+  llvm::cl::desc("Format of index export"),
+  llvm::cl::values(
+  clEnumValN(IndexFileFormat::YAML, "yaml",
+ "human-readable YAML format"),
+  clEnumValN(IndexFileFormat::RIFF, "binary", "binary RIFF format")),
+  llvm::cl::init(IndexFileFormat::YAML),
+  };
+  llvm::cl::opt OutputFile{
+  "output-file",
+  llvm::cl::Positional,
+  llvm::cl::Required,
+  llvm::cl::desc("Output file for export"),
+  };
+
+public:
+  void run() {
+using namespace clang::clangd;
+// Read input file (as specified in global option)
+auto Buffer = llvm::MemoryBuffer::getFile(IndexPath);
+if (!Buffer) {
+  llvm::errs() << llvm::formatv("Can't open {0}", IndexPath) << "\n";
+  return;
+}
+
+// Auto-detects input format when parsing
+auto IndexIn = clang::clangd::readIndexFile(Buffer->get()->getBuffer());
+if (!IndexIn) {
+  llvm::errs() << llvm::toString(IndexIn.takeError()) << "\n";
+  return;
+}
+
+// Prepare output file
+std::error_code EC;
+llvm::raw_fd_ostream OutputStream(OutputFile, EC);
+if (EC) {
+  llvm::errs() << llvm::formatv("Can't open {0} for writing", OutputFile)
+   << "\n";
+  return;
+}
+
+// Export
+clang::clangd::IndexFileOut IndexOut(IndexIn.get());
+IndexOut.Format = Format;
+OutputStream << IndexOut;
+  }
+};
+
 struct {
   const char *Name;
   const char *Description;
@@ -269,6 +319,7 @@
  std::make_unique},
 {"refs", "Find references by ID or qualified name",
  std::make_unique},
+{"export", "Export index", std::make_unique},
 };
 
 std::unique_ptr openIndex(llvm::StringRef Index) {


Index: clang-tools-extra/clangd/index/dex/dexp/Dexp.cpp
===
--- clang-tools-extra/clangd/index/dex/dexp/Dexp.cpp
+++ clang-tools-extra/clangd/index/dex/dexp/Dexp.cpp
@@ -259,6 +259,56 @@
   }
 };
 
+class Export : public Command {
+  llvm::cl::opt Format{
+  "format",
+  llvm::cl::desc("Format of index export"),
+  llvm::cl::values(
+  clEnumValN(IndexFileFormat::YAML, "yaml",
+ "human-readable YAML format"),
+  clEnumValN(IndexFileFormat::RIFF, "binary", "binary RIFF format")),
+  llvm::cl::init(IndexFileFormat::YAML),
+  };
+  llvm::cl::opt OutputFile{
+  "output-file",
+  llvm::cl::Positional,
+  llvm::cl::Required,
+  llvm::cl::desc("Output file for export"),
+  };
+
+public:
+  void run() {
+using namespace clang::clangd;
+// Read input file (as specified in global option)
+auto Buffer = llvm::MemoryBuffer::getFile(IndexPath);
+if (!Buffer) {
+  llvm::errs() << llvm::formatv("Can't open {0}", IndexPath) << "\n";
+  return;
+}
+
+// Auto-detects input format when parsing
+auto IndexIn = clang::clangd::readIndexFile(Buffer->get()->getBuffer());
+if (!IndexIn) {
+  llvm::errs() << llvm::toString(IndexIn.takeError()) << "\n";
+  return;
+}
+
+// Prepare output file
+std::error_code EC;
+llvm::raw_fd_ostream OutputStream(OutputFile, EC);
+if (EC) {
+  llvm::errs() << llvm::formatv("Can't open {0} for writing", OutputFile)
+   << "\n";
+  return;
+}
+
+// Export
+clang::clangd::IndexFileOut IndexOut(IndexIn.get());
+IndexOut.Format = Format;
+OutputStream << IndexOut;
+  }
+};
+
 struct {
   const char *Name;
   const char *Description;
@@ -269,6 +319,7 @@
  std::make_unique},
 {"refs", "Find references by ID or qualified name",
  std::make_unique},
+{"export", "Export index", std::make_unique},
 };
 
 std::unique_ptr openIndex(llvm::StringRef Index) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D77385: [clangd] Add index export to dexp

[Mark Nauwelaerts via Phabricator via cfe-commits]

mnauw added a comment.

As suggested, I will provide the YAMLSerialization changes in a separate patch. 
 Regarding test for that, I was thinking of some running some "simple/mock YAML 
data" through some load and save cycle(s).  I presume a separate YAML file (in 
e.g. test/Inputs) is best for that?


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

https://reviews.llvm.org/D77385



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

[PATCH] D63616: Implement `-fsanitize-coverage-whitelist` and `-fsanitize-coverage-blacklist` for clang

[Yannis Juglaret via Phabricator via cfe-commits]

tuktuk updated this revision to Diff 256556.
tuktuk added a comment.

I forgot to apply //clang-format// on //clang/lib/Driver/SanitizerArgs.cpp//, 
now it should be OK.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63616

Files:
  clang/docs/SanitizerCoverage.rst
  clang/include/clang/Basic/CodeGenOptions.h
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/include/clang/Driver/SanitizerArgs.h
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/SanitizerArgs.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  
compiler-rt/test/sanitizer_common/TestCases/sanitizer_coverage_whitelist_blacklist.cpp
  llvm/include/llvm/Transforms/Instrumentation/SanitizerCoverage.h
  llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp

Index: llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
===
--- llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
+++ llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
@@ -35,6 +35,8 @@
 #include "llvm/InitializePasses.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/Debug.h"
+#include "llvm/Support/SpecialCaseList.h"
+#include "llvm/Support/VirtualFileSystem.h"
 #include "llvm/Support/raw_ostream.h"
 #include "llvm/Transforms/Instrumentation.h"
 #include "llvm/Transforms/Utils/BasicBlockUtils.h"
@@ -198,8 +200,11 @@
 class ModuleSanitizerCoverage {
 public:
   ModuleSanitizerCoverage(
-  const SanitizerCoverageOptions &Options = SanitizerCoverageOptions())
-  : Options(OverrideFromCL(Options)) {}
+  const SanitizerCoverageOptions &Options = SanitizerCoverageOptions(),
+  const SpecialCaseList *Whitelist = nullptr,
+  const SpecialCaseList *Blacklist = nullptr)
+  : Options(OverrideFromCL(Options)), Whitelist(Whitelist),
+Blacklist(Blacklist) {}
   bool instrumentModule(Module &M, DomTreeCallback DTCallback,
 PostDomTreeCallback PDTCallback);
 
@@ -263,18 +268,32 @@
   SmallVector GlobalsToAppendToCompilerUsed;
 
   SanitizerCoverageOptions Options;
+
+  const SpecialCaseList *Whitelist;
+  const SpecialCaseList *Blacklist;
 };
 
 class ModuleSanitizerCoverageLegacyPass : public ModulePass {
 public:
   ModuleSanitizerCoverageLegacyPass(
-  const SanitizerCoverageOptions &Options = SanitizerCoverageOptions())
+  const SanitizerCoverageOptions &Options = SanitizerCoverageOptions(),
+  const std::vector &WhitelistFiles =
+  std::vector(),
+  const std::vector &BlacklistFiles =
+  std::vector())
   : ModulePass(ID), Options(Options) {
+if (WhitelistFiles.size() > 0)
+  Whitelist = SpecialCaseList::createOrDie(WhitelistFiles,
+   *vfs::getRealFileSystem());
+if (BlacklistFiles.size() > 0)
+  Blacklist = SpecialCaseList::createOrDie(BlacklistFiles,
+   *vfs::getRealFileSystem());
 initializeModuleSanitizerCoverageLegacyPassPass(
 *PassRegistry::getPassRegistry());
   }
   bool runOnModule(Module &M) override {
-ModuleSanitizerCoverage ModuleSancov(Options);
+ModuleSanitizerCoverage ModuleSancov(Options, Whitelist.get(),
+ Blacklist.get());
 auto DTCallback = [this](Function &F) -> const DominatorTree * {
   return &this->getAnalysis(F).getDomTree();
 };
@@ -295,6 +314,9 @@
 
 private:
   SanitizerCoverageOptions Options;
+
+  std::unique_ptr Whitelist;
+  std::unique_ptr Blacklist;
 };
 
 } // namespace
@@ -374,6 +396,12 @@
 Module &M, DomTreeCallback DTCallback, PostDomTreeCallback PDTCallback) {
   if (Options.CoverageType == SanitizerCoverageOptions::SCK_None)
 return false;
+  if (Whitelist &&
+  !Whitelist->inSection("coverage", "src", M.getSourceFileName()))
+return false;
+  if (Blacklist &&
+  Blacklist->inSection("coverage", "src", M.getSourceFileName()))
+return false;
   C = &(M.getContext());
   DL = &M.getDataLayout();
   CurModule = &M;
@@ -611,6 +639,10 @@
   if (F.hasPersonalityFn() &&
   isAsynchronousEHPersonality(classifyEHPersonality(F.getPersonalityFn(
 return;
+  if (Whitelist && !Whitelist->inSection("coverage", "fun", F.getName()))
+return;
+  if (Blacklist && Blacklist->inSection("coverage", "fun", F.getName()))
+return;
   if (Options.CoverageType >= SanitizerCoverageOptions::SCK_Edge)
 SplitAllCriticalEdges(F, CriticalEdgeSplittingOptions().setIgnoreUnreachableDests());
   SmallVector IndirCalls;
@@ -976,6 +1008,9 @@
 "Pass for instrumenting coverage on functions", false,
 false)
 ModulePass *llvm::createModuleSanitizerCoverageLegacyPassPass(
-const SanitizerCoverageOptions &Options) {
-  return new ModuleSanitizerCoverageLegacyPass(Options);
+const SanitizerCoverageOpti

[PATCH] D76768: [analyzer] Added support of scan-build and exploded-graph-rewriter regression tests for Windows

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

In D76768#1974044 , @thakis wrote:

> If I add scan-build to clang/test/CMakeLists.txt and undo my other changes, 
> the test passes for me. I guess you always build that target, which is why 
> you didn't see this problem. But I wonder why this isn't needed on 
> non-Windows.


On non-Windows, %scan-build expands to clang/tools/scan-build/bin/scan-build 
directly, and so non-Windows doesn't require scan-build on the PATH (i.e. in 
bin/ in the build dir) since there's no scan-build.bat trampoline.

I wonder if %scan-build should expand to "perl 
clang/tools/scan-build/bin/scan-build" on Windows, instead of to 
scan-build.bat, so that the Windows setup is more similar to the non-Windows 
setup.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76768



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

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

[Luke Geeson via Phabricator via cfe-commits]

LukeGeeson created this revision.
LukeGeeson added reviewers: ostannard, t.p.northover.
Herald added subscribers: cfe-commits, danielkiss, hiraditya, kristof.beyls.
Herald added a reviewer: rengolin.
Herald added a project: clang.
LukeGeeson added a parent revision: D77540: [PATCH] [ARM]: Armv8.6-a Matrix Mul 
Asm and Intrinsics Support.
LukeGeeson added a child revision: D77872: [AArch32] Armv8.6-a Matrix Mult 
Assembly + Intrinsics.

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

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

This patch includes:

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

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

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

Based on work by:

- Luke Geeson
- Oliver Stannard
- Luke Cheeseman


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D77871

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

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

[PATCH] D76768: [analyzer] Added support of scan-build and exploded-graph-rewriter regression tests for Windows

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov added a comment.

@thakis
Let me explain what works for me.
This is in my **PATH**:

- C:\Perl\c\bin
- C:\Perl\perl\site\bin
- C:\Perl\perl\bin
- D:\llvm-project\buildn\bin

This is what in D:\llvm-project\buildn\bin (all this is a product of ninja+gcc):

- clang.exe
- FileCheck.exe
- scan-build.bat
- scan-build
- llvm-lit.py

No additional changes required (CMakeList.txt, bat editing, etc.).
Than I run command promt from arbitrary dir and run next: //llvm-lit.py 
D:/llvm-project/clang/test/Analysis/scan-build/exclude_directories.test//
Test passes. Done.
I hope it will help.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76768



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

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

[Luke Geeson via Phabricator via cfe-commits]

LukeGeeson created this revision.
LukeGeeson added a reviewer: t.p.northover.
Herald added subscribers: cfe-commits, danielkiss, hiraditya, kristof.beyls.
Herald added a project: clang.
LukeGeeson added a parent revision: D77871: [AArch64] Armv8.6-a Matrix Mult 
Assembly + Intrinsics.
LukeGeeson added a child revision: D77873: [AArch64] Armv8.6-A Mat Mul SVE 
Assembly.

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

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

This patch includes:

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

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

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

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

Based on work by:

- Luke Geeson
- Oliver Stannard
- Luke Cheeseman


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D77872

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

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

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

[Luke Geeson via Phabricator via cfe-commits]

LukeGeeson created this revision.
LukeGeeson added a reviewer: t.p.northover.
Herald added subscribers: cfe-commits, danielkiss, kristof.beyls.
Herald added a project: clang.
LukeGeeson added a parent revision: D77874:  [AArch32] Armv8.6a Matrix Mul 
Assembly.

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

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

This patch includes:

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

Note: +f32mm and +f64mm are optional and so have
to be enabled by default

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

Based on work by:

- Luke Geeson
- Oliver Stannard
- Luke Cheeseman


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D77875

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

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

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

[Luke Geeson via Phabricator via cfe-commits]

LukeGeeson added a comment.

Hi folks,
Thank you for your help, I have split the patches up as follows:

1. https://reviews.llvm.org/D77871 [AArch64] Armv8.6-a Matrix Mult Assembly + 
Intrinsics
2. https://reviews.llvm.org/D77872 [AArch32] Armv8.6-a Matrix Mult Assembly + 
Intrinsics
3. https://reviews.llvm.org/D77873 [AArch64] Armv8.6-A Mat Mul SVE Assembly
4. https://reviews.llvm.org/D77874 [AArch32] Armv8.6a Matrix Mul Assembly
5. https://reviews.llvm.org/D77875 [ARM] Armv8.6-a Matrix Mul cmd line support

In detail this covers the intrinsics (with minimum llvm backend needed to build 
and pass tests), SVE Assembly, (non-SVE) Assembly, and command-line support to 
enable the use of this extension. I mentioned above that there was so little 
intrinsics work needed and so the natural way to split up this patch was to 
include the llvm code needed to get each patch to build in the order above.

I'd appreciate any help you can give reviewing these!


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

https://reviews.llvm.org/D77540



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

[PATCH] D77062: [analyzer] Added check for unacceptable equality operation between Loc and NonLoc types

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov added a comment.

@NoQ , 
sorry for the late response, was working on other patch.

> Why are we getting a compound value here?

We are getting **nonloc::SymbolVal** here, not a compound value, since //* 
*ptr// result is unknown after //*ptr = foo();// (look at the test sample).
The root cause was that we compared **nonloc** with Zero sval which was **loc** 
and we got an assertion as a result.
Here I've improved and simplified a bit and now it is handles OK without 
assertions and passes all the tests.
 What do you think, is it worth to be landed?


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

https://reviews.llvm.org/D77062



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

[PATCH] D77632: [TLI] Per-function fveclib for math library used for vectorization

[Wenlei He via Phabricator via cfe-commits]

wenlei added a comment.

In D77632#1974015 , @nikic wrote:

> This change causes a ~0.5% compile-time regressions: 
> http://llvm-compile-time-tracker.com/compare.php?from=5b18b6e9a84d985c0a907009fb71de7c1943bc88&to=60c642e74be6af86906d9f3d982728be7bd4329f&stat=instructions
>  This is quite a lot as these things go, so it would be great if you could 
> double check if there's any optimization potential here. In particular I'm 
> wondering why this affects normal builds so much, even though they 
> (presumably?) don't use any veclib at all.


Thanks for the heads-up. This is surprising but there is a change even when 
veclib is not used - in order to allow each function to use different veclib 
without duplicating the work of populating vector function list for each 
function, we now always pre-populate vector function list for three supported 
vector libraries for each module. However 0.5% compile-time for that work given 
it's per-module is not expected. I suspect we may be passing/copying TLII 
around more than we anticipated (now we always have more stuff to copy). I will 
take a look. We could also turn this into a lazy initialization - only populate 
the needed list for module level TLII when it's first queried by a function 
level TLI.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77632



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

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

[Luke Geeson via Phabricator via cfe-commits]

LukeGeeson added a comment.

Harbourmaster now biulds, and unit tests pass, errors related to linting


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77872



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

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

[Luke Geeson via Phabricator via cfe-commits]

LukeGeeson added a comment.

Removed reliance on parent revision, harbormaster now builds with unit tests 
passing


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77871



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

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

[Luke Geeson via Phabricator via cfe-commits]

LukeGeeson added a comment.

harbour master builds, unit tests passing, failures down to linting


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77875



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

[PATCH] D77632: [TLI] Per-function fveclib for math library used for vectorization

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson added a comment.

In D77632#1974363 , @wenlei wrote:

> In D77632#1974015 , @nikic wrote:
>
> > This change causes a ~0.5% compile-time regressions: 
> > http://llvm-compile-time-tracker.com/compare.php?from=5b18b6e9a84d985c0a907009fb71de7c1943bc88&to=60c642e74be6af86906d9f3d982728be7bd4329f&stat=instructions
> >  This is quite a lot as these things go, so it would be great if you could 
> > double check if there's any optimization potential here. In particular I'm 
> > wondering why this affects normal builds so much, even though they 
> > (presumably?) don't use any veclib at all.
>
>
> Thanks for the heads-up. This is surprising but there is a change even when 
> veclib is not used - in order to allow each function to use different veclib 
> without duplicating the work of populating vector function list for each 
> function, we now always pre-populate vector function list for three supported 
> vector libraries for each module. However 0.5% compile-time for that work 
> given it's per-module is not expected. I suspect we may be passing/copying 
> TLII around more than we anticipated (now we always have more stuff to copy). 
> I will take a look. We could also turn this into a lazy initialization - only 
> populate the needed list for module level TLII when it's first queried by a 
> function level TLI.


Hmm, yeah that is surprising, because the TLII should be built once per module 
per TLI analysis, which is never invalidated. We've gone from populating one 
set of vec libs to 3, I wouldn't have thought that was particularly expensive, 
so it would be good to see what is going on here and confirm we are only 
building this once as expected.

Looking at the compile time data at that link, interestingly the "instructions" 
metric increased, but not wall time or cycles or task clock - they were all 
neutral.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77632



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

[clang-tools-extra] 89f1321 - [clang-tidy] Add check to find calls to NSInvocation methods under ARC that don't have proper object argument lifetimes.

[Michael Wyman via cfe-commits]

Author: Michael Wyman
Date: 2020-04-10T08:51:21-07:00
New Revision: 89f1321fe4ef203a4674213280b430a274dc2001

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

LOG: [clang-tidy] Add check to find calls to NSInvocation methods under ARC 
that don't have proper object argument lifetimes.

Summary: This check is similar to an ARC Migration check that warned about this 
incorrect usage under ARC, but most projects are no longer undergoing migration 
from pre-ARC code. The documentation for NSInvocation is not explicit about 
these requirements and incorrect usage has been found in many of our projects.

Reviewers: stephanemoore, benhamilton, dmaclach, alexfh, aaron.ballman, hokein, 
njames93

Reviewed By: stephanemoore, benhamilton, aaron.ballman

Subscribers: xazax.hun, Eugene.Zelenko, mgorny, cfe-commits

Tags: #clang, #clang-tools-extra

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

Added: 
clang-tools-extra/clang-tidy/objc/NSInvocationArgumentLifetimeCheck.cpp
clang-tools-extra/clang-tidy/objc/NSInvocationArgumentLifetimeCheck.h

clang-tools-extra/docs/clang-tidy/checks/objc-nsinvocation-argument-lifetime.rst

clang-tools-extra/test/clang-tidy/checkers/objc-nsinvocation-argument-lifetime.m

Modified: 
clang-tools-extra/clang-tidy/objc/CMakeLists.txt
clang-tools-extra/clang-tidy/objc/ObjCTidyModule.cpp
clang-tools-extra/docs/ReleaseNotes.rst
clang-tools-extra/docs/clang-tidy/checks/list.rst

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/objc/CMakeLists.txt 
b/clang-tools-extra/clang-tidy/objc/CMakeLists.txt
index 9b010f069cde..5c6c5057174f 100644
--- a/clang-tools-extra/clang-tidy/objc/CMakeLists.txt
+++ b/clang-tools-extra/clang-tidy/objc/CMakeLists.txt
@@ -8,6 +8,7 @@ add_clang_library(clangTidyObjCModule
   DeallocInCategoryCheck.cpp
   ForbiddenSubclassingCheck.cpp
   MissingHashCheck.cpp
+  NSInvocationArgumentLifetimeCheck.cpp
   ObjCTidyModule.cpp
   PropertyDeclarationCheck.cpp
   SuperSelfCheck.cpp

diff  --git 
a/clang-tools-extra/clang-tidy/objc/NSInvocationArgumentLifetimeCheck.cpp 
b/clang-tools-extra/clang-tidy/objc/NSInvocationArgumentLifetimeCheck.cpp
new file mode 100644
index ..520bdc3b9f12
--- /dev/null
+++ b/clang-tools-extra/clang-tidy/objc/NSInvocationArgumentLifetimeCheck.cpp
@@ -0,0 +1,146 @@
+//===--- NSInvocationArgumentLifetimeCheck.cpp - clang-tidy -===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "NSInvocationArgumentLifetimeCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/Attrs.inc"
+#include "clang/AST/ComputeDependence.h"
+#include "clang/AST/Decl.h"
+#include "clang/AST/Expr.h"
+#include "clang/AST/ExprObjC.h"
+#include "clang/AST/Type.h"
+#include "clang/AST/TypeLoc.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/ASTMatchers/ASTMatchersMacros.h"
+#include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/LLVM.h"
+#include "clang/Basic/LangOptions.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/SourceManager.h"
+#include "llvm/ADT/None.h"
+#include "llvm/ADT/Optional.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace objc {
+namespace {
+
+static constexpr StringRef WeakText = "__weak";
+static constexpr StringRef StrongText = "__strong";
+static constexpr StringRef UnsafeUnretainedText = "__unsafe_unretained";
+
+/// Matches ObjCIvarRefExpr, DeclRefExpr, or MemberExpr that reference
+/// Objective-C object (or block) variables or fields whose object lifetimes
+/// are not __unsafe_unretained.
+AST_POLYMORPHIC_MATCHER(isObjCManagedLifetime,
+AST_POLYMORPHIC_SUPPORTED_TYPES(ObjCIvarRefExpr,
+DeclRefExpr,
+MemberExpr)) {
+  QualType QT = Node.getType();
+  return QT->isScalarType() &&
+ (QT->getScalarTypeKind() == Type::STK_ObjCObjectPointer ||
+  QT->getScalarTypeKind() == Type::STK_BlockPointer) &&
+ QT.getQualifiers().getObjCLifetime() > Qualifiers::OCL_ExplicitNone;
+}
+
+static llvm::Optional
+fixItHintReplacementForOwnershipString(StringRef Text, CharSourceRange Range,
+   StringRef Ownership) {
+  size_t Index = Text.find(Ownership);
+  if (Index == StringRef::npos)
+return llvm::None;
+
+  SourceLocation Begin = Ra

[PATCH] D77880: get scan-view executable from environment

[Oliver Tušla via Phabricator via cfe-commits]

asmar created this revision.
asmar added a reviewer: NoQ.
Herald added subscribers: cfe-commits, Charusso.
Herald added a project: clang.

Fixes "Use of uninitialized value $ScanView in exec" error on systems with 
scan-view executable not located in the expected place.

Currently when scan-build is installed in Debian-like (Ubuntu 18.04 my case) 
system the scan-view executable is not correctly identified when installed by 
apt from clang-tools package.

The buggy code was first introduced here 10 ago:

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

The issue was recently reported on Debian Bugs:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941614

The problem lies in current master scan-build:974:

https://github.com/llvm/llvm-project/blob/350522670232c74587138dc83161de514567f411/clang/tools/scan-build/bin/scan-build#L974

Searching for "$RealBin/../../scan-view/bin/scan-view" may not work in such 
cases because directories are versioned e.g. 
"$RealBin/../../scan-view-6.0/bin/scan-view".


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D77880

Files:
  clang/tools/scan-build/bin/scan-build


Index: clang/tools/scan-build/bin/scan-build
===
--- clang/tools/scan-build/bin/scan-build
+++ clang/tools/scan-build/bin/scan-build
@@ -971,6 +971,7 @@
 my $ScanView = Cwd::realpath("$RealBin/scan-view");
 if (! -x $ScanView) { $ScanView = "scan-view"; }
 if (! -x $ScanView) { $ScanView = 
Cwd::realpath("$RealBin/../../scan-view/bin/scan-view"); }
+if (! -x $ScanView) { $ScanView = `which scan-view`; chomp $ScanView; }
 exec $ScanView, "$Options{OutputDir}";
   }
 


Index: clang/tools/scan-build/bin/scan-build
===
--- clang/tools/scan-build/bin/scan-build
+++ clang/tools/scan-build/bin/scan-build
@@ -971,6 +971,7 @@
 my $ScanView = Cwd::realpath("$RealBin/scan-view");
 if (! -x $ScanView) { $ScanView = "scan-view"; }
 if (! -x $ScanView) { $ScanView = Cwd::realpath("$RealBin/../../scan-view/bin/scan-view"); }
+if (! -x $ScanView) { $ScanView = `which scan-view`; chomp $ScanView; }
 exec $ScanView, "$Options{OutputDir}";
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D77571: [clang-tidy] Add check to find calls to NSInvocation methods under ARC that don't have proper object argument lifetimes.

[Michael Wyman via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG89f1321fe4ef: [clang-tidy] Add check to find calls to 
NSInvocation methods under ARC that… (authored by mwyman).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77571

Files:
  clang-tools-extra/clang-tidy/objc/CMakeLists.txt
  clang-tools-extra/clang-tidy/objc/NSInvocationArgumentLifetimeCheck.cpp
  clang-tools-extra/clang-tidy/objc/NSInvocationArgumentLifetimeCheck.h
  clang-tools-extra/clang-tidy/objc/ObjCTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/docs/clang-tidy/checks/objc-nsinvocation-argument-lifetime.rst
  
clang-tools-extra/test/clang-tidy/checkers/objc-nsinvocation-argument-lifetime.m

Index: clang-tools-extra/test/clang-tidy/checkers/objc-nsinvocation-argument-lifetime.m
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/objc-nsinvocation-argument-lifetime.m
@@ -0,0 +1,103 @@
+// RUN: %check_clang_tidy %s objc-nsinvocation-argument-lifetime %t
+
+__attribute__((objc_root_class))
+@interface NSObject
+@end
+
+@interface NSInvocation : NSObject
+- (void)getArgument:(void *)Arg atIndex:(int)Index;
+- (void)getReturnValue:(void *)ReturnValue;
+@end
+
+@interface OtherClass : NSObject
+- (void)getArgument:(void *)Arg atIndex:(int)Index;
+@end
+
+struct Foo {
+  __unsafe_unretained id Field1;
+  id Field2;
+  int IntField;
+};
+
+void foo(NSInvocation *Invocation) {
+  __unsafe_unretained id Arg2;
+  id Arg3;
+  // CHECK-FIXES: __unsafe_unretained id Arg3;
+  NSObject __strong *Arg4;
+  // CHECK-FIXES: NSObject __unsafe_unretained *Arg4;
+  __weak id Arg5;
+  // CHECK-FIXES: __unsafe_unretained id Arg5;
+  id ReturnValue;
+  // CHECK-FIXES: __unsafe_unretained id ReturnValue;
+  void (^BlockArg1)();
+  // CHECK-FIXES: __unsafe_unretained void (^BlockArg1)();
+  __unsafe_unretained void (^BlockArg2)();
+  int IntVar;
+  struct Foo Bar;
+
+  [Invocation getArgument:&Arg2 atIndex:2];
+  [Invocation getArgument:&IntVar atIndex:2];
+
+  [Invocation getArgument:&Arg3 atIndex:3];
+  // CHECK-MESSAGES: :[[@LINE-1]]:27: warning: NSInvocation '-getArgument:atIndex:' should only pass pointers to objects with ownership __unsafe_unretained [objc-nsinvocation-argument-lifetime]
+
+  [Invocation getArgument:&Arg4 atIndex:4];
+  // CHECK-MESSAGES: :[[@LINE-1]]:27: warning: NSInvocation '-getArgument:atIndex:' should only pass pointers to objects with ownership __unsafe_unretained [objc-nsinvocation-argument-lifetime]
+
+  [Invocation getArgument:&Arg5 atIndex:5];
+  // CHECK-MESSAGES: :[[@LINE-1]]:27: warning: NSInvocation '-getArgument:atIndex:' should only pass pointers to objects with ownership __unsafe_unretained [objc-nsinvocation-argument-lifetime]
+
+  [Invocation getArgument:&BlockArg1 atIndex:6];
+  // CHECK-MESSAGES: :[[@LINE-1]]:27: warning: NSInvocation '-getArgument:atIndex:' should only pass pointers to objects with ownership __unsafe_unretained [objc-nsinvocation-argument-lifetime]
+
+  [Invocation getArgument:&BlockArg2 atIndex:6];
+
+  [Invocation getReturnValue:&ReturnValue];
+  // CHECK-MESSAGES: :[[@LINE-1]]:30: warning: NSInvocation '-getReturnValue:' should only pass pointers to objects with ownership __unsafe_unretained [objc-nsinvocation-argument-lifetime]
+
+  [Invocation getArgument:(void *)0 atIndex:6];
+
+  [Invocation getArgument:&Bar.Field1 atIndex:2];
+  [Invocation getArgument:&Bar.Field2 atIndex:2];
+  // CHECK-MESSAGES: :[[@LINE-1]]:27: warning: NSInvocation '-getArgument:atIndex:' should only pass pointers to objects with ownership __unsafe_unretained [objc-nsinvocation-argument-lifetime]
+  [Invocation getArgument:&Bar.IntField atIndex:2];
+}
+
+void bar(OtherClass *OC) {
+  id Arg;
+  [OC getArgument:&Arg atIndex:2];
+}
+
+@interface TestClass : NSObject {
+@public
+  id Argument1;
+  __unsafe_unretained id Argument2;
+  struct Foo Bar;
+  int IntIvar;
+}
+@end
+
+@implementation TestClass
+
+- (void)processInvocation:(NSInvocation *)Invocation {
+  [Invocation getArgument:&Argument1 atIndex:2];
+  // CHECK-MESSAGES: :[[@LINE-1]]:27: warning: NSInvocation '-getArgument:atIndex:' should only pass pointers to objects with ownership __unsafe_unretained [objc-nsinvocation-argument-lifetime]
+  [Invocation getArgument:&self->Argument1 atIndex:2];
+  // CHECK-MESSAGES: :[[@LINE-1]]:27: warning: NSInvocation '-getArgument:atIndex:' should only pass pointers to objects with ownership __unsafe_unretained [objc-nsinvocation-argument-lifetime]
+  [Invocation getArgument:&Argument2 atIndex:2];
+  [Invocation getArgument:&self->Argument2 atIndex:2];
+  [Invocation getArgument:&self->IntIvar atIndex:2];
+
+  [Invocation getReturnValue:&(self->Bar.Field1)];
+  [Invocation getReturnValue:&(self->Bar.Field2)];
+  // CHECK-MESSAGES: :[[@LINE-1]]:30: warning: NSI

[PATCH] D77682: [clang-format] Always break line after enum opening brace

[Omar Sandoval via Phabricator via cfe-commits]

osandov added a comment.

Thank you! I don't have commit access. How can I get this committed?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77682



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

[PATCH] D77802: [analyzer] Improved RangeSet::Negate support of unsigned ranges

[Balázs Benics via Phabricator via cfe-commits]

steakhal added a comment.

It took me some time to understand what you were doing.
Probably a bit ASCII-art would have had help (eg. about the wrapping behavior).

By the same token, I wouldn't mind more tests, especially exercising the 
implemented behavior.
Probably `unit-tests` would fit better than `lit-tests` for this purpose.
Eg. showing that if the `RangeSet`  includes the `MIN`, then the negated 
`RangeSet` also includes that.
And the negated RangeSet really unites consecutive ranges.

Please note that **I'm not a math expert** and I haven't spent much time 
working with `RangeSets`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77802



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

[PATCH] D77545: Represent FP options in AST by special Expression node

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

> ! In D77545#1973765 , @sepavloff 
> wrote:
> 
>> ! In D77545#1973169 , @rjmccall 
>> wrote:
>>  all of which will just do the wrong thing if they don't preserve and pass 
>> down the right information.  It's extremely error-prone, and I don't see a 
>> way to make it not error-prone.
> 
> Actually support of FP environment is very similar to scope mechanism. It is 
> changed *only* at compound statement entry or exit. We already have many RAII 
> objects that facilitate this maintenance

Okay, so you're proposing that we maintain global state in the ASTContext for 
what pragmas are in effect, managed by RAII objects, rather than passing the 
current pragma state in as an argument.  I agree that this is relatively 
straightforward for clients to support if they're just performing a recursive 
walk.  However, it is extremely susceptible to bugs where the current context 
is incorrectly applied to expressions written in a different context.

For example, in this code:

  const float global = 2.22 + 3.33;
  
  #pragma STDV FENV_ROUND 
  float getGlobal() { return global; }

The code-generation of `getGlobal` will attempt to constant-evaluate the 
initializer of `global` so that it can just return a constant instead of 
emitting a load from a global.  It is important for correctness that this 
constant-evaluation occur in the default FP environment, not the active FP 
environment at the point of use.  Presumably you are not proposing that 
`global`'s initializer is a `PragmaExpr`, since it's in the default 
environment.  Perhaps we can recognize by the *absence* of a `PragmaExpr` that 
it's meant to use the default environment?  It's not clear at what level we 
would trigger this check, however.  Is it now semantically important that we 
call a method like `VarDecl::evaluateValue()` rather than 
`Expr::EvaluateAsFloat(...)`?  What happens with variables in local scope?  A 
local variable could be from a scope outside the current pragma, so presumably 
we need to introduce `PragmaExpr`s on the initializers of all variables within 
pragmas.

This sort of problem is why having the pragma state be an argument rather than 
global state is so much more attractive.  And making it an argument is much 
more disruptive for clients, who must now do their own tracking, and recreate 
the state appropriately when calling outside the context.

Storing the pragma state in the expressions avoids these problems much more 
cleanly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77545



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

[PATCH] D77882: [clang-tidy] Add option to use alpha checkers from clang-analyzer when using `run-clang-tidy.py`

[Andi via Phabricator via cfe-commits]

Abpostelnicu created this revision.
Abpostelnicu added a reviewer: JonasToth.
Herald added subscribers: cfe-commits, ASDenysPetrov, Charusso, dkrupp, 
donat.nagy, Szelethus, a.sidorin, baloghadamsoftware, xazax.hun.
Herald added a project: clang.
Abpostelnicu edited the summary of this revision.
Abpostelnicu edited the summary of this revision.

Add option to use alpha checkers from clang-analyzer when using 
`run-clang-tidy.py`.
In D46159  has been added the possibility to 
use alpha checkers from `clang-analyzer` but this option hasn't reach 
`run-clang-tidy.py`, the purpose of this patch is to have this option.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D77882

Files:
  clang-tools-extra/clang-tidy/tool/run-clang-tidy.py


Index: clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
===
--- clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
+++ clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
@@ -78,10 +78,12 @@
 
 
 def get_tidy_invocation(f, clang_tidy_binary, checks, tmpdir, build_path,
-header_filter, extra_arg, extra_arg_before, quiet,
-config):
+header_filter, allow_enabling_alpha_checkers,
+extra_arg, extra_arg_before, quiet, config):
   """Gets a command line for clang-tidy."""
   start = [clang_tidy_binary]
+  if allow_enabling_alpha_checkers is not None:
+start.append('-allow-enabling-analyzer-alpha-checkers')
   if header_filter is not None:
 start.append('-header-filter=' + header_filter)
   if checks:
@@ -159,6 +161,7 @@
 name = queue.get()
 invocation = get_tidy_invocation(name, args.clang_tidy_binary, args.checks,
  tmpdir, build_path, args.header_filter,
+ args.allow_enabling_alpha_checkers,
  args.extra_arg, args.extra_arg_before,
  args.quiet, args.config)
 
@@ -179,6 +182,9 @@
'in a compilation database. Requires '
'clang-tidy and clang-apply-replacements in 
'
'$PATH.')
+  parser.add_argument('-allow-enabling-alpha-checkers',
+  action='store_true', help='allow alpha checkers from '
+'clang-analyzer.')
   parser.add_argument('-clang-tidy-binary', metavar='PATH',
   default='clang-tidy',
   help='path to clang-tidy binary')
@@ -238,6 +244,8 @@
 
   try:
 invocation = [args.clang_tidy_binary, '-list-checks']
+if args.allow_enabling_alpha_checkers:
+  invocation.append('-allow-enabling-analyzer-alpha-checkers')
 invocation.append('-p=' + build_path)
 if args.checks:
   invocation.append('-checks=' + args.checks)


Index: clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
===
--- clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
+++ clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
@@ -78,10 +78,12 @@
 
 
 def get_tidy_invocation(f, clang_tidy_binary, checks, tmpdir, build_path,
-header_filter, extra_arg, extra_arg_before, quiet,
-config):
+header_filter, allow_enabling_alpha_checkers,
+extra_arg, extra_arg_before, quiet, config):
   """Gets a command line for clang-tidy."""
   start = [clang_tidy_binary]
+  if allow_enabling_alpha_checkers is not None:
+start.append('-allow-enabling-analyzer-alpha-checkers')
   if header_filter is not None:
 start.append('-header-filter=' + header_filter)
   if checks:
@@ -159,6 +161,7 @@
 name = queue.get()
 invocation = get_tidy_invocation(name, args.clang_tidy_binary, args.checks,
  tmpdir, build_path, args.header_filter,
+ args.allow_enabling_alpha_checkers,
  args.extra_arg, args.extra_arg_before,
  args.quiet, args.config)
 
@@ -179,6 +182,9 @@
'in a compilation database. Requires '
'clang-tidy and clang-apply-replacements in '
'$PATH.')
+  parser.add_argument('-allow-enabling-alpha-checkers',
+  action='store_true', help='allow alpha checkers from '
+'clang-analyzer.')
   parser.add_argument('-clang-tidy-binary', metavar='PATH',
   default='clang-tidy',
   help='path to clang-tidy binary')
@@ -238,6 +244,8 @@
 
   try:
 invocation = [args.clang_tidy_binary, '-list-checks']
+if args.allow_enabling_alpha

[PATCH] D77885: AMDGPU: Search for new ROCm bitcode library structure

[Matt Arsenault via Phabricator via cfe-commits]

arsenm created this revision.
arsenm added reviewers: yaxunl, b-sumner, hliao.
Herald added subscribers: kerbowa, t-tye, tpr, dstuttard, nhaehnle, wdng, 
jvesely, kzhuravl.

The current install situation is a mess, but I'm working on fixing
it. Search for the target layout instead of one of the N options that
exist today.


https://reviews.llvm.org/D77885

Files:
  clang/lib/Driver/ToolChains/AMDGPU.cpp
  clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/hip.bc
  clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/ockl.bc
  
clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_correctly_rounded_sqrt_off.bc
  
clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_correctly_rounded_sqrt_on.bc
  clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_daz_opt_off.bc
  clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_daz_opt_on.bc
  
clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_finite_only_off.bc
  
clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_finite_only_on.bc
  
clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_isa_version_1010.bc
  
clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_isa_version_1011.bc
  
clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_isa_version_1012.bc
  
clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_isa_version_803.bc
  
clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_isa_version_900.bc
  
clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_unsafe_math_off.bc
  
clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_unsafe_math_on.bc
  
clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_wavefrontsize64_off.bc
  
clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_wavefrontsize64_on.bc
  clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/ocml.bc
  clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/opencl.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/hip.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/ockl.amdgcn.bc
  
clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_correctly_rounded_sqrt_off.amdgcn.bc
  
clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_correctly_rounded_sqrt_on.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_daz_opt_off.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_daz_opt_on.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_finite_only_off.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_finite_only_on.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_isa_version_1010.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_isa_version_1011.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_isa_version_1012.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_isa_version_803.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_isa_version_900.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_unsafe_math_off.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_unsafe_math_on.amdgcn.bc
  
clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_wavefrontsize64_off.amdgcn.bc
  
clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_wavefrontsize64_on.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/ocml.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/opencl.amdgcn.bc


Index: clang/lib/Driver/ToolChains/AMDGPU.cpp
===
--- clang/lib/Driver/ToolChains/AMDGPU.cpp
+++ clang/lib/Driver/ToolChains/AMDGPU.cpp
@@ -65,30 +65,18 @@
 if (InstallPath.empty() || !D.getVFS().exists(InstallPath))
   continue;
 
-// FIXME: The install path situation is a real mess.
-
-// For a cmake install, these are placed directly in
-// ${INSTALL_PREFIX}/lib
-
-// In the separate OpenCL builds, the bitcode libraries are placed in
-// ${OPENCL_ROOT}/lib/x86_64/bitcode/*
-
-// For the rocm installed packages, these are placed at
-// /opt/rocm/opencl/lib/x86_64/bitcode
-
-// An additional copy is installed, in scattered locations between
-// /opt/rocm/hcc/rocdl/oclc
-// /opt/rocm/hcc/rocdl/ockl
-// /opt/rocm/hcc/rocdl/lib
+// The install path situation in old versions of ROCm is a real mess, and
+// use a different install layout. Multiple copies of the device libraries
+// exist for each frontend project, and differ depending on which build
+// system produced the packages. Standalone OpenCL builds also have a
+// different directory structure from the ROCm OpenCL package.
 //
-// Yet another complete set is installed to
-// /opt/rocm/hcc/rocdl/lib
-
-// For now just recognize the opencl package layout.
+// The desired structure is (${ROCM_ROOT} or
+// ${OPENCL_ROOT})/amdgcn/bitcode/*, so try to detect this layout.
 
 // BinPath = InstallPath + "/bin";
 llvm::sys::path::append(IncludeP

[PATCH] D77885: AMDGPU: Search for new ROCm bitcode library structure

[Matt Arsenault via Phabricator via cfe-commits]

arsenm updated this revision to Diff 256598.
arsenm added a comment.

Forgot to commit part


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

https://reviews.llvm.org/D77885

Files:
  clang/lib/Driver/ToolChains/AMDGPU.cpp
  clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/hip.bc
  clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/ockl.bc
  
clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_correctly_rounded_sqrt_off.bc
  
clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_correctly_rounded_sqrt_on.bc
  clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_daz_opt_off.bc
  clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_daz_opt_on.bc
  
clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_finite_only_off.bc
  
clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_finite_only_on.bc
  
clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_isa_version_1010.bc
  
clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_isa_version_1011.bc
  
clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_isa_version_1012.bc
  
clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_isa_version_803.bc
  
clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_isa_version_900.bc
  
clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_unsafe_math_off.bc
  
clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_unsafe_math_on.bc
  
clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_wavefrontsize64_off.bc
  
clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/oclc_wavefrontsize64_on.bc
  clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/ocml.bc
  clang/test/Driver/Inputs/rocm-device-libs/amdgcn/bitcode/opencl.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/hip.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/ockl.amdgcn.bc
  
clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_correctly_rounded_sqrt_off.amdgcn.bc
  
clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_correctly_rounded_sqrt_on.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_daz_opt_off.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_daz_opt_on.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_finite_only_off.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_finite_only_on.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_isa_version_1010.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_isa_version_1011.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_isa_version_1012.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_isa_version_803.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_isa_version_900.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_unsafe_math_off.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_unsafe_math_on.amdgcn.bc
  
clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_wavefrontsize64_off.amdgcn.bc
  
clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_wavefrontsize64_on.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/ocml.amdgcn.bc
  clang/test/Driver/Inputs/rocm-device-libs/lib/opencl.amdgcn.bc
  clang/test/Driver/rocm-device-libs.cl

Index: clang/test/Driver/rocm-device-libs.cl
===
--- clang/test/Driver/rocm-device-libs.cl
+++ clang/test/Driver/rocm-device-libs.cl
@@ -121,43 +121,43 @@
 
 
 // COMMON: "-triple" "amdgcn-amd-amdhsa"
-// COMMON-SAME: "-mlink-builtin-bitcode" "{{.*}}/lib/opencl.amdgcn.bc"
-// COMMON-SAME: "-mlink-builtin-bitcode" "{{.*}}/lib/ocml.amdgcn.bc"
-// COMMON-SAME: "-mlink-builtin-bitcode" "{{.*}}/lib/ockl.amdgcn.bc"
+// COMMON-SAME: "-mlink-builtin-bitcode" "{{.*}}/amdgcn/bitcode/opencl.bc"
+// COMMON-SAME: "-mlink-builtin-bitcode" "{{.*}}/amdgcn/bitcode/ocml.bc"
+// COMMON-SAME: "-mlink-builtin-bitcode" "{{.*}}/amdgcn/bitcode/ockl.bc"
 
-// GFX900-DEFAULT-SAME: "-mlink-builtin-bitcode" "{{.*}}/lib/oclc_daz_opt_off.amdgcn.bc"
-// GFX803-DEFAULT-SAME: "-mlink-builtin-bitcode" "{{.*}}/lib/oclc_daz_opt_on.amdgcn.bc"
-// GFX700-DEFAULT-SAME: "-mlink-builtin-bitcode" "{{.*}}/lib/oclc_daz_opt_on.amdgcn.bc"
-// COMMON-DAZ-SAME: "-mlink-builtin-bitcode" "{{.*}}/lib/oclc_daz_opt_on.amdgcn.bc"
+// GFX900-DEFAULT-SAME: "-mlink-builtin-bitcode" "{{.*}}/amdgcn/bitcode/oclc_daz_opt_off.bc"
+// GFX803-DEFAULT-SAME: "-mlink-builtin-bitcode" "{{.*}}/amdgcn/bitcode/oclc_daz_opt_on.bc"
+// GFX700-DEFAULT-SAME: "-mlink-builtin-bitcode" "{{.*}}/amdgcn/bitcode/oclc_daz_opt_on.bc"
+// COMMON-DAZ-SAME: "-mlink-builtin-bitcode" "{{.*}}/amdgcn/bitcode/oclc_daz_opt_on.bc"
 
 
-// COMMON-DEFAULT-SAME: "-mlink-builtin-bitcode" "{{.*}}/lib/oclc_unsafe_math_off.amdgcn.bc"
-// COMMON-DEFAULT-SAME: "-mlink-builtin-bitcode" "{{.*}}/lib/oclc_finite_only_off.amdgcn.bc"
-// COMMON-DEFAULT-SAME: "-mlink-builtin-bitcode" "{{.*}}/lib/oclc_correctly_rounded_sqrt_o

[clang] 4593e41 - AMDGPU: Teach toolchain to link rocm device libs

[Matt Arsenault via cfe-commits]

Author: Matt Arsenault
Date: 2020-04-10T13:37:32-04:00
New Revision: 4593e4131affa84e61d7b6844be409ba46d29f11

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

LOG: AMDGPU: Teach toolchain to link rocm device libs

Currently the library is separately linked, but this isn't correct to
implement fast math flags correctly. Each module should get the
version of the library appropriate for its combination of fast math
and related flags, with the attributes propagated into its functions
and internalized.

HIP already maintains the list of libraries, but this is not used for
OpenCL. Unfortunately, HIP uses a separate --hip-device-lib argument,
despite both languages using the same bitcode library. Eventually
these two searches need to be merged.

An additional problem is there are 3 different locations the libraries
are installed, depending on which build is used. This also needs to be
consolidated (or at least the search logic needs to deal with this
unnecessary complexity).

Added: 
clang/test/Driver/Inputs/rocm-device-libs/lib/hip.amdgcn.bc
clang/test/Driver/Inputs/rocm-device-libs/lib/ockl.amdgcn.bc

clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_correctly_rounded_sqrt_off.amdgcn.bc

clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_correctly_rounded_sqrt_on.amdgcn.bc
clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_daz_opt_off.amdgcn.bc
clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_daz_opt_on.amdgcn.bc
clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_finite_only_off.amdgcn.bc
clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_finite_only_on.amdgcn.bc

clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_isa_version_1010.amdgcn.bc

clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_isa_version_1011.amdgcn.bc

clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_isa_version_1012.amdgcn.bc
clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_isa_version_803.amdgcn.bc
clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_isa_version_900.amdgcn.bc
clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_unsafe_math_off.amdgcn.bc
clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_unsafe_math_on.amdgcn.bc

clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_wavefrontsize64_off.amdgcn.bc

clang/test/Driver/Inputs/rocm-device-libs/lib/oclc_wavefrontsize64_on.amdgcn.bc
clang/test/Driver/Inputs/rocm-device-libs/lib/ocml.amdgcn.bc
clang/test/Driver/Inputs/rocm-device-libs/lib/opencl.amdgcn.bc
clang/test/Driver/rocm-detect.cl
clang/test/Driver/rocm-device-libs.cl
clang/test/Driver/rocm-not-found.cl

Modified: 
clang/include/clang/Basic/DiagnosticDriverKinds.td
clang/include/clang/Driver/Options.td
clang/lib/Driver/Driver.cpp
clang/lib/Driver/ToolChains/AMDGPU.cpp
clang/lib/Driver/ToolChains/AMDGPU.h
clang/lib/Driver/ToolChains/HIP.cpp
clang/lib/Driver/ToolChains/HIP.h
clang/test/CodeGenOpenCL/amdgpu-debug-info-pointer-address-space.cl
clang/test/CodeGenOpenCL/amdgpu-debug-info-variable-expression.cl
clang/test/Driver/amdgpu-visibility.cl
llvm/include/llvm/Support/TargetParser.h
llvm/lib/Support/TargetParser.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticDriverKinds.td 
b/clang/include/clang/Basic/DiagnosticDriverKinds.td
index cba59cb3b66d..b28ee88f3d87 100644
--- a/clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ b/clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -55,6 +55,14 @@ def err_drv_no_cuda_installation : Error<
 def err_drv_no_cuda_libdevice : Error<
   "cannot find libdevice for %0. Provide path to 
diff erent CUDA installation "
   "via --cuda-path, or pass -nocudalib to build without linking with 
libdevice.">;
+
+def err_drv_no_rocm_installation : Error<
+  "cannot find ROCm installation.  Provide its path via --rocm-path, or pass "
+  "-nogpulib.">;
+def err_drv_no_rocm_device_lib : Error<
+  "cannot find device library for %0. Provide path to 
diff erent ROCm installation "
+  "via --rocm-path, or pass -nogpulib to build without linking default 
libraries.">;
+
 def err_drv_cuda_version_unsupported : Error<
   "GPU arch %0 is supported by CUDA versions between %1 and %2 (inclusive), "
   "but installation at %3 is %4. Use --cuda-path to specify a 
diff erent CUDA "

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 02875f68ebfe..661aad49a8ee 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -608,6 +608,8 @@ def : Flag<["-"], "fno-cuda-rdc">, Alias;
 def fcuda_short_ptr : Flag<["-"], "fcuda-short-ptr">, Flags<[CC1Option]>,
   HelpText<"Use 32-bit pointers for accessing const/local/shared address 
spaces.">;
 def fno_cuda_short

[PATCH] D59321: AMDGPU: Teach toolchain to link rocm device libs

[Matt Arsenault via Phabricator via cfe-commits]

arsenm closed this revision.
arsenm added a comment.

4593e4131affa84e61d7b6844be409ba46d29f11 



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

https://reviews.llvm.org/D59321



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

[PATCH] D63616: Implement `-fsanitize-coverage-whitelist` and `-fsanitize-coverage-blacklist` for clang

[Matt Morehouse via Phabricator via cfe-commits]

morehouse accepted this revision.
morehouse 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/D63616/new/

https://reviews.llvm.org/D63616



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

[PATCH] D63616: Implement `-fsanitize-coverage-whitelist` and `-fsanitize-coverage-blacklist` for clang

[Matt Morehouse via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGbef187c75090: Implement `-fsanitize-coverage-whitelist` and 
`-fsanitize-coverage-blacklist`… (authored by morehouse).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63616

Files:
  clang/docs/SanitizerCoverage.rst
  clang/include/clang/Basic/CodeGenOptions.h
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/include/clang/Driver/SanitizerArgs.h
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/SanitizerArgs.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  
compiler-rt/test/sanitizer_common/TestCases/sanitizer_coverage_whitelist_blacklist.cpp
  llvm/include/llvm/Transforms/Instrumentation/SanitizerCoverage.h
  llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp

Index: llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
===
--- llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
+++ llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
@@ -35,6 +35,8 @@
 #include "llvm/InitializePasses.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/Debug.h"
+#include "llvm/Support/SpecialCaseList.h"
+#include "llvm/Support/VirtualFileSystem.h"
 #include "llvm/Support/raw_ostream.h"
 #include "llvm/Transforms/Instrumentation.h"
 #include "llvm/Transforms/Utils/BasicBlockUtils.h"
@@ -198,8 +200,11 @@
 class ModuleSanitizerCoverage {
 public:
   ModuleSanitizerCoverage(
-  const SanitizerCoverageOptions &Options = SanitizerCoverageOptions())
-  : Options(OverrideFromCL(Options)) {}
+  const SanitizerCoverageOptions &Options = SanitizerCoverageOptions(),
+  const SpecialCaseList *Whitelist = nullptr,
+  const SpecialCaseList *Blacklist = nullptr)
+  : Options(OverrideFromCL(Options)), Whitelist(Whitelist),
+Blacklist(Blacklist) {}
   bool instrumentModule(Module &M, DomTreeCallback DTCallback,
 PostDomTreeCallback PDTCallback);
 
@@ -263,18 +268,32 @@
   SmallVector GlobalsToAppendToCompilerUsed;
 
   SanitizerCoverageOptions Options;
+
+  const SpecialCaseList *Whitelist;
+  const SpecialCaseList *Blacklist;
 };
 
 class ModuleSanitizerCoverageLegacyPass : public ModulePass {
 public:
   ModuleSanitizerCoverageLegacyPass(
-  const SanitizerCoverageOptions &Options = SanitizerCoverageOptions())
+  const SanitizerCoverageOptions &Options = SanitizerCoverageOptions(),
+  const std::vector &WhitelistFiles =
+  std::vector(),
+  const std::vector &BlacklistFiles =
+  std::vector())
   : ModulePass(ID), Options(Options) {
+if (WhitelistFiles.size() > 0)
+  Whitelist = SpecialCaseList::createOrDie(WhitelistFiles,
+   *vfs::getRealFileSystem());
+if (BlacklistFiles.size() > 0)
+  Blacklist = SpecialCaseList::createOrDie(BlacklistFiles,
+   *vfs::getRealFileSystem());
 initializeModuleSanitizerCoverageLegacyPassPass(
 *PassRegistry::getPassRegistry());
   }
   bool runOnModule(Module &M) override {
-ModuleSanitizerCoverage ModuleSancov(Options);
+ModuleSanitizerCoverage ModuleSancov(Options, Whitelist.get(),
+ Blacklist.get());
 auto DTCallback = [this](Function &F) -> const DominatorTree * {
   return &this->getAnalysis(F).getDomTree();
 };
@@ -295,6 +314,9 @@
 
 private:
   SanitizerCoverageOptions Options;
+
+  std::unique_ptr Whitelist;
+  std::unique_ptr Blacklist;
 };
 
 } // namespace
@@ -374,6 +396,12 @@
 Module &M, DomTreeCallback DTCallback, PostDomTreeCallback PDTCallback) {
   if (Options.CoverageType == SanitizerCoverageOptions::SCK_None)
 return false;
+  if (Whitelist &&
+  !Whitelist->inSection("coverage", "src", M.getSourceFileName()))
+return false;
+  if (Blacklist &&
+  Blacklist->inSection("coverage", "src", M.getSourceFileName()))
+return false;
   C = &(M.getContext());
   DL = &M.getDataLayout();
   CurModule = &M;
@@ -611,6 +639,10 @@
   if (F.hasPersonalityFn() &&
   isAsynchronousEHPersonality(classifyEHPersonality(F.getPersonalityFn(
 return;
+  if (Whitelist && !Whitelist->inSection("coverage", "fun", F.getName()))
+return;
+  if (Blacklist && Blacklist->inSection("coverage", "fun", F.getName()))
+return;
   if (Options.CoverageType >= SanitizerCoverageOptions::SCK_Edge)
 SplitAllCriticalEdges(F, CriticalEdgeSplittingOptions().setIgnoreUnreachableDests());
   SmallVector IndirCalls;
@@ -976,6 +1008,9 @@
 "Pass for instrumenting coverage on functions", false,
 false)
 ModulePass *llvm::createModuleSanitizerCoverageLegacyPassPass(
-const SanitizerCoverageOptions &Options) {
-  return new ModuleSanitizerCoverageLegacyPass(O

[PATCH] D77777: [nvptx] Add `nvvm.texsurf.handle` internalizer.

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

In D7#1972720 , @hliao wrote:

> In D7#1972349 , @tra wrote:
>
> > The patch could use a more detailed description. Specifically, it does not 
> > describe the purpose of these changes.
> >
> > > Replace them with the internal version, i.e. nvvm.texsurf.handle.internal 
> > > just before the instruction selector.
> >
> > It's not clear what is 'them'. 'nvvm.texsurf.handle' ?
> >  If so, do we need 'internal' any more? Can we just rename internal and be 
> > done with it? Adding an extra pass just to replace one intrinsic with 
> > another seems to be unnecessary.
> >
> > I may be missing something here. Why do we have internal and non-internal 
> > intrinsics at all? Do we need both?
>
>
> besides required by NVVM IR spec,


NVVM IR spec is for nvidia's own compiler. It's based on LLVM, but it does not 
impose direct constraints on LLVM's design choices.

> the metadata in that intrinsic is a trick to prevent it from being sunk into 
> common code during optimization in LLVM IR.

This sounds like it may have been done that way in an attempt to work around a 
problem with intrinsics' constraints. We may want to check if there's a better 
way to do it now.
Right now both intrinsics are marked with `[IntrNoMem]` which may be the reason 
for compiler feeling free to move it around. We may need to give compiler 
correct information and then we may not need this just-in-time intrinsic 
replacement hack. I think it should be at least `IntrArgMemOnly` or, maybe  
`IntrInaccessibleMemOrArgMemOnly`.

> NVPTX backend only handles the `internal` version.

This is obviously fixable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D7



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

[PATCH] D77257: Clean up usages of asserting vector getters in Type

[Christopher Tetreault via Phabricator via cfe-commits]

ctetreau updated this revision to Diff 256611.
ctetreau added a comment.

Address code review issues


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77257

Files:
  clang/lib/CodeGen/CGAtomic.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/PatternInit.cpp
  clang/lib/CodeGen/TargetInfo.cpp

Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ clang/lib/CodeGen/TargetInfo.cpp
@@ -3054,7 +3054,7 @@
 // Don't pass vXi128 vectors in their native type, the backend can't
 // legalize them.
 if (passInt128VectorsInMem() &&
-IRType->getVectorElementType()->isIntegerTy(128)) {
+cast(IRType)->getElementType()->isIntegerTy(128)) {
   // Use a vXi64 vector.
   uint64_t Size = getContext().getTypeSize(Ty);
   return llvm::VectorType::get(llvm::Type::getInt64Ty(getVMContext()),
Index: clang/lib/CodeGen/PatternInit.cpp
===
--- clang/lib/CodeGen/PatternInit.cpp
+++ clang/lib/CodeGen/PatternInit.cpp
@@ -34,17 +34,15 @@
   constexpr bool NegativeNaN = true;
   constexpr uint64_t NaNPayload = 0xull;
   if (Ty->isIntOrIntVectorTy()) {
-unsigned BitWidth = cast(
-Ty->isVectorTy() ? Ty->getVectorElementType() : Ty)
-->getBitWidth();
+unsigned BitWidth =
+cast(Ty->getScalarType())->getBitWidth();
 if (BitWidth <= 64)
   return llvm::ConstantInt::get(Ty, IntValue);
 return llvm::ConstantInt::get(
 Ty, llvm::APInt::getSplat(BitWidth, llvm::APInt(64, IntValue)));
   }
   if (Ty->isPtrOrPtrVectorTy()) {
-auto *PtrTy = cast(
-Ty->isVectorTy() ? Ty->getVectorElementType() : Ty);
+auto *PtrTy = cast(Ty->getScalarType());
 unsigned PtrWidth = CGM.getContext().getTargetInfo().getPointerWidth(
 PtrTy->getAddressSpace());
 if (PtrWidth > 64)
@@ -55,8 +53,7 @@
   }
   if (Ty->isFPOrFPVectorTy()) {
 unsigned BitWidth = llvm::APFloat::semanticsSizeInBits(
-(Ty->isVectorTy() ? Ty->getVectorElementType() : Ty)
-->getFltSemantics());
+Ty->getScalarType()->getFltSemantics());
 llvm::APInt Payload(64, NaNPayload);
 if (BitWidth >= 64)
   Payload = llvm::APInt::getSplat(BitWidth, Payload);
Index: clang/lib/CodeGen/CGExprScalar.cpp
===
--- clang/lib/CodeGen/CGExprScalar.cpp
+++ clang/lib/CodeGen/CGExprScalar.cpp
@@ -1309,7 +1309,7 @@
"Splatted expr doesn't match with vector element type?");
 
 // Splat the element across to all elements
-unsigned NumElements = DstTy->getVectorNumElements();
+unsigned NumElements = cast(DstTy)->getNumElements();
 return Builder.CreateVectorSplat(NumElements, Src, "splat");
   }
 
@@ -1327,8 +1327,8 @@
 // short or half vector.
 
 // Source and destination are both expected to be vectors.
-llvm::Type *SrcElementTy = SrcTy->getVectorElementType();
-llvm::Type *DstElementTy = DstTy->getVectorElementType();
+llvm::Type *SrcElementTy = cast(SrcTy)->getElementType();
+llvm::Type *DstElementTy = cast(DstTy)->getElementType();
 (void)DstElementTy;
 
 assert(((SrcElementTy->isIntegerTy() &&
@@ -1694,8 +1694,8 @@
   assert(DstTy->isVectorTy() &&
  "ConvertVector destination IR type must be a vector");
 
-  llvm::Type *SrcEltTy = SrcTy->getVectorElementType(),
- *DstEltTy = DstTy->getVectorElementType();
+  llvm::Type *SrcEltTy = cast(SrcTy)->getElementType(),
+ *DstEltTy = cast(DstTy)->getElementType();
 
   if (DstEltType->isBooleanType()) {
 assert((SrcEltTy->isFloatingPointTy() ||
@@ -,7 +,7 @@
 llvm::Type *DstTy = ConvertType(DestTy);
 Value *Elt = Visit(const_cast(E));
 // Splat the element across to all elements
-unsigned NumElements = DstTy->getVectorNumElements();
+unsigned NumElements = cast(DstTy)->getNumElements();
 return Builder.CreateVectorSplat(NumElements, Elt, "splat");
   }
 
@@ -4617,7 +4617,8 @@
   // get a vec3.
   if (NumElementsSrc != 3 && NumElementsDst == 3) {
 if (!CGF.CGM.getCodeGenOpts().PreserveVec3Type) {
-  auto Vec4Ty = llvm::VectorType::get(DstTy->getVectorElementType(), 4);
+  auto Vec4Ty = llvm::VectorType::get(
+  cast(DstTy)->getElementType(), 4);
   Src = createCastsForTypeOfSameSize(Builder, CGF.CGM.getDataLayout(), Src,
  Vec4Ty);
 }
Index: clang/lib/CodeGen/CGExpr.cpp
===
--- clang/lib/CodeGen/CGExpr.cpp
+++ clang/lib/CodeGen/CGExpr.cpp
@@ -2127,7 +2127,8 @@
 
   if (const VectorType *VTy = Dst.getType()->getAs()) {
 unsigned Nu

[PATCH] D76768: [analyzer] Added support of scan-build and exploded-graph-rewriter regression tests for Windows

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

In D76768#1974255 , @ASDenysPetrov 
wrote:

> @thakis
>  Let me explain what works for me.
>  This is in my **PATH**:
>
> - C:\Perl\c\bin
> - C:\Perl\perl\site\bin
> - C:\Perl\perl\bin
> - D:\llvm-project\buildn\bin


^ This is not usually true. (But I think lit adds build/bin to the PATH for 
tests, so it's possibly true for tests, which would be enough.)

> This is what in D:\llvm-project\buildn\bin (all this is a product of 
> ninja+gcc):
> 
> - clang.exe
> - FileCheck.exe
> - scan-build.bat
> - scan-build
> - llvm-lit.py No additional changes required (CMakeList.txt, bat editing, 
> etc.). Than I run command promt from arbitrary dir and run next: 
> //llvm-lit.py 
> D:/llvm-project/clang/test/Analysis/scan-build/exclude_directories.test// 
> Test passes. Done.

If you run `del bin\*` followed by `make check-clang` (or `ninja check-clang` 
or what have you), then I think bin/scan-build won't be built since it's not a 
dependency of the check-clang target. It doesn't have to be a dependency on 
non-Win, but on Win the execution flow is different due to the bat trampoline.

Please try that and confirm that you see a test failure in that scenario as 
well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76768



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

[PATCH] D77257: Clean up usages of asserting vector getters in Type

[Eli Friedman via Phabricator via cfe-commits]

efriedma accepted this revision.
efriedma added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77257



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

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

[Andrew via Phabricator via cfe-commits]

browneee updated this revision to Diff 256621.
browneee added a comment.

Change to suggested approach: size and capacity type conditionally larger for 
small element types.

Also incorporate https://reviews.llvm.org/D77601


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77621

Files:
  llvm/include/llvm/ADT/SmallVector.h
  llvm/lib/Support/SmallVector.cpp

Index: llvm/lib/Support/SmallVector.cpp
===
--- llvm/lib/Support/SmallVector.cpp
+++ llvm/lib/Support/SmallVector.cpp
@@ -37,29 +37,11 @@
   sizeof(unsigned) * 2 + sizeof(void *) * 2,
   "wasted space in SmallVector size 1");
 
-/// grow_pod - This is an implementation of the grow() method which only works
-/// on POD-like datatypes and is out of line to reduce code duplication.
-void SmallVectorBase::grow_pod(void *FirstEl, size_t MinCapacity,
-   size_t TSize) {
-  // Ensure we can fit the new capacity in 32 bits.
-  if (MinCapacity > UINT32_MAX)
-report_bad_alloc_error("SmallVector capacity overflow during allocation");
-
-  size_t NewCapacity = 2 * capacity() + 1; // Always grow.
-  NewCapacity =
-  std::min(std::max(NewCapacity, MinCapacity), size_t(UINT32_MAX));
-
-  void *NewElts;
-  if (BeginX == FirstEl) {
-NewElts = safe_malloc(NewCapacity * TSize);
-
-// Copy the elements over.  No need to run dtors on PODs.
-memcpy(NewElts, this->BeginX, size() * TSize);
-  } else {
-// If this wasn't grown from the inline copy, grow the allocated space.
-NewElts = safe_realloc(this->BeginX, NewCapacity * TSize);
-  }
-
-  this->BeginX = NewElts;
-  this->Capacity = NewCapacity;
-}
+// Check that SmallVector with 1 byte elements takes extra space due to using
+// uintptr_r instead of uint32_t for size and capacity.
+static_assert(sizeof(SmallVector) > sizeof(SmallVector) ||
+  sizeof(uintptr_t) == sizeof(uint32_t),
+  "1 byte elements should cause larger size and capacity type");
+static_assert(sizeof(SmallVector) ==
+  sizeof(SmallVector),
+  "larger elements should keep the same size and capacity type");
Index: llvm/include/llvm/ADT/SmallVector.h
===
--- llvm/include/llvm/ADT/SmallVector.h
+++ llvm/include/llvm/ADT/SmallVector.h
@@ -34,11 +34,23 @@
 
 namespace llvm {
 
-/// This is all the non-templated stuff common to all SmallVectors.
-class SmallVectorBase {
+/// This is all the stuff common to all SmallVectors.
+///
+/// The template parameter specifies the type which should be used to hold the
+/// Size and Capacity of the SmallVector, so it can be adjusted.
+/// Using 32 bit size is desirable to shink the size of the SmallVector.
+/// Using 64 bit size is desirable for cases like SmallVector, where a
+/// 32 bit size would limit the vector to ~4GB. SmallVectors are used for
+/// buffering bitcode output - which can exceed 4GB.
+template  class SmallVectorBase {
 protected:
+  typedef Size_T size_type;
+
   void *BeginX;
-  unsigned Size = 0, Capacity;
+  size_type Size = 0, Capacity;
+
+  // The maximum size depends on size_type used.
+  size_t SizeMax() { return size_type(-1ULL); }
 
   SmallVectorBase() = delete;
   SmallVectorBase(void *FirstEl, size_t TotalCapacity)
@@ -46,7 +58,39 @@
 
   /// This is an implementation of the grow() method which only works
   /// on POD-like data types and is out of line to reduce code duplication.
-  void grow_pod(void *FirstEl, size_t MinCapacity, size_t TSize);
+  /// This function will report a fatal error if it cannot increase capacity.
+  void grow_pod(void *FirstEl, size_t MinCapacity, size_t TSize) {
+// Ensure we can fit the new capacity.
+// This is only going to be applicable if the when the capacity is 32 bit.
+if (MinCapacity > SizeMax())
+  report_bad_alloc_error("SmallVector capacity overflow during allocation");
+
+// Ensure we can meet the guarantee of space for at least one more element.
+// The above check alone will not catch the case where grow is called with a
+// default MinCapacity of 0, but the current capacity cannot be increased.
+// This is only going to be applicable if the when the capacity is 32 bit.
+if (capacity() == SizeMax())
+  report_bad_alloc_error("SmallVector capacity unable to grow");
+
+// In theory 2*capacity can overflow if the capacity is 64 bit, but the
+// original capacity would never be large enough for this to be a problem.
+size_t NewCapacity = 2 * capacity() + 1; // Always grow.
+NewCapacity = std::min(std::max(NewCapacity, MinCapacity), SizeMax());
+
+void *NewElts;
+if (BeginX == FirstEl) {
+  NewElts = safe_malloc(NewCapacity * TSize);
+
+  // Copy the elements over.  No need to run dtors on PODs.
+  memcpy(NewElts, this->BeginX, size() 

[PATCH] D77621: ADT: SmallVector size & capacity use word-size integers when elements are small.

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

Please update the patch description/subject line.

@dexonsmith I'll leave this to you for final approval, since it was your 
idea/you've been touching things here. But looks like about the right direction.




Comment at: llvm/include/llvm/ADT/SmallVector.h:47
 protected:
+  typedef Size_T size_type;
+

Don't think this typedef is really pulling its weight - probably just refer to 
the template type parameter directly?



Comment at: llvm/include/llvm/ADT/SmallVector.h:53
+  // The maximum size depends on size_type used.
+  size_t SizeMax() { return size_type(-1ULL); }
 

I'd probably use numeric_limits here & make this static constexpr



Comment at: llvm/include/llvm/ADT/SmallVector.h:132
+: public SmallVectorBase> {
   /// Find the address of the first element.  For this pointer math to be valid
   /// with small-size of 0 for T with lots of alignment, it's important that

I'd probably add a "using Base = SmallVectorBase>" here, 
and then use that in the ctor and grow_pod.

Also down by the other using decls maybe add "using 
Base::size/Base::capacity/Base::empty" so you don't have to "this->" everything.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77621



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

[PATCH] D77777: [nvptx] Add `nvvm.texsurf.handle` internalizer.

[Michael Liao via Phabricator via cfe-commits]

hliao added a comment.

In D7#1974672 , @tra wrote:

> In D7#1972720 , @hliao wrote:
>
> > In D7#1972349 , @tra wrote:
> >
> > > The patch could use a more detailed description. Specifically, it does 
> > > not describe the purpose of these changes.
> > >
> > > > Replace them with the internal version, i.e. 
> > > > nvvm.texsurf.handle.internal just before the instruction selector.
> > >
> > > It's not clear what is 'them'. 'nvvm.texsurf.handle' ?
> > >  If so, do we need 'internal' any more? Can we just rename internal and 
> > > be done with it? Adding an extra pass just to replace one intrinsic with 
> > > another seems to be unnecessary.
> > >
> > > I may be missing something here. Why do we have internal and non-internal 
> > > intrinsics at all? Do we need both?
> >
> >
> > besides required by NVVM IR spec,
>
>
> NVVM IR spec is for nvidia's own compiler. It's based on LLVM, but it does 
> not impose direct constraints on LLVM's design choices.


It would be an advantage and, sometimes, desirable to generate IR compatible to 
NVVM IR spec.

> 
> 
>> the metadata in that intrinsic is a trick to prevent it from being sunk into 
>> common code during optimization in LLVM IR.
> 
> This sounds like it may have been done that way in an attempt to work around 
> a problem with intrinsics' constraints. We may want to check if there's a 
> better way to do it now.
>  Right now both intrinsics are marked with `[IntrNoMem]` which may be the 
> reason for compiler feeling free to move it around. We may need to give 
> compiler correct information and then we may not need this just-in-time 
> intrinsic replacement hack. I think it should be at least `IntrArgMemOnly` 
> or, maybe  `IntrInaccessibleMemOrArgMemOnly`.

That may not exactly model the behavior as, for binding texture/surface 
support, in fact, it's true that there's no memory operation at all. Even with 
InstArgMemOnly or similar attributes, it still won't be preventable for 
optimizations to sink common code. Such trick is played in lots of intrinsics, 
such as `read.register` and etc.

> 
> 
>> NVPTX backend only handles the `internal` version.
> 
> This is obviously fixable.

SDAG so far cannot handle metadata GISel doesn't have support either. Getting 
that supported in TICG won't justify too much for target-specific intrinsics as 
metadata should not directly be used in code generation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D7



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

[PATCH] D59321: AMDGPU: Teach toolchain to link rocm device libs

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

test fails on win: 
http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/15191/steps/stage%201%20check/logs/stdio


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

https://reviews.llvm.org/D59321



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

[PATCH] D75903: [AArch64][CodeGen] Fixing stack alignment of HFA arguments on AArch64 PCS

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

In D75903#1963382 , @pratlucas wrote:

> In regards to the compatibility with other compilers, I'm not sure that 
> following what seems to be an uncompliant behavior would be the best way to 
> proceed. @rnk and @ostannard, what would be your take on this?


I don't have any familiarity with the prevailing practices for ARM ABI 
compatibility, so I couldn't say. It might be worth checking in with 
stakeholders from the other compilers, i.e. file bugs against both compilers 
and ask for an opinion.




Comment at: llvm/docs/LangRef.rst:1220
+``alignstack()``
+This indicates the alignment that should be considered by the backend when
+assigning this parameter to a stack slot during calling convention

This seems like you are introducing a new meaning to `alignstack`, which 
according to the comments, only affects function SP alignment, not parameter 
alignment.

I'm assuming the reason you can't use the regular `align` attribute is that it 
is overloaded to mean two things: the alignment of the pointer when applied to 
a pointer, and the alignment of the argument memory when that pointer argument 
is marked `byval`. If you want to resolve this ambiguity, it seems like 
something that should be discussed on llvm-dev with a wider audience.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75903



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

[PATCH] D74387: [SYCL] Defer __float128 type usage diagnostics

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

As I mentioned before. As long as the type is not "used" you can treat it as a 
sequence of bytes just as well. So we can lower `__float128` to `char [16]` 
with the right alignment. SPIRV will never see unsupported types and the code 
works because we never access it as `float128` anyway. WDYT?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74387



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

[PATCH] D77903: [SVE] Remove calls to getBitWidth from clang

[Christopher Tetreault via Phabricator via cfe-commits]

ctetreau created this revision.
Herald added subscribers: cfe-commits, psnobl, rkruppe, tschuett.
Herald added a reviewer: efriedma.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D77903

Files:
  clang/lib/CodeGen/TargetInfo.cpp


Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ clang/lib/CodeGen/TargetInfo.cpp
@@ -970,7 +970,8 @@
  .Cases("y", "&y", "^Ym", true)
  .Default(false);
   if (IsMMXCons && Ty->isVectorTy()) {
-if (cast(Ty)->getBitWidth() != 64) {
+if (cast(Ty)->getPrimitiveSizeInBits().getFixedSize() !=
+64) {
   // Invalid MMX constraint
   return nullptr;
 }
@@ -2260,7 +2261,7 @@
 if (info.isDirect()) {
   llvm::Type *ty = info.getCoerceToType();
   if (llvm::VectorType *vectorTy = dyn_cast_or_null(ty))
-return (vectorTy->getBitWidth() > 128);
+return vectorTy->getPrimitiveSizeInBits().getFixedSize() > 128;
 }
 return false;
   }


Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ clang/lib/CodeGen/TargetInfo.cpp
@@ -970,7 +970,8 @@
  .Cases("y", "&y", "^Ym", true)
  .Default(false);
   if (IsMMXCons && Ty->isVectorTy()) {
-if (cast(Ty)->getBitWidth() != 64) {
+if (cast(Ty)->getPrimitiveSizeInBits().getFixedSize() !=
+64) {
   // Invalid MMX constraint
   return nullptr;
 }
@@ -2260,7 +2261,7 @@
 if (info.isDirect()) {
   llvm::Type *ty = info.getCoerceToType();
   if (llvm::VectorType *vectorTy = dyn_cast_or_null(ty))
-return (vectorTy->getBitWidth() > 128);
+return vectorTy->getPrimitiveSizeInBits().getFixedSize() > 128;
 }
 return false;
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76384: Move FPFeatures from BinaryOperator bitfields to Trailing storage

[Melanie Blower via Phabricator via cfe-commits]

mibintc updated this revision to Diff 256648.
mibintc added a comment.

I finally decided that combining BinaryOperator and CompoundAssignOperator was 
too difficult, this patch uses the trailing object approach similar to that 
used in CallExpr. @rjmccall thank you once again for all your reviews in 
developing this patch. I hope that this version is acceptable or within a 
hair's breadth of acceptable.  As an experiment to confirm to myself that the 
trailing storage was only active in the pragma case, i added a "assert(0)" to 
getStoredFPFeatures. In that case check-clang showed 5 expected fails for the 
pragma tests cases.  (  Clang :: CodeGen/constrained-math-builtins.c  Clang :: 
CodeGen/fp-contract-fast-pragma.cpp  Clang :: CodeGen/fp-contract-on-asm.c  
Clang :: CodeGen/fp-contract-on-pragma.cpp  Clang :: 
CodeGen/fp-contract-pragma.cpp)

Then i removed that assert before submitting this to review.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76384

Files:
  clang/include/clang/AST/Expr.h
  clang/include/clang/AST/ExprCXX.h
  clang/include/clang/AST/Stmt.h
  clang/include/clang/Basic/LangOptions.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/Expr.cpp
  clang/lib/AST/ExprCXX.cpp
  clang/lib/Analysis/BodyFarm.cpp
  clang/lib/Basic/LangOptions.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CGObjC.cpp
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/lib/Frontend/Rewrite/RewriteModernObjC.cpp
  clang/lib/Frontend/Rewrite/RewriteObjC.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/SemaPseudoObject.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp

Index: clang/lib/Serialization/ASTWriterStmt.cpp
===
--- clang/lib/Serialization/ASTWriterStmt.cpp
+++ clang/lib/Serialization/ASTWriterStmt.cpp
@@ -918,11 +918,16 @@
 
 void ASTStmtWriter::VisitBinaryOperator(BinaryOperator *E) {
   VisitExpr(E);
+  bool HasFPFeatures = E->hasStoredFPFeatures();
+  // Write this first for easy access when deserializing, as they affect the
+  // size of the UnaryOperator.
+  Record.push_back(HasFPFeatures);
+  Record.push_back(E->getOpcode()); // FIXME: stable encoding
   Record.AddStmt(E->getLHS());
   Record.AddStmt(E->getRHS());
-  Record.push_back(E->getOpcode()); // FIXME: stable encoding
   Record.AddSourceLocation(E->getOperatorLoc());
-  Record.push_back(E->getFPFeatures().getInt());
+  if (HasFPFeatures)
+Record.push_back(E->getStoredFPFeatures().getAsOpaqueInt());
   Code = serialization::EXPR_BINARY_OPERATOR;
 }
 
@@ -1513,7 +1518,7 @@
 void ASTStmtWriter::VisitCXXOperatorCallExpr(CXXOperatorCallExpr *E) {
   VisitCallExpr(E);
   Record.push_back(E->getOperator());
-  Record.push_back(E->getFPFeatures().getInt());
+  Record.push_back(E->getFPFeatures().getAsOpaqueInt());
   Record.AddSourceRange(E->Range);
   Code = serialization::EXPR_CXX_OPERATOR_CALL;
 }
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -3905,7 +3905,7 @@
 
 /// Write an FP_PRAGMA_OPTIONS block for the given FPOptions.
 void ASTWriter::WriteFPPragmaOptions(const FPOptions &Opts) {
-  RecordData::value_type Record[] = {Opts.getInt()};
+  RecordData::value_type Record[] = {Opts.getAsOpaqueInt()};
   Stream.EmitRecord(FP_PRAGMA_OPTIONS, Record);
 }
 
Index: clang/lib/Serialization/ASTReaderStmt.cpp
===
--- clang/lib/Serialization/ASTReaderStmt.cpp
+++ clang/lib/Serialization/ASTReaderStmt.cpp
@@ -1050,12 +1050,16 @@
 }
 
 void ASTStmtReader::VisitBinaryOperator(BinaryOperator *E) {
+  bool hasFP_Features;
+  BinaryOperator::Opcode opc;
   VisitExpr(E);
+  E->setHasStoredFPFeatures(hasFP_Features = Record.readInt());
+  E->setOpcode(opc = (BinaryOperator::Opcode)Record.readInt());
   E->setLHS(Record.readSubExpr());
   E->setRHS(Record.readSubExpr());
-  E->setOpcode((BinaryOperator::Opcode)Record.readInt());
   E->setOperatorLoc(readSourceLocation());
-  E->setFPFeatures(FPOptions(Record.readInt()));
+  if (hasFP_Features)
+E->setStoredFPFeatures(FPOptions(Record.readInt()));
 }
 
 void ASTStmtReader::VisitCompoundAssignOperator(CompoundAssignOperator *E) {
@@ -2937,11 +2941,13 @@
   break;
 
 case EXPR_BINARY_OPERATOR:
-  S = new (Context) BinaryOperator(Empty);
+  S = BinaryOperator::CreateEmpty(Context,
+Record[ASTStmtReader::NumExprFields]);
   break;
 
 case EXPR_COMPOUND_ASSIGN_OPERATOR:
-  S = new (Context) CompoundAssignOperator(Empty);
+  S = CompoundAssignOperator::CreateEmpty(Context,
+ 

[PATCH] D77777: [nvptx] Add `nvvm.texsurf.handle` internalizer.

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

In D7#1974849 , @hliao wrote:

>




>> NVVM IR spec is for nvidia's own compiler. It's based on LLVM, but it does 
>> not impose direct constraints on LLVM's design choices.
> 
> It would be an advantage and, sometimes, desirable to generate IR compatible 
> to NVVM IR spec.

I'm not against it, but I think it's OK to make different choices if we have 
good reasons for that. NVIDIA didn't update LLVM since they've contributed the 
original implementation, so by now we're both far behind the current state of 
NVVM and quite a bit sideways due to the things LLVM has added to NVPTX backend.

>> This sounds like it may have been done that way in an attempt to work around 
>> a problem with intrinsics' constraints. We may want to check if there's a 
>> better way to do it now.
>>  Right now both intrinsics are marked with `[IntrNoMem]` which may be the 
>> reason for compiler feeling free to move it around. We may need to give 
>> compiler correct information and then we may not need this just-in-time 
>> intrinsic replacement hack. I think it should be at least `IntrArgMemOnly` 
>> or, maybe  `IntrInaccessibleMemOrArgMemOnly`.
> 
> That may not exactly model the behavior as, for binding texture/surface 
> support, in fact, it's true that there's no memory operation at all. Even 
> with InstArgMemOnly or similar attributes, it still won't be preventable for 
> optimizations to sink common code. Such trick is played in lots of 
> intrinsics, such as `read.register` and etc.

Can you give me an example where/how optimizer would break things? Is that 
because were using metadata as an argument?

I've re-read NVVM docs and I can't say that I understand how it's supposed to 
work.
`metadata holding the texture or surface variable` alone is a rather odd notion 
and I'm not surprised that it's not handled well. In the end we do end up with 
a 'handle' which is an in-memory object. Perhaps it should be represented as a 
real variable with a metadata attribute. Then we can lower it as a handle,  can 
enforce that only texture/surface instructions are allowed to use it and will 
have a way to tell LLVM what it's allowed to do.

I don't have a good picture of how it all will fit together in the end (or 
whether what I suggest makes sense), but the current implementation appears to 
be in need of rethinking.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D7



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

[PATCH] D77908: [WebAssembly] Enable nontrapping-fptoint for `default` cpu

[Sam Clegg via Phabricator via cfe-commits]

sbc100 created this revision.
Herald added subscribers: cfe-commits, jfb, arphaman, sunfish, aheejin, 
hiraditya, jgravelle-google, dschuff.
Herald added a project: clang.

Since this feature is now merged into the upstream wasm spec it
makes sense to enable it by default, at least for the `default` CPU.
The `mvp` CPU can still be used to avoid this feature.

See: https://github.com/WebAssembly/spec/pull/1143

This is just to test the water and the plan is to enable all features
that have been merged, assuming this change is accepted.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D77908

Files:
  clang/lib/Basic/Targets/WebAssembly.cpp
  clang/lib/Basic/Targets/WebAssembly.h
  clang/test/CodeGen/builtins-wasm.c
  clang/test/Preprocessor/wasm-target-features.c
  lld/test/wasm/alias.ll
  lld/test/wasm/call-indirect.ll
  lld/test/wasm/cxx-mangling.ll
  lld/test/wasm/data-layout.ll
  lld/test/wasm/function-imports-first.ll
  lld/test/wasm/function-imports.ll
  lld/test/wasm/gc-imports.ll
  lld/test/wasm/gc-sections.ll
  lld/test/wasm/import-memory.test
  lld/test/wasm/init-fini.ll
  lld/test/wasm/load-undefined.test
  lld/test/wasm/local-symbols.ll
  lld/test/wasm/locals-duplicate.test
  lld/test/wasm/relocatable.ll
  lld/test/wasm/signature-mismatch-export.ll
  lld/test/wasm/signature-mismatch.ll
  lld/test/wasm/stack-pointer.ll
  lld/test/wasm/undefined-weak-call.ll
  lld/test/wasm/weak-alias-overide.ll
  lld/test/wasm/weak-alias.ll
  lld/test/wasm/weak-symbols.ll
  lld/test/wasm/weak-undefined.ll
  llvm/lib/Target/WebAssembly/WebAssembly.td
  llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
  llvm/test/CodeGen/WebAssembly/conv.ll
  llvm/test/CodeGen/WebAssembly/multivalue.ll
  llvm/test/CodeGen/WebAssembly/mutable-globals.ll
  llvm/test/CodeGen/WebAssembly/reference-types.ll
  llvm/test/CodeGen/WebAssembly/tailcall.ll
  llvm/test/CodeGen/WebAssembly/target-features-tls.ll
  llvm/test/MC/WebAssembly/array-fill.ll
  llvm/test/MC/WebAssembly/assembler-binary.ll
  llvm/test/MC/WebAssembly/basic-assembly-errors.s
  llvm/test/MC/WebAssembly/basic-assembly.s
  llvm/test/MC/WebAssembly/bss.ll
  llvm/test/MC/WebAssembly/comdat.ll
  llvm/test/MC/WebAssembly/data-section.s
  llvm/test/MC/WebAssembly/debug-info.ll
  llvm/test/MC/WebAssembly/explicit-sections.ll
  llvm/test/MC/WebAssembly/global-ctor-dtor.ll
  llvm/test/MC/WebAssembly/objdump.s
  llvm/test/MC/WebAssembly/type-index.s
  llvm/test/MC/WebAssembly/visibility.ll

Index: llvm/test/MC/WebAssembly/visibility.ll
===
--- llvm/test/MC/WebAssembly/visibility.ll
+++ llvm/test/MC/WebAssembly/visibility.ll
@@ -25,4 +25,5 @@
 ; CHECK-NEXT: Name:hiddenVis
 ; CHECK-NEXT: Flags:   [ VISIBILITY_HIDDEN ]
 ; CHECK-NEXT: Function:1
-; CHECK-NEXT: ...
+; CHECK-NEXT:   - Type:CUSTOM
+; CHECK-NEXT: Name:target_features
Index: llvm/test/MC/WebAssembly/type-index.s
===
--- llvm/test/MC/WebAssembly/type-index.s
+++ llvm/test/MC/WebAssembly/type-index.s
@@ -1,6 +1,6 @@
-# RUN: llvm-mc -triple=wasm32-unknown-unknown -mattr=+unimplemented-simd128,+nontrapping-fptoint,+exception-handling < %s | FileCheck %s
+# RUN: llvm-mc -triple=wasm32-unknown-unknown -mattr=+unimplemented-simd128,+exception-handling < %s | FileCheck %s
 # Check that it converts to .o without errors:
-# RUN: llvm-mc -triple=wasm32-unknown-unknown -filetype=obj -mattr=+unimplemented-simd128,+nontrapping-fptoint,+exception-handling < %s | obj2yaml | FileCheck -check-prefix=BIN %s
+# RUN: llvm-mc -triple=wasm32-unknown-unknown -filetype=obj -mattr=+unimplemented-simd128,+exception-handling < %s | obj2yaml | FileCheck -check-prefix=BIN %s
 
 # Minimal test for type indices in call_indirect.
 
Index: llvm/test/MC/WebAssembly/objdump.s
===
--- llvm/test/MC/WebAssembly/objdump.s
+++ llvm/test/MC/WebAssembly/objdump.s
@@ -1,4 +1,4 @@
-# RUN: llvm-mc -triple=wasm32-unknown-unknown -filetype=obj -o %t.o -mattr=+simd128,+nontrapping-fptoint,+exception-handling < %s
+# RUN: llvm-mc -triple=wasm32-unknown-unknown -filetype=obj -o %t.o -mattr=+simd128,+exception-handling < %s
 # RUN: llvm-objdump --triple=wasm32-unknown-unknown -d %t.o | FileCheck %s
 
 test0:
Index: llvm/test/MC/WebAssembly/global-ctor-dtor.ll
===
--- llvm/test/MC/WebAssembly/global-ctor-dtor.ll
+++ llvm/test/MC/WebAssembly/global-ctor-dtor.ll
@@ -183,4 +183,5 @@
 ; CHECK-NEXT: Symbol: 10
 ; CHECK-NEXT:   - Priority: 65535
 ; CHECK-NEXT: Symbol: 7
-; CHECK-NEXT: ...
+; CHECK-NEXT:   - Type:CUSTOM
+; CHECK-NEXT: Name:target_features
Index: llvm/test/MC/WebAssembly/explicit-sections.ll
===
--- llvm

[PATCH] D77572: [clang-tidy] add new check readability-use-anyofallof

[Matthias Gehre via Phabricator via cfe-commits]

mgehre added a comment.

Thanks @njames93, this is a good examples which I did not consider yet. I agree 
that only transforming
the second loop would make the code worse.

I would argue that a human seeing a warning on the second loop might also 
realize
that the first loop can be transformed in a similar way, and possibly combine 
them into

  return llvm::all_of(getConds(), [](const Init *Cond) { return Val->Cond(); }) 
&& llvm::all_of(getVals(), [](const Init *Val) { return Val->isConcrete(); });

(I was wondering whether the check should have an option to suggest 
`llvm::all_of` (or `boost::algorithm::all_of`, ...) instead of `std::all_of`, 
but
I thought that this could go into another PR.)

I have the feeling that extracting code into algorithms is generally a hard 
topic,
and automatic fixits would possible give a false sense of automatism (at least 
at the current point).
Your example is a good reminder of that.

Personally, clang-tidy has been a good source of learning C++ best practices. 
And I hope that this clang-tidy check would help
me and my coworkers to remember using those algorithms.

Are you saying that this check should not land unless its scope is extended? 
What would be the minimal scope making this check
worth-while to land?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77572



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

[PATCH] D77908: [WebAssembly] Enable nontrapping-fptoint for `default` cpu

[Thomas Lively via Phabricator via cfe-commits]

tlively added a comment.

Do we have tests that check that passing `-nontrapping-fptoint` to llc (or 
clang) successfully disables the feature?




Comment at: clang/lib/Basic/Targets/WebAssembly.h:33
 
-  bool HasNontrappingFPToInt = false;
+  bool HasNontrappingFPToInt = true;
   bool HasSignExt = false;

It seems strange to change the default here. x86 initializes all its 
corresponding features to `false` then selectively enables them in 
`initFeatureMap`. I think we should stick with that pattern if possible.



Comment at: clang/test/Preprocessor/wasm-target-features.c:10
+
+// NONTRAPPING-FPTOINT:#define __wasm_nontrapping_fptoint__ 1{{$}}
+

Is there a RUN line corresponding to this check anymore?



Comment at: lld/test/wasm/data-layout.ll:72
 ; RUN: wasm-ld -no-gc-sections --allow-undefined --no-entry --shared-memory \
-; RUN: --features=atomics,bulk-memory --initial-memory=131072 \
+; RUN: --features=atomics,bulk-memory,nontrapping-fptoint 
--initial-memory=131072 \
 ; RUN: --max-memory=131072 -o %t_max.wasm %t.o %t.hello.o

Would it make more sense to use the MVP CPU to avoid the unnecessary 
nontrapping-fptoint? I feel like it just distracts from the point of the test 
here.



Comment at: lld/test/wasm/import-memory.test:36
+# RUN: wasm-ld --import-memory --shared-memory \
+# RUN: --features=nontrapping-fptoint,atomics,bulk-memory \
 # RUN: --initial-memory=262144 --max-memory=327680 -o %t.max.wasm 
%t.start.o

Same here about using the mvp cpu.



Comment at: llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp:229
+  if (!Features[KV.Value] && Defaults[KV.Value])
+Ret += (StringRef("-") + KV.Key + ",").str();
 }

Nice!



Comment at: llvm/test/CodeGen/WebAssembly/multivalue.ll:259
+; CHECK-NEXT: .ascii "nontrapping-fptoint"
+; CHECK-NEXT: .int8 43
 ; CHECK-NEXT: .int8 9

Might want to use mvp cpu here too, not because this is necessarily 
distracting, but because I don't see any value in updating this test every time 
we standardize another feature. Same with many other tests.



Comment at: llvm/test/MC/WebAssembly/array-fill.ll:27
 ; CHECK-NEXT: Flags:   [ ]
-; CHECK-NEXT: ...

In some tests you just remove this line and in others you explicitly check for 
the start of the target features section. Would it make sense to just choose 
one or the other? FWIW I think checking for the start of the target features 
section makes the most sense.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77908



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

[PATCH] D77903: [SVE] Remove calls to getBitWidth from clang

[Eli Friedman via Phabricator via cfe-commits]

efriedma accepted this revision.
efriedma 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/D77903/new/

https://reviews.llvm.org/D77903



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

[PATCH] D77777: [nvptx] Add `nvvm.texsurf.handle` internalizer.

[Michael Liao via Phabricator via cfe-commits]

hliao added a comment.

In D7#1974988 , @tra wrote:

> In D7#1974849 , @hliao wrote:
>
> >
>
>
>
>
> >> NVVM IR spec is for nvidia's own compiler. It's based on LLVM, but it does 
> >> not impose direct constraints on LLVM's design choices.
> > 
> > It would be an advantage and, sometimes, desirable to generate IR 
> > compatible to NVVM IR spec.
>
> I'm not against it, but I think it's OK to make different choices if we have 
> good reasons for that. NVIDIA didn't update LLVM since they've contributed 
> the original implementation, so by now we're both far behind the current 
> state of NVVM and quite a bit sideways due to the things LLVM has added to 
> NVPTX backend.
>
> >> This sounds like it may have been done that way in an attempt to work 
> >> around a problem with intrinsics' constraints. We may want to check if 
> >> there's a better way to do it now.
> >>  Right now both intrinsics are marked with `[IntrNoMem]` which may be the 
> >> reason for compiler feeling free to move it around. We may need to give 
> >> compiler correct information and then we may not need this just-in-time 
> >> intrinsic replacement hack. I think it should be at least `IntrArgMemOnly` 
> >> or, maybe  `IntrInaccessibleMemOrArgMemOnly`.
> > 
> > That may not exactly model the behavior as, for binding texture/surface 
> > support, in fact, it's true that there's no memory operation at all. Even 
> > with InstArgMemOnly or similar attributes, it still won't be preventable 
> > for optimizations to sink common code. Such trick is played in lots of 
> > intrinsics, such as `read.register` and etc.
>
> Can you give me an example where/how optimizer would break things? Is that 
> because were using metadata as an argument?
>
> I've re-read NVVM docs and I can't say that I understand how it's supposed to 
> work.
>  `metadata holding the texture or surface variable` alone is a rather odd 
> notion and I'm not surprised that it's not handled well. In the end we do end 
> up with a 'handle' which is an in-memory object. Perhaps it should be 
> represented as a real variable with a metadata attribute. Then we can lower 
> it as a handle,  can enforce that only texture/surface instructions are 
> allowed to use it and will have a way to tell LLVM what it's allowed to do.
>
> I don't have a good picture of how it all will fit together in the end (or 
> whether what I suggest makes sense), but the current implementation appears 
> to be in need of rethinking.


the 1st argument in `llvm.nvvm.texsurf.hande.internal` or the 2nd one in 
`llvm.nvvm.texsurf.handle` must be kept as an immediate or constant value, i.e. 
that global variable. However, optimizations will find common code in the 
following

  if (cond) {
%hnd = texsurf.handle.internal(@tex1);
  } else {
%hnd = texsurf.handle.internal(@tex2)
  }
  = use(%hnd)

and hoist or sink it into

  if (cond) {
%ptr = @tex1;
  } else {
%ptr = @tex2;
  }
  %hnd = texsurf.handle.intenal(%ptr);
  = use(%hnd)

The backend cannot handle non immediate operand in `texsurf.handle`. The 
similar thing happens to `read.register` as well as it also assumes its 
argument is always an immediate value.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D7



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

[PATCH] D77572: [clang-tidy] add new check readability-use-anyofallof

[Nathan James via Phabricator via cfe-commits]

njames93 added a comment.

Right now it would be a great candidate for this - 
http://lists.llvm.org/pipermail/cfe-dev/2020-March/064980.html, however in its 
current state I wouldn't say its ready to get the green light right now.
No point worrying about the fix-its yet, but when it is time, could add options 
for `RangeAllOfName`, `RangeAnyOfName`, `RangeNoneOfName`, `AlgorithmHeader`.
Gonna throw it out there that generating that templated lambda automatically... 
just don't :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77572



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

[PATCH] D77910: AMDGPU: Define cl_khr_gl_sharing as a supported extension

[Matt Arsenault via Phabricator via cfe-commits]

arsenm created this revision.
arsenm added reviewers: yaxunl, Anastasia.
Herald added subscribers: danielkiss, kerbowa, kristof.beyls, t-tye, tpr, 
dstuttard, nhaehnle, wdng, jvesely, kzhuravl.

This doesn't seem to be that useful, since it doesn't change any
device side functions. Report it since it seems a macro should be
reported for every extension.

  

ROCm already reports this. Clover doesn't report it, but since this
isn't useful for device code, it probably isn't harmful to always
define the macro.


https://reviews.llvm.org/D77910

Files:
  clang/lib/Basic/Targets/AMDGPU.h
  clang/test/Misc/amdgcn.languageOptsOpenCL.cl


Index: clang/test/Misc/amdgcn.languageOptsOpenCL.cl
===
--- clang/test/Misc/amdgcn.languageOptsOpenCL.cl
+++ clang/test/Misc/amdgcn.languageOptsOpenCL.cl
@@ -29,11 +29,10 @@
 #endif
 #pragma OPENCL EXTENSION cl_khr_int64_extended_atomics: enable
 
-#ifdef cl_khr_gl_sharing
+#ifndef cl_khr_gl_sharing
 #error "Incorrect cl_khr_gl_sharing define"
 #endif
 #pragma OPENCL EXTENSION cl_khr_gl_sharing: enable
-// expected-warning@-1{{unsupported OpenCL extension 'cl_khr_gl_sharing' - 
ignoring}}
 
 #ifndef cl_khr_icd
 #error "Missing cl_khr_icd define"
Index: clang/lib/Basic/Targets/AMDGPU.h
===
--- clang/lib/Basic/Targets/AMDGPU.h
+++ clang/lib/Basic/Targets/AMDGPU.h
@@ -267,6 +267,7 @@
   Opts.support("cl_khr_mipmap_image_writes");
   Opts.support("cl_khr_subgroups");
   Opts.support("cl_khr_3d_image_writes");
+  Opts.support("cl_khr_gl_sharing");
   Opts.support("cl_amd_media_ops");
   Opts.support("cl_amd_media_ops2");
 }


Index: clang/test/Misc/amdgcn.languageOptsOpenCL.cl
===
--- clang/test/Misc/amdgcn.languageOptsOpenCL.cl
+++ clang/test/Misc/amdgcn.languageOptsOpenCL.cl
@@ -29,11 +29,10 @@
 #endif
 #pragma OPENCL EXTENSION cl_khr_int64_extended_atomics: enable
 
-#ifdef cl_khr_gl_sharing
+#ifndef cl_khr_gl_sharing
 #error "Incorrect cl_khr_gl_sharing define"
 #endif
 #pragma OPENCL EXTENSION cl_khr_gl_sharing: enable
-// expected-warning@-1{{unsupported OpenCL extension 'cl_khr_gl_sharing' - ignoring}}
 
 #ifndef cl_khr_icd
 #error "Missing cl_khr_icd define"
Index: clang/lib/Basic/Targets/AMDGPU.h
===
--- clang/lib/Basic/Targets/AMDGPU.h
+++ clang/lib/Basic/Targets/AMDGPU.h
@@ -267,6 +267,7 @@
   Opts.support("cl_khr_mipmap_image_writes");
   Opts.support("cl_khr_subgroups");
   Opts.support("cl_khr_3d_image_writes");
+  Opts.support("cl_khr_gl_sharing");
   Opts.support("cl_amd_media_ops");
   Opts.support("cl_amd_media_ops2");
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 1e93b3d - Disable test on windows

[Matt Arsenault via cfe-commits]

Author: Matt Arsenault
Date: 2020-04-10T18:48:18-04:00
New Revision: 1e93b3d8a75638c2268df58e44a8738845df3ed5

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

LOG: Disable test on windows

Added: 


Modified: 
clang/test/Driver/rocm-device-libs.cl

Removed: 




diff  --git a/clang/test/Driver/rocm-device-libs.cl 
b/clang/test/Driver/rocm-device-libs.cl
index 83641d24d156..77e9782f2594 100644
--- a/clang/test/Driver/rocm-device-libs.cl
+++ b/clang/test/Driver/rocm-device-libs.cl
@@ -1,5 +1,6 @@
 // REQUIRES: clang-driver
 // REQUIRES: amdgpu-registered-target
+// REQUIRES: !system-windows
 
 // Test flush-denormals-to-zero enabled uses oclc_daz_opt_on
 



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

[PATCH] D77918: [OpenMP] Avoid crash in preparation for diagnose of unsupported type

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert created this revision.
jdoerfert added reviewers: hfinkel, ABataev, JonChesterfield.
Herald added subscribers: guansong, bollu, yaxunl.
Herald added a project: clang.

This was reported as PR45231 but occurs even without `cmath` in C++17
mode if we have an expression involving unsupported types outside of a
function. For now we just avoid to create a diagnose builder in this
case as it might be valid anyway. A proper solution to handle
unsupported types has to be found. Discussion is ongoing in D74387 
.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D77918

Files:
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/nvptx_unsupported_type_messages.cpp


Index: clang/test/OpenMP/nvptx_unsupported_type_messages.cpp
===
--- clang/test/OpenMP/nvptx_unsupported_type_messages.cpp
+++ clang/test/OpenMP/nvptx_unsupported_type_messages.cpp
@@ -56,3 +56,8 @@
   T1 t = bar1();
 }
 #pragma omp end declare target
+
+// Do not crash on these expressions during device compilation.
+long double qa, qb;
+decltype(qa + qb) qc;
+double qd[sizeof(-(-(qc * 2)))];
Index: clang/lib/Sema/SemaOpenMP.cpp
===
--- clang/lib/Sema/SemaOpenMP.cpp
+++ clang/lib/Sema/SemaOpenMP.cpp
@@ -1828,6 +1828,10 @@
 void Sema::checkOpenMPDeviceExpr(const Expr *E) {
   assert(getLangOpts().OpenMP && getLangOpts().OpenMPIsDevice &&
  "OpenMP device compilation mode is expected.");
+  // TODO: Do not check outside of functions for now as the targetDiag below
+  //   requires one.
+  if (!getCurFunctionDecl())
+return;
   QualType Ty = E->getType();
   if ((Ty->isFloat16Type() && !Context.getTargetInfo().hasFloat16Type()) ||
   ((Ty->isFloat128Type() ||


Index: clang/test/OpenMP/nvptx_unsupported_type_messages.cpp
===
--- clang/test/OpenMP/nvptx_unsupported_type_messages.cpp
+++ clang/test/OpenMP/nvptx_unsupported_type_messages.cpp
@@ -56,3 +56,8 @@
   T1 t = bar1();
 }
 #pragma omp end declare target
+
+// Do not crash on these expressions during device compilation.
+long double qa, qb;
+decltype(qa + qb) qc;
+double qd[sizeof(-(-(qc * 2)))];
Index: clang/lib/Sema/SemaOpenMP.cpp
===
--- clang/lib/Sema/SemaOpenMP.cpp
+++ clang/lib/Sema/SemaOpenMP.cpp
@@ -1828,6 +1828,10 @@
 void Sema::checkOpenMPDeviceExpr(const Expr *E) {
   assert(getLangOpts().OpenMP && getLangOpts().OpenMPIsDevice &&
  "OpenMP device compilation mode is expected.");
+  // TODO: Do not check outside of functions for now as the targetDiag below
+  //   requires one.
+  if (!getCurFunctionDecl())
+return;
   QualType Ty = E->getType();
   if ((Ty->isFloat16Type() && !Context.getTargetInfo().hasFloat16Type()) ||
   ((Ty->isFloat128Type() ||
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D77777: [nvptx] Add `nvvm.texsurf.handle` internalizer.

[Artem Belevich via Phabricator via cfe-commits]

tra added a subscriber: majnemer.
tra added a comment.

In D7#1975178 , @hliao wrote:

> the 1st argument in `llvm.nvvm.texsurf.hande.internal` or the 2nd one in 
> `llvm.nvvm.texsurf.handle` must be kept as an immediate or constant value, 
> i.e. that global variable. However, optimizations will find common code in 
> the following
>
>   if (cond) {
> %hnd = texsurf.handle.internal(@tex1);
>   } else {
> %hnd = texsurf.handle.internal(@tex2)
>   }
>   = use(%hnd)
>
>
> and hoist or sink it into
>
>   if (cond) {
> %ptr = @tex1;
>   } else {
> %ptr = @tex2;
>   }
>   %hnd = texsurf.handle.intenal(%ptr);
>   = use(%hnd)
>
>
> The backend cannot handle non immediate operand in `texsurf.handle`. The 
> similar thing happens to `read.register` as well as it also assumes its 
> argument is always an immediate value.


I wonder if we can use `token` types to represent the handle? 
https://reviews.llvm.org/D11861
@majnemer -- would this use case be suitable for the `token` type?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D7



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

[PATCH] D77777: [nvptx] Add `nvvm.texsurf.handle` internalizer.

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

Also, if I read PTX docs correctly, it should be OK to pass texture handle 
address via an intermediate variable:
https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#texture-sampler-and-surface-types

> Creating pointers to opaque variables using mov, e.g., mov.u64 reg, 
> opaque_var;. The resulting pointer may be stored to and loaded from memory, 
> passed as a parameter to functions, and de-referenced by texture and surface 
> load, store, and query instructions

We may not need the tokens and should be able to use regular pointer.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D7



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

[PATCH] D77923: OpenCL: Fix some missing predefined macros

[Matt Arsenault via Phabricator via cfe-commits]

arsenm created this revision.
arsenm added reviewers: Anastasia, yaxunl, scott.linder.
Herald added subscribers: kerbowa, hiraditya, nhaehnle, wdng, jvesely.

Some of the device specific standard predefines were missing.

  

__IMAGE_SUPPORT__ was only hardcoded for SPIR. __OPENCL_VERSION__
wasn't defined at all, so allow targets to pick values for these.


https://reviews.llvm.org/D77923

Files:
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/lib/Basic/Targets/AMDGPU.h
  clang/lib/Basic/Targets/SPIR.h
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/test/Preprocessor/predefined-macros.c
  llvm/include/llvm/Support/TargetParser.h
  llvm/lib/Support/TargetParser.cpp

Index: llvm/lib/Support/TargetParser.cpp
===
--- llvm/lib/Support/TargetParser.cpp
+++ llvm/lib/Support/TargetParser.cpp
@@ -72,36 +72,36 @@
   {{"oland"}, {"gfx601"},  GK_GFX601,  FEATURE_NONE},
   {{"pitcairn"},  {"gfx601"},  GK_GFX601,  FEATURE_NONE},
   {{"verde"}, {"gfx601"},  GK_GFX601,  FEATURE_NONE},
-  {{"gfx700"},{"gfx700"},  GK_GFX700,  FEATURE_NONE},
-  {{"kaveri"},{"gfx700"},  GK_GFX700,  FEATURE_NONE},
-  {{"gfx701"},{"gfx701"},  GK_GFX701,  FEATURE_FAST_FMA_F32},
-  {{"hawaii"},{"gfx701"},  GK_GFX701,  FEATURE_FAST_FMA_F32},
-  {{"gfx702"},{"gfx702"},  GK_GFX702,  FEATURE_FAST_FMA_F32},
-  {{"gfx703"},{"gfx703"},  GK_GFX703,  FEATURE_NONE},
-  {{"kabini"},{"gfx703"},  GK_GFX703,  FEATURE_NONE},
-  {{"mullins"},   {"gfx703"},  GK_GFX703,  FEATURE_NONE},
-  {{"gfx704"},{"gfx704"},  GK_GFX704,  FEATURE_NONE},
-  {{"bonaire"},   {"gfx704"},  GK_GFX704,  FEATURE_NONE},
-  {{"gfx801"},{"gfx801"},  GK_GFX801,  FEATURE_FAST_FMA_F32|FEATURE_FAST_DENORMAL_F32},
-  {{"carrizo"},   {"gfx801"},  GK_GFX801,  FEATURE_FAST_FMA_F32|FEATURE_FAST_DENORMAL_F32},
-  {{"gfx802"},{"gfx802"},  GK_GFX802,  FEATURE_FAST_DENORMAL_F32},
-  {{"iceland"},   {"gfx802"},  GK_GFX802,  FEATURE_FAST_DENORMAL_F32},
-  {{"tonga"}, {"gfx802"},  GK_GFX802,  FEATURE_FAST_DENORMAL_F32},
-  {{"gfx803"},{"gfx803"},  GK_GFX803,  FEATURE_FAST_DENORMAL_F32},
-  {{"fiji"},  {"gfx803"},  GK_GFX803,  FEATURE_FAST_DENORMAL_F32},
-  {{"polaris10"}, {"gfx803"},  GK_GFX803,  FEATURE_FAST_DENORMAL_F32},
-  {{"polaris11"}, {"gfx803"},  GK_GFX803,  FEATURE_FAST_DENORMAL_F32},
-  {{"gfx810"},{"gfx810"},  GK_GFX810,  FEATURE_FAST_DENORMAL_F32},
-  {{"stoney"},{"gfx810"},  GK_GFX810,  FEATURE_FAST_DENORMAL_F32},
-  {{"gfx900"},{"gfx900"},  GK_GFX900,  FEATURE_FAST_FMA_F32|FEATURE_FAST_DENORMAL_F32},
-  {{"gfx902"},{"gfx902"},  GK_GFX902,  FEATURE_FAST_FMA_F32|FEATURE_FAST_DENORMAL_F32},
-  {{"gfx904"},{"gfx904"},  GK_GFX904,  FEATURE_FAST_FMA_F32|FEATURE_FAST_DENORMAL_F32},
-  {{"gfx906"},{"gfx906"},  GK_GFX906,  FEATURE_FAST_FMA_F32|FEATURE_FAST_DENORMAL_F32},
-  {{"gfx908"},{"gfx908"},  GK_GFX908,  FEATURE_FAST_FMA_F32|FEATURE_FAST_DENORMAL_F32},
-  {{"gfx909"},{"gfx909"},  GK_GFX909,  FEATURE_FAST_FMA_F32|FEATURE_FAST_DENORMAL_F32},
-  {{"gfx1010"},   {"gfx1010"}, GK_GFX1010, FEATURE_FAST_FMA_F32|FEATURE_FAST_DENORMAL_F32|FEATURE_WAVE32},
-  {{"gfx1011"},   {"gfx1011"}, GK_GFX1011, FEATURE_FAST_FMA_F32|FEATURE_FAST_DENORMAL_F32|FEATURE_WAVE32},
-  {{"gfx1012"},   {"gfx1012"}, GK_GFX1012, FEATURE_FAST_FMA_F32|FEATURE_FAST_DENORMAL_F32|FEATURE_WAVE32},
+  {{"gfx700"},{"gfx700"},  GK_GFX700,  FEATURE_FLAT_ADDRESS_SPACE},
+  {{"kaveri"},{"gfx700"},  GK_GFX700,  FEATURE_FLAT_ADDRESS_SPACE},
+  {{"gfx701"},{"gfx701"},  GK_GFX701,  FEATURE_FAST_FMA_F32|FEATURE_FLAT_ADDRESS_SPACE},
+  {{"hawaii"},{"gfx701"},  GK_GFX701,  FEATURE_FAST_FMA_F32|FEATURE_FLAT_ADDRESS_SPACE},
+  {{"gfx702"},{"gfx702"},  GK_GFX702,  FEATURE_FAST_FMA_F32|FEATURE_FLAT_ADDRESS_SPACE},
+  {{"gfx703"},{"gfx703"},  GK_GFX703,  FEATURE_FLAT_ADDRESS_SPACE},
+  {{"kabini"},{"gfx703"},  GK_GFX703,  FEATURE_FLAT_ADDRESS_SPACE},
+  {{"mullins"},   {"gfx703"},  GK_GFX703,  FEATURE_FLAT_ADDRESS_SPACE},
+  {{"gfx704"},{"gfx704"},  GK_GFX704,  FEATURE_FLAT_ADDRESS_SPACE},
+  {{"bonaire"},   {"gfx704"},  GK_GFX704,  FEATURE_FLAT_ADDRESS_SPACE},
+  {{"gfx801"},{"gfx801"},  GK_GFX801,  FEATURE_FAST_FMA_F32|FEATURE_FAST_DENORMAL_F32|FEATURE_FLAT_ADDRESS_SPACE},
+  {{"carrizo"},   {"gfx801"},  GK_GFX801,  FEATURE_FAST_FMA_F32|FEATURE_FAST_DENORMAL_F32|FEATURE_FLAT_ADDRESS_SPACE},
+  {{"gfx802"},{"gfx802"},  GK_GFX802,  FEATURE_FAST_DENORMAL_F32|FEATURE_FLAT_ADDRESS_SPACE},
+  {{"iceland"},   {"gfx802"},  GK_GFX802,  FEATURE_FAST_DENORMAL_F32|FEATURE_FLAT_ADDRESS_SPACE},
+  {{"tonga"}, {"gfx802"},  GK_GFX802,  FEATURE_FAST_DENORMAL_F32|FEATURE_FLAT_ADDRESS_SPACE},
+  {{"gfx803"},{"gfx803"},  GK_GFX803,  FEATURE_FAST_DENORMAL_F32|FEATURE_FLAT_ADDRESS_SPACE},
+  {{"fiji"},  {"gfx803"},  GK_GFX803,  FEATURE_FAST_DENORMAL_F32|FEATURE_FLAT_ADDRESS_SPACE},
+  {{"polaris10"}, {"gfx803"},  GK_GFX803

[PATCH] D75936: Add a Pass to X86 that builds a Condensed CFG for Load Value Injection (LVI) Gadgets [4/6]

[Matthew Riley via Phabricator via cfe-commits]

mattdr added a comment.

@craig.topper can you please update/rebase this stack to remove the early LVI 
CFI work that ended up landed in https://reviews.llvm.org/D76812 instead?


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

https://reviews.llvm.org/D75936



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

[PATCH] D75934: Add Indirect Thunk Support to X86 to mitigate Load Value Injection (LVI) [2/6]

[Matthew Riley via Phabricator via cfe-commits]

mattdr added a comment.

I accidentally spent time reviewing this, only to cross-reference something in 
the LLVM code and find another diff (https://reviews.llvm.org/D76812) was 
written to answer Zola's request and has already been submitted.


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

https://reviews.llvm.org/D75934



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

[PATCH] D77908: [WebAssembly] Enable nontrapping-fptoint for `default` cpu

[Sam Clegg via Phabricator via cfe-commits]

sbc100 added inline comments.



Comment at: clang/lib/Basic/Targets/WebAssembly.h:33
 
-  bool HasNontrappingFPToInt = false;
+  bool HasNontrappingFPToInt = true;
   bool HasSignExt = false;

tlively wrote:
> It seems strange to change the default here. x86 initializes all its 
> corresponding features to `false` then selectively enables them in 
> `initFeatureMap`. I think we should stick with that pattern if possible.
Right.. makes sense. Done.



Comment at: clang/test/Preprocessor/wasm-target-features.c:10
+
+// NONTRAPPING-FPTOINT:#define __wasm_nontrapping_fptoint__ 1{{$}}
+

tlively wrote:
> Is there a RUN line corresponding to this check anymore?
Oops, deleted that line.



Comment at: clang/test/Preprocessor/wasm-target-features.c:37
 //
-// NONTRAPPING-FPTOINT:#define __wasm_nontrapping_fptoint__ 1{{$}}
+// NO-NONTRAPPING-FPTOINT-NOT:#define __wasm_nontrapping_fptoint__ 1{{$}}
 

Here is t he test for disabling in clang.

For llc there was already a test for `-mattr=-nontrapping-fptoint` in the form 
of `llvm/test/CodeGen/WebAssembly/conv-trap.ll`.   This is what caused me to 
need to fix `getFeatureString`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77908



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

[PATCH] D77908: [WebAssembly] Enable nontrapping-fptoint for `default` cpu

[Sam Clegg via Phabricator via cfe-commits]

sbc100 updated this revision to Diff 256712.
sbc100 marked 7 inline comments as done.
sbc100 added a comment.

feedback


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77908

Files:
  clang/lib/Basic/Targets/WebAssembly.cpp
  clang/lib/Basic/Targets/WebAssembly.h
  clang/test/Preprocessor/wasm-target-features.c
  lld/test/wasm/alias.ll
  lld/test/wasm/call-indirect.ll
  lld/test/wasm/cxx-mangling.ll
  lld/test/wasm/data-layout.ll
  lld/test/wasm/import-memory.test
  llvm/test/CodeGen/WebAssembly/multivalue.ll

Index: llvm/test/CodeGen/WebAssembly/multivalue.ll
===
--- llvm/test/CodeGen/WebAssembly/multivalue.ll
+++ llvm/test/CodeGen/WebAssembly/multivalue.ll
@@ -1,5 +1,5 @@
-; RUN: llc < %s -asm-verbose=false -verify-machineinstrs -mattr=+multivalue,+tail-call | FileCheck %s
-; RUN: llc < %s -asm-verbose=false -verify-machineinstrs -disable-wasm-fallthrough-return-opt -wasm-disable-explicit-locals -wasm-keep-registers -mattr=+multivalue,+tail-call | FileCheck %s --check-prefix REGS
+; RUN: llc < %s -asm-verbose=false -verify-machineinstrs -mcpu=mvp -mattr=+multivalue,+tail-call | FileCheck %s
+; RUN: llc < %s -asm-verbose=false -verify-machineinstrs -mcpu=mvp -disable-wasm-fallthrough-return-opt -wasm-disable-explicit-locals -wasm-keep-registers -mattr=+multivalue,+tail-call | FileCheck %s --check-prefix REGS
 ; RUN: llc < %s --filetype=obj -mattr=+multivalue,+tail-call | obj2yaml | FileCheck %s --check-prefix OBJ
 
 ; Test that the multivalue calls, returns, function types, and block
@@ -249,14 +249,11 @@
 }
 
 ; CHECK-LABEL: .section .custom_section.target_features
-; CHECK-NEXT: .int8 3
+; CHECK-NEXT: .int8 2
 ; CHECK-NEXT: .int8 43
 ; CHECK-NEXT: .int8 10
 ; CHECK-NEXT: .ascii "multivalue"
 ; CHECK-NEXT: .int8 43
-; CHECK-NEXT: .int8 19
-; CHECK-NEXT: .ascii "nontrapping-fptoint"
-; CHECK-NEXT: .int8 43
 ; CHECK-NEXT: .int8 9
 ; CHECK-NEXT: .ascii "tail-call"
 
Index: lld/test/wasm/import-memory.test
===
--- lld/test/wasm/import-memory.test
+++ lld/test/wasm/import-memory.test
@@ -1,4 +1,4 @@
-# RUN: llc -filetype=obj %p/Inputs/start.ll -o %t.start.o
+# RUN: llc -mcpu=mvp -filetype=obj %p/Inputs/start.ll -o %t.start.o
 # RUN: wasm-ld --import-memory -o %t.wasm %t.start.o
 # RUN: obj2yaml %t.wasm | FileCheck %s
 
@@ -32,8 +32,7 @@
 # CHECK-MAX-NEXT:  Maximum: 0x0005
 # CHECK-MAX-NEXT:  - Type:
 
-# RUN: wasm-ld --import-memory --shared-memory \
-# RUN: --features=nontrapping-fptoint,atomics,bulk-memory \
+# RUN: wasm-ld --import-memory --shared-memory --features=atomics,bulk-memory \
 # RUN: --initial-memory=262144 --max-memory=327680 -o %t.max.wasm %t.start.o
 # RUN: obj2yaml %t.max.wasm | FileCheck -check-prefix=CHECK-SHARED %s
 
Index: lld/test/wasm/data-layout.ll
===
--- lld/test/wasm/data-layout.ll
+++ lld/test/wasm/data-layout.ll
@@ -1,5 +1,5 @@
-; RUN: llc -filetype=obj %p/Inputs/hello.ll -o %t.hello.o
-; RUN: llc -filetype=obj %s -o %t.o
+; RUN: llc -mcpu=mvp -filetype=obj %p/Inputs/hello.ll -o %t.hello.o
+; RUN: llc -mcpu=mvp -filetype=obj %s -o %t.o
 
 target triple = "wasm32-unknown-unknown"
 
@@ -69,7 +69,7 @@
 ; CHECK-MAX-NEXT: Maximum: 0x0002
 
 ; RUN: wasm-ld -no-gc-sections --allow-undefined --no-entry --shared-memory \
-; RUN: --features=atomics,bulk-memory,nontrapping-fptoint --initial-memory=131072 \
+; RUN: --features=atomics,bulk-memory --initial-memory=131072 \
 ; RUN: --max-memory=131072 -o %t_max.wasm %t.o %t.hello.o
 ; RUN: obj2yaml %t_max.wasm | FileCheck %s -check-prefix=CHECK-SHARED
 
Index: lld/test/wasm/cxx-mangling.ll
===
--- lld/test/wasm/cxx-mangling.ll
+++ lld/test/wasm/cxx-mangling.ll
@@ -54,3 +54,5 @@
 ; MANGLE-NEXT:Name:_Z3fooi
 ; CHECK-NEXT:   - Index:   2
 ; CHECK-NEXT: Name:_start
+; CHECK-NEXT:   - Type:CUSTOM
+; CHECK-NEXT: Name:target_features
Index: lld/test/wasm/call-indirect.ll
===
--- lld/test/wasm/call-indirect.ll
+++ lld/test/wasm/call-indirect.ll
@@ -154,3 +154,5 @@
 ; CHECK-NEXT: Name:_start
 ; CHECK-NEXT:   - Index:   4
 ; CHECK-NEXT: Name:call_ptr
+; CHECK-NEXT:   - Type:CUSTOM
+; CHECK-NEXT: Name:target_features
Index: lld/test/wasm/alias.ll
===
--- lld/test/wasm/alias.ll
+++ lld/test/wasm/alias.ll
@@ -62,3 +62,5 @@
 ; CHECK-NEXT: FunctionNames:
 ; CHECK-NEXT:   - Index:   0
 ; CHECK-NEXT: Name:_start
+; CHECK-NEXT:   - Type:CU

[PATCH] D75934: Add Indirect Thunk Support to X86 to mitigate Load Value Injection (LVI) [2/6]

[Craig Topper via Phabricator via cfe-commits]

craig.topper abandoned this revision.
craig.topper added a comment.

This was superceded by D76812 


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

https://reviews.llvm.org/D75934



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

[PATCH] D77908: [WebAssembly] Enable nontrapping-fptoint for `default` cpu

[Sam Clegg via Phabricator via cfe-commits]

sbc100 updated this revision to Diff 256713.
sbc100 added a comment.

err.. arc diff did something funny.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77908

Files:
  clang/lib/Basic/Targets/WebAssembly.cpp
  clang/test/CodeGen/builtins-wasm.c
  clang/test/Preprocessor/wasm-target-features.c
  lld/test/wasm/alias.ll
  lld/test/wasm/call-indirect.ll
  lld/test/wasm/cxx-mangling.ll
  lld/test/wasm/data-layout.ll
  lld/test/wasm/function-imports-first.ll
  lld/test/wasm/function-imports.ll
  lld/test/wasm/gc-imports.ll
  lld/test/wasm/gc-sections.ll
  lld/test/wasm/import-memory.test
  lld/test/wasm/init-fini.ll
  lld/test/wasm/load-undefined.test
  lld/test/wasm/local-symbols.ll
  lld/test/wasm/locals-duplicate.test
  lld/test/wasm/relocatable.ll
  lld/test/wasm/signature-mismatch-export.ll
  lld/test/wasm/signature-mismatch.ll
  lld/test/wasm/stack-pointer.ll
  lld/test/wasm/undefined-weak-call.ll
  lld/test/wasm/weak-alias-overide.ll
  lld/test/wasm/weak-alias.ll
  lld/test/wasm/weak-symbols.ll
  lld/test/wasm/weak-undefined.ll
  llvm/lib/Target/WebAssembly/WebAssembly.td
  llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
  llvm/test/CodeGen/WebAssembly/conv.ll
  llvm/test/CodeGen/WebAssembly/multivalue.ll
  llvm/test/CodeGen/WebAssembly/mutable-globals.ll
  llvm/test/CodeGen/WebAssembly/reference-types.ll
  llvm/test/CodeGen/WebAssembly/tailcall.ll
  llvm/test/CodeGen/WebAssembly/target-features-tls.ll
  llvm/test/MC/WebAssembly/array-fill.ll
  llvm/test/MC/WebAssembly/assembler-binary.ll
  llvm/test/MC/WebAssembly/basic-assembly-errors.s
  llvm/test/MC/WebAssembly/basic-assembly.s
  llvm/test/MC/WebAssembly/bss.ll
  llvm/test/MC/WebAssembly/comdat.ll
  llvm/test/MC/WebAssembly/data-section.s
  llvm/test/MC/WebAssembly/debug-info.ll
  llvm/test/MC/WebAssembly/explicit-sections.ll
  llvm/test/MC/WebAssembly/global-ctor-dtor.ll
  llvm/test/MC/WebAssembly/objdump.s
  llvm/test/MC/WebAssembly/type-index.s
  llvm/test/MC/WebAssembly/visibility.ll

Index: llvm/test/MC/WebAssembly/visibility.ll
===
--- llvm/test/MC/WebAssembly/visibility.ll
+++ llvm/test/MC/WebAssembly/visibility.ll
@@ -25,4 +25,5 @@
 ; CHECK-NEXT: Name:hiddenVis
 ; CHECK-NEXT: Flags:   [ VISIBILITY_HIDDEN ]
 ; CHECK-NEXT: Function:1
-; CHECK-NEXT: ...
+; CHECK-NEXT:   - Type:CUSTOM
+; CHECK-NEXT: Name:target_features
Index: llvm/test/MC/WebAssembly/type-index.s
===
--- llvm/test/MC/WebAssembly/type-index.s
+++ llvm/test/MC/WebAssembly/type-index.s
@@ -1,6 +1,6 @@
-# RUN: llvm-mc -triple=wasm32-unknown-unknown -mattr=+unimplemented-simd128,+nontrapping-fptoint,+exception-handling < %s | FileCheck %s
+# RUN: llvm-mc -triple=wasm32-unknown-unknown -mattr=+unimplemented-simd128,+exception-handling < %s | FileCheck %s
 # Check that it converts to .o without errors:
-# RUN: llvm-mc -triple=wasm32-unknown-unknown -filetype=obj -mattr=+unimplemented-simd128,+nontrapping-fptoint,+exception-handling < %s | obj2yaml | FileCheck -check-prefix=BIN %s
+# RUN: llvm-mc -triple=wasm32-unknown-unknown -filetype=obj -mattr=+unimplemented-simd128,+exception-handling < %s | obj2yaml | FileCheck -check-prefix=BIN %s
 
 # Minimal test for type indices in call_indirect.
 
Index: llvm/test/MC/WebAssembly/objdump.s
===
--- llvm/test/MC/WebAssembly/objdump.s
+++ llvm/test/MC/WebAssembly/objdump.s
@@ -1,4 +1,4 @@
-# RUN: llvm-mc -triple=wasm32-unknown-unknown -filetype=obj -o %t.o -mattr=+simd128,+nontrapping-fptoint,+exception-handling < %s
+# RUN: llvm-mc -triple=wasm32-unknown-unknown -filetype=obj -o %t.o -mattr=+simd128,+exception-handling < %s
 # RUN: llvm-objdump --triple=wasm32-unknown-unknown -d %t.o | FileCheck %s
 
 test0:
Index: llvm/test/MC/WebAssembly/global-ctor-dtor.ll
===
--- llvm/test/MC/WebAssembly/global-ctor-dtor.ll
+++ llvm/test/MC/WebAssembly/global-ctor-dtor.ll
@@ -183,4 +183,5 @@
 ; CHECK-NEXT: Symbol: 10
 ; CHECK-NEXT:   - Priority: 65535
 ; CHECK-NEXT: Symbol: 7
-; CHECK-NEXT: ...
+; CHECK-NEXT:   - Type:CUSTOM
+; CHECK-NEXT: Name:target_features
Index: llvm/test/MC/WebAssembly/explicit-sections.ll
===
--- llvm/test/MC/WebAssembly/explicit-sections.ll
+++ llvm/test/MC/WebAssembly/explicit-sections.ll
@@ -70,4 +70,5 @@
 ; CHECK-NEXT: Name:.sec2
 ; CHECK-NEXT: Alignment:   3
 ; CHECK-NEXT: Flags:   [ ]
-; CHECK-NEXT: ...
+; CHECK-NEXT:   - Type:CUSTOM
+; CHECK-NEXT: Name:target_features
Index: llvm/test/MC/WebAssembly/debug-info.ll
===

[PATCH] D77772: [Clang] Expose RequiresNullTerminator in FileManager.

[Michael Spencer via Phabricator via cfe-commits]

Bigcheese updated this revision to Diff 256722.
Bigcheese added a comment.

Added a test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D2

Files:
  clang/include/clang/Basic/FileManager.h
  clang/lib/Basic/FileManager.cpp
  llvm/lib/Support/MemoryBuffer.cpp
  llvm/unittests/Support/MemoryBufferTest.cpp

Index: llvm/unittests/Support/MemoryBufferTest.cpp
===
--- llvm/unittests/Support/MemoryBufferTest.cpp
+++ llvm/unittests/Support/MemoryBufferTest.cpp
@@ -380,4 +380,24 @@
   ASSERT_EQ(16u, MB.getBufferSize());
   EXPECT_EQ("", MB.getBuffer());
 }
+
+TEST_F(MemoryBufferTest, mmapVolatileNoNull) {
+  int FD;
+  SmallString<64> TestPath;
+  ASSERT_NO_ERROR(sys::fs::createTemporaryFile(
+  "MemoryBufferTest_mmapVolatileNoNull", "temp", FD, TestPath));
+  FileRemover Cleanup(TestPath);
+  raw_fd_ostream OF(FD, true);
+  // Create a file large enough to mmap. A 32KiB file should be enough.
+  for (unsigned i = 0; i < 0x1000; ++i)
+OF << "01234567";
+  OF.flush();
+
+  auto MBOrError = MemoryBuffer::getOpenFile(FD, TestPath, -1, false, true);
+  ASSERT_NO_ERROR(MBOrError.getError())
+  OwningBuffer MB = std::move(*MBOrError);
+  EXPECT_EQ(MB->getBufferKind(), MemoryBuffer::MemoryBuffer_MMap);
+  EXPECT_EQ(MB->getBufferSize(), std::size_t(0x8000));
+  EXPECT_TRUE(MB->getBuffer().startswith("01234567"));
+}
 }
Index: llvm/lib/Support/MemoryBuffer.cpp
===
--- llvm/lib/Support/MemoryBuffer.cpp
+++ llvm/lib/Support/MemoryBuffer.cpp
@@ -329,7 +329,7 @@
   // mmap may leave the buffer without null terminator if the file size changed
   // by the time the last page is mapped in, so avoid it if the file size is
   // likely to change.
-  if (IsVolatile)
+  if (IsVolatile && RequiresNullTerminator)
 return false;
 
   // We don't use mmap for small files because this can severely fragment our
Index: clang/lib/Basic/FileManager.cpp
===
--- clang/lib/Basic/FileManager.cpp
+++ clang/lib/Basic/FileManager.cpp
@@ -458,7 +458,8 @@
 }
 
 llvm::ErrorOr>
-FileManager::getBufferForFile(const FileEntry *Entry, bool isVolatile) {
+FileManager::getBufferForFile(const FileEntry *Entry, bool isVolatile,
+  bool RequiresNullTerminator) {
   uint64_t FileSize = Entry->getSize();
   // If there's a high enough chance that the file have changed since we
   // got its size, force a stat before opening it.
@@ -468,28 +469,29 @@
   StringRef Filename = Entry->getName();
   // If the file is already open, use the open file descriptor.
   if (Entry->File) {
-auto Result =
-Entry->File->getBuffer(Filename, FileSize,
-   /*RequiresNullTerminator=*/true, isVolatile);
+auto Result = Entry->File->getBuffer(Filename, FileSize,
+ RequiresNullTerminator, isVolatile);
 Entry->closeFile();
 return Result;
   }
 
   // Otherwise, open the file.
-  return getBufferForFileImpl(Filename, FileSize, isVolatile);
+  return getBufferForFileImpl(Filename, FileSize, isVolatile,
+  RequiresNullTerminator);
 }
 
 llvm::ErrorOr>
 FileManager::getBufferForFileImpl(StringRef Filename, int64_t FileSize,
-  bool isVolatile) {
+  bool isVolatile,
+  bool RequiresNullTerminator) {
   if (FileSystemOpts.WorkingDir.empty())
-return FS->getBufferForFile(Filename, FileSize,
-/*RequiresNullTerminator=*/true, isVolatile);
+return FS->getBufferForFile(Filename, FileSize, RequiresNullTerminator,
+isVolatile);
 
   SmallString<128> FilePath(Filename);
   FixupRelativePath(FilePath);
-  return FS->getBufferForFile(FilePath, FileSize,
-  /*RequiresNullTerminator=*/true, isVolatile);
+  return FS->getBufferForFile(FilePath, FileSize, RequiresNullTerminator,
+  isVolatile);
 }
 
 /// getStatValue - Get the 'stat' information for the specified path,
Index: clang/include/clang/Basic/FileManager.h
===
--- clang/include/clang/Basic/FileManager.h
+++ clang/include/clang/Basic/FileManager.h
@@ -378,15 +378,19 @@
   /// Open the specified file as a MemoryBuffer, returning a new
   /// MemoryBuffer if successful, otherwise returning null.
   llvm::ErrorOr>
-  getBufferForFile(const FileEntry *Entry, bool isVolatile = false);
+  getBufferForFile(const FileEntry *Entry, bool isVolatile = false,
+   bool RequiresNullTerminator = true);
   llvm::ErrorOr>
-  getBufferForFile(StringRef Filename, bool isVolatile = false) {
-return getBufferForFileImp

[clang] ed03d94 - Revert "[TLI] Per-function fveclib for math library used for vectorization"

[Mehdi Amini via cfe-commits]

Author: Mehdi Amini
Date: 2020-04-11T01:05:01Z
New Revision: ed03d9485eb5b502708f8a21ce34fa6da05a9ca5

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

LOG: Revert "[TLI] Per-function fveclib for math library used for vectorization"

This reverts commit 60c642e74be6af86906d9f3d982728be7bd4329f.

This patch is making the TLI "closed" for a predefined set of VecLib
while at the moment it is extensible for anyone to customize when using
LLVM as a library.
Reverting while we figure out a way to re-land it without losing the
generality of the current API.

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

Added: 


Modified: 
clang/lib/CodeGen/BackendUtil.cpp
clang/lib/CodeGen/CGCall.cpp
llvm/include/llvm/Analysis/TargetLibraryInfo.h
llvm/lib/Analysis/InlineCost.cpp
llvm/lib/Analysis/TargetLibraryInfo.cpp
llvm/test/Transforms/Inline/inline-no-builtin-compatible.ll

Removed: 
clang/test/CodeGen/libcalls-veclib.c
llvm/test/Transforms/Inline/veclib-compat.ll



diff  --git a/clang/lib/CodeGen/BackendUtil.cpp 
b/clang/lib/CodeGen/BackendUtil.cpp
index bd1a4e50e7a5..87d5ebe853d8 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -354,8 +354,24 @@ static void addMemTagOptimizationPasses(const 
PassManagerBuilder &Builder,
   PM.add(createStackSafetyGlobalInfoWrapperPass(/*SetMetadata=*/true));
 }
 
-static TargetLibraryInfoImpl *createTLII(llvm::Triple &TargetTriple) {
-  return new TargetLibraryInfoImpl(TargetTriple);
+static TargetLibraryInfoImpl *createTLII(llvm::Triple &TargetTriple,
+ const CodeGenOptions &CodeGenOpts) {
+  TargetLibraryInfoImpl *TLII = new TargetLibraryInfoImpl(TargetTriple);
+
+  switch (CodeGenOpts.getVecLib()) {
+  case CodeGenOptions::Accelerate:
+
TLII->addVectorizableFunctionsFromVecLib(TargetLibraryInfoImpl::Accelerate);
+break;
+  case CodeGenOptions::MASSV:
+TLII->addVectorizableFunctionsFromVecLib(TargetLibraryInfoImpl::MASSV);
+break;
+  case CodeGenOptions::SVML:
+TLII->addVectorizableFunctionsFromVecLib(TargetLibraryInfoImpl::SVML);
+break;
+  default:
+break;
+  }
+  return TLII;
 }
 
 static void addSymbolRewriterPass(const CodeGenOptions &Opts,
@@ -548,7 +564,8 @@ void EmitAssemblyHelper::CreatePasses(legacy::PassManager 
&MPM,
   // are inserted before PMBuilder ones - they'd get the default-constructed
   // TLI with an unknown target otherwise.
   Triple TargetTriple(TheModule->getTargetTriple());
-  std::unique_ptr TLII(createTLII(TargetTriple));
+  std::unique_ptr TLII(
+  createTLII(TargetTriple, CodeGenOpts));
 
   // If we reached here with a non-empty index file name, then the index file
   // was empty and we are not performing ThinLTO backend compilation (used in
@@ -790,7 +807,8 @@ bool EmitAssemblyHelper::AddEmitPasses(legacy::PassManager 
&CodeGenPasses,
raw_pwrite_stream *DwoOS) {
   // Add LibraryInfo.
   llvm::Triple TargetTriple(TheModule->getTargetTriple());
-  std::unique_ptr TLII(createTLII(TargetTriple));
+  std::unique_ptr TLII(
+  createTLII(TargetTriple, CodeGenOpts));
   CodeGenPasses.add(new TargetLibraryInfoWrapperPass(*TLII));
 
   // Normal mode, emit a .s or .o file by running the code generator. Note,
@@ -1126,7 +1144,8 @@ void EmitAssemblyHelper::EmitAssemblyWithNewPassManager(
   // Register the target library analysis directly and give it a customized
   // preset TLI.
   Triple TargetTriple(TheModule->getTargetTriple());
-  std::unique_ptr TLII(createTLII(TargetTriple));
+  std::unique_ptr TLII(
+  createTLII(TargetTriple, CodeGenOpts));
   FAM.registerPass([&] { return TargetLibraryAnalysis(*TLII); });
 
   // Register all the basic analyses with the managers.

diff  --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index 73869fa3c9b0..3c44632dfd60 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -1868,24 +1868,6 @@ static void addNoBuiltinAttributes(llvm::AttrBuilder 
&FuncAttrs,
   llvm::for_each(NBA->builtinNames(), AddNoBuiltinAttr);
 }
 
-static void addVectLibAttributes(llvm::AttrBuilder &FuncAttrs,
- const CodeGenOptions &CodeGenOpts) {
-  StringRef AttributeName = "veclib";
-  switch (CodeGenOpts.getVecLib()) {
-  case CodeGenOptions::Accelerate:
-FuncAttrs.addAttribute(AttributeName, "Accelerate");
-break;
-  case CodeGenOptions::MASSV:
-FuncAttrs.addAttribute(AttributeName, "MASSV");
-break;
-  case CodeGenOptions::SVML:
-FuncAttrs.addAttribute(AttributeName, "SVML");
-break;
-  case CodeGenOptions::NoLibrary:
-break;
-  }
-}
-
 void CodeGenModule::ConstructAttributeList(
 StringRef Name, const CGFunctionInf

[PATCH] D77925: Revert "[TLI] Per-function fveclib for math library used for vectorization"

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini created this revision.
mehdi_amini added a reviewer: tejohnson.
Herald added subscribers: cfe-commits, haicheng, hiraditya, eraman.
Herald added a project: clang.
mehdi_amini added a reviewer: wenlei.
tejohnson accepted this revision.
tejohnson added a comment.
This revision is now accepted and ready to land.

lgtm


This reverts commit 60c642e74be6af86906d9f3d982728be7bd4329f 
.

This patch is making the TLI "closed" for a predefined set of VecLib
while at the moment it is extensible for anyone to customize when using
LLVM as a library.
Reverting while we figure out a way to re-land it without losing the
generality of the current API.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D77925

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/libcalls-veclib.c
  llvm/include/llvm/Analysis/TargetLibraryInfo.h
  llvm/lib/Analysis/InlineCost.cpp
  llvm/lib/Analysis/TargetLibraryInfo.cpp
  llvm/test/Transforms/Inline/inline-no-builtin-compatible.ll
  llvm/test/Transforms/Inline/veclib-compat.ll

Index: llvm/test/Transforms/Inline/veclib-compat.ll
===
--- llvm/test/Transforms/Inline/veclib-compat.ll
+++ /dev/null
@@ -1,48 +0,0 @@
-; RUN: opt < %s -inline -inline-caller-superset-tli=true -S | FileCheck %s --check-prefixes=COMMON
-; RUN: opt < %s -passes='cgscc(inline)' -inline-caller-superset-tli=true -S | FileCheck %s --check-prefixes=COMMON
-; RUN: opt < %s -inline -inline-caller-superset-tli=false -S | FileCheck %s --check-prefixes=NOSUPERSET,COMMON
-; RUN: opt < %s -passes='cgscc(inline)' -inline-caller-superset-tli=false -S | FileCheck %s --check-prefixes=NOSUPERSET,COMMON
-
-
-
-define i32 @callee_svml(i8 %X) #0 {
-entry:
-  ret i32 1
-}
-
-define i32 @callee_massv(i8 %X) #1 {
-entry:
-  ret i32 1
-}
-
-define i32 @callee_nolibrary(i8 %X) {
-entry:
-  ret i32 1
-}
-
-define i32 @caller_svml() #0 {
-; COMMON-LABEL: define i32 @caller_svml()
-entry:
-  %rslt = call i32 @callee_massv(i8 123)
-; COMMON: call i32 @callee_massv
-  %tmp1 = call i32 @callee_nolibrary(i8 123)
-; NOSUPERSET: call i32 @callee_nolibrary
-  %tmp2 = call i32 @callee_svml(i8 123)
-; COMMON-NOT: call
-  ret i32 %rslt
-}
-
-define i32 @caller_nolibrary() {
-; COMMON-LABEL: define i32 @caller_nolibrary()
-entry:
-  %rslt = call i32 @callee_svml(i8 123)
-; COMMON: call i32 @callee_svml
-  %tmp1 = call i32 @callee_massv(i8 123)
-; COMMON: call i32 @callee_massv
-  %tmp2 = call i32 @callee_nolibrary(i8 123)
-; COMMON-NOT: call
-  ret i32 %rslt
-}
-
-attributes #0 = { "veclib"="SVML" }
-attributes #1 = { "veclib"="MASSV" }
\ No newline at end of file
Index: llvm/test/Transforms/Inline/inline-no-builtin-compatible.ll
===
--- llvm/test/Transforms/Inline/inline-no-builtin-compatible.ll
+++ llvm/test/Transforms/Inline/inline-no-builtin-compatible.ll
@@ -3,8 +3,8 @@
 ; RUN: opt < %s -mtriple=x86_64-unknown-linux-gnu -S -passes='cgscc(inline)' | FileCheck %s
 
 ; Make sure we don't inline callees into a caller with a superset of the
-; no builtin attributes when -inline-caller-superset-tli=false.
-; RUN: opt < %s -inline-caller-superset-tli=false -mtriple=x86_64-unknown-linux-gnu -S -passes='cgscc(inline)' | FileCheck %s --check-prefix=NOSUPERSET
+; no builtin attributes when -inline-caller-superset-nobuiltin=false.
+; RUN: opt < %s -inline-caller-superset-nobuiltin=false -mtriple=x86_64-unknown-linux-gnu -S -passes='cgscc(inline)' | FileCheck %s --check-prefix=NOSUPERSET
 
 target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-unknown-linux-gnu"
Index: llvm/lib/Analysis/TargetLibraryInfo.cpp
===
--- llvm/lib/Analysis/TargetLibraryInfo.cpp
+++ llvm/lib/Analysis/TargetLibraryInfo.cpp
@@ -550,7 +550,7 @@
 TLI.setUnavailable(LibFunc_nvvm_reflect);
   }
 
-  TLI.addAllVectorizableFunctions();
+  TLI.addVectorizableFunctionsFromVecLib(ClVectorLibrary);
 }
 
 TargetLibraryInfoImpl::TargetLibraryInfoImpl() {
@@ -572,8 +572,8 @@
   ShouldExtI32Return(TLI.ShouldExtI32Return),
   ShouldSignExtI32Param(TLI.ShouldSignExtI32Param) {
   memcpy(AvailableArray, TLI.AvailableArray, sizeof(AvailableArray));
-  for (unsigned i = 0; i < NumVecLibs; i++)
-VecLibDescs[i] = TLI.VecLibDescs[i];
+  VectorDescs = TLI.VectorDescs;
+  ScalarDescs = TLI.ScalarDescs;
 }
 
 TargetLibraryInfoImpl::TargetLibraryInfoImpl(TargetLibraryInfoImpl &&TLI)
@@ -583,8 +583,8 @@
   ShouldSignExtI32Param(TLI.ShouldSignExtI32Param) {
   std::move(std::begin(TLI.AvailableArray), std::end(TLI.AvailableArray),
 AvailableArray);
-  for (unsigned i = 0; i < NumVecLibs; i++)
-VecLibDescs[i] = TLI.VecLibDescs[i];
+  VectorDescs = TLI.VectorDescs;
+  ScalarDescs = TLI.ScalarDescs;
 }
 
 TargetLibraryInfoImpl &T

[PATCH] D77777: [nvptx] Add `nvvm.texsurf.handle` internalizer.

[Michael Liao via Phabricator via cfe-commits]

hliao added a comment.

In D7#1975406 , @tra wrote:

> In D7#1975178 , @hliao wrote:
>
> > the 1st argument in `llvm.nvvm.texsurf.hande.internal` or the 2nd one in 
> > `llvm.nvvm.texsurf.handle` must be kept as an immediate or constant value, 
> > i.e. that global variable. However, optimizations will find common code in 
> > the following
> >
> >   if (cond) {
> > %hnd = texsurf.handle.internal(@tex1);
> >   } else {
> > %hnd = texsurf.handle.internal(@tex2)
> >   }
> >   = use(%hnd)
> >
> >
> > and hoist or sink it into
> >
> >   if (cond) {
> > %ptr = @tex1;
> >   } else {
> > %ptr = @tex2;
> >   }
> >   %hnd = texsurf.handle.intenal(%ptr);
> >   = use(%hnd)
> >
> >
> > The backend cannot handle non immediate operand in `texsurf.handle`. The 
> > similar thing happens to `read.register` as well as it also assumes its 
> > argument is always an immediate value.
>
>
> I wonder if we can use `token` types to represent the handle? 
> https://reviews.llvm.org/D11861
>  @majnemer -- would this use case be suitable for the `token` type?


If we still could make PHI over token, it canont serve this purpose. Check 
`llvm::canReplaceOperandWithVariable` for operand for details.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D7



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

[PATCH] D77925: Revert "[TLI] Per-function fveclib for math library used for vectorization"

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson accepted this revision.
tejohnson 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/D77925/new/

https://reviews.llvm.org/D77925



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

[PATCH] D77632: [TLI] Per-function fveclib for math library used for vectorization

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini added a comment.

The existing TLI provides a very convenient way to define a VecLib without LLVM 
knowing about it ahead of time. This feature is important for any embedded use 
of LLVM as a library out-of-tree (I'll add a unit-test in-tree).
I don't think it is a big change to this patch to preserve the current ability 
but I wanted to check first (and in the meantime I reverted in temporarily in 
https://reviews.llvm.org/D77925 to avoid the feature regression).

At the moment the place where you seem to use this knowledge is with the `enum 
VectorLibrary`  in the `TargetLibraryInfoImpl` class, and the `VecLibDescs` 
array which statically contains the known VecLib.
It seems to me that if we replace this enum with a string instead to identify 
the VecLib everything should still hold together and this would fit with minor 
changes to this path. The `VecLibDescs` could just be a 
`StringMap` in this case.

That was a third-party (in my case the XLA compiler) can still register its own 
"XLA" VecLib and add all the descriptors.

How does it sound?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77632



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

[PATCH] D73188: [AST] Improve overflow diagnostics for fixed-point constant evaluation.

[John McCall via Phabricator via cfe-commits]

rjmccall accepted this revision.
rjmccall added a comment.

LGTM.  I'm somewhat surprised that this is the implementation design for 
integer overflow diagnostics, but since it is, I see no reason not to adopt it 
for fixed-point as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73188



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

[PATCH] D76384: Move FPFeatures from BinaryOperator bitfields to Trailing storage

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Okay, that's fine, it's definitely a simpler change to not mess with the basic 
node hierarchy.  The one problem I see is that you've (accidentally?) set up 
the `FPOptions` methods so that you can't call them on a `BinaryOperator` 
that's actually a `CompoundAssignOperator` — they'll end up accessing the wrong 
memory.  Fortunately, that's pretty easy to fix, and fixing it should let you 
drop all the duplicate methods you've currently got on `CompoundAssignOperator`.




Comment at: clang/include/clang/AST/Expr.h:3480
+reinterpret_cast(this) + sizeof(BinaryOperator));
+return slot;
+  }

You should add an `offsetOfTrailingStorage()` method that returns 
`isa(this) ? sizeof(CompoundAssignOperator) : 
sizeof(BinaryOperator)`, and then you can add that here instead of hard-coding 
`sizeof(BinaryOperator)`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76384



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

[PATCH] D77925: Revert "[TLI] Per-function fveclib for math library used for vectorization"

[Mehdi AMINI via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGed03d9485eb5: Revert "[TLI] Per-function fveclib for 
math library used for vectorization" (authored by mehdi_amini).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77925

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/libcalls-veclib.c
  llvm/include/llvm/Analysis/TargetLibraryInfo.h
  llvm/lib/Analysis/InlineCost.cpp
  llvm/lib/Analysis/TargetLibraryInfo.cpp
  llvm/test/Transforms/Inline/inline-no-builtin-compatible.ll
  llvm/test/Transforms/Inline/veclib-compat.ll

Index: llvm/test/Transforms/Inline/veclib-compat.ll
===
--- llvm/test/Transforms/Inline/veclib-compat.ll
+++ /dev/null
@@ -1,48 +0,0 @@
-; RUN: opt < %s -inline -inline-caller-superset-tli=true -S | FileCheck %s --check-prefixes=COMMON
-; RUN: opt < %s -passes='cgscc(inline)' -inline-caller-superset-tli=true -S | FileCheck %s --check-prefixes=COMMON
-; RUN: opt < %s -inline -inline-caller-superset-tli=false -S | FileCheck %s --check-prefixes=NOSUPERSET,COMMON
-; RUN: opt < %s -passes='cgscc(inline)' -inline-caller-superset-tli=false -S | FileCheck %s --check-prefixes=NOSUPERSET,COMMON
-
-
-
-define i32 @callee_svml(i8 %X) #0 {
-entry:
-  ret i32 1
-}
-
-define i32 @callee_massv(i8 %X) #1 {
-entry:
-  ret i32 1
-}
-
-define i32 @callee_nolibrary(i8 %X) {
-entry:
-  ret i32 1
-}
-
-define i32 @caller_svml() #0 {
-; COMMON-LABEL: define i32 @caller_svml()
-entry:
-  %rslt = call i32 @callee_massv(i8 123)
-; COMMON: call i32 @callee_massv
-  %tmp1 = call i32 @callee_nolibrary(i8 123)
-; NOSUPERSET: call i32 @callee_nolibrary
-  %tmp2 = call i32 @callee_svml(i8 123)
-; COMMON-NOT: call
-  ret i32 %rslt
-}
-
-define i32 @caller_nolibrary() {
-; COMMON-LABEL: define i32 @caller_nolibrary()
-entry:
-  %rslt = call i32 @callee_svml(i8 123)
-; COMMON: call i32 @callee_svml
-  %tmp1 = call i32 @callee_massv(i8 123)
-; COMMON: call i32 @callee_massv
-  %tmp2 = call i32 @callee_nolibrary(i8 123)
-; COMMON-NOT: call
-  ret i32 %rslt
-}
-
-attributes #0 = { "veclib"="SVML" }
-attributes #1 = { "veclib"="MASSV" }
\ No newline at end of file
Index: llvm/test/Transforms/Inline/inline-no-builtin-compatible.ll
===
--- llvm/test/Transforms/Inline/inline-no-builtin-compatible.ll
+++ llvm/test/Transforms/Inline/inline-no-builtin-compatible.ll
@@ -3,8 +3,8 @@
 ; RUN: opt < %s -mtriple=x86_64-unknown-linux-gnu -S -passes='cgscc(inline)' | FileCheck %s
 
 ; Make sure we don't inline callees into a caller with a superset of the
-; no builtin attributes when -inline-caller-superset-tli=false.
-; RUN: opt < %s -inline-caller-superset-tli=false -mtriple=x86_64-unknown-linux-gnu -S -passes='cgscc(inline)' | FileCheck %s --check-prefix=NOSUPERSET
+; no builtin attributes when -inline-caller-superset-nobuiltin=false.
+; RUN: opt < %s -inline-caller-superset-nobuiltin=false -mtriple=x86_64-unknown-linux-gnu -S -passes='cgscc(inline)' | FileCheck %s --check-prefix=NOSUPERSET
 
 target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-unknown-linux-gnu"
Index: llvm/lib/Analysis/TargetLibraryInfo.cpp
===
--- llvm/lib/Analysis/TargetLibraryInfo.cpp
+++ llvm/lib/Analysis/TargetLibraryInfo.cpp
@@ -550,7 +550,7 @@
 TLI.setUnavailable(LibFunc_nvvm_reflect);
   }
 
-  TLI.addAllVectorizableFunctions();
+  TLI.addVectorizableFunctionsFromVecLib(ClVectorLibrary);
 }
 
 TargetLibraryInfoImpl::TargetLibraryInfoImpl() {
@@ -572,8 +572,8 @@
   ShouldExtI32Return(TLI.ShouldExtI32Return),
   ShouldSignExtI32Param(TLI.ShouldSignExtI32Param) {
   memcpy(AvailableArray, TLI.AvailableArray, sizeof(AvailableArray));
-  for (unsigned i = 0; i < NumVecLibs; i++)
-VecLibDescs[i] = TLI.VecLibDescs[i];
+  VectorDescs = TLI.VectorDescs;
+  ScalarDescs = TLI.ScalarDescs;
 }
 
 TargetLibraryInfoImpl::TargetLibraryInfoImpl(TargetLibraryInfoImpl &&TLI)
@@ -583,8 +583,8 @@
   ShouldSignExtI32Param(TLI.ShouldSignExtI32Param) {
   std::move(std::begin(TLI.AvailableArray), std::end(TLI.AvailableArray),
 AvailableArray);
-  for (unsigned i = 0; i < NumVecLibs; i++)
-VecLibDescs[i] = TLI.VecLibDescs[i];
+  VectorDescs = TLI.VectorDescs;
+  ScalarDescs = TLI.ScalarDescs;
 }
 
 TargetLibraryInfoImpl &TargetLibraryInfoImpl::operator=(const TargetLibraryInfoImpl &TLI) {
@@ -1520,16 +1520,7 @@
   return LHS.VectorFnName < S;
 }
 
-void TargetLibraryInfoImpl::addAllVectorizableFunctions() {
-  addVectorizableFunctionsFromVecLib(Accelerate, VecLibDescs[Accelerate]);
-  addVectorizableFunctionsFromVecLib(MASSV, VecLibDescs[MASSV]);
-  addVectorizableFunctionsFromVecLib(SVML, VecLibDescs[SVML]);
-}
-
-void TargetLibraryInfoImpl::addVectorizableFunct

[PATCH] D77592: [NFC}[CodeGen] Make VTable initialization a method of CGCXXABI

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

This is a weird point to allow further ABI customization of.  I understand why 
you want to customize this, but I wonder if it's actually worthwhile to make a 
`virtual` function for it vs. just checking some sort of flag in the builder.  
Isn't there quite a lot of structure you're going to have to duplicate just to 
call `addRelativeAddress` at the leaves?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77592



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

[PATCH] D77777: [nvptx] Add `nvvm.texsurf.handle` internalizer.

[Michael Liao via Phabricator via cfe-commits]

hliao added a comment.

In D7#1975440 , @tra wrote:

> Also, if I read PTX docs correctly, it should be OK to pass texture handle 
> address via an intermediate variable:
>  
> https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#texture-sampler-and-surface-types
>
> > Creating pointers to opaque variables using mov, e.g., mov.u64 reg, 
> > opaque_var;. The resulting pointer may be stored to and loaded from memory, 
> > passed as a parameter to functions, and de-referenced by texture and 
> > surface load, store, and query instructions
>
> We may not need the tokens and should be able to use regular pointer.


That handle is the output of `texsurf.handle` intrinsic instead of its input. 
Internally within NVTPX backend, it needs to keep track of which global 
variable needs to be a `texref` or `surfref` and requires the operand of 
`texsurf.handle` must be a global variable. Check 
`NVPTXReplaceImageHandles.cpp` line 167 - 175.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D7



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

[PATCH] D57226: [Fixed Point] [AST] Add an AST serialization code for fixed-point literals.

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Some minor requests, but otherwise this LGTM.




Comment at: include/clang/Serialization/ASTBitCodes.h:1637
+  /// A FixedPointLiteral record.
+  EXPR_FIXEDPOINT_LITERAL,
+

rjmccall wrote:
> ebevhan wrote:
> > I'm unsure if this is the right location for a new code. This will bump 
> > down all the other codes below this and cause any older file to not be read 
> > correctly.
> > 
> > Should the file format version number be bumped up?
> IIRC the real file format version for this is based on the exact revision of 
> the compiler and there is no pretense of serialized ASTs being sharable 
> between compilers.  I don't think we've ever bumped the version number for 
> incompatible changes like this.
But really you should add the enumerator to the end of the list.



Comment at: test/PCH/fixed-point-literal.h:1
+// Header for PCH test fixed-point-literal.c
+

Inputs like this generally go into the `Inputs` directory. 


Repository:
  rC Clang

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

https://reviews.llvm.org/D57226



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

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

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Scanned through the first bit.




Comment at: clang/docs/LanguageExtensions.rst:500
+Clang provides a matrix extension, which is currently being implemented. See
+:ref:`matrixsupport` for more details.
+

This should include just a bit more detail about the extension.  I would 
suggest:

> Clang supports matrix types as an experimental extension.  See 
> :`ref`matrices` for more details.



Comment at: clang/docs/MatrixSupport.rst:3
+Matrix Support
+==
+

This extension should be called something like "Matrices" or "Matrix Types".  
The "X Support" name makes it sound like it's a support layer for some external 
technology.



Comment at: clang/docs/MatrixSupport.rst:12
+matrix math on the C/C++ level. The draft specification can be found
+:ref:`below `.
+

1. "Clang provides a C/C++ language extension that allows users to directly 
express fixed-size matrices as language values and perform arithmetic on them."

2. This document *is* the specification, there's nothing to cross-reference it.



Comment at: clang/docs/MatrixSupport.rst:14
+
+Note that the implementation is currently in progress.
+

"This feature is currently experimental, and both its design and its 
implementation are in flux."



Comment at: clang/docs/MatrixSupport.rst:30
+directly. An *attribute-argument-clause* must be present and it shall have the
+form:
+

You can assume the existence of a hypothetical external language specification 
for GNU attribute syntax, so these starting paragraphs whittle down to:

> Matrix types can be declared by adding the `matrix_type` attribute to the 
> declaration of a `typedef` (or a C++ alias declaration).  The underlying type 
> of the `typedef` must be an unqualified integer or floating-point type.  The 
> attribute takes two arguments, both of which must be integer constant 
> expressions that evaluate to a value greater than zero.  The first specifies 
> the number of rows, and the second specifies the number of columns.  The 
> underlying type of the `typedef` becomes a matrix type with the given 
> dimensions and an element type of the former underlying type.

The paragraph about redeclarations is good.



Comment at: clang/docs/MatrixSupport.rst:48
+Matrix Type
+---
+

I would put this first before getting into the spelling.  You can also put the 
stuff about implementation limits on dimensions in here.



Comment at: clang/docs/MatrixSupport.rst:55
+padding in a way compatible with an array of at least that many elements of the
+underlying *element type*.
+

Do you actually want to guarantee this layout in the language specification?  I 
would just say that a matrix includes storage for `rows * columns` elements but 
that the interior layout and overall size and alignment are 
implementation-defined.



Comment at: clang/docs/MatrixSupport.rst:57
+
+A matrix type is a *scalar type* and its alignment is implementation defined.
+

These are both important to include, but they're unrelated and shouldn't be in 
the same sentence.



Comment at: clang/docs/MatrixSupport.rst:64
+
+TODO: Specify how matrix values are passed to functions.
+

That doesn't belong in a language specification, but you could reasonably add a 
non-normative section at the end about the decisions that Clang currently makes 
for things like size, alignment, internal layout, and argument/result 
conventions.



Comment at: clang/docs/MatrixSupport.rst:106
+expression. ``expression`` shall not be a comma expression, and shall be a
+prvalue of unscoped enumeration or integral type. Given the expression
+``E1[E2][E3]`` the result is an lvalue of the same type as the underlying

It would be better to say explicitly that "The index expressions shall..."



Comment at: clang/docs/MatrixSupport.rst:110
+the matrix. The expression E1 is sequenced before E2 and E3. The expressions
+E2 and E3 are unsequenced.
+

I'd put all this like:

> An expression of the form ``E1 [E2] [E3]``, where ``E1`` has matrix type ``cv 
> M``, is a matrix element access expression.  Let ``T`` be the element type of 
> ``M``, and let ``R`` and ``C`` be the number of rows and columns in ``M`` 
> respectively.  The index expressions shall have integral or unscoped 
> enumeration type and shall not be uses of the comma operator unless 
> parenthesized.  The first index expression shall evaluate to a non-negative 
> value less than ``R``, and the second index expression shall evaluate to a 
> non-negative value less than ``C``, or else the expression has undefined 
> behavior.  If ``E1`` is a prvalue, the result is a prvalue with type ``T`` 
> and is the value of the

[PATCH] D77910: AMDGPU: Define cl_khr_gl_sharing as a supported extension

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

I am not so sure whether compiler should always report this.

I thought it depends on platform and should let runtime to add it when it is 
really supported.

But on the other hand, we could report it by default if it is the most case, 
and let runtime to disable it if it is not supported.

So I will defer this to Brian.


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

https://reviews.llvm.org/D77910



___
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.

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

It appears I can crash clang with some texture code: 
https://godbolt.org/z/5vdEwC


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76365



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

[PATCH] D77777: [nvptx] Add `nvvm.texsurf.handle` internalizer.

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

In D7#1975628 , @hliao wrote:

> In D7#1975440 , @tra wrote:
>
> > Also, if I read PTX docs correctly, it should be OK to pass texture handle 
> > address via an intermediate variable:
> >  
> > https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#texture-sampler-and-surface-types
> >
> > > Creating pointers to opaque variables using mov, e.g., mov.u64 reg, 
> > > opaque_var;. The resulting pointer may be stored to and loaded from 
> > > memory, passed as a parameter to functions, and de-referenced by texture 
> > > and surface load, store, and query instructions
> >
> > We may not need the tokens and should be able to use regular pointer.
>
>
> That handle is the output of `texsurf.handle` intrinsic instead of its input. 
> Internally within NVTPX backend, it needs to keep track of which global 
> variable needs to be a `texref` or `surfref` and requires the operand of 
> `texsurf.handle` must be a global variable. Check 
> `NVPTXReplaceImageHandles.cpp` line 167 - 175.


That's the point I'm trying to make -- existing code may not be the best way to 
implement this and should be improved. If we are serious about supporting 
textures & surfaces, then it may be worth making it work properly, as opposed 
to adding more hacks to get the old and till-now largely unused bits of LLVM do 
what we want.

We could do something like this:

- class instances with the texref attribute are lowered in a way that produces 
a global handle. It could be a handle-only, or the handle may be produced in 
addition to the object itself.
- intrinsics accept texref pointers and follow standard LLVM rules/assumptions.
- => code is subject to regular LLVM optimizations
- => no need to have special passes to tweak IR just so. At worst, we may keep 
something similar to NVPTXReplaceImageHandles which would replace object 
references with handle references. We may not even need to do that. As far as 
LLVM is concerned texture handle is just a pointer, and the objects with texref 
attribute are lowered as a .texref global in PTX. It's user's responsibility to 
pass the right pointer to the intrinsic.

On a side note, the lowering of texture/surface instructions and intrinsics 
could use a major overhaul, too. It's currently excessively redundant and could 
be reduced to a much more concise tablegen-driven implementation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D7



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