[PATCH] D52342: [XRay][clang] Propagate -fxray-instrumentation-bundle to -cc1

2018-09-21 Thread Dean Michael Berris via Phabricator via cfe-commits
dberris created this revision.
dberris added reviewers: mboerger, tejohnson.

Add a test and ensure that we propagate the
-fxray-instrumentation-bundle flag from the driver invocation to the
-cc1 options.


https://reviews.llvm.org/D52342

Files:
  clang/include/clang/Basic/XRayInstr.h
  clang/lib/Driver/XRayArgs.cpp
  clang/test/CodeGen/xray-instrumentation-bundles-flags.cpp


Index: clang/test/CodeGen/xray-instrumentation-bundles-flags.cpp
===
--- /dev/null
+++ clang/test/CodeGen/xray-instrumentation-bundles-flags.cpp
@@ -0,0 +1,8 @@
+// This test ensures that when we invoke the clang compiler, that the -cc1
+// options include the -fxray-instrumentation-bundle= flag we provide in the
+// invocation.
+//
+// RUN: %clang -fxray-instrument -fxray-instrumentation-bundle=function -### \
+// RUN: -x c++ -std=c++11 -emit-llvm -c -o - %s 2>&1 \
+// RUN: | FileCheck %s
+// CHECK:  -fxray-instrumentation-bundle=function
Index: clang/lib/Driver/XRayArgs.cpp
===
--- clang/lib/Driver/XRayArgs.cpp
+++ clang/lib/Driver/XRayArgs.cpp
@@ -215,4 +215,19 @@
 ModeOpt += Mode;
 CmdArgs.push_back(Args.MakeArgString(ModeOpt));
   }
+
+  SmallString<64> Bundle("-fxray-instrumentation-bundle=");
+  if (InstrumentationBundle.full()) {
+Bundle += "all";
+  } else if (InstrumentationBundle.empty()) {
+Bundle += "none";
+  } else {
+if (InstrumentationBundle.has(XRayInstrKind::Function))
+  Bundle += "function";
+if (InstrumentationBundle.has(XRayInstrKind::Custom))
+  Bundle += "custom";
+if (InstrumentationBundle.has(XRayInstrKind::Typed))
+  Bundle += "typed";
+  }
+  CmdArgs.push_back(Args.MakeArgString(Bundle));
 }
Index: clang/include/clang/Basic/XRayInstr.h
===
--- clang/include/clang/Basic/XRayInstr.h
+++ clang/include/clang/Basic/XRayInstr.h
@@ -60,6 +60,8 @@
 
   bool empty() const { return Mask == 0; }
 
+  bool full() const { return Mask == XRayInstrKind::All; }
+
   XRayInstrMask Mask = 0;
 };
 


Index: clang/test/CodeGen/xray-instrumentation-bundles-flags.cpp
===
--- /dev/null
+++ clang/test/CodeGen/xray-instrumentation-bundles-flags.cpp
@@ -0,0 +1,8 @@
+// This test ensures that when we invoke the clang compiler, that the -cc1
+// options include the -fxray-instrumentation-bundle= flag we provide in the
+// invocation.
+//
+// RUN: %clang -fxray-instrument -fxray-instrumentation-bundle=function -### \
+// RUN: -x c++ -std=c++11 -emit-llvm -c -o - %s 2>&1 \
+// RUN: | FileCheck %s
+// CHECK:  -fxray-instrumentation-bundle=function
Index: clang/lib/Driver/XRayArgs.cpp
===
--- clang/lib/Driver/XRayArgs.cpp
+++ clang/lib/Driver/XRayArgs.cpp
@@ -215,4 +215,19 @@
 ModeOpt += Mode;
 CmdArgs.push_back(Args.MakeArgString(ModeOpt));
   }
+
+  SmallString<64> Bundle("-fxray-instrumentation-bundle=");
+  if (InstrumentationBundle.full()) {
+Bundle += "all";
+  } else if (InstrumentationBundle.empty()) {
+Bundle += "none";
+  } else {
+if (InstrumentationBundle.has(XRayInstrKind::Function))
+  Bundle += "function";
+if (InstrumentationBundle.has(XRayInstrKind::Custom))
+  Bundle += "custom";
+if (InstrumentationBundle.has(XRayInstrKind::Typed))
+  Bundle += "typed";
+  }
+  CmdArgs.push_back(Args.MakeArgString(Bundle));
 }
Index: clang/include/clang/Basic/XRayInstr.h
===
--- clang/include/clang/Basic/XRayInstr.h
+++ clang/include/clang/Basic/XRayInstr.h
@@ -60,6 +60,8 @@
 
   bool empty() const { return Mask == 0; }
 
+  bool full() const { return Mask == XRayInstrKind::All; }
+
   XRayInstrMask Mask = 0;
 };
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D52261: [Sema] Generate completion fix-its for C code as well

2018-09-21 Thread Ivan Donchevskii via Phabricator via cfe-commits
yvvan added a comment.

You're right actually. The fix is much simpler than I expected :)


https://reviews.llvm.org/D52261



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


[PATCH] D52261: [Sema] Generate completion fix-its for C code as well

2018-09-21 Thread Ivan Donchevskii via Phabricator via cfe-commits
yvvan updated this revision to Diff 166407.
yvvan added a comment.

Provide CorrectedBase = Base for C code


https://reviews.llvm.org/D52261

Files:
  lib/Parse/ParseExpr.cpp
  test/CodeCompletion/member-access.c


Index: test/CodeCompletion/member-access.c
===
--- test/CodeCompletion/member-access.c
+++ test/CodeCompletion/member-access.c
@@ -10,3 +10,22 @@
   // CHECK-CC1: x
   // CHECK-CC1: y
   // CHECK-CC1: z
+}
+
+struct Point2 {
+  float x;
+};
+
+void test2(struct Point2 p) {
+  p->
+}
+
+void test3(struct Point2 *p) {
+  p.
+}
+
+// RUN: %clang_cc1 -fsyntax-only -code-completion-with-fixits 
-code-completion-at=%s:20:6 %s -o - | FileCheck -check-prefix=CHECK-CC2 %s
+// CHECK-CC2: x (requires fix-it: {20:4-20:6} to ".")
+
+// RUN: %clang_cc1 -fsyntax-only -code-completion-with-fixits 
-code-completion-at=%s:24:5 %s -o - | FileCheck -check-prefix=CHECK-CC3 %s
+// CHECK-CC3: x (requires fix-it: {24:4-24:5} to "->")
Index: lib/Parse/ParseExpr.cpp
===
--- lib/Parse/ParseExpr.cpp
+++ lib/Parse/ParseExpr.cpp
@@ -1738,6 +1738,8 @@
 
 Expr *Base = LHS.get();
 Expr *CorrectedBase = CorrectedLHS.get();
+if (!CorrectedBase && !getLangOpts().CPlusPlus)
+  CorrectedBase = Base;
 
 // Code completion for a member access expression.
 Actions.CodeCompleteMemberReferenceExpr(


Index: test/CodeCompletion/member-access.c
===
--- test/CodeCompletion/member-access.c
+++ test/CodeCompletion/member-access.c
@@ -10,3 +10,22 @@
   // CHECK-CC1: x
   // CHECK-CC1: y
   // CHECK-CC1: z
+}
+
+struct Point2 {
+  float x;
+};
+
+void test2(struct Point2 p) {
+  p->
+}
+
+void test3(struct Point2 *p) {
+  p.
+}
+
+// RUN: %clang_cc1 -fsyntax-only -code-completion-with-fixits -code-completion-at=%s:20:6 %s -o - | FileCheck -check-prefix=CHECK-CC2 %s
+// CHECK-CC2: x (requires fix-it: {20:4-20:6} to ".")
+
+// RUN: %clang_cc1 -fsyntax-only -code-completion-with-fixits -code-completion-at=%s:24:5 %s -o - | FileCheck -check-prefix=CHECK-CC3 %s
+// CHECK-CC3: x (requires fix-it: {24:4-24:5} to "->")
Index: lib/Parse/ParseExpr.cpp
===
--- lib/Parse/ParseExpr.cpp
+++ lib/Parse/ParseExpr.cpp
@@ -1738,6 +1738,8 @@
 
 Expr *Base = LHS.get();
 Expr *CorrectedBase = CorrectedLHS.get();
+if (!CorrectedBase && !getLangOpts().CPlusPlus)
+  CorrectedBase = Base;
 
 // Code completion for a member access expression.
 Actions.CodeCompleteMemberReferenceExpr(
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D48742: Set _LIBCPP_TLS_DESTRUCTOR_CC convention to run_dtors

2018-09-21 Thread Pirama Arumuga Nainar via Phabricator via cfe-commits
pirama abandoned this revision.
pirama added a comment.
Herald added subscribers: libcxx-commits, jfb.

This file is not built for WIN32.


Repository:
  rCXXA libc++abi

https://reviews.llvm.org/D48742



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


[PATCH] D52334: [clang-tidy] Build it even without static analyzer

2018-09-21 Thread Jonas Toth via Phabricator via cfe-commits
JonasToth added a comment.

Do builds even work properly if the CSA is not build right now?




Comment at: clang-tidy/tool/CMakeLists.txt:32
   clangTidyModernizeModule
-  clangTidyMPIModule
   clangTidyObjCModule

Is the MPI module remove from the list of available checks (`clang-tidy 
-list-checks`) with that?


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D52334



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


[PATCH] D52281: [clang-tidy] Add modernize check to use std::invoke in generic code

2018-09-21 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added inline comments.



Comment at: clang-tidy/modernize/ReplaceGenericFunctorCallCheck.cpp:27-32
+  // template
+  // void f(T func) {
+  //   func();
+  //   ^~~
+  //   ::std::invoke(func, 1)
+  Finder->addMatcher(callExpr(has(declRefExpr())).bind("functor"), this);

aaron.ballman wrote:
> lebedev.ri wrote:
> > Bikeshedding: i do not understand the idea behind `std::invoke`.
> > Why is the new version better/preferred?
> It generically handles all the various kinds of "callable" objects (lambdas, 
> functors, function pointers, pointer to member functions, etc).
Thank you for answering, but i still do not understand.
E.g. on that example, what benefits does it give?
Even after looking at cppreference, i'm not sure..
Just curious.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D52281



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


[PATCH] D52315: [clang-tidy] Fix for performance-unnecessary-value-param, performance-unnecessary-copy-initialization and performance-for-range-copy

2018-09-21 Thread Balogh , Ádám via Phabricator via cfe-commits
baloghadamsoftware added a comment.

I still wonder what true positives could we get without checking the size? No 
real-life types come to my mind with size of a pointer but really expensive 
copy operations. What could be so really expensive when copying a single 
machine world?


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D52315



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


[PATCH] D52292: [Sema][OpenCL] Improve diagnostics for not viable overloadable function candidates

2018-09-21 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added inline comments.



Comment at: lib/Sema/Sema.cpp:1856
 
+std::string Sema::getOpenCLExtensionsFromDeclExtMap(FunctionDecl *FD) {
+  if (!OpenCLDeclExtMap.empty())

sidorovd wrote:
> Anastasia wrote:
> > Is this function to be used for both `OpenCLDeclExtMap` and 
> > `OpenCLTypeExtMap`? If yes, may be we could give it more generic name like 
> > 'getOpenCLExtensionsFromExtMap'...
> No, this exact function is only for 'OpenCLDeclExtMap', for the type map one 
> should implement a new function 'getOpenCLExtensionsFromTypeExtMap'. Actually 
> I have done this for https://reviews.llvm.org/D51341 to make the patch more 
> generic, but since I'm not sure if it ever came to light I can add it here 
> unused.
I think it's ok to provide generic helper function even if it's not used 
currently. But if you don't want to do this is there any value in splitting 
this into two function and using template?


https://reviews.llvm.org/D52292



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


[PATCH] D51484: [OpenCL] Add support of cl_intel_device_side_avc_motion_estimation extension

2018-09-21 Thread Alexey Sachkov via Phabricator via cfe-commits
AlexeySachkov added inline comments.



Comment at: include/clang/Basic/OpenCLExtensionTypes.def:27
+
+INTEL_SGAVC_TYPE(mce_payload_t, McePayload)
+INTEL_SGAVC_TYPE(ime_payload_t, ImePayload)

Anastasia wrote:
> AlexeySotkin wrote:
> > Anastasia wrote:
> > > AlexeySachkov wrote:
> > > > Anastasia wrote:
> > > > > From the specification of this extension I can't quite see if these 
> > > > > types have to be in Clang instead of the header. Can you please 
> > > > > elaborate on any example where it wouldn't be possible for this type 
> > > > > to be declared in the header using the technique explained in:
> > > > > https://clang.llvm.org/docs/UsersManual.html#opencl-extensions 
> > > > We cannot define these types in header because their layout is not 
> > > > defined in specification, i.e. all of these types are opaque
> > > This is not the reason to add functionality to Clang. You can easily sort 
> > > such things with target specific headers or even general headers (see 
> > > `ndrange_t` for example). Spec doesn't have to describe everything. The 
> > > question is whether there is something about those types that can't be 
> > > handled using standard include mechanisms. Usually it's prohibited 
> > > behaviors that can't be represented with such mechanisms. Like if some 
> > > operations have to be disallowed or allowed (since in OpenCL C you can't 
> > > define user defined operators) with the types.
> > > 
> > > I think the trend is to avoid adding complexity into Clang, unless there 
> > > is no other way to implement some feature correctly.
> > Major part of these types must support initialization only by zero. 
> > intel_sub_group_avc_mce_payload_t and intel_sub_group_avc_mce_result_t must 
> > support initialization only via special builtins defined in the spec. 
> > Corresponding errors must be reported. I think we can't implement this 
> > behavior using standard include mechanism, can we?
> > 
> > Possible value of the additional complexity, except builtin declaration, is 
> > that the patch is quite generic. So next time anyone wants to implement an 
> > extension with a type restrictions which can't be handled with the include 
> > mechanism, all that they needs to do is to modify this single file.
> > Major part of these types must support initialization only by zero. 
> > intel_sub_group_avc_mce_payload_t and intel_sub_group_avc_mce_result_t must 
> > support initialization only via special builtins defined in the spec. 
> > Corresponding errors must be reported. I think we can't implement this 
> > behavior using standard include mechanism, can we?
> 
> Are these restrictions not mentioned in the specification document then? Or 
> is it not the final version yet (not sure since it says First Draft). Do you 
> plan to add the diagnostics for the restrictions afterwards? It doesn't have 
> to be in the same patch, but just checking because if not I don't think it 
> would make sense to go this route.
> 
> > Possible value of the additional complexity, except builtin declaration, is 
> > that the patch is quite generic. So next time anyone wants to implement an 
> > extension with a type restrictions which can't be handled with the include 
> > mechanism, all that they needs to do is to modify this single file.
> > 
> 
> It seems reasonable to implement this extra mechanism, provided that there 
> are more of similar use cases.
> 
> Btw, considering that there are some modifications to core language spec 
> restriction sections in this document, does this extension invalidate or 
> change any core language rules that might affect parsing/diagnostics? 
> 
> 
> Are these restrictions not mentioned in the specification document then? Or 
> is it not the final version yet (not sure since it says First Draft).

Current version of spec is not very clear regarding all these restrictions. I'm 
working with authors to get updated version published at Khronos registry.

> Do you plan to add the diagnostics for the restrictions afterwards?

Yes, I'm going to update this patch and add some tests for Sema

> Btw, considering that there are some modifications to core language spec 
> restriction sections in this document, does this extension invalidate or 
> change any core language rules that might affect parsing/diagnostics?

AFAIK extension describes a new one kind of sampler and initialization rules 
for it. This new sampler reusing existing sampler_t type, but value of 
initializer macro doesn't correspond to existing OpenCL spec: next version of 
patch will hide one warning message:

> if (FilterMode != 1 && FilterMode != 2 &&
>   !S.getOpenCLOptions().isEnabled(
>   "cl_intel_device_side_avc_motion_estimation"))
> S.Diag(Kind.getLocation(),
>diag::warn_sampler_initializer_invalid_bits)
><< "Filter Mode";



Repository:
  rC Clang

https://reviews.llvm.org/D51484



_

[PATCH] D52315: [clang-tidy] Fix for performance-unnecessary-value-param, performance-unnecessary-copy-initialization and performance-for-range-copy

2018-09-21 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

In https://reviews.llvm.org/D52315#1241487, @baloghadamsoftware wrote:

> I still wonder what true positives could we get without checking the size? No 
> real-life types come to my mind with size of a pointer but really expensive 
> copy operations. What could be so really expensive when copying a single 
> machine world?


The type is not trivially-copyable, so how do you know the user-provided copy 
constructors
don't treat that pointer as a pointer to a string, which they allocate and copy 
on each copy?

I really don't think the default should change.
I think the best solution would be simply to add type blacklists for each of 
these checks.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D52315



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


[PATCH] D52342: [XRay][clang] Propagate -fxray-instrumentation-bundle to -cc1

2018-09-21 Thread Marcus Boerger via Phabricator via cfe-commits
mboerger accepted this revision.
mboerger added a comment.
This revision is now accepted and ready to land.

LGTM


https://reviews.llvm.org/D52342



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


[PATCH] D52342: [XRay][clang] Propagate -fxray-instrumentation-bundle to -cc1

2018-09-21 Thread Dean Michael Berris via Phabricator via cfe-commits
dberris updated this revision to Diff 166410.
dberris added a comment.

Move the test to the driver, more appropriate location.


https://reviews.llvm.org/D52342

Files:
  clang/include/clang/Basic/XRayInstr.h
  clang/lib/Driver/XRayArgs.cpp
  clang/test/Driver/XRay/xray-instrumentation-bundles-flags.cpp


Index: clang/test/Driver/XRay/xray-instrumentation-bundles-flags.cpp
===
--- /dev/null
+++ clang/test/Driver/XRay/xray-instrumentation-bundles-flags.cpp
@@ -0,0 +1,11 @@
+// This test ensures that when we invoke the clang compiler, that the -cc1
+// options include the -fxray-instrumentation-bundle= flag we provide in the
+// invocation.
+//
+// RUN: %clang -fxray-instrument -fxray-instrumentation-bundle=function -### \
+// RUN: -x c++ -std=c++11 -emit-llvm -c -o - %s 2>&1 \
+// RUN: | FileCheck %s
+// CHECK:  -fxray-instrumentation-bundle=function
+//
+// REQUIRES-ANY: linux, freebsd
+// REQUIRES-ANY: amd64, x86_64, x86_64h, arm, aarch64, arm64
Index: clang/lib/Driver/XRayArgs.cpp
===
--- clang/lib/Driver/XRayArgs.cpp
+++ clang/lib/Driver/XRayArgs.cpp
@@ -215,4 +215,19 @@
 ModeOpt += Mode;
 CmdArgs.push_back(Args.MakeArgString(ModeOpt));
   }
+
+  SmallString<64> Bundle("-fxray-instrumentation-bundle=");
+  if (InstrumentationBundle.full()) {
+Bundle += "all";
+  } else if (InstrumentationBundle.empty()) {
+Bundle += "none";
+  } else {
+if (InstrumentationBundle.has(XRayInstrKind::Function))
+  Bundle += "function";
+if (InstrumentationBundle.has(XRayInstrKind::Custom))
+  Bundle += "custom";
+if (InstrumentationBundle.has(XRayInstrKind::Typed))
+  Bundle += "typed";
+  }
+  CmdArgs.push_back(Args.MakeArgString(Bundle));
 }
Index: clang/include/clang/Basic/XRayInstr.h
===
--- clang/include/clang/Basic/XRayInstr.h
+++ clang/include/clang/Basic/XRayInstr.h
@@ -60,6 +60,8 @@
 
   bool empty() const { return Mask == 0; }
 
+  bool full() const { return Mask == XRayInstrKind::All; }
+
   XRayInstrMask Mask = 0;
 };
 


Index: clang/test/Driver/XRay/xray-instrumentation-bundles-flags.cpp
===
--- /dev/null
+++ clang/test/Driver/XRay/xray-instrumentation-bundles-flags.cpp
@@ -0,0 +1,11 @@
+// This test ensures that when we invoke the clang compiler, that the -cc1
+// options include the -fxray-instrumentation-bundle= flag we provide in the
+// invocation.
+//
+// RUN: %clang -fxray-instrument -fxray-instrumentation-bundle=function -### \
+// RUN: -x c++ -std=c++11 -emit-llvm -c -o - %s 2>&1 \
+// RUN: | FileCheck %s
+// CHECK:  -fxray-instrumentation-bundle=function
+//
+// REQUIRES-ANY: linux, freebsd
+// REQUIRES-ANY: amd64, x86_64, x86_64h, arm, aarch64, arm64
Index: clang/lib/Driver/XRayArgs.cpp
===
--- clang/lib/Driver/XRayArgs.cpp
+++ clang/lib/Driver/XRayArgs.cpp
@@ -215,4 +215,19 @@
 ModeOpt += Mode;
 CmdArgs.push_back(Args.MakeArgString(ModeOpt));
   }
+
+  SmallString<64> Bundle("-fxray-instrumentation-bundle=");
+  if (InstrumentationBundle.full()) {
+Bundle += "all";
+  } else if (InstrumentationBundle.empty()) {
+Bundle += "none";
+  } else {
+if (InstrumentationBundle.has(XRayInstrKind::Function))
+  Bundle += "function";
+if (InstrumentationBundle.has(XRayInstrKind::Custom))
+  Bundle += "custom";
+if (InstrumentationBundle.has(XRayInstrKind::Typed))
+  Bundle += "typed";
+  }
+  CmdArgs.push_back(Args.MakeArgString(Bundle));
 }
Index: clang/include/clang/Basic/XRayInstr.h
===
--- clang/include/clang/Basic/XRayInstr.h
+++ clang/include/clang/Basic/XRayInstr.h
@@ -60,6 +60,8 @@
 
   bool empty() const { return Mask == 0; }
 
+  bool full() const { return Mask == XRayInstrKind::All; }
+
   XRayInstrMask Mask = 0;
 };
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D52342: [XRay][clang] Propagate -fxray-instrumentation-bundle to -cc1

2018-09-21 Thread Marcus Boerger via Phabricator via cfe-commits
mboerger accepted this revision.
mboerger added a comment.

LGTM


https://reviews.llvm.org/D52342



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


[PATCH] D52300: [clangd] Implement VByte PostingList compression

2018-09-21 Thread Kirill Bobyrev via Phabricator via cfe-commits
kbobyrev added a comment.

@sammccall thank you for the comments, I'll improve it. @ilya-biryukov also 
provided valuable feedback and suggested that the code looks complicated now. 
We also discussed different compression approach which would require storing 
`Head`s and `Payload`s separately so that binary search over `Head`s could have 
better cache locality. That can dramatically improve performance.

For now, I think it's important to simplify the code and I'll start with that. 
Also, your suggestions will help to save even more memory! Zeroed bytes are an 
example of that: I started the patch with the general encoding API (so that 
zeros could be encoded in the list), but there's no good reason to keep that 
assumption now.

Also, I think I got my measurements wrong yesterday. I measured posting lists 
only: without compression size is 55 MB and with compression (current version, 
not optimized yet) it's 22 MB. This seems like a huge win. I try to keep myself 
from being overenthusiastic and double-check the numbers, but it looks more 
like something you estimated when we used posting list size distribution.




Comment at: clang-tools-extra/clangd/index/dex/PostingList.cpp:262
+ "Unterminated byte sequence at the end of input stream.");
+  return Result;
+}

sammccall wrote:
> here I think you're missing a memory optimization probably equal in size to 
> the whole gains achieved by compression :-)
> 
> libstdc++ uses a 2x growth factor for std::vector, so we're probably wasting 
> an extra 30% or so of ram (depending on size distribution, I forget the 
> theory here).
> We should shrink to fit. If we were truly desperate we'd iterate over all the 
> numbers and presize the array, but we're probably not.
> 
> I think `return std::vector(Result); // no move, shrink-to-fit` will 
> shrink it as you want (note that `shrink_to_fit()` is usually a no-op :-\)
Great catch! I have to be careful with `std::vector`s which are not allocated 
with their final size in advance.



Comment at: clang-tools-extra/clangd/index/dex/fuzzer/VByteFuzzer.cpp:1
+//===-- VByteFuzzer.cpp - Fuzz VByte Posting List encoding 
===//
+//

sammccall wrote:
> For better or worse, adding a fuzzer in the open-source project is pretty 
> high ceremony (CMake stuff, subdirectory, oss-fuzz configuration, following 
> up on bugs).
> 
> I'm not sure the maintenance cost is justified here. Can we just run the 
> fuzzer but not check it in?
OK, I'll leave this here until the patch is accepted for continuous testing, 
but I won't push it in the final version.


https://reviews.llvm.org/D52300



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


r342715 - [XRay][clang] Propagate -fxray-instrumentation-bundle to -cc1

2018-09-21 Thread Dean Michael Berris via cfe-commits
Author: dberris
Date: Fri Sep 21 01:32:49 2018
New Revision: 342715

URL: http://llvm.org/viewvc/llvm-project?rev=342715&view=rev
Log:
[XRay][clang] Propagate -fxray-instrumentation-bundle to -cc1

Summary:
Add a test and ensure that we propagate the
-fxray-instrumentation-bundle flag from the driver invocation to the
-cc1 options.

Reviewers: mboerger, tejohnson

Subscribers: cfe-commits

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

Added:
cfe/trunk/test/Driver/XRay/xray-instrumentation-bundles-flags.cpp
Modified:
cfe/trunk/include/clang/Basic/XRayInstr.h
cfe/trunk/lib/Driver/XRayArgs.cpp

Modified: cfe/trunk/include/clang/Basic/XRayInstr.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/XRayInstr.h?rev=342715&r1=342714&r2=342715&view=diff
==
--- cfe/trunk/include/clang/Basic/XRayInstr.h (original)
+++ cfe/trunk/include/clang/Basic/XRayInstr.h Fri Sep 21 01:32:49 2018
@@ -60,6 +60,8 @@ struct XRayInstrSet {
 
   bool empty() const { return Mask == 0; }
 
+  bool full() const { return Mask == XRayInstrKind::All; }
+
   XRayInstrMask Mask = 0;
 };
 

Modified: cfe/trunk/lib/Driver/XRayArgs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/XRayArgs.cpp?rev=342715&r1=342714&r2=342715&view=diff
==
--- cfe/trunk/lib/Driver/XRayArgs.cpp (original)
+++ cfe/trunk/lib/Driver/XRayArgs.cpp Fri Sep 21 01:32:49 2018
@@ -215,4 +215,19 @@ void XRayArgs::addArgs(const ToolChain &
 ModeOpt += Mode;
 CmdArgs.push_back(Args.MakeArgString(ModeOpt));
   }
+
+  SmallString<64> Bundle("-fxray-instrumentation-bundle=");
+  if (InstrumentationBundle.full()) {
+Bundle += "all";
+  } else if (InstrumentationBundle.empty()) {
+Bundle += "none";
+  } else {
+if (InstrumentationBundle.has(XRayInstrKind::Function))
+  Bundle += "function";
+if (InstrumentationBundle.has(XRayInstrKind::Custom))
+  Bundle += "custom";
+if (InstrumentationBundle.has(XRayInstrKind::Typed))
+  Bundle += "typed";
+  }
+  CmdArgs.push_back(Args.MakeArgString(Bundle));
 }

Added: cfe/trunk/test/Driver/XRay/xray-instrumentation-bundles-flags.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/XRay/xray-instrumentation-bundles-flags.cpp?rev=342715&view=auto
==
--- cfe/trunk/test/Driver/XRay/xray-instrumentation-bundles-flags.cpp (added)
+++ cfe/trunk/test/Driver/XRay/xray-instrumentation-bundles-flags.cpp Fri Sep 
21 01:32:49 2018
@@ -0,0 +1,11 @@
+// This test ensures that when we invoke the clang compiler, that the -cc1
+// options include the -fxray-instrumentation-bundle= flag we provide in the
+// invocation.
+//
+// RUN: %clang -fxray-instrument -fxray-instrumentation-bundle=function -### \
+// RUN: -x c++ -std=c++11 -emit-llvm -c -o - %s 2>&1 \
+// RUN: | FileCheck %s
+// CHECK:  -fxray-instrumentation-bundle=function
+//
+// REQUIRES-ANY: linux, freebsd
+// REQUIRES-ANY: amd64, x86_64, x86_64h, arm, aarch64, arm64


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


[PATCH] D52342: [XRay][clang] Propagate -fxray-instrumentation-bundle to -cc1

2018-09-21 Thread Dean Michael Berris via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rC342715: [XRay][clang] Propagate 
-fxray-instrumentation-bundle to -cc1 (authored by dberris, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D52342?vs=166410&id=166412#toc

Repository:
  rC Clang

https://reviews.llvm.org/D52342

Files:
  include/clang/Basic/XRayInstr.h
  lib/Driver/XRayArgs.cpp
  test/Driver/XRay/xray-instrumentation-bundles-flags.cpp


Index: lib/Driver/XRayArgs.cpp
===
--- lib/Driver/XRayArgs.cpp
+++ lib/Driver/XRayArgs.cpp
@@ -215,4 +215,19 @@
 ModeOpt += Mode;
 CmdArgs.push_back(Args.MakeArgString(ModeOpt));
   }
+
+  SmallString<64> Bundle("-fxray-instrumentation-bundle=");
+  if (InstrumentationBundle.full()) {
+Bundle += "all";
+  } else if (InstrumentationBundle.empty()) {
+Bundle += "none";
+  } else {
+if (InstrumentationBundle.has(XRayInstrKind::Function))
+  Bundle += "function";
+if (InstrumentationBundle.has(XRayInstrKind::Custom))
+  Bundle += "custom";
+if (InstrumentationBundle.has(XRayInstrKind::Typed))
+  Bundle += "typed";
+  }
+  CmdArgs.push_back(Args.MakeArgString(Bundle));
 }
Index: include/clang/Basic/XRayInstr.h
===
--- include/clang/Basic/XRayInstr.h
+++ include/clang/Basic/XRayInstr.h
@@ -60,6 +60,8 @@
 
   bool empty() const { return Mask == 0; }
 
+  bool full() const { return Mask == XRayInstrKind::All; }
+
   XRayInstrMask Mask = 0;
 };
 
Index: test/Driver/XRay/xray-instrumentation-bundles-flags.cpp
===
--- test/Driver/XRay/xray-instrumentation-bundles-flags.cpp
+++ test/Driver/XRay/xray-instrumentation-bundles-flags.cpp
@@ -0,0 +1,11 @@
+// This test ensures that when we invoke the clang compiler, that the -cc1
+// options include the -fxray-instrumentation-bundle= flag we provide in the
+// invocation.
+//
+// RUN: %clang -fxray-instrument -fxray-instrumentation-bundle=function -### \
+// RUN: -x c++ -std=c++11 -emit-llvm -c -o - %s 2>&1 \
+// RUN: | FileCheck %s
+// CHECK:  -fxray-instrumentation-bundle=function
+//
+// REQUIRES-ANY: linux, freebsd
+// REQUIRES-ANY: amd64, x86_64, x86_64h, arm, aarch64, arm64


Index: lib/Driver/XRayArgs.cpp
===
--- lib/Driver/XRayArgs.cpp
+++ lib/Driver/XRayArgs.cpp
@@ -215,4 +215,19 @@
 ModeOpt += Mode;
 CmdArgs.push_back(Args.MakeArgString(ModeOpt));
   }
+
+  SmallString<64> Bundle("-fxray-instrumentation-bundle=");
+  if (InstrumentationBundle.full()) {
+Bundle += "all";
+  } else if (InstrumentationBundle.empty()) {
+Bundle += "none";
+  } else {
+if (InstrumentationBundle.has(XRayInstrKind::Function))
+  Bundle += "function";
+if (InstrumentationBundle.has(XRayInstrKind::Custom))
+  Bundle += "custom";
+if (InstrumentationBundle.has(XRayInstrKind::Typed))
+  Bundle += "typed";
+  }
+  CmdArgs.push_back(Args.MakeArgString(Bundle));
 }
Index: include/clang/Basic/XRayInstr.h
===
--- include/clang/Basic/XRayInstr.h
+++ include/clang/Basic/XRayInstr.h
@@ -60,6 +60,8 @@
 
   bool empty() const { return Mask == 0; }
 
+  bool full() const { return Mask == XRayInstrKind::All; }
+
   XRayInstrMask Mask = 0;
 };
 
Index: test/Driver/XRay/xray-instrumentation-bundles-flags.cpp
===
--- test/Driver/XRay/xray-instrumentation-bundles-flags.cpp
+++ test/Driver/XRay/xray-instrumentation-bundles-flags.cpp
@@ -0,0 +1,11 @@
+// This test ensures that when we invoke the clang compiler, that the -cc1
+// options include the -fxray-instrumentation-bundle= flag we provide in the
+// invocation.
+//
+// RUN: %clang -fxray-instrument -fxray-instrumentation-bundle=function -### \
+// RUN: -x c++ -std=c++11 -emit-llvm -c -o - %s 2>&1 \
+// RUN: | FileCheck %s
+// CHECK:  -fxray-instrumentation-bundle=function
+//
+// REQUIRES-ANY: linux, freebsd
+// REQUIRES-ANY: amd64, x86_64, x86_64h, arm, aarch64, arm64
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D52273: [clangd] Initial implementation of expected types

2018-09-21 Thread Eric Liu via Phabricator via cfe-commits
ioeric added a comment.

In https://reviews.llvm.org/D52273#1241281, @sammccall wrote:

> This seems very clever, but extremely complicated - you've implemented much 
> of C++'s conversion logic, it's not clear to me which parts are actually 
> necessary to completion quality.
>  (Honestly this applies to expected types overall - it seems intuitively 
> likely that it's a good signal, it seems less obvious that it pulls its 
> weight if it can't be made simple).
>
> From the outside it seems much of it is YAGNI, and if we do then we need to 
> build it up slowly with an eye for maintainability.
>  Can we start with expected type boosting (no conversions) as previously 
> discussed, and later measure which other parts make a difference? (I think 
> we'll need/want the simple model anyway, for this to work with Dex and other 
> token-based indexes).


+1 to a simpler model.

As chatted offline, I think the return type can be split into multiple 
orthogonal signals. For example, `const T &` can be split into 3 independent 
signals {`const`, `type T`, `reference`}. I think this can make the reasoning 
of boosting/scoring easier for both index and code completion. Agree with Sam 
that we should start with something simple (e.g. type matching without 
conversing) and land basic components to make further evaluation possible.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D52273



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


[PATCH] D52225: [clang] Implement Override Suggestions in Sema.

2018-09-21 Thread Eric Liu via Phabricator via cfe-commits
ioeric added a comment.

Could you move the corresponding tests from clangd to sema?




Comment at: lib/Sema/SemaCodeComplete.cpp:3063
+CodeCompletionString *
+CodeCompletionResult::CreateCodeCompletionString(ASTContext &Ctx,
+ Preprocessor &PP,

Could you put this definition before `createCodeCompletionStringForDecl`? I 
think it should make it easier to see unchanged lines.


Repository:
  rC Clang

https://reviews.llvm.org/D52225



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


[PATCH] D49916: [CodeGen] Add to emitted DebugLoc information about coverage when it's required

2018-09-21 Thread calixte via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rC342717: [CodeGen] Add to emitted DebugLoc information about 
coverage when it's required (authored by calixte, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D49916?vs=164860&id=166416#toc

Repository:
  rC Clang

https://reviews.llvm.org/D49916

Files:
  lib/CodeGen/CGDebugInfo.cpp
  lib/CodeGen/CGDebugInfo.h
  lib/CodeGen/CGException.cpp
  lib/CodeGen/CodeGenFunction.cpp
  lib/CodeGen/CodeGenFunction.h
  test/CodeGen/debug-info-scope-file.c
  test/CodeGenCXX/debug-info-inheriting-constructor.cpp
  test/CodeGenCXX/linetable-virtual-variadic.cpp
  test/CodeGenObjC/arc-linetable.m
  test/CodeGenObjC/debug-info-blocks.m

Index: lib/CodeGen/CGDebugInfo.cpp
===
--- lib/CodeGen/CGDebugInfo.cpp
+++ lib/CodeGen/CGDebugInfo.cpp
@@ -76,20 +76,22 @@
 }
 
 ApplyDebugLocation::ApplyDebugLocation(CodeGenFunction &CGF,
-   SourceLocation TemporaryLocation)
+   SourceLocation TemporaryLocation,
+   bool ImplicitCode)
 : CGF(&CGF) {
-  init(TemporaryLocation);
+  init(TemporaryLocation, false /* DefaultToEmpty */, ImplicitCode);
 }
 
 ApplyDebugLocation::ApplyDebugLocation(CodeGenFunction &CGF,
bool DefaultToEmpty,
-   SourceLocation TemporaryLocation)
+   SourceLocation TemporaryLocation,
+   bool ImplicitCode)
 : CGF(&CGF) {
-  init(TemporaryLocation, DefaultToEmpty);
+  init(TemporaryLocation, DefaultToEmpty, ImplicitCode);
 }
 
 void ApplyDebugLocation::init(SourceLocation TemporaryLocation,
-  bool DefaultToEmpty) {
+  bool DefaultToEmpty, bool ImplicitCode) {
   auto *DI = CGF->getDebugInfo();
   if (!DI) {
 CGF = nullptr;
@@ -102,7 +104,7 @@
 return;
 
   if (TemporaryLocation.isValid()) {
-DI->EmitLocation(CGF->Builder, TemporaryLocation);
+DI->EmitLocation(CGF->Builder, TemporaryLocation, ImplicitCode);
 return;
   }
 
@@ -3484,16 +3486,18 @@
   setInlinedAt(llvm::DebugLoc(CurInlinedAt).getInlinedAt());
 }
 
-void CGDebugInfo::EmitLocation(CGBuilderTy &Builder, SourceLocation Loc) {
+void CGDebugInfo::EmitLocation(CGBuilderTy &Builder, SourceLocation Loc,
+   bool ImplicitCode) {
   // Update our current location
   setLocation(Loc);
 
   if (CurLoc.isInvalid() || CurLoc.isMacroID())
 return;
 
   llvm::MDNode *Scope = LexicalBlockStack.back();
-  Builder.SetCurrentDebugLocation(llvm::DebugLoc::get(
-  getLineNumber(CurLoc), getColumnNumber(CurLoc), Scope, CurInlinedAt));
+  Builder.SetCurrentDebugLocation(
+  llvm::DebugLoc::get(getLineNumber(CurLoc), getColumnNumber(CurLoc), Scope,
+  CurInlinedAt, ImplicitCode));
 }
 
 void CGDebugInfo::CreateLexicalBlock(SourceLocation Loc) {
@@ -3540,7 +3544,7 @@
   assert(!LexicalBlockStack.empty() && "Region stack mismatch, stack empty!");
 
   // Provide an entry in the line table for the end of the block.
-  EmitLocation(Builder, Loc);
+  EmitLocation(Builder, Loc, true /* ImplicitCode */);
 
   if (DebugKind <= codegenoptions::DebugLineTablesOnly)
 return;
@@ -3556,7 +3560,7 @@
   // Pop all regions for this function.
   while (LexicalBlockStack.size() != RCount) {
 // Provide an entry in the line table for the end of the block.
-EmitLocation(Builder, CurLoc);
+EmitLocation(Builder, CurLoc, true /* ImplicitCode */);
 LexicalBlockStack.pop_back();
   }
   FnBeginRegionCount.pop_back();
Index: lib/CodeGen/CGDebugInfo.h
===
--- lib/CodeGen/CGDebugInfo.h
+++ lib/CodeGen/CGDebugInfo.h
@@ -377,7 +377,9 @@
   /// Emit metadata to indicate a change in line/column information in
   /// the source file. If the location is invalid, the previous
   /// location will be reused.
-  void EmitLocation(CGBuilderTy &Builder, SourceLocation Loc);
+  /// \param ImplicitCode  True if the Loc must have coverage information
+  void EmitLocation(CGBuilderTy &Builder, SourceLocation Loc,
+bool ImplicitCode = false);
 
   /// Emit a call to llvm.dbg.function.start to indicate
   /// start of a new function.
@@ -664,16 +666,19 @@
 /// location or preferred location of the specified Expr.
 class ApplyDebugLocation {
 private:
-  void init(SourceLocation TemporaryLocation, bool DefaultToEmpty = false);
+  void init(SourceLocation TemporaryLocation, bool DefaultToEmpty = false,
+bool ImplicitCode = false);
   ApplyDebugLocation(CodeGenFunction &CGF, bool DefaultToEmpty,
- SourceLocation TemporaryLocation);
+ SourceLocation TemporaryLocation,
+ bool Implic

[PATCH] D52344: [Clang][CodeGen][ObjC]: Fix non-bridged CoreFoundation builds on ELF targets that use `-fconstant-cfstrings`.

2018-09-21 Thread Kristina Brooks via Phabricator via cfe-commits
kristina created this revision.
kristina added reviewers: rnk, echristo, clang, rjmccall.
Herald added a subscriber: cfe-commits.

Attempt to unbreak behavior caused by https://reviews.llvm.org/D44491 resulting 
in inability to build standalone/unbridged CoreFoundation on an ELF target with 
`-fconstant-cfstrings` as the cast<> expression would fail when attempting to 
use the builtin since the faux-ObjectiveC class backing CFSTR constant strings 
is an `llvm::Constant` being cast to an `llvm::GlobalValue`. This only affects 
ELF targets, PE/COFF targets will still follow the same path so this should not 
affect them and takes an approach more in-line with how Apple toolchains behave.

I will add a lit test for Clang codegen shortly after I figure out how to get 
it to work correctly, though with said patch I'm able to build standalone 
CoreFoundation with constant CFStrings without it being bridged against 
Foundation or Swift runtimes (as far as I know that was previously only 
supported on Windows).

Trying to make a similar test to cfstring-windows.c but still trying to get the 
hang of FileCheck.

  
  Testing Time: 10.56s
  
  Failing Tests (1):
  Clang :: CodeGen/cfstring-linux-unbridged.c


Repository:
  rC Clang

https://reviews.llvm.org/D52344

Files:
  lib/CodeGen/CodeGenModule.cpp


Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -4093,15 +4093,20 @@
 
   llvm::Constant *Zero = llvm::Constant::getNullValue(Int32Ty);
   llvm::Constant *Zeros[] = { Zero, Zero };
-
+  
   // If we don't already have it, get __CFConstantStringClassReference.
   if (!CFConstantStringClassRef) {
 llvm::Type *Ty = getTypes().ConvertType(getContext().IntTy);
 Ty = llvm::ArrayType::get(Ty, 0);
-llvm::GlobalValue *GV = cast(
-CreateRuntimeVariable(Ty, "__CFConstantStringClassReference"));
-
+llvm::Constant *CGV =
+CreateRuntimeVariable(Ty, "__CFConstantStringClassReference");
+llvm::GlobalValue *GV = dyn_cast(CGV);
+
 if (getTriple().isOSBinFormatCOFF()) {
+  // Instead of using a cast<>, just assert if it's null, this is
+  // consistent with old behavior for this target as it would fail
+  // on the cast<> instead.
+  assert(GV && "isa isn't a GlobalValue");
   IdentifierInfo &II = getContext().Idents.get(GV->getName());
   TranslationUnitDecl *TUDecl = getContext().getTranslationUnitDecl();
   DeclContext *DC = TranslationUnitDecl::castToDeclContext(TUDecl);
@@ -4119,11 +4124,12 @@
 GV->setLinkage(llvm::GlobalValue::ExternalLinkage);
   }
 }
-setDSOLocal(GV);
+if (GV)
+  setDSOLocal(GV);
 
 // Decay array -> ptr
 CFConstantStringClassRef =
-llvm::ConstantExpr::getGetElementPtr(Ty, GV, Zeros);
+llvm::ConstantExpr::getGetElementPtr(Ty, CGV, Zeros);
   }
 
   QualType CFTy = getContext().getCFConstantStringType();


Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -4093,15 +4093,20 @@
 
   llvm::Constant *Zero = llvm::Constant::getNullValue(Int32Ty);
   llvm::Constant *Zeros[] = { Zero, Zero };
-
+  
   // If we don't already have it, get __CFConstantStringClassReference.
   if (!CFConstantStringClassRef) {
 llvm::Type *Ty = getTypes().ConvertType(getContext().IntTy);
 Ty = llvm::ArrayType::get(Ty, 0);
-llvm::GlobalValue *GV = cast(
-CreateRuntimeVariable(Ty, "__CFConstantStringClassReference"));
-
+llvm::Constant *CGV =
+CreateRuntimeVariable(Ty, "__CFConstantStringClassReference");
+llvm::GlobalValue *GV = dyn_cast(CGV);
+
 if (getTriple().isOSBinFormatCOFF()) {
+  // Instead of using a cast<>, just assert if it's null, this is
+  // consistent with old behavior for this target as it would fail
+  // on the cast<> instead.
+  assert(GV && "isa isn't a GlobalValue");
   IdentifierInfo &II = getContext().Idents.get(GV->getName());
   TranslationUnitDecl *TUDecl = getContext().getTranslationUnitDecl();
   DeclContext *DC = TranslationUnitDecl::castToDeclContext(TUDecl);
@@ -4119,11 +4124,12 @@
 GV->setLinkage(llvm::GlobalValue::ExternalLinkage);
   }
 }
-setDSOLocal(GV);
+if (GV)
+  setDSOLocal(GV);
 
 // Decay array -> ptr
 CFConstantStringClassRef =
-llvm::ConstantExpr::getGetElementPtr(Ty, GV, Zeros);
+llvm::ConstantExpr::getGetElementPtr(Ty, CGV, Zeros);
   }
 
   QualType CFTy = getContext().getCFConstantStringType();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D50229: +fp16fml feature for ARM and AArch64

2018-09-21 Thread Sjoerd Meijer via Phabricator via cfe-commits
SjoerdMeijer added a comment.

(I am now picking this up, and will try to progress this patch and also 
https://reviews.llvm.org/D50179)

> Do you expect that the regression tests will be affected by the TargetParser 
> fixes?

No, and that's exactly the reason why it would be nice to get this in. The 
tests won't change, they show the expected behaviour, and thus we have a sort 
of "baseline implementation" while we are working on the new options framework.

And just repeating what I said in the other ticket, this option handling 
implementation is far from ideal and pretty, it's very easy to agree on that. 
This is a low maintenance patch, so very easy to keep downstream for us, but it 
would be useful to have it on trunk too perhaps.

I will add comments and a FIXME that we expect a full reimplementation of it.


Repository:
  rC Clang

https://reviews.llvm.org/D50229



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


[PATCH] D52292: [Sema][OpenCL] Improve diagnostics for not viable overloadable function candidates

2018-09-21 Thread Dmitry Sidorov via Phabricator via cfe-commits
sidorovd updated this revision to Diff 166425.
sidorovd added a comment.

getOpenCLExtensionsFromTypeExtMap was added


https://reviews.llvm.org/D52292

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Sema/Sema.h
  lib/Sema/Sema.cpp
  lib/Sema/SemaOverload.cpp
  test/SemaOpenCL/extension-begin.cl

Index: test/SemaOpenCL/extension-begin.cl
===
--- test/SemaOpenCL/extension-begin.cl
+++ test/SemaOpenCL/extension-begin.cl
@@ -48,7 +48,7 @@
   PointerOfA test_A_pointer; // expected-error {{use of type 'PointerOfA' (aka 'const struct A *') requires my_ext extension to be enabled}}
   f(); // expected-error {{use of declaration 'f' requires my_ext extension to be enabled}}
   g(0); // expected-error {{no matching function for call to 'g'}}
-// expected-note@-26 {{candidate disabled due to OpenCL extension}}
+// expected-note@-26 {{candidate unavailable as it requires OpenCL extension 'my_ext' to be disabled}}
 // expected-note@-22 {{candidate function not viable: requires 0 arguments, but 1 was provided}}
 }
 
Index: lib/Sema/SemaOverload.cpp
===
--- lib/Sema/SemaOverload.cpp
+++ lib/Sema/SemaOverload.cpp
@@ -10242,7 +10242,8 @@
   FunctionDecl *Callee = Cand->Function;
 
   S.Diag(Callee->getLocation(),
- diag::note_ovl_candidate_disabled_by_extension);
+ diag::note_ovl_candidate_disabled_by_extension)
+<< S.getOpenCLExtensionsFromDeclExtMap(Callee);
 }
 
 /// Generates a 'note' diagnostic for an overload candidate.  We've
Index: lib/Sema/Sema.cpp
===
--- lib/Sema/Sema.cpp
+++ lib/Sema/Sema.cpp
@@ -1853,6 +1853,34 @@
   setOpenCLExtensionForDecl(D, CurrOpenCLExtension);
 }
 
+std::string Sema::getOpenCLExtensionsFromDeclExtMap(FunctionDecl *FD) {
+  if (!OpenCLDeclExtMap.empty())
+return getOpenCLExtensionsFromExtMap(FD, OpenCLDeclExtMap);
+
+  return "";
+}
+
+std::string Sema::getOpenCLExtensionsFromTypeExtMap(FunctionType *FT) {
+  if (!OpenCLTypeExtMap.empty())
+return getOpenCLExtensionsFromExtMap(FT, OpenCLTypeExtMap);
+
+  return "";
+}
+
+template 
+std::string Sema::getOpenCLExtensionsFromExtMap(T *FDT, MapT &Map) {
+  std::string ExtensionNames = "";
+  auto Loc = Map.find(FDT);
+
+  for (auto const& I : Loc->second) {
+ExtensionNames += I;
+ExtensionNames += " ";
+  }
+  ExtensionNames.pop_back();
+
+  return ExtensionNames;
+}
+
 bool Sema::isOpenCLDisabledDecl(Decl *FD) {
   auto Loc = OpenCLDeclExtMap.find(FD);
   if (Loc == OpenCLDeclExtMap.end())
Index: include/clang/Sema/Sema.h
===
--- include/clang/Sema/Sema.h
+++ include/clang/Sema/Sema.h
@@ -8567,6 +8567,21 @@
   llvm::StringRef getCurrentOpenCLExtension() const {
 return CurrOpenCLExtension;
   }
+
+  /// Check if a function declaration \p FD associates with any
+  /// extensions present in OpenCLDeclExtMap and if so return the
+  /// extension(s) name(s).
+  std::string getOpenCLExtensionsFromDeclExtMap(FunctionDecl *FD);
+
+  /// Check if a function type \p FT associates with any
+  /// extensions present in OpenCLTypeExtMap and if so return the
+  /// extension(s) name(s).
+  std::string getOpenCLExtensionsFromTypeExtMap(FunctionType *FT);
+
+  /// Find an extension in an appropriate extension map and return its name
+  template
+  std::string getOpenCLExtensionsFromExtMap(T* FT, MapT &Map);
+
   void setCurrentOpenCLExtension(llvm::StringRef Ext) {
 CurrOpenCLExtension = Ext;
   }
Index: include/clang/Basic/DiagnosticSemaKinds.td
===
--- include/clang/Basic/DiagnosticSemaKinds.td
+++ include/clang/Basic/DiagnosticSemaKinds.td
@@ -3652,7 +3652,7 @@
 def note_ovl_candidate_disabled_by_function_cond_attr : Note<
 "candidate disabled: %0">;
 def note_ovl_candidate_disabled_by_extension : Note<
-"candidate disabled due to OpenCL extension">;
+"candidate unavailable as it requires OpenCL extension '%0' to be disabled">;
 def err_addrof_function_disabled_by_enable_if_attr : Error<
 "cannot take address of function %0 because it has one or more "
 "non-tautological enable_if conditions">;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D51484: [OpenCL] Add support of cl_intel_device_side_avc_motion_estimation extension

2018-09-21 Thread Alexey Sachkov via Phabricator via cfe-commits
AlexeySachkov updated this revision to Diff 166423.
AlexeySachkov added a comment.

Updated patch with new functionality and tests


https://reviews.llvm.org/D51484

Files:
  include/clang-c/Index.h
  include/clang/AST/ASTContext.h
  include/clang/AST/OperationKinds.def
  include/clang/AST/Type.h
  include/clang/Basic/OpenCLExtensionTypes.def
  include/clang/Basic/OpenCLExtensions.def
  include/clang/Sema/Initialization.h
  include/clang/Serialization/ASTBitCodes.h
  include/clang/module.modulemap
  lib/AST/ASTContext.cpp
  lib/AST/ASTImporter.cpp
  lib/AST/Expr.cpp
  lib/AST/ExprConstant.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/MicrosoftMangle.cpp
  lib/AST/NSAPI.cpp
  lib/AST/Type.cpp
  lib/AST/TypeLoc.cpp
  lib/Analysis/PrintfFormatString.cpp
  lib/CodeGen/CGDebugInfo.cpp
  lib/CodeGen/CGDebugInfo.h
  lib/CodeGen/CGExpr.cpp
  lib/CodeGen/CGExprAgg.cpp
  lib/CodeGen/CGExprComplex.cpp
  lib/CodeGen/CGExprConstant.cpp
  lib/CodeGen/CGExprScalar.cpp
  lib/CodeGen/CGOpenCLRuntime.cpp
  lib/CodeGen/CodeGenTypes.cpp
  lib/CodeGen/ItaniumCXXABI.cpp
  lib/Edit/RewriteObjCFoundationAPI.cpp
  lib/Headers/opencl-c.h
  lib/Index/USRGeneration.cpp
  lib/Sema/Sema.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaInit.cpp
  lib/Serialization/ASTCommon.cpp
  lib/Serialization/ASTReader.cpp
  lib/StaticAnalyzer/Core/ExprEngineC.cpp
  test/CodeGenOpenCL/intel-subgroups-avc-ext-types.cl
  test/SemaOpenCL/extension-version.cl
  test/SemaOpenCL/intel-subgroup-avc-ext-types.cl
  tools/libclang/CIndex.cpp
  tools/libclang/CXType.cpp

Index: tools/libclang/CXType.cpp
===
--- tools/libclang/CXType.cpp
+++ tools/libclang/CXType.cpp
@@ -70,6 +70,8 @@
 #define IMAGE_TYPE(ImgType, Id, SingletonId, Access, Suffix) BTCASE(Id);
 #include "clang/Basic/OpenCLImageTypes.def"
 #undef IMAGE_TYPE
+#define EXT_OPAQUE_TYPE(ExtType, Id, Ext) BTCASE(Id);
+#include "clang/Basic/OpenCLExtensionTypes.def"
 BTCASE(OCLSampler);
 BTCASE(OCLEvent);
 BTCASE(OCLQueue);
@@ -605,6 +607,8 @@
 #define IMAGE_TYPE(ImgType, Id, SingletonId, Access, Suffix) TKIND(Id);
 #include "clang/Basic/OpenCLImageTypes.def"
 #undef IMAGE_TYPE
+#define EXT_OPAQUE_TYPE(ExtTYpe, Id, Ext) TKIND(Id);
+#include "clang/Basic/OpenCLExtensionTypes.def"
 TKIND(OCLSampler);
 TKIND(OCLEvent);
 TKIND(OCLQueue);
Index: tools/libclang/CIndex.cpp
===
--- tools/libclang/CIndex.cpp
+++ tools/libclang/CIndex.cpp
@@ -1519,6 +1519,9 @@
 #define IMAGE_TYPE(ImgType, Id, SingletonId, Access, Suffix) \
   case BuiltinType::Id:
 #include "clang/Basic/OpenCLImageTypes.def"
+#define EXT_OPAQUE_TYPE(ExtTYpe, Id, Ext) \
+  case BuiltinType::Id:
+#include "clang/Basic/OpenCLExtensionTypes.def"
   case BuiltinType::OCLSampler:
   case BuiltinType::OCLEvent:
   case BuiltinType::OCLClkEvent:
Index: test/SemaOpenCL/intel-subgroup-avc-ext-types.cl
===
--- /dev/null
+++ test/SemaOpenCL/intel-subgroup-avc-ext-types.cl
@@ -0,0 +1,76 @@
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -cl-std=CL1.2 -cl-ext=+cl_intel_device_side_avc_motion_estimation -fsyntax-only -verify -DNEGATIVE %s
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -cl-std=CL1.2 -cl-ext=+cl_intel_device_side_avc_motion_estimation -fsyntax-only -verify %s
+
+#pragma OPENCL EXTENSION cl_intel_device_side_avc_motion_estimation : enable
+
+// Having the initializers defined in the test allows us not to include default
+// opencl header, and thus reducing test execution time.
+// The initializers' values must match with ones defined in the default opencl
+// header (clang/lib/Headers/opencl-c.h)
+
+#define CLK_AVC_ME_INITIALIZE_INTEL 0x0
+
+#define CLK_AVC_IME_PAYLOAD_INITIALIZE_INTEL   { 0 }
+#define CLK_AVC_REF_PAYLOAD_INITIALIZE_INTEL   { 0 }
+#define CLK_AVC_SIC_PAYLOAD_INITIALIZE_INTEL   { 0 }
+
+#define CLK_AVC_IME_RESULT_INITIALIZE_INTEL{ 0 }
+#define CLK_AVC_REF_RESULT_INITIALIZE_INTEL{ 0 }
+#define CLK_AVC_SIC_RESULT_INITIALIZE_INTEL{ 0 }
+
+#if defined NEGATIVE
+struct st{};
+typedef char char4 __attribute__((ext_vector_type(4)));
+void foo(bool b, char c, short s, long l, float f, double d, void* v,
+ char4 c4, event_t e, struct st ss) {
+  intel_sub_group_avc_mce_payload_t payload_mce = 0; // No zero initializer for mce types
+  // expected-error@-1 {{initializing 'intel_sub_group_avc_mce_payload_t' with an expression of incompatible type 'int'}}
+  intel_sub_group_avc_ime_payload_t payload_ime = b;
+  // expected-error@-1 {{initializing 'intel_sub_group_avc_ime_payload_t' with an expression of incompatible type 'bool'}}
+  intel_sub_group_avc_ref_payload_t payload_ref = c;
+  // expected-error@-1 {{initializing 'intel_sub_group_avc_ref_payload_t' with an expression of incompatible type 'char'}}
+  intel_sub_group_avc_sic_payload_t payload_sic = s;
+  // expected-error@-1 {{initializing 'intel_sub_group_a

[PATCH] D50229: +fp16fml feature for ARM and AArch64

2018-09-21 Thread Sjoerd Meijer via Phabricator via cfe-commits
SjoerdMeijer added a comment.

Ah, and just for your info, the proposal was just sent to the dev list: 
http://lists.llvm.org/pipermail/llvm-dev/2018-September/126346.html


Repository:
  rC Clang

https://reviews.llvm.org/D50229



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


[PATCH] D52344: [Clang][CodeGen][ObjC]: Fix non-bridged CoreFoundation builds on ELF targets that use `-fconstant-cfstrings`.

2018-09-21 Thread Kristina Brooks via Phabricator via cfe-commits
kristina added a comment.

Does appear to work properly:

  cfstring:002AC640 off_2AC640  dq offset 
__CFConstantStringClassReference
  cfstring:002AC640 ; DATA 
XREF: skipDTD+19D↑o
  cfstring:002AC640 ; 
skipDTD+2F7↑o
  cfstring:002AC648 dq offset stru_7B8.st_size
  cfstring:002AC650 dq offset dword_0
  cfstring:002AC658 dq offset qword_28+4

Though it seems it's best off if the section for it were renamed to something 
like `.text.cfstring` as it otherwise results in a rather bizarre ELF file 
layout. I should probably mark the section as constant when building it as well:

  [18] cfstring  PROGBITS002a9580 2a9580 007740 00  WA  
0   0  8


Repository:
  rC Clang

https://reviews.llvm.org/D52344



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


[PATCH] D50229: [ARM][AArch64] Add feature +fp16fml

2018-09-21 Thread Sjoerd Meijer via Phabricator via cfe-commits
SjoerdMeijer updated this revision to Diff 166439.
SjoerdMeijer retitled this revision from "+fp16fml feature for ARM and AArch64" 
to "[ARM][AArch64] Add feature +fp16fml".
SjoerdMeijer edited the summary of this revision.
SjoerdMeijer added a comment.

Added FIXMEs.


https://reviews.llvm.org/D50229

Files:
  lib/Driver/ToolChains/Arch/AArch64.cpp
  lib/Driver/ToolChains/Arch/ARM.cpp
  test/Driver/aarch64-cpus.c
  test/Driver/arm-cortex-cpus.c
  test/Preprocessor/aarch64-target-features.c
  test/Preprocessor/arm-target-features.c

Index: test/Preprocessor/arm-target-features.c
===
--- test/Preprocessor/arm-target-features.c
+++ test/Preprocessor/arm-target-features.c
@@ -21,18 +21,58 @@
 // CHECK-V8A-ALLOW-FP-INSTR: #define __ARM_FP16_FORMAT_IEEE 1
 // CHECK-V8A-ALLOW-FP-INSTR-V8A-NOT: #define __ARM_FEATURE_DOTPROD
 
-// RUN: %clang -target arm-none-linux-gnueabi -march=armv8.2a+fp16 -x c -E -dM %s -o - | FileCheck -match-full-lines --check-prefix=CHECK-FULLFP16-VECTOR-SCALAR %s
+// RUN: %clang -target arm-none-linux-gnueabi -march=armv8.2-a+nofp16fml+fp16 -x c -E -dM %s -o - | FileCheck -match-full-lines --check-prefix=CHECK-FULLFP16-VECTOR-SCALAR %s
+// RUN: %clang -target arm-none-linux-gnueabi -march=armv8.2-a+nofp16+fp16fml -x c -E -dM %s -o - | FileCheck -match-full-lines --check-prefix=CHECK-FULLFP16-VECTOR-SCALAR %s
+// RUN: %clang -target arm-none-linux-gnueabi -march=armv8.2-a+fp16+nofp16fml -x c -E -dM %s -o - | FileCheck -match-full-lines --check-prefix=CHECK-FULLFP16-VECTOR-SCALAR %s
+// RUN: %clang -target arm-none-linux-gnueabi -march=armv8-a+fp16fml -x c -E -dM %s -o - | FileCheck -match-full-lines --check-prefix=CHECK-FULLFP16-VECTOR-SCALAR %s
+// RUN: %clang -target arm-none-linux-gnueabi -march=armv8-a+fp16 -x c -E -dM %s -o - | FileCheck -match-full-lines --check-prefix=CHECK-FULLFP16-VECTOR-SCALAR %s
+// RUN: %clang -target arm-none-linux-gnueabi -march=armv8.4-a+nofp16fml+fp16 -x c -E -dM %s -o - | FileCheck -match-full-lines --check-prefix=CHECK-FULLFP16-VECTOR-SCALAR %s
+// RUN: %clang -target arm-none-linux-gnueabi -march=armv8.4-a+nofp16+fp16fml -x c -E -dM %s -o - | FileCheck -match-full-lines --check-prefix=CHECK-FULLFP16-VECTOR-SCALAR %s
+// RUN: %clang -target arm-none-linux-gnueabi -march=armv8.4-a+fp16+nofp16fml -x c -E -dM %s -o - | FileCheck -match-full-lines --check-prefix=CHECK-FULLFP16-VECTOR-SCALAR %s
+// RUN: %clang -target arm-none-linux-gnueabi -march=armv8.4-a+fp16fml -x c -E -dM %s -o - | FileCheck -match-full-lines --check-prefix=CHECK-FULLFP16-VECTOR-SCALAR %s
+// RUN: %clang -target arm-none-linux-gnueabi -march=armv8.4-a+fp16 -x c -E -dM %s -o - | FileCheck -match-full-lines --check-prefix=CHECK-FULLFP16-VECTOR-SCALAR %s
 // CHECK-FULLFP16-VECTOR-SCALAR: #define __ARM_FEATURE_FP16_SCALAR_ARITHMETIC 1
 // CHECK-FULLFP16-VECTOR-SCALAR: #define __ARM_FEATURE_FP16_VECTOR_ARITHMETIC 1
 // CHECK-FULLFP16-VECTOR-SCALAR: #define __ARM_FP 0xe
 // CHECK-FULLFP16-VECTOR-SCALAR: #define __ARM_FP16_FORMAT_IEEE 1
 
-// RUN: %clang -target arm-none-linux-gnueabi -march=armv8.2a+fp16 -mfpu=vfp4 -x c -E -dM %s -o - | FileCheck -match-full-lines --check-prefix=CHECK-FULLFP16-SCALAR %s
+// +fp16fml without neon doesn't make sense as the fp16fml instructions all require SIMD.
+// However, as +fp16fml implies +fp16 there is a set of defines that we would expect.
+// RUN: %clang -target arm-none-linux-gnueabi -march=armv8-a+fp16fml -mfpu=vfp4 -x c -E -dM %s -o - | FileCheck -match-full-lines --check-prefix=CHECK-FULLFP16-SCALAR %s
+// RUN: %clang -target arm-none-linux-gnueabi -march=armv8-a+fp16 -mfpu=vfp4 -x c -E -dM %s -o - | FileCheck -match-full-lines --check-prefix=CHECK-FULLFP16-SCALAR %s
+// RUN: %clang -target arm-none-linux-gnueabi -march=armv8.4-a+fp16fml -mfpu=vfp4 -x c -E -dM %s -o - | FileCheck -match-full-lines --check-prefix=CHECK-FULLFP16-SCALAR %s
+// RUN: %clang -target arm-none-linux-gnueabi -march=armv8.4-a+fp16 -mfpu=vfp4 -x c -E -dM %s -o - | FileCheck -match-full-lines --check-prefix=CHECK-FULLFP16-SCALAR %s
 // CHECK-FULLFP16-SCALAR:   #define __ARM_FEATURE_FP16_SCALAR_ARITHMETIC 1
 // CHECK-FULLFP16-SCALAR-NOT:   #define __ARM_FEATURE_FP16_VECTOR_ARITHMETIC 1
 // CHECK-FULLFP16-SCALAR:   #define __ARM_FP 0xe
 // CHECK-FULLFP16-SCALAR:   #define __ARM_FP16_FORMAT_IEEE 1
-//
+
+// RUN: %clang -target arm-none-linux-gnueabi -march=armv8.2-a -x c -E -dM %s -o - | FileCheck -match-full-lines --check-prefix=CHECK-FULLFP16-NOFML-VECTOR-SCALAR %s
+// RUN: %clang -target arm-none-linux-gnueabi -march=armv8.2-a+nofp16 -x c -E -dM %s -o - | FileCheck -match-full-lines --check-prefix=CHECK-FULLFP16-NOFML-VECTOR-SCALAR %s
+// RUN: %clang -target arm-none-linux-gnueabi -march=armv8.2-a+nofp16fml -x c -E -dM %s -o - | FileCheck -match-full-lines --check-prefix=CHECK-FULLFP16-NOFML-VECTOR-SCALAR %s
+// RUN: %clang -target arm-none-linux-gnueabi -march=armv8.2-a+fp16fml+nofp16 -x c -E -dM %s -o -

[PATCH] D52261: [Sema] Generate completion fix-its for C code as well

2018-09-21 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov accepted this revision.
ilya-biryukov added a comment.
This revision is now accepted and ready to land.

Thanks! LGTM!


https://reviews.llvm.org/D52261



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


r342721 - [CodeComplete] Generate completion fix-its for C code as well

2018-09-21 Thread Ivan Donchevskii via cfe-commits
Author: yvvan
Date: Fri Sep 21 04:23:22 2018
New Revision: 342721

URL: http://llvm.org/viewvc/llvm-project?rev=342721&view=rev
Log:
[CodeComplete] Generate completion fix-its for C code as well

Current completion fix-its approach does not provide OtherOpBase for C code.
But we can easily proceed in this case taking the original Base type.

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

Modified:
cfe/trunk/lib/Parse/ParseExpr.cpp
cfe/trunk/test/CodeCompletion/member-access.c

Modified: cfe/trunk/lib/Parse/ParseExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseExpr.cpp?rev=342721&r1=342720&r2=342721&view=diff
==
--- cfe/trunk/lib/Parse/ParseExpr.cpp (original)
+++ cfe/trunk/lib/Parse/ParseExpr.cpp Fri Sep 21 04:23:22 2018
@@ -1766,6 +1766,8 @@ Parser::ParsePostfixExpressionSuffix(Exp
 
 Expr *Base = LHS.get();
 Expr *CorrectedBase = CorrectedLHS.get();
+if (!CorrectedBase && !getLangOpts().CPlusPlus)
+  CorrectedBase = Base;
 
 // Code completion for a member access expression.
 Actions.CodeCompleteMemberReferenceExpr(

Modified: cfe/trunk/test/CodeCompletion/member-access.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeCompletion/member-access.c?rev=342721&r1=342720&r2=342721&view=diff
==
--- cfe/trunk/test/CodeCompletion/member-access.c (original)
+++ cfe/trunk/test/CodeCompletion/member-access.c Fri Sep 21 04:23:22 2018
@@ -10,3 +10,22 @@ void test(struct Point *p) {
   // CHECK-CC1: x
   // CHECK-CC1: y
   // CHECK-CC1: z
+}
+
+struct Point2 {
+  float x;
+};
+
+void test2(struct Point2 p) {
+  p->
+}
+
+void test3(struct Point2 *p) {
+  p.
+}
+
+// RUN: %clang_cc1 -fsyntax-only -code-completion-with-fixits 
-code-completion-at=%s:20:6 %s -o - | FileCheck -check-prefix=CHECK-CC2 %s
+// CHECK-CC2: x (requires fix-it: {20:4-20:6} to ".")
+
+// RUN: %clang_cc1 -fsyntax-only -code-completion-with-fixits 
-code-completion-at=%s:24:5 %s -o - | FileCheck -check-prefix=CHECK-CC3 %s
+// CHECK-CC3: x (requires fix-it: {24:4-24:5} to "->")


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


[PATCH] D52261: [Sema] Generate completion fix-its for C code as well

2018-09-21 Thread Ivan Donchevskii via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rC342721: [CodeComplete] Generate completion fix-its for C 
code as well (authored by yvvan, committed by ).

Repository:
  rC Clang

https://reviews.llvm.org/D52261

Files:
  lib/Parse/ParseExpr.cpp
  test/CodeCompletion/member-access.c


Index: test/CodeCompletion/member-access.c
===
--- test/CodeCompletion/member-access.c
+++ test/CodeCompletion/member-access.c
@@ -10,3 +10,22 @@
   // CHECK-CC1: x
   // CHECK-CC1: y
   // CHECK-CC1: z
+}
+
+struct Point2 {
+  float x;
+};
+
+void test2(struct Point2 p) {
+  p->
+}
+
+void test3(struct Point2 *p) {
+  p.
+}
+
+// RUN: %clang_cc1 -fsyntax-only -code-completion-with-fixits 
-code-completion-at=%s:20:6 %s -o - | FileCheck -check-prefix=CHECK-CC2 %s
+// CHECK-CC2: x (requires fix-it: {20:4-20:6} to ".")
+
+// RUN: %clang_cc1 -fsyntax-only -code-completion-with-fixits 
-code-completion-at=%s:24:5 %s -o - | FileCheck -check-prefix=CHECK-CC3 %s
+// CHECK-CC3: x (requires fix-it: {24:4-24:5} to "->")
Index: lib/Parse/ParseExpr.cpp
===
--- lib/Parse/ParseExpr.cpp
+++ lib/Parse/ParseExpr.cpp
@@ -1766,6 +1766,8 @@
 
 Expr *Base = LHS.get();
 Expr *CorrectedBase = CorrectedLHS.get();
+if (!CorrectedBase && !getLangOpts().CPlusPlus)
+  CorrectedBase = Base;
 
 // Code completion for a member access expression.
 Actions.CodeCompleteMemberReferenceExpr(


Index: test/CodeCompletion/member-access.c
===
--- test/CodeCompletion/member-access.c
+++ test/CodeCompletion/member-access.c
@@ -10,3 +10,22 @@
   // CHECK-CC1: x
   // CHECK-CC1: y
   // CHECK-CC1: z
+}
+
+struct Point2 {
+  float x;
+};
+
+void test2(struct Point2 p) {
+  p->
+}
+
+void test3(struct Point2 *p) {
+  p.
+}
+
+// RUN: %clang_cc1 -fsyntax-only -code-completion-with-fixits -code-completion-at=%s:20:6 %s -o - | FileCheck -check-prefix=CHECK-CC2 %s
+// CHECK-CC2: x (requires fix-it: {20:4-20:6} to ".")
+
+// RUN: %clang_cc1 -fsyntax-only -code-completion-with-fixits -code-completion-at=%s:24:5 %s -o - | FileCheck -check-prefix=CHECK-CC3 %s
+// CHECK-CC3: x (requires fix-it: {24:4-24:5} to "->")
Index: lib/Parse/ParseExpr.cpp
===
--- lib/Parse/ParseExpr.cpp
+++ lib/Parse/ParseExpr.cpp
@@ -1766,6 +1766,8 @@
 
 Expr *Base = LHS.get();
 Expr *CorrectedBase = CorrectedLHS.get();
+if (!CorrectedBase && !getLangOpts().CPlusPlus)
+  CorrectedBase = Base;
 
 // Code completion for a member access expression.
 Actions.CodeCompleteMemberReferenceExpr(
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D45179: [libc++] Add _LIBCPP_ENABLE_NODISCARD and _LIBCPP_NODISCARD_EXT to allow pre-C++2a [[nodiscard]]

2018-09-21 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

In https://reviews.llvm.org/D45179#1225911, @EricWF wrote:

> I don't think it ever landed. I'll try to get it in this week.


What does this need?
Is there some changes missing still?
Or this simply needs to be committed (and bots watched?)


https://reviews.llvm.org/D45179



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


[PATCH] D51340: Add /Zc:DllexportInlines option to clang-cl

2018-09-21 Thread Takuto Ikuta via Phabricator via cfe-commits
takuto.ikuta updated this revision to Diff 166448.
takuto.ikuta edited the summary of this revision.
takuto.ikuta added a comment.

Remove unnecessary willHaveBody check condition


https://reviews.llvm.org/D51340

Files:
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Driver/CC1Options.td
  clang/include/clang/Driver/CLCompatOptions.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/test/CodeGenCXX/dllexport-no-dllexport-inlines.cpp

Index: clang/test/CodeGenCXX/dllexport-no-dllexport-inlines.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/dllexport-no-dllexport-inlines.cpp
@@ -0,0 +1,162 @@
+// RUN: %clang_cc1 %s -fms-extensions -triple x86_64-windows-msvc   \
+// RUN: -fno-dllexport-inlines -emit-llvm -O0 -o - |\
+// RUN: FileCheck --check-prefix=DEFAULT --check-prefix=NOINLINE %s
+
+// RUN: %clang_cc1 %s -fms-extensions -triple x86_64-windows-msvc   \
+// RUN: -emit-llvm -O0 -o - |   \
+// RUN: FileCheck --check-prefix=DEFAULT --check-prefix=INLINE %s
+
+
+// Function
+
+// DEFAULT-DAG: define dso_local dllexport void @"?NormalFunction@@YAXXZ"()
+void __declspec(dllexport) NormalFunction() {}
+
+
+// DEFAULT-DAG: define weak_odr dso_local dllexport void @"?AlwaysInlineFunction@@YAXXZ"
+__forceinline void __declspec(dllexport) AlwaysInlineFunction() {}
+
+// DEFAULT-DAG: @"?static_variable@?1??AlwaysInlineWithStaticVariableExported@@YAHXZ@4HA" = weak_odr dso_local dllexport global i32 0, comdat, align 4
+__forceinline int __declspec(dllexport) AlwaysInlineWithStaticVariableExported() {
+  static int static_variable = 0;
+  ++static_variable;
+  return static_variable;
+}
+
+// DEFAULT-DAG: @"?static_variable@?1??AlwaysInlineWithStaticVariableImported@@YAHXZ@4HA" = available_externally dllimport global i32 0, align 4
+__forceinline int __declspec(dllimport) AlwaysInlineWithStaticVariableImported() {
+  static int static_variable = 0;
+  ++static_variable;
+  return static_variable;
+}
+
+int ImportedFunctionUser() {
+  return AlwaysInlineWithStaticVariableImported();
+}
+
+// Class member function
+
+// check for local static variables
+// NOINLINE-DAG: @"?static_variable@?1??InclassDefFuncWithStaticVariable@NoTemplateExportedClass@@QEAAHXZ@4HA" = linkonce_odr dso_local global i32 0, comdat, align 4
+// INLINE-DAG: @"?static_variable@?1??InclassDefFuncWithStaticVariable@NoTemplateExportedClass@@QEAAHXZ@4HA" = weak_odr dso_local dllexport global i32 0, comdat, align 4
+
+// DEFAULT-DAG: @"?static_variable@?1??InlineOutclassDefFuncWithStaticVariable@NoTemplateExportedClass@@QEAAHXZ@4HA" = weak_odr dso_local dllexport global i32 0, comdat, align 4
+
+class __declspec(dllexport) NoTemplateExportedClass {
+ public:
+  // DEFAULT-NOT: NoTemplateExportedClass@NoTemplateExportedClass@@
+  NoTemplateExportedClass() = default;
+
+  // NOINLINE-NOT: InclassDefFunc@NoTemplateExportedClass
+  // INLINE-DAG: define weak_odr dso_local dllexport void @"?InclassDefFunc@NoTemplateExportedClass@@
+  void InclassDefFunc() {}
+
+  int f();
+
+  // DEFAULT-DAG: define weak_odr dso_local dllexport i32 @"?InclassDefFuncWithStaticVariable@NoTemplateExportedClass@@QEAAHXZ"
+  int InclassDefFuncWithStaticVariable() {
+static int static_variable = 0;
+++static_variable;
+return static_variable;
+  }
+
+  // DEFAULT-DAG: define weak_odr dso_local dllexport i32 @"?InclassDefFunctWithLambdaStaticVariable@NoTemplateExportedClass@@QEAAHXZ"
+  int InclassDefFunctWithLambdaStaticVariable() {
+return ([]() { static int static_x; return ++static_x; })();
+  }
+
+  // DEFAULT-NOT: InlineOutclassDefFuncWihtoutDefinition
+  __forceinline void InlineOutclassDefFuncWihtoutDefinition();
+
+  // DEFAULT-NOT: InlineOutclassDefFunc@NoTemplateExportedClass@@
+  __forceinline void InlineOutclassDefFunc();
+
+  // DEFAULT-NOT: InlineOutclassDefFuncWithStaticVariable@NoTemplateExportedClass@@
+  __forceinline int InlineOutclassDefFuncWithStaticVariable();
+
+  // DEFAULT-DAG: define dso_local dllexport void @"?OutclassDefFunc@NoTemplateExportedClass@@QEAAXXZ"
+  void OutclassDefFunc();
+};
+
+void NoTemplateExportedClass::OutclassDefFunc() {}
+
+__forceinline void NoTemplateExportedClass::InlineOutclassDefFunc() {}
+
+__forceinline int NoTemplateExportedClass::InlineOutclassDefFuncWithStaticVariable() {
+  static int static_variable = 0;
+  return ++static_variable;
+}
+
+void __declspec(dllexport) NoTemplateExportedClassUser() {
+  NoTemplateExportedClass a;
+  a.InlineOutclassDefFunc();
+}
+
+template
+class __declspec(dllexport) TemplateExportedClass {
+  void InclassDefFunc() {}
+  void OutclassDefFunc();
+
+  T templateValue;
+};
+
+// DEFAULT-NOT: define dso_local dllexport void @"?OutclassDefFunc@NoTemplateExportedClass@@
+template void TemplateExportedClass::OutclassDefFu

[PATCH] D51340: Add /Zc:DllexportInlines option to clang-cl

2018-09-21 Thread Takuto Ikuta via Phabricator via cfe-commits
takuto.ikuta updated this revision to Diff 166450.

https://reviews.llvm.org/D51340

Files:
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Driver/CC1Options.td
  clang/include/clang/Driver/CLCompatOptions.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/test/CodeGenCXX/dllexport-no-dllexport-inlines.cpp

Index: clang/test/CodeGenCXX/dllexport-no-dllexport-inlines.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/dllexport-no-dllexport-inlines.cpp
@@ -0,0 +1,159 @@
+// RUN: %clang_cc1 %s -fms-extensions -triple x86_64-windows-msvc   \
+// RUN: -fno-dllexport-inlines -emit-llvm -O0 -o - |\
+// RUN: FileCheck --check-prefix=DEFAULT --check-prefix=NOINLINE %s
+
+// RUN: %clang_cc1 %s -fms-extensions -triple x86_64-windows-msvc   \
+// RUN: -emit-llvm -O0 -o - |   \
+// RUN: FileCheck --check-prefix=DEFAULT --check-prefix=INLINE %s
+
+
+// Function
+
+// DEFAULT-DAG: define dso_local dllexport void @"?NormalFunction@@YAXXZ"()
+void __declspec(dllexport) NormalFunction() {}
+
+
+// DEFAULT-DAG: define weak_odr dso_local dllexport void @"?AlwaysInlineFunction@@YAXXZ"
+__forceinline void __declspec(dllexport) AlwaysInlineFunction() {}
+
+// DEFAULT-DAG: @"?static_variable@?1??AlwaysInlineWithStaticVariableExported@@YAHXZ@4HA" = weak_odr dso_local dllexport global i32 0, comdat, align 4
+__forceinline int __declspec(dllexport) AlwaysInlineWithStaticVariableExported() {
+  static int static_variable = 0;
+  ++static_variable;
+  return static_variable;
+}
+
+// DEFAULT-DAG: @"?static_variable@?1??AlwaysInlineWithStaticVariableImported@@YAHXZ@4HA" = available_externally dllimport global i32 0, align 4
+__forceinline int __declspec(dllimport) AlwaysInlineWithStaticVariableImported() {
+  static int static_variable = 0;
+  ++static_variable;
+  return static_variable;
+}
+
+int ImportedFunctionUser() {
+  return AlwaysInlineWithStaticVariableImported();
+}
+
+// Class member function
+
+// check for local static variables
+// NOINLINE-DAG: @"?static_variable@?1??InclassDefFuncWithStaticVariable@NoTemplateExportedClass@@QEAAHXZ@4HA" = linkonce_odr dso_local global i32 0, comdat, align 4
+// INLINE-DAG: @"?static_variable@?1??InclassDefFuncWithStaticVariable@NoTemplateExportedClass@@QEAAHXZ@4HA" = weak_odr dso_local dllexport global i32 0, comdat, align 4
+class __declspec(dllexport) NoTemplateExportedClass {
+ public:
+  // DEFAULT-NOT: NoTemplateExportedClass@NoTemplateExportedClass@@
+  NoTemplateExportedClass() = default;
+
+  // NOINLINE-NOT: InclassDefFunc@NoTemplateExportedClass
+  // INLINE-DAG: define weak_odr dso_local dllexport void @"?InclassDefFunc@NoTemplateExportedClass@@
+  void InclassDefFunc() {}
+
+  int f();
+
+  // DEFAULT-DAG: define weak_odr dso_local dllexport i32 @"?InclassDefFuncWithStaticVariable@NoTemplateExportedClass@@QEAAHXZ"
+  int InclassDefFuncWithStaticVariable() {
+static int static_variable = 0;
+++static_variable;
+return static_variable;
+  }
+
+  // DEFAULT-DAG: define weak_odr dso_local dllexport i32 @"?InclassDefFunctWithLambdaStaticVariable@NoTemplateExportedClass@@QEAAHXZ"
+  int InclassDefFunctWithLambdaStaticVariable() {
+return ([]() { static int static_x; return ++static_x; })();
+  }
+
+  // DEFAULT-NOT: InlineOutclassDefFuncWihtoutDefinition
+  __forceinline void InlineOutclassDefFuncWihtoutDefinition();
+
+  // DEFAULT-NOT: InlineOutclassDefFunc@NoTemplateExportedClass@@
+  __forceinline void InlineOutclassDefFunc();
+
+  // DEFAULT-NOT: InlineOutclassDefFuncWithStaticVariable@NoTemplateExportedClass@@
+  __forceinline int InlineOutclassDefFuncWithStaticVariable();
+
+  // DEFAULT-DAG: define dso_local dllexport void @"?OutclassDefFunc@NoTemplateExportedClass@@QEAAXXZ"
+  void OutclassDefFunc();
+};
+
+void NoTemplateExportedClass::OutclassDefFunc() {}
+
+__forceinline void NoTemplateExportedClass::InlineOutclassDefFunc() {}
+
+__forceinline int NoTemplateExportedClass::InlineOutclassDefFuncWithStaticVariable() {
+  static int static_variable = 0;
+  return ++static_variable;
+}
+
+void __declspec(dllexport) NoTemplateExportedClassUser() {
+  NoTemplateExportedClass a;
+  a.InlineOutclassDefFunc();
+}
+
+template
+class __declspec(dllexport) TemplateExportedClass {
+  void InclassDefFunc() {}
+  void OutclassDefFunc();
+
+  T templateValue;
+};
+
+// DEFAULT-NOT: define dso_local dllexport void @"?OutclassDefFunc@NoTemplateExportedClass@@
+template void TemplateExportedClass::OutclassDefFunc() {}
+
+class A11{};
+class B22{};
+
+// DEFAULT-DAG: define weak_odr dso_local dllexport void @"?InclassDefFunc@?$TemplateExportedClass@VA11@@
+// DEFAULT-DAG: define weak_odr dso_local dllexport void @"?OutclassDefFunc@?$TemplateExportedClass@VA11@@
+template class __declspec(dllexport) TemplateExportedClas

[PATCH] D52300: [clangd] Implement VByte PostingList compression

2018-09-21 Thread Kirill Bobyrev via Phabricator via cfe-commits
kbobyrev updated this revision to Diff 166453.
kbobyrev marked 9 inline comments as done.
kbobyrev added a comment.

I addressed the easiest issues. I'll try to implement separate storage 
structure for `Head`s and `Payload`s which would potentially make the 
implementation cleaner and easier to understand (and also more maintainable 
since that would be way easier to go for SIMD instructions speedups and other 
encoding schemes if we do that).

Also, I'll refine https://reviews.llvm.org/D52047 a little bit and I believe 
that is should be way easier to understand performance + memory consumption 
once we have these benchmarks in. Both @ioeric and @ilya-biryukov expressed 
their concern with regard to the memory consumption "benchmark" and suggested a 
separate binary. While this seems fine to me, I think it's important to keep 
performance + memory tracking infrastructure easy to use (in this sense 
scattering different metrics across multiple binaries makes it less accessible 
and probably introduce some code duplication) and therefore using this "trick" 
is OK to me, but I don't have a strong opinion about this. What do you think, 
@sammccall?


https://reviews.llvm.org/D52300

Files:
  clang-tools-extra/clangd/CMakeLists.txt
  clang-tools-extra/clangd/index/dex/Dex.cpp
  clang-tools-extra/clangd/index/dex/PostingList.cpp
  clang-tools-extra/clangd/index/dex/PostingList.h
  clang-tools-extra/clangd/index/dex/fuzzer/CMakeLists.txt
  clang-tools-extra/clangd/index/dex/fuzzer/VByteFuzzer.cpp
  clang-tools-extra/unittests/clangd/DexTests.cpp

Index: clang-tools-extra/unittests/clangd/DexTests.cpp
===
--- clang-tools-extra/unittests/clangd/DexTests.cpp
+++ clang-tools-extra/unittests/clangd/DexTests.cpp
@@ -260,15 +260,15 @@
   const PostingList L2({1, 5, 7, 9});
   const PostingList L3({0, 5});
   const PostingList L4({0, 1, 5});
-  const PostingList L5({});
-
-  EXPECT_EQ(llvm::to_string(*(L0.iterator())), "[4]");
-
-  auto Nested =
-  createAnd(createAnd(L1.iterator(), L2.iterator()),
-createOr(L3.iterator(), L4.iterator(), L5.iterator()));
-
-  EXPECT_EQ(llvm::to_string(*Nested), "(& (| [5] [1] [END]) (& [1] [1]))");
+  const PostingList Empty({});
+
+  EXPECT_EQ(llvm::to_string(*(L0.iterator())), "[4 ...]");
+  EXPECT_EQ(llvm::to_string(*Empty.iterator()), "[END]");
+  auto It = L0.iterator();
+  It->advanceTo(19);
+  EXPECT_EQ(llvm::to_string(*It), "[... 20 ...]");
+  It->advanceTo(9000);
+  EXPECT_EQ(llvm::to_string(*It), "[... END]");
 }
 
 TEST(DexIterators, Limit) {
Index: clang-tools-extra/clangd/index/dex/fuzzer/VByteFuzzer.cpp
===
--- /dev/null
+++ clang-tools-extra/clangd/index/dex/fuzzer/VByteFuzzer.cpp
@@ -0,0 +1,64 @@
+//===-- VByteFuzzer.cpp - Fuzz VByte Posting List encoding ===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+///
+/// \file
+/// \brief This file implements a function that runs clangd on a single input.
+/// This function is then linked into the Fuzzer library.
+///
+//===--===//
+
+#include "../Iterator.h"
+#include "../PostingList.h"
+#include "llvm/Support/Compiler.h"
+#include "llvm/Support/FileSystem.h"
+#include "llvm/Support/raw_ostream.h"
+#include 
+#include 
+
+using DocID = clang::clangd::dex::DocID;
+
+/// Transform raw byte sequence into list of DocIDs.
+std::vector generateDocuments(uint8_t *Data, size_t Size) {
+  std::vector Result;
+  DocID ID = 0;
+  for (size_t I = 0; I < Size; ++I) {
+size_t Offset = I % 4;
+if (Offset == 0 && I != 0) {
+  ID = 0;
+  Result.push_back(ID);
+}
+ID |= (Data[I] << Offset);
+  }
+  if (Size > 4 && Size % 4 != 0)
+Result.push_back(ID);
+  return Result;
+}
+
+/// This fuzzer checks that compressed PostingList contains can be successfully
+/// decoded into the original sequence.
+extern "C" int LLVMFuzzerTestOneInput(uint8_t *Data, size_t Size) {
+  if (Size == 0)
+return 0;
+  const auto OriginalDocuments = generateDocuments(Data, Size);
+  if (OriginalDocuments.empty())
+return 0;
+  // Ensure that given sequence of DocIDs is sorted.
+  for (size_t I = 1; I < OriginalDocuments.size(); ++I)
+if (OriginalDocuments[I] <= OriginalDocuments[I - 1])
+  return 0;
+  const clang::clangd::dex::PostingList List(OriginalDocuments);
+  const auto DecodedDocuments = clang::clangd::dex::consume(*List.iterator());
+  // Compare decoded sequence against the original PostingList contents.
+  if (DecodedDocuments.size() != OriginalDocuments.size())
+LLVM_BUILTIN_TRAP;
+  for (size_t I = 0; I < DecodedDocuments.size(); ++I)
+if (DecodedDocuments[I]

[PATCH] D52300: [clangd] Implement VByte PostingList compression

2018-09-21 Thread Eric Liu via Phabricator via cfe-commits
ioeric added a comment.

In https://reviews.llvm.org/D52300#1241754, @kbobyrev wrote:

> Also, I'll refine https://reviews.llvm.org/D52047 a little bit and I believe 
> that is should be way easier to understand performance + memory consumption 
> once we have these benchmarks in. Both @ioeric and @ilya-biryukov expressed 
> their concern with regard to the memory consumption "benchmark" and suggested 
> a separate binary. While this seems fine to me, I think it's important to 
> keep performance + memory tracking infrastructure easy to use (in this sense 
> scattering different metrics across multiple binaries makes it less 
> accessible and probably introduce some code duplication) and therefore using 
> this "trick" is OK to me, but I don't have a strong opinion about this. What 
> do you think, @sammccall?


FWIW, I think the "trick" for memory benchmark is fine. I just think we should 
add proper output to make the trick clear to users, as suggested in the patch 
comment.


https://reviews.llvm.org/D52300



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


[PATCH] D52300: [clangd] Implement VByte PostingList compression

2018-09-21 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

In https://reviews.llvm.org/D52300#1241776, @ioeric wrote:

> In https://reviews.llvm.org/D52300#1241754, @kbobyrev wrote:
>
> > Also, I'll refine https://reviews.llvm.org/D52047 a little bit and I 
> > believe that is should be way easier to understand performance + memory 
> > consumption once we have these benchmarks in. Both @ioeric and 
> > @ilya-biryukov expressed their concern with regard to the memory 
> > consumption "benchmark" and suggested a separate binary. While this seems 
> > fine to me, I think it's important to keep performance + memory tracking 
> > infrastructure easy to use (in this sense scattering different metrics 
> > across multiple binaries makes it less accessible and probably introduce 
> > some code duplication) and therefore using this "trick" is OK to me, but I 
> > don't have a strong opinion about this. What do you think, @sammccall?
>
>
> FWIW, I think the "trick" for memory benchmark is fine. I just think we 
> should add proper output to make the trick clear to users, as suggested in 
> the patch comment.


It seems to be omitted in README.md, but you are probably after 
`benchmark::State::SetLabel()` 



https://reviews.llvm.org/D52300



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


[PATCH] D52268: [AST] Squeeze some bits in LinkageComputer

2018-09-21 Thread Bruno Ricci via Phabricator via cfe-commits
riccibruno added a comment.

In https://reviews.llvm.org/D52268#1241033, @rjmccall wrote:

> `LinkageComputer` isn't actually persisted anywhere, right?  And there's 
> maybe one computer active at once?  So this compression is theoretically 
> saving one pointer of stack space but forcing a bunch of bit-manipulation 
> every time these fields are accessed.


It is not persisted but this saves one pointer per entry in the map. Another 
factor is that hashing a pair involves hashing
each component and then combining the result, which is comparatively much more 
expansive than just hashing a `PointerIntPair`,
which involves only a shift and a xor. The field storing the 
`LVComputationKind` is never directly read but only used to differentiate
various kinds of computations in the map. I went back and instrumented the 
lookup function `LinkageComputer::lookup` with `rdtsc`,
and (with all the usual caveats about microbenchmarks and `rdtsc`) I get that 
this cuts the number of ticks spent inside `lookup`
from about 8e6 to 3.5e6. Now of course taking a step back this represent only 
milliseconds and is firmly in the category of
"way to small to bother",  but now we might as well do it.


Repository:
  rC Clang

https://reviews.llvm.org/D52268



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


[PATCH] D52047: [clangd] Add building benchmark and memory consumption tracking

2018-09-21 Thread Kirill Bobyrev via Phabricator via cfe-commits
kbobyrev updated this revision to Diff 166462.
kbobyrev marked 4 inline comments as done.
kbobyrev added a comment.

Use `llvm::Expected`, cleanup the patch.


https://reviews.llvm.org/D52047

Files:
  clang-tools-extra/clangd/benchmarks/IndexBenchmark.cpp
  clang-tools-extra/clangd/index/Serialization.cpp
  clang-tools-extra/clangd/index/SymbolYAML.cpp
  clang-tools-extra/clangd/index/SymbolYAML.h
  clang-tools-extra/clangd/index/dex/Dex.cpp

Index: clang-tools-extra/clangd/index/dex/Dex.cpp
===
--- clang-tools-extra/clangd/index/dex/Dex.cpp
+++ clang-tools-extra/clangd/index/dex/Dex.cpp
@@ -124,9 +124,6 @@
   for (const auto &TokenToPostingList : TempInvertedIndex)
 InvertedIndex.insert({TokenToPostingList.first,
   PostingList(move(TokenToPostingList.second))});
-
-  vlog("Built Dex with estimated memory usage {0} bytes.",
-   estimateMemoryUsage());
 }
 
 /// Constructs iterators over tokens extracted from the query and exhausts it
@@ -238,8 +235,9 @@
   Bytes += SymbolQuality.size() * sizeof(float);
   Bytes += LookupTable.getMemorySize();
   Bytes += InvertedIndex.getMemorySize();
-  for (const auto &P : InvertedIndex)
-Bytes += P.second.bytes();
+  for (const auto &TokenAndPostingList : InvertedIndex)
+Bytes += TokenAndPostingList.first.Data.size() +
+ TokenAndPostingList.second.bytes();
   return Bytes + BackingDataSize;
 }
 
Index: clang-tools-extra/clangd/index/SymbolYAML.h
===
--- clang-tools-extra/clangd/index/SymbolYAML.h
+++ clang-tools-extra/clangd/index/SymbolYAML.h
@@ -29,6 +29,9 @@
 // Read symbols from a YAML-format string.
 SymbolSlab symbolsFromYAML(llvm::StringRef YAMLContent);
 
+// Read symbols from YAML or RIFF file.
+llvm::Expected symbolsFromFile(llvm::StringRef SymbolFilename);
+
 // Read one symbol from a YAML-stream.
 // The returned symbol is backed by Input.
 Symbol SymbolFromYAML(llvm::yaml::Input &Input);
Index: clang-tools-extra/clangd/index/SymbolYAML.cpp
===
--- clang-tools-extra/clangd/index/SymbolYAML.cpp
+++ clang-tools-extra/clangd/index/SymbolYAML.cpp
@@ -9,6 +9,7 @@
 
 #include "SymbolYAML.h"
 #include "Index.h"
+#include "Logger.h"
 #include "Serialization.h"
 #include "Trace.h"
 #include "dex/Dex.h"
@@ -172,6 +173,7 @@
 namespace clangd {
 
 SymbolSlab symbolsFromYAML(llvm::StringRef YAMLContent) {
+  trace::Span Tracer("ParseYAML");
   llvm::yaml::Input Yin(YAMLContent);
   std::vector S;
   Yin >> S;
@@ -182,6 +184,24 @@
   return std::move(Syms).build();
 }
 
+llvm::Expected symbolsFromFile(llvm::StringRef SymbolFilename) {
+  auto Buffer = llvm::MemoryBuffer::getFile(SymbolFilename);
+  if (!Buffer)
+return llvm::make_error(
+("Can't open " + SymbolFilename).str(), llvm::errc::invalid_argument);
+
+  StringRef Data = Buffer->get()->getBuffer();
+
+  if (!Data.startswith("RIFF")) { // Magic for binary index file.
+return symbolsFromYAML(Data);
+  }
+  auto RIFF = readIndexFile(Data);
+  return RIFF ? llvm::Expected(std::move(*RIFF->Symbols))
+  : llvm::make_error(
+("Can't open " + SymbolFilename).str(),
+llvm::errc::invalid_argument);
+}
+
 Symbol SymbolFromYAML(llvm::yaml::Input &Input) {
   Symbol S;
   Input >> S;
@@ -206,30 +226,16 @@
llvm::ArrayRef URISchemes,
bool UseDex) {
   trace::Span OverallTracer("LoadIndex");
-  auto Buffer = llvm::MemoryBuffer::getFile(SymbolFilename);
-  if (!Buffer) {
-llvm::errs() << "Can't open " << SymbolFilename << "\n";
-return nullptr;
-  }
-  StringRef Data = Buffer->get()->getBuffer();
-
-  llvm::Optional Slab;
-  if (Data.startswith("RIFF")) { // Magic for binary index file.
-trace::Span Tracer("ParseRIFF");
-if (auto RIFF = readIndexFile(Data))
-  Slab = std::move(RIFF->Symbols);
-else
-  llvm::errs() << "Bad RIFF: " << llvm::toString(RIFF.takeError()) << "\n";
-  } else {
-trace::Span Tracer("ParseYAML");
-Slab = symbolsFromYAML(Data);
-  }
-
+  auto Slab = symbolsFromFile(SymbolFilename);
   if (!Slab)
 return nullptr;
   trace::Span Tracer("BuildIndex");
-  return UseDex ? dex::Dex::build(std::move(*Slab), URISchemes)
-: MemIndex::build(std::move(*Slab), RefSlab());
+  auto Index = UseDex ? dex::Dex::build(std::move(*Slab), URISchemes)
+  : MemIndex::build(std::move(*Slab), RefSlab());
+  vlog("Loaded {0} from {1} with estimated memory usage {2}",
+   UseDex ? "Dex" : "MemIndex", SymbolFilename,
+   Index->estimateMemoryUsage());
+  return Index;
 }
 
 } // namespace clangd
Index: clang-tools-extra/clangd/index/Serialization.cpp
===
--- clang-tools-extra/clangd/index/Serialization.cp

r342729 - [AST] Various optimizations + refactoring in DeclarationName(Table)

2018-09-21 Thread Bruno Ricci via cfe-commits
Author: brunoricci
Date: Fri Sep 21 05:53:22 2018
New Revision: 342729

URL: http://llvm.org/viewvc/llvm-project?rev=342729&view=rev
Log:
[AST] Various optimizations + refactoring in DeclarationName(Table)

Introduce the following optimizations in DeclarationName(Table):

 1. Store common kinds inline in DeclarationName instead of
DeclarationNameExtra. Currently the kind of C++ constructor, destructor,
conversion function and overloaded operator names is stored in
DeclarationNameExtra. Instead store it inline in DeclarationName.
To do this align IdentifierInfo, CXXSpecialName, DeclarationNameExtra
and CXXOperatorIdName to 8 bytes so that we can use the lower 3 bits of
DeclarationName::Ptr. This is already the case on 64 bits archs anyway.
This also allow us to remove DeclarationNameExtra from CXXSpecialName
and CXXOperatorIdName, which shave off a pointer from CXXSpecialName. 

 2. Synchronize the enumerations DeclarationName::NameKind,
DeclarationName::StoredNameKind and Selector::IdentifierInfoFlag.
This makes DeclarationName::getNameKind much more efficient since we can
replace the switch table by a single comparison and an addition.

 3. Put the overloaded operator names inline in DeclarationNameTable to remove
an indirection. This increase the size of DeclarationNameTable a little
bit but this is not important since it is only used in ASTContext, and
never copied nor moved from. This also get rid of the last dynamic
allocation in DeclarationNameTable.

Altogether these optimizations cut the run time of parsing all of Boost by
about 0.8%. While we are at it, do the following NFC modifications:

 1. Put the internal classes CXXSpecialName, CXXDeductionGuideNameExtra,
CXXOperatorIdName, CXXLiteralOperatorIdName and DeclarationNameExtra
in a namespace detail since these classes are only meant to be used by
DeclarationName and DeclarationNameTable. Make this more explicit by making
the members of these classes private and friending DeclarationName(Table).

 2. Make DeclarationName::getFETokenInfo a non-template since every users are
using it to get a void *. It was supposed to be used with a type to avoid
a subsequent static_cast.

 3. Change the internal functions DeclarationName::getAs* to castAs* since when
we use them we already know the correct kind. This has no external impact
since all of these are private.

Reviewed By: erichkeane, rjmccall

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


Modified:
cfe/trunk/include/clang/AST/DeclarationName.h
cfe/trunk/include/clang/Basic/IdentifierTable.h
cfe/trunk/lib/AST/DeclarationName.cpp
cfe/trunk/lib/Basic/IdentifierTable.cpp
cfe/trunk/lib/Sema/IdentifierResolver.cpp
cfe/trunk/lib/Serialization/ASTReader.cpp
cfe/trunk/lib/Serialization/ASTWriter.cpp

Modified: cfe/trunk/include/clang/AST/DeclarationName.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclarationName.h?rev=342729&r1=342728&r2=342729&view=diff
==
--- cfe/trunk/include/clang/AST/DeclarationName.h (original)
+++ cfe/trunk/include/clang/AST/DeclarationName.h Fri Sep 21 05:53:22 2018
@@ -17,6 +17,7 @@
 #include "clang/AST/Type.h"
 #include "clang/Basic/Diagnostic.h"
 #include "clang/Basic/IdentifierTable.h"
+#include "clang/Basic/OperatorKinds.h"
 #include "clang/Basic/PartialDiagnostic.h"
 #include "clang/Basic/SourceLocation.h"
 #include "llvm/ADT/DenseMapInfo.h"
@@ -32,14 +33,9 @@ namespace clang {
 
 class ASTContext;
 template  class CanQual;
-class CXXDeductionGuideNameExtra;
-class CXXLiteralOperatorIdName;
-class CXXOperatorIdName;
-class CXXSpecialName;
-class DeclarationNameExtra;
-class IdentifierInfo;
+class DeclarationName;
+class DeclarationNameTable;
 class MultiKeywordSelector;
-enum OverloadedOperatorKind : int;
 struct PrintingPolicy;
 class TemplateDecl;
 class TypeSourceInfo;
@@ -47,50 +43,185 @@ class UsingDirectiveDecl;
 
 using CanQualType = CanQual;
 
-/// DeclarationName - The name of a declaration. In the common case,
-/// this just stores an IdentifierInfo pointer to a normal
-/// name. However, it also provides encodings for Objective-C
-/// selectors (optimizing zero- and one-argument selectors, which make
-/// up 78% percent of all selectors in Cocoa.h) and special C++ names
-/// for constructors, destructors, and conversion functions.
-class DeclarationName {
+namespace detail {
+
+/// CXXSpecialNameExtra records the type associated with one of the "special"
+/// kinds of declaration names in C++, e.g., constructors, destructors, and
+/// conversion functions. Note that CXXSpecialName is used for C++ constructor,
+/// destructor and conversion functions, but the actual kind is not stored in
+/// CXXSpecialName. Instead we use three different FoldingSet
+/// in DeclarationNameTable.
+class alignas(IdentifierInfoAlignment) CXXSpecialNameExtra

[PATCH] D52267: [AST] Various optimizations + refactoring in DeclarationName(Table)

2018-09-21 Thread Phabricator via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rC342729: [AST] Various optimizations + refactoring in 
DeclarationName(Table) (authored by brunoricci, committed by ).

Repository:
  rC Clang

https://reviews.llvm.org/D52267

Files:
  include/clang/AST/DeclarationName.h
  include/clang/Basic/IdentifierTable.h
  lib/AST/DeclarationName.cpp
  lib/Basic/IdentifierTable.cpp
  lib/Sema/IdentifierResolver.cpp
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTWriter.cpp

Index: include/clang/AST/DeclarationName.h
===
--- include/clang/AST/DeclarationName.h
+++ include/clang/AST/DeclarationName.h
@@ -17,6 +17,7 @@
 #include "clang/AST/Type.h"
 #include "clang/Basic/Diagnostic.h"
 #include "clang/Basic/IdentifierTable.h"
+#include "clang/Basic/OperatorKinds.h"
 #include "clang/Basic/PartialDiagnostic.h"
 #include "clang/Basic/SourceLocation.h"
 #include "llvm/ADT/DenseMapInfo.h"
@@ -32,65 +33,195 @@
 
 class ASTContext;
 template  class CanQual;
-class CXXDeductionGuideNameExtra;
-class CXXLiteralOperatorIdName;
-class CXXOperatorIdName;
-class CXXSpecialName;
-class DeclarationNameExtra;
-class IdentifierInfo;
+class DeclarationName;
+class DeclarationNameTable;
 class MultiKeywordSelector;
-enum OverloadedOperatorKind : int;
 struct PrintingPolicy;
 class TemplateDecl;
 class TypeSourceInfo;
 class UsingDirectiveDecl;
 
 using CanQualType = CanQual;
 
-/// DeclarationName - The name of a declaration. In the common case,
-/// this just stores an IdentifierInfo pointer to a normal
-/// name. However, it also provides encodings for Objective-C
-/// selectors (optimizing zero- and one-argument selectors, which make
-/// up 78% percent of all selectors in Cocoa.h) and special C++ names
-/// for constructors, destructors, and conversion functions.
-class DeclarationName {
+namespace detail {
+
+/// CXXSpecialNameExtra records the type associated with one of the "special"
+/// kinds of declaration names in C++, e.g., constructors, destructors, and
+/// conversion functions. Note that CXXSpecialName is used for C++ constructor,
+/// destructor and conversion functions, but the actual kind is not stored in
+/// CXXSpecialName. Instead we use three different FoldingSet
+/// in DeclarationNameTable.
+class alignas(IdentifierInfoAlignment) CXXSpecialNameExtra
+: public llvm::FoldingSetNode {
+  friend class clang::DeclarationName;
+  friend class clang::DeclarationNameTable;
+
+  /// The type associated with this declaration name.
+  QualType Type;
+
+  /// Extra information associated with this declaration name that
+  /// can be used by the front end. All bits are really needed
+  /// so it is not possible to stash something in the low order bits.
+  void *FETokenInfo;
+
+  CXXSpecialNameExtra(QualType QT) : Type(QT), FETokenInfo(nullptr) {}
+
 public:
-  /// NameKind - The kind of name this object contains.
-  enum NameKind {
-Identifier,
-ObjCZeroArgSelector,
-ObjCOneArgSelector,
-ObjCMultiArgSelector,
-CXXConstructorName,
-CXXDestructorName,
-CXXConversionFunctionName,
-CXXDeductionGuideName,
-CXXOperatorName,
-CXXLiteralOperatorName,
-CXXUsingDirective
-  };
+  void Profile(llvm::FoldingSetNodeID &ID) {
+ID.AddPointer(Type.getAsOpaquePtr());
+  }
+};
 
-  static const unsigned NumNameKinds = CXXUsingDirective + 1;
+/// Contains extra information for the name of a C++ deduction guide.
+class alignas(IdentifierInfoAlignment) CXXDeductionGuideNameExtra
+: public detail::DeclarationNameExtra,
+  public llvm::FoldingSetNode {
+  friend class clang::DeclarationName;
+  friend class clang::DeclarationNameTable;
 
-private:
+  /// The template named by the deduction guide.
+  TemplateDecl *Template;
+
+  /// Extra information associated with this operator name that
+  /// can be used by the front end. All bits are really needed
+  /// so it is not possible to stash something in the low order bits.
+  void *FETokenInfo;
+
+  CXXDeductionGuideNameExtra(TemplateDecl *TD)
+  : DeclarationNameExtra(CXXDeductionGuideName), Template(TD),
+FETokenInfo(nullptr) {}
+
+public:
+  void Profile(llvm::FoldingSetNodeID &ID) { ID.AddPointer(Template); }
+};
+
+/// Contains extra information for the name of an overloaded operator
+/// in C++, such as "operator+. This do not includes literal or conversion
+/// operators. For literal operators see CXXLiteralOperatorIdName and for
+/// conversion operators see CXXSpecialNameExtra.
+class alignas(IdentifierInfoAlignment) CXXOperatorIdName {
+  friend class clang::DeclarationName;
+  friend class clang::DeclarationNameTable;
+
+  /// The kind of this operator.
+  OverloadedOperatorKind Kind = OO_None;
+
+  /// Extra information associated with this operator name that
+  /// can be used by the front end. All bits are really needed
+  /// so it is not possible to stash something in the low order bits.
+  void *FEToken

[PATCH] D52259: [CUDA] Rearrange search path ordering to fix two test case failures

2018-09-21 Thread Jonas Hahnfeld via Phabricator via cfe-commits
Hahnfeld added a comment.

IMO the current logic makes sense for the end user, prioritizing the 
environment guess over default paths. I think the tests should be fixed using 
`--cuda-path-ignore-env`, I remember I added this parameter to fix the failing 
tests when I wrote the code.


Repository:
  rC Clang

https://reviews.llvm.org/D52259



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


[clang-tools-extra] r342730 - [clangd] Remember to serialize symbol origin in YAML.

2018-09-21 Thread Eric Liu via cfe-commits
Author: ioeric
Date: Fri Sep 21 06:04:57 2018
New Revision: 342730

URL: http://llvm.org/viewvc/llvm-project?rev=342730&view=rev
Log:
[clangd] Remember to serialize symbol origin in YAML.

Modified:
clang-tools-extra/trunk/clangd/index/SymbolYAML.cpp
clang-tools-extra/trunk/unittests/clangd/SerializationTests.cpp

Modified: clang-tools-extra/trunk/clangd/index/SymbolYAML.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/index/SymbolYAML.cpp?rev=342730&r1=342729&r2=342730&view=diff
==
--- clang-tools-extra/trunk/clangd/index/SymbolYAML.cpp (original)
+++ clang-tools-extra/trunk/clangd/index/SymbolYAML.cpp Fri Sep 21 06:04:57 2018
@@ -27,6 +27,7 @@ namespace yaml {
 
 using clang::clangd::Symbol;
 using clang::clangd::SymbolID;
+using clang::clangd::SymbolOrigin;
 using clang::clangd::SymbolLocation;
 using clang::index::SymbolInfo;
 using clang::index::SymbolKind;
@@ -65,6 +66,17 @@ struct NormalizedSymbolFlag {
   uint8_t Flag = 0;
 };
 
+struct NormalizedSymbolOrigin {
+  NormalizedSymbolOrigin(IO &) {}
+  NormalizedSymbolOrigin(IO &, SymbolOrigin O) {
+Origin = static_cast(O);
+  }
+
+  SymbolOrigin denormalize(IO &) { return static_cast(Origin); }
+
+  uint8_t Origin = 0;
+};
+
 template <> struct MappingTraits {
   static void mapping(IO &IO, SymbolLocation::Position &Value) {
 IO.mapRequired("Line", Value.Line);
@@ -102,6 +114,8 @@ template <> struct MappingTraits
 MappingNormalization NSymbolID(IO, Sym.ID);
 MappingNormalization NSymbolFlag(
 IO, Sym.Flags);
+MappingNormalization NSymbolOrigin(
+IO, Sym.Origin);
 IO.mapRequired("ID", NSymbolID->HexString);
 IO.mapRequired("Name", Sym.Name);
 IO.mapRequired("Scope", Sym.Scope);
@@ -110,6 +124,7 @@ template <> struct MappingTraits
SymbolLocation());
 IO.mapOptional("Definition", Sym.Definition, SymbolLocation());
 IO.mapOptional("References", Sym.References, 0u);
+IO.mapOptional("Origin", NSymbolOrigin->Origin);
 IO.mapOptional("Flags", NSymbolFlag->Flag);
 IO.mapOptional("Signature", Sym.Signature);
 IO.mapOptional("CompletionSnippetSuffix", Sym.CompletionSnippetSuffix);

Modified: clang-tools-extra/trunk/unittests/clangd/SerializationTests.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/clangd/SerializationTests.cpp?rev=342730&r1=342729&r2=342730&view=diff
==
--- clang-tools-extra/trunk/unittests/clangd/SerializationTests.cpp (original)
+++ clang-tools-extra/trunk/unittests/clangd/SerializationTests.cpp Fri Sep 21 
06:04:57 2018
@@ -7,6 +7,7 @@
 //
 
//===--===//
 
+#include "index/Index.h"
 #include "index/Serialization.h"
 #include "index/SymbolYAML.h"
 #include "llvm/Support/ScopedPrinter.h"
@@ -35,6 +36,7 @@ CanonicalDeclaration:
   End:
 Line: 1
 Column: 1
+Origin:4
 Flags:1
 Documentation:'Foo doc'
 ReturnType:'int'
@@ -82,6 +84,7 @@ TEST(SerializationTest, YAMLConversions)
   EXPECT_EQ(Sym1.Documentation, "Foo doc");
   EXPECT_EQ(Sym1.ReturnType, "int");
   EXPECT_EQ(Sym1.CanonicalDeclaration.FileURI, "file:///path/foo.h");
+  EXPECT_EQ(Sym1.Origin, SymbolOrigin::Static);
   EXPECT_TRUE(Sym1.Flags & Symbol::IndexedForCodeCompletion);
   EXPECT_FALSE(Sym1.Flags & Symbol::Deprecated);
   EXPECT_THAT(Sym1.IncludeHeaders,


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


r342731 - [AST][NFC] Remove a superfluous enum in ObjCMethodDeclBitfields added in r338641

2018-09-21 Thread Bruno Ricci via cfe-commits
Author: brunoricci
Date: Fri Sep 21 06:11:39 2018
New Revision: 342731

URL: http://llvm.org/viewvc/llvm-project?rev=342731&view=rev
Log:
[AST][NFC] Remove a superfluous enum in ObjCMethodDeclBitfields added in r338641

I originally added this enum to avoid including Basic/IdentifierTable.h
in AST/DeclBase.h. However I did not realise it is already included
transitively by AST/DeclarationName.h. Therefore remove this enum and
explicitly include Basic/IdentifierTable.h


Modified:
cfe/trunk/include/clang/AST/DeclBase.h

Modified: cfe/trunk/include/clang/AST/DeclBase.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclBase.h?rev=342731&r1=342730&r2=342731&view=diff
==
--- cfe/trunk/include/clang/AST/DeclBase.h (original)
+++ cfe/trunk/include/clang/AST/DeclBase.h Fri Sep 21 06:11:39 2018
@@ -16,6 +16,7 @@
 
 #include "clang/AST/AttrIterator.h"
 #include "clang/AST/DeclarationName.h"
+#include "clang/Basic/IdentifierTable.h"
 #include "clang/Basic/LLVM.h"
 #include "clang/Basic/SourceLocation.h"
 #include "clang/Basic/Specifiers.h"
@@ -1558,13 +1559,6 @@ class DeclContext {
   class ObjCMethodDeclBitfields {
 friend class ObjCMethodDecl;
 
-/// This is needed for the bitwidth of Family below but
-/// is defined in Basic/IdentifierTable.h which we do not include.
-/// To avoid mismatches between the two definitions we have
-/// a static_assert in the ctor of ObjCMethodDecl which checks
-/// that these two ObjCMethodFamilyBitWidth are equal.
-enum { ObjCMethodFamilyBitWidth = 4 };
-
 /// For the bits in DeclContextBitfields.
 uint64_t : NumDeclContextBits;
 


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


[PATCH] D52047: [clangd] Add building benchmark and memory consumption tracking

2018-09-21 Thread Kirill Bobyrev via Phabricator via cfe-commits
kbobyrev added inline comments.



Comment at: clang-tools-extra/clangd/benchmarks/IndexBenchmark.cpp:81
+// Same for the next "benchmark".
+// FIXME(kbobyrev): Should this be separated into the BackingMemorySize
+// (underlying SymbolSlab size) and Symbol Index (MemIndex/Dex) overhead?

ilya-biryukov wrote:
> Given the trick we use for display, how are we going to show **two** memory 
> uses?
As discussed offline, this hack also relies on the fact that benchmark has a 
dynamic nature of determining iterations count. Giving a large number of "time 
units" to the  counter results in a single iteration.

I've tried to understand whether I could use any flags for [[ 
https://github.com/google/benchmark#user-defined-counters | User-Defined 
Counter ]] that could just divide the number of iterations by `IterationTime`, 
but I could find one that would do exactly what is needed here. Also, I didn't 
find any way to manually set the iteration count.



Comment at: clang-tools-extra/clangd/index/dex/Dex.cpp:239
   for (const auto &P : InvertedIndex)
-Bytes += P.second.bytes();
+Bytes += P.first.Data.size() + P.second.bytes();
   return Bytes + BackingDataSize;

ilya-biryukov wrote:
> Just to clarify: `P.first.Data.size()` is the size of the arena for all the 
> symbols?
`P` is `std::pair` here, so that would be 
`Token.Data.size()` which is the size of `std::string` stored in Token (e.g. 
trigram symbols for `Trigram` tokens, directory URI for `ProximityPath` tokens, 
etc). `P` is probably bad here, I'll change the naming to be more explicit.


https://reviews.llvm.org/D52047



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


[PATCH] D52357: [clangd] Force Dex to respect symbol collector flags

2018-09-21 Thread Kirill Bobyrev via Phabricator via cfe-commits
kbobyrev created this revision.
kbobyrev added a reviewer: ioeric.
kbobyrev added a project: clang-tools-extra.
Herald added subscribers: kadircet, arphaman, jkorous, MaskRay.

`Dex` should utilize `FuzzyFindRequest.RestrictForCodeCompletion` flags and 
omit symbols not meant for code completion when asked for it.

Results show that the average query time did not change significantly. 
Although, it might be faster/cleaner to have a single token and implement `NOT` 
iterator to append it on top smaller posting list.

|| 
Before, ns | After, ns | Relative difference |
| -- | 
-- | - | --- |
| Cumulative query latency (7000 `FuzzyFindRequest`s over LLVM static index) | 
7270930798  | 7282297568 | +0.0015 |


https://reviews.llvm.org/D52357

Files:
  clang-tools-extra/clangd/index/dex/Dex.cpp
  clang-tools-extra/unittests/clangd/DexTests.cpp


Index: clang-tools-extra/unittests/clangd/DexTests.cpp
===
--- clang-tools-extra/unittests/clangd/DexTests.cpp
+++ clang-tools-extra/unittests/clangd/DexTests.cpp
@@ -583,6 +583,23 @@
   EXPECT_THAT(lookup(*I, SymbolID("ns::nonono")), UnorderedElementsAre());
 }
 
+TEST(DexTest, SymbolIndexOptionsFilter) {
+  auto CodeCompletionSymbol = symbol("Completion");
+  auto NonCodeCompletionSymbol = symbol("NoCompletion");
+  std::vector Symbols{CodeCompletionSymbol, NonCodeCompletionSymbol};
+  Dex I(Symbols, URISchemes);
+  FuzzyFindRequest Req;
+  EXPECT_THAT(match(I, Req), ElementsAre("Completion", "NoCompletion"));
+  CodeCompletionSymbol.Flags = Symbol::SymbolFlag::IndexedForCodeCompletion;
+  NonCodeCompletionSymbol.Flags = Symbol::SymbolFlag::None;
+  Symbols = {CodeCompletionSymbol, NonCodeCompletionSymbol};
+  I = Dex(Symbols, URISchemes);
+  Req.RestrictForCodeCompletion = true;
+  EXPECT_THAT(match(I, Req), ElementsAre("Completion"));
+  Req.RestrictForCodeCompletion = false;
+  EXPECT_THAT(match(I, Req), ElementsAre("NoCompletion"));
+}
+
 TEST(DexTest, ProximityPathsBoosting) {
   auto RootSymbol = symbol("root::abc");
   RootSymbol.CanonicalDeclaration.FileURI = "unittest:///file.h";
Index: clang-tools-extra/clangd/index/dex/Dex.cpp
===
--- clang-tools-extra/clangd/index/dex/Dex.cpp
+++ clang-tools-extra/clangd/index/dex/Dex.cpp
@@ -22,6 +22,11 @@
 
 namespace {
 
+static const Token RestrictedForCodeCompletion =
+Token(Token::Kind::Sentinel, "Restricted For Code Completion");
+static const Token NotRestrictedForCodeCompletion =
+Token(Token::Kind::Sentinel, "Not Restricted For Code Completion");
+
 // Returns the tokens which are given symbol's characteristics. Currently, the
 // generated tokens only contain fuzzy matching trigrams and symbol's scope,
 // but in the future this will also return path proximity tokens and other
@@ -39,6 +44,9 @@
 for (const auto &ProximityURI :
  generateProximityURIs(Sym.CanonicalDeclaration.FileURI))
   Result.emplace_back(Token::Kind::ProximityURI, ProximityURI);
+  Result.emplace_back(Sym.Flags & Symbol::IndexedForCodeCompletion
+  ? RestrictedForCodeCompletion
+  : NotRestrictedForCodeCompletion);
   return Result;
 }
 
@@ -119,7 +127,6 @@
 for (const auto &Token : generateSearchTokens(*Sym))
   TempInvertedIndex[Token].push_back(SymbolRank);
   }
-
   // Convert lists of items to posting lists.
   for (const auto &TokenToPostingList : TempInvertedIndex)
 InvertedIndex.insert({TokenToPostingList.first,
@@ -175,6 +182,13 @@
 TopLevelChildren.push_back(createOr(move(BoostingIterators)));
   }
 
+  // Filter symbols which are (not) indexed for code completion.
+  TopLevelChildren.push_back(InvertedIndex
+ .find(Req.RestrictForCodeCompletion
+   ? RestrictedForCodeCompletion
+   : NotRestrictedForCodeCompletion)
+ ->second.iterator());
+
   // Use TRUE iterator if both trigrams and scopes from the query are not
   // present in the symbol index.
   auto QueryIterator = TopLevelChildren.empty()


Index: clang-tools-extra/unittests/clangd/DexTests.cpp
===
--- clang-tools-extra/unittests/clangd/DexTests.cpp
+++ clang-tools-extra/unittests/clangd/DexTests.cpp
@@ -583,6 +583,23 @@
   EXPECT_THAT(lookup(*I, SymbolID("ns::nonono")), UnorderedElementsAre());
 }
 
+TEST(DexTest, SymbolIndexOptionsFilter) {
+  auto CodeCompletionSymbol = symbol("Completion");
+  auto NonCodeCompletionSymbol = symbol("NoCompletion");
+  std::vector Symbols{CodeCompletionSymbol, NonCodeCompletionSymbol};
+  Dex I(Symbols, URISchemes);
+  

[PATCH] D52357: [clangd] Force Dex to respect symbol collector flags

2018-09-21 Thread Eric Liu via Phabricator via cfe-commits
ioeric added inline comments.



Comment at: clang-tools-extra/clangd/index/dex/Dex.cpp:27
+Token(Token::Kind::Sentinel, "Restricted For Code Completion");
+static const Token NotRestrictedForCodeCompletion =
+Token(Token::Kind::Sentinel, "Not Restricted For Code Completion");

Why do we need `NotRestrictedForCodeCompletion` token? If 
`RestrictedForCodeCompletion` is false, all symbols can match.


https://reviews.llvm.org/D52357



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


[PATCH] D52047: [clangd] Add building benchmark and memory consumption tracking

2018-09-21 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added inline comments.



Comment at: clang-tools-extra/clangd/benchmarks/IndexBenchmark.cpp:81
+// Same for the next "benchmark".
+// FIXME(kbobyrev): Should this be separated into the BackingMemorySize
+// (underlying SymbolSlab size) and Symbol Index (MemIndex/Dex) overhead?

kbobyrev wrote:
> ilya-biryukov wrote:
> > Given the trick we use for display, how are we going to show **two** memory 
> > uses?
> As discussed offline, this hack also relies on the fact that benchmark has a 
> dynamic nature of determining iterations count. Giving a large number of 
> "time units" to the  counter results in a single iteration.
> 
> I've tried to understand whether I could use any flags for [[ 
> https://github.com/google/benchmark#user-defined-counters | User-Defined 
> Counter ]] that could just divide the number of iterations by 
> `IterationTime`, but I could find one that would do exactly what is needed 
> here. Also, I didn't find any way to manually set the iteration count.
> divide the number of iterations by IterationTime
And more unsolicited advices:
[[ 
https://github.com/google/benchmark/blob/1b44120cd16712f3b5decd95dc8ff2813574b273/include/benchmark/benchmark.h#L366-L368
 | `kIsIterationInvariantRate` ]], but it is master-only, not in any release.
For now, do
```
State.counters["kIsIterationInvariantRate"] = benchmark::Counter(
state.iterations(),

benchmark::Counter::Flags::kIsRate);
```
If understood the question right.

> Also, I didn't find any way to manually set the iteration count.
[[ 
https://github.com/google/benchmark/blob/1b44120cd16712f3b5decd95dc8ff2813574b273/include/benchmark/benchmark.h#L853-L859
 | `benchmark::Benchmark::Iterations()` ]]



https://reviews.llvm.org/D52047



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


[PATCH] D52359: [OPENMP] Add support for OMP5 requires directive + unified_address clause

2018-09-21 Thread Patrick Lyster via Phabricator via cfe-commits
patricklyster created this revision.
patricklyster added reviewers: ABataev, Hahnfeld, RaviNarayanaswamy, mikerice, 
kkwli0, hfinkel, gtbercea.
patricklyster added projects: clang, OpenMP.
Herald added subscribers: cfe-commits, jfb, guansong, jholewinski.

Add support for new OMP5.0 `requires` directive and `unified_address` clause. 
Patches to follow will include support for additional clauses.


Repository:
  rC Clang

https://reviews.llvm.org/D52359

Files:
  clang/include/clang/AST/DeclOpenMP.h
  clang/include/clang/AST/OpenMPClause.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/Basic/DeclNodes.td
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/OpenMPKinds.def
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/lib/AST/ASTDumper.cpp
  clang/lib/AST/DeclBase.cpp
  clang/lib/AST/DeclOpenMP.cpp
  clang/lib/AST/DeclPrinter.cpp
  clang/lib/AST/OpenMPClause.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/AST/StmtProfile.cpp
  clang/lib/Basic/OpenMPKinds.cpp
  clang/lib/CodeGen/CGDecl.cpp
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenModule.h
  clang/lib/Parse/ParseOpenMP.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTCommon.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/test/OpenMP/requires_unified_address_ast_print.cpp
  clang/test/OpenMP/requires_unified_address_messages.cpp
  clang/tools/libclang/CIndex.cpp

Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -2207,6 +2207,9 @@
 
 void OMPClauseEnqueue::VisitOMPNogroupClause(const OMPNogroupClause *) {}
 
+void OMPClauseEnqueue::VisitOMPUnifiedAddressClause(
+const OMPUnifiedAddressClause *) {}
+
 void OMPClauseEnqueue::VisitOMPDeviceClause(const OMPDeviceClause *C) {
   Visitor->AddStmt(C->getDevice());
 }
@@ -6220,6 +6223,7 @@
   case Decl::Import:
   case Decl::OMPThreadPrivate:
   case Decl::OMPDeclareReduction:
+  case Decl::OMPRequires:
   case Decl::ObjCTypeParam:
   case Decl::BuiltinTemplate:
   case Decl::PragmaComment:
Index: clang/test/OpenMP/requires_unified_address_messages.cpp
===
--- /dev/null
+++ clang/test/OpenMP/requires_unified_address_messages.cpp
@@ -0,0 +1,36 @@
+// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100  %s
+
+#pragma omp requires unified_address // expected-note {{unified_address clause previously used here}} expected-note {{unified_address clause previously used here}} expected-note {{unified_address clause previously used here}} expected-note {{unified_address clause previously used here}} expected-note {{unified_address clause previously used here}}
+
+#pragma omp requires unified_address // expected-error {{Only one unified_address clause can appear on a requires directive in a single translation unit}} 
+
+#pragma omp requires unified_address, unified_address // expected-error {{Only one unified_address clause can appear on a requires directive in a single translation unit}} expected-error {{directive '#pragma omp requires' cannot contain more than one 'unified_address' clause}}
+
+#pragma omp requires // expected-error {{expected at least one clause on '#pragma omp requires' directive}}
+
+#pragma omp requires invalid_clause // expected-warning {{extra tokens at the end of '#pragma omp requires' are ignored}} expected-error {{expected at least one clause on '#pragma omp requires' directive}}
+
+#pragma omp requires nowait // expected-error {{unexpected OpenMP clause 'nowait' in directive '#pragma omp requires'}} expected-error {{expected at least one clause on '#pragma omp requires' directive}}
+
+#pragma omp requires unified_address, invalid_clause // expected-warning {{extra tokens at the end of '#pragma omp requires' are ignored}} expected-error {{Only one unified_address clause can appear on a requires directive in a single translation unit}}
+
+#pragma omp requires invalid_clause unified_address // expected-warning {{extra tokens at the end of '#pragma omp requires' are ignored}} expected-error {{expected at least one clause on '#pragma omp requires' directive}}
+
+namespace A {
+  #pragma omp requires unified_address // expected-error {{Only one unified_address clause can appear on a requires directive in a single translation unit}}
+  namespace B {
+#pragma omp requires unified_address // expected-error {{Only one unified_address clause can appear on a requires directive in a single translation u

r342734 - NFC: deduplicate isRepeatedBytePattern from clang to LLVM's isBytewiseValue

2018-09-21 Thread JF Bastien via cfe-commits
Author: jfb
Date: Fri Sep 21 06:54:09 2018
New Revision: 342734

URL: http://llvm.org/viewvc/llvm-project?rev=342734&view=rev
Log:
NFC: deduplicate isRepeatedBytePattern from clang to LLVM's isBytewiseValue

Summary:
This code was in CGDecl.cpp and really belongs in LLVM. It happened to have 
isBytewiseValue which served a very similar purpose but wasn't as powerful as 
clang's version. Remove the clang version, and augment isBytewiseValue to be as 
powerful so that clang does the same thing it used to.

LLVM part of this patch: D51751

Subscribers: dexonsmith, cfe-commits

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

Modified:
cfe/trunk/lib/CodeGen/CGDecl.cpp

Modified: cfe/trunk/lib/CodeGen/CGDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDecl.cpp?rev=342734&r1=342733&r2=342734&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDecl.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDecl.cpp Fri Sep 21 06:54:09 2018
@@ -30,6 +30,7 @@
 #include "clang/Basic/TargetInfo.h"
 #include "clang/CodeGen/CGFunctionInfo.h"
 #include "clang/Frontend/CodeGenOptions.h"
+#include "llvm/Analysis/ValueTracking.h"
 #include "llvm/IR/DataLayout.h"
 #include "llvm/IR/GlobalVariable.h"
 #include "llvm/IR/Intrinsics.h"
@@ -948,111 +949,17 @@ static bool shouldUseBZeroPlusStoresToIn
  canEmitInitWithFewStoresAfterBZero(Init, StoreBudget);
 }
 
-/// A byte pattern.
-///
-/// Can be "any" pattern if the value was padding or known to be undef.
-/// Can be "none" pattern if a sequence doesn't exist.
-class BytePattern {
-  uint8_t Val;
-  enum class ValueType : uint8_t { Specific, Any, None } Type;
-  BytePattern(ValueType Type) : Type(Type) {}
-
-public:
-  BytePattern(uint8_t Value) : Val(Value), Type(ValueType::Specific) {}
-  static BytePattern Any() { return BytePattern(ValueType::Any); }
-  static BytePattern None() { return BytePattern(ValueType::None); }
-  bool isAny() const { return Type == ValueType::Any; }
-  bool isNone() const { return Type == ValueType::None; }
-  bool isValued() const { return Type == ValueType::Specific; }
-  uint8_t getValue() const {
-assert(isValued());
-return Val;
-  }
-  BytePattern merge(const BytePattern Other) const {
-if (isNone() || Other.isNone())
-  return None();
-if (isAny())
-  return Other;
-if (Other.isAny())
-  return *this;
-if (getValue() == Other.getValue())
-  return *this;
-return None();
-  }
-};
-
-/// Figures out whether the constant can be initialized with memset.
-static BytePattern constantIsRepeatedBytePattern(llvm::Constant *C) {
-  if (isa(C) || isa(C))
-return BytePattern(0x00);
-  if (isa(C))
-return BytePattern::Any();
-
-  if (isa(C)) {
-auto *Int = cast(C);
-if (Int->getBitWidth() % 8 != 0)
-  return BytePattern::None();
-const llvm::APInt &Value = Int->getValue();
-if (Value.isSplat(8))
-  return BytePattern(Value.getLoBits(8).getLimitedValue());
-return BytePattern::None();
-  }
-
-  if (isa(C)) {
-auto *FP = cast(C);
-llvm::APInt Bits = FP->getValueAPF().bitcastToAPInt();
-if (Bits.getBitWidth() % 8 != 0)
-  return BytePattern::None();
-if (!Bits.isSplat(8))
-  return BytePattern::None();
-return BytePattern(Bits.getLimitedValue() & 0xFF);
-  }
-
-  if (isa(C)) {
-llvm::Constant *Splat = cast(C)->getSplatValue();
-if (Splat)
-  return constantIsRepeatedBytePattern(Splat);
-return BytePattern::None();
-  }
-
-  if (isa(C) || isa(C)) {
-BytePattern Pattern(BytePattern::Any());
-for (unsigned I = 0, E = C->getNumOperands(); I != E; ++I) {
-  llvm::Constant *Elt = cast(C->getOperand(I));
-  Pattern = Pattern.merge(constantIsRepeatedBytePattern(Elt));
-  if (Pattern.isNone())
-return Pattern;
-}
-return Pattern;
-  }
-
-  if (llvm::ConstantDataSequential *CDS =
-  dyn_cast(C)) {
-BytePattern Pattern(BytePattern::Any());
-for (unsigned I = 0, E = CDS->getNumElements(); I != E; ++I) {
-  llvm::Constant *Elt = CDS->getElementAsConstant(I);
-  Pattern = Pattern.merge(constantIsRepeatedBytePattern(Elt));
-  if (Pattern.isNone())
-return Pattern;
-}
-return Pattern;
-  }
-
-  // BlockAddress, ConstantExpr, and everything else is scary.
-  return BytePattern::None();
-}
-
 /// Decide whether we should use memset to initialize a local variable instead
 /// of using a memcpy from a constant global. Assumes we've already decided to
 /// not user bzero.
 /// FIXME We could be more clever, as we are for bzero above, and generate
 ///   memset followed by stores. It's unclear that's worth the effort.
-static BytePattern shouldUseMemSetToInitialize(llvm::Constant *Init,
-   uint64_t GlobalSize) {
+static llvm::Value *shouldUseMemSetToInitialize(llvm::Constant *Init,
+uint64_

[PATCH] D51752: NFC: deduplicate isRepeatedBytePattern from clang to LLVM's isBytewiseValue

2018-09-21 Thread JF Bastien via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL342734: NFC: deduplicate isRepeatedBytePattern from clang to 
LLVM's isBytewiseValue (authored by jfb, committed by ).
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

https://reviews.llvm.org/D51752

Files:
  cfe/trunk/lib/CodeGen/CGDecl.cpp

Index: cfe/trunk/lib/CodeGen/CGDecl.cpp
===
--- cfe/trunk/lib/CodeGen/CGDecl.cpp
+++ cfe/trunk/lib/CodeGen/CGDecl.cpp
@@ -30,6 +30,7 @@
 #include "clang/Basic/TargetInfo.h"
 #include "clang/CodeGen/CGFunctionInfo.h"
 #include "clang/Frontend/CodeGenOptions.h"
+#include "llvm/Analysis/ValueTracking.h"
 #include "llvm/IR/DataLayout.h"
 #include "llvm/IR/GlobalVariable.h"
 #include "llvm/IR/Intrinsics.h"
@@ -948,111 +949,17 @@
  canEmitInitWithFewStoresAfterBZero(Init, StoreBudget);
 }
 
-/// A byte pattern.
-///
-/// Can be "any" pattern if the value was padding or known to be undef.
-/// Can be "none" pattern if a sequence doesn't exist.
-class BytePattern {
-  uint8_t Val;
-  enum class ValueType : uint8_t { Specific, Any, None } Type;
-  BytePattern(ValueType Type) : Type(Type) {}
-
-public:
-  BytePattern(uint8_t Value) : Val(Value), Type(ValueType::Specific) {}
-  static BytePattern Any() { return BytePattern(ValueType::Any); }
-  static BytePattern None() { return BytePattern(ValueType::None); }
-  bool isAny() const { return Type == ValueType::Any; }
-  bool isNone() const { return Type == ValueType::None; }
-  bool isValued() const { return Type == ValueType::Specific; }
-  uint8_t getValue() const {
-assert(isValued());
-return Val;
-  }
-  BytePattern merge(const BytePattern Other) const {
-if (isNone() || Other.isNone())
-  return None();
-if (isAny())
-  return Other;
-if (Other.isAny())
-  return *this;
-if (getValue() == Other.getValue())
-  return *this;
-return None();
-  }
-};
-
-/// Figures out whether the constant can be initialized with memset.
-static BytePattern constantIsRepeatedBytePattern(llvm::Constant *C) {
-  if (isa(C) || isa(C))
-return BytePattern(0x00);
-  if (isa(C))
-return BytePattern::Any();
-
-  if (isa(C)) {
-auto *Int = cast(C);
-if (Int->getBitWidth() % 8 != 0)
-  return BytePattern::None();
-const llvm::APInt &Value = Int->getValue();
-if (Value.isSplat(8))
-  return BytePattern(Value.getLoBits(8).getLimitedValue());
-return BytePattern::None();
-  }
-
-  if (isa(C)) {
-auto *FP = cast(C);
-llvm::APInt Bits = FP->getValueAPF().bitcastToAPInt();
-if (Bits.getBitWidth() % 8 != 0)
-  return BytePattern::None();
-if (!Bits.isSplat(8))
-  return BytePattern::None();
-return BytePattern(Bits.getLimitedValue() & 0xFF);
-  }
-
-  if (isa(C)) {
-llvm::Constant *Splat = cast(C)->getSplatValue();
-if (Splat)
-  return constantIsRepeatedBytePattern(Splat);
-return BytePattern::None();
-  }
-
-  if (isa(C) || isa(C)) {
-BytePattern Pattern(BytePattern::Any());
-for (unsigned I = 0, E = C->getNumOperands(); I != E; ++I) {
-  llvm::Constant *Elt = cast(C->getOperand(I));
-  Pattern = Pattern.merge(constantIsRepeatedBytePattern(Elt));
-  if (Pattern.isNone())
-return Pattern;
-}
-return Pattern;
-  }
-
-  if (llvm::ConstantDataSequential *CDS =
-  dyn_cast(C)) {
-BytePattern Pattern(BytePattern::Any());
-for (unsigned I = 0, E = CDS->getNumElements(); I != E; ++I) {
-  llvm::Constant *Elt = CDS->getElementAsConstant(I);
-  Pattern = Pattern.merge(constantIsRepeatedBytePattern(Elt));
-  if (Pattern.isNone())
-return Pattern;
-}
-return Pattern;
-  }
-
-  // BlockAddress, ConstantExpr, and everything else is scary.
-  return BytePattern::None();
-}
-
 /// Decide whether we should use memset to initialize a local variable instead
 /// of using a memcpy from a constant global. Assumes we've already decided to
 /// not user bzero.
 /// FIXME We could be more clever, as we are for bzero above, and generate
 ///   memset followed by stores. It's unclear that's worth the effort.
-static BytePattern shouldUseMemSetToInitialize(llvm::Constant *Init,
-   uint64_t GlobalSize) {
+static llvm::Value *shouldUseMemSetToInitialize(llvm::Constant *Init,
+uint64_t GlobalSize) {
   uint64_t SizeLimit = 32;
   if (GlobalSize <= SizeLimit)
-return BytePattern::None();
-  return constantIsRepeatedBytePattern(Init);
+return nullptr;
+  return llvm::isBytewiseValue(Init);
 }
 
 static void emitStoresForConstant(CodeGenModule &CGM, const VarDecl &D,
@@ -1081,9 +988,14 @@
 return;
   }
 
-  BytePattern Pattern = shouldUseMemSetToInitialize(constant, ConstantSize);
-  if (!Pattern.isNone()) {
-uint8_t Value = Pattern.isAny() ? 0x00 : Pattern.getValue();
+  llvm::Value *Pattern = shoul

[PATCH] D52359: [OPENMP] Add support for OMP5 requires directive + unified_address clause

2018-09-21 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev accepted this revision.
ABataev added a comment.
This revision is now accepted and ready to land.

LG


Repository:
  rC Clang

https://reviews.llvm.org/D52359



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


r342735 - [AST][NFC] DeclarationName.h : add missing parentheses to silence warnings

2018-09-21 Thread Bruno Ricci via cfe-commits
Author: brunoricci
Date: Fri Sep 21 07:03:32 2018
New Revision: 342735

URL: http://llvm.org/viewvc/llvm-project?rev=342735&view=rev
Log:
[AST][NFC] DeclarationName.h : add missing parentheses to silence warnings

Some bots are complaining about missing parentheses in assertions added in
r342729: [AST] Various optimizations + refactoring in DeclarationName(Table)


Modified:
cfe/trunk/include/clang/AST/DeclarationName.h

Modified: cfe/trunk/include/clang/AST/DeclarationName.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclarationName.h?rev=342735&r1=342734&r2=342735&view=diff
==
--- cfe/trunk/include/clang/AST/DeclarationName.h (original)
+++ cfe/trunk/include/clang/AST/DeclarationName.h Fri Sep 21 07:03:32 2018
@@ -277,9 +277,9 @@ private:
   /// Construct a declaration name from a CXXSpecialNameExtra.
   DeclarationName(detail::CXXSpecialNameExtra *Name,
   StoredNameKind StoredKind) {
-assert(StoredKind == StoredCXXConstructorName ||
+assert((StoredKind == StoredCXXConstructorName ||
StoredKind == StoredCXXDestructorName ||
-   StoredKind == StoredCXXConversionFunctionName &&
+   StoredKind == StoredCXXConversionFunctionName) &&
"Invalid StoredNameKind when constructing a DeclarationName"
" from a CXXSpecialNameExtra!");
 setPtrAndKind(Name, StoredKind);
@@ -308,9 +308,9 @@ private:
   /// Assert that the stored pointer points to a CXXSpecialNameExtra
   /// and return it.
   detail::CXXSpecialNameExtra *castAsCXXSpecialNameExtra() const {
-assert(getStoredNameKind() == StoredCXXConstructorName ||
+assert((getStoredNameKind() == StoredCXXConstructorName ||
getStoredNameKind() == StoredCXXDestructorName ||
-   getStoredNameKind() == StoredCXXConversionFunctionName &&
+   getStoredNameKind() == StoredCXXConversionFunctionName) &&
"DeclarationName does not store a CXXSpecialNameExtra!");
 return static_cast(getPtr());
   }
@@ -318,7 +318,7 @@ private:
   /// Assert that the stored pointer points to a CXXOperatorIdName
   /// and return it.
   detail::CXXOperatorIdName *castAsCXXOperatorIdName() const {
-assert(getStoredNameKind() == StoredCXXOperatorName &&
+assert((getStoredNameKind() == StoredCXXOperatorName) &&
"DeclarationName does not store a CXXOperatorIdName!");
 return static_cast(getPtr());
   }


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


[PATCH] D52357: [clangd] Force Dex to respect symbol collector flags

2018-09-21 Thread Kirill Bobyrev via Phabricator via cfe-commits
kbobyrev updated this revision to Diff 166474.
kbobyrev marked an inline comment as done.
kbobyrev edited the summary of this revision.
kbobyrev added a comment.

`RestirctForCodeCompletion` and `!RestrictForCodeCompletion` are not mutually 
exclusive.


https://reviews.llvm.org/D52357

Files:
  clang-tools-extra/clangd/index/dex/Dex.cpp
  clang-tools-extra/unittests/clangd/DexTests.cpp


Index: clang-tools-extra/unittests/clangd/DexTests.cpp
===
--- clang-tools-extra/unittests/clangd/DexTests.cpp
+++ clang-tools-extra/unittests/clangd/DexTests.cpp
@@ -583,6 +583,22 @@
   EXPECT_THAT(lookup(*I, SymbolID("ns::nonono")), UnorderedElementsAre());
 }
 
+TEST(DexTest, SymbolIndexOptionsFilter) {
+  auto CodeCompletionSymbol = symbol("Completion");
+  auto NonCodeCompletionSymbol = symbol("NoCompletion");
+  std::vector Symbols{CodeCompletionSymbol, NonCodeCompletionSymbol};
+  Dex I(Symbols, URISchemes);
+  FuzzyFindRequest Req;
+  Req.RestrictForCodeCompletion = false;
+  EXPECT_THAT(match(I, Req), ElementsAre("Completion", "NoCompletion"));
+  CodeCompletionSymbol.Flags = Symbol::SymbolFlag::IndexedForCodeCompletion;
+  NonCodeCompletionSymbol.Flags = Symbol::SymbolFlag::None;
+  Symbols = {CodeCompletionSymbol, NonCodeCompletionSymbol};
+  I = Dex(Symbols, URISchemes);
+  Req.RestrictForCodeCompletion = true;
+  EXPECT_THAT(match(I, Req), ElementsAre("Completion"));
+}
+
 TEST(DexTest, ProximityPathsBoosting) {
   auto RootSymbol = symbol("root::abc");
   RootSymbol.CanonicalDeclaration.FileURI = "unittest:///file.h";
Index: clang-tools-extra/clangd/index/dex/Dex.cpp
===
--- clang-tools-extra/clangd/index/dex/Dex.cpp
+++ clang-tools-extra/clangd/index/dex/Dex.cpp
@@ -22,6 +22,10 @@
 
 namespace {
 
+// Mark symbols which are can be used for code completion.
+static const Token RestrictedForCodeCompletion =
+Token(Token::Kind::Sentinel, "Restricted For Code Completion");
+
 // Returns the tokens which are given symbol's characteristics. Currently, the
 // generated tokens only contain fuzzy matching trigrams and symbol's scope,
 // but in the future this will also return path proximity tokens and other
@@ -39,6 +43,8 @@
 for (const auto &ProximityURI :
  generateProximityURIs(Sym.CanonicalDeclaration.FileURI))
   Result.emplace_back(Token::Kind::ProximityURI, ProximityURI);
+  if (Sym.Flags & Symbol::IndexedForCodeCompletion)
+Result.emplace_back(RestrictedForCodeCompletion);
   return Result;
 }
 
@@ -175,6 +181,11 @@
 TopLevelChildren.push_back(createOr(move(BoostingIterators)));
   }
 
+  // Filter symbols which are not indexed for code completion.
+  if (Req.RestrictForCodeCompletion)
+TopLevelChildren.push_back(
+InvertedIndex.find(RestrictedForCodeCompletion)->second.iterator());
+
   // Use TRUE iterator if both trigrams and scopes from the query are not
   // present in the symbol index.
   auto QueryIterator = TopLevelChildren.empty()


Index: clang-tools-extra/unittests/clangd/DexTests.cpp
===
--- clang-tools-extra/unittests/clangd/DexTests.cpp
+++ clang-tools-extra/unittests/clangd/DexTests.cpp
@@ -583,6 +583,22 @@
   EXPECT_THAT(lookup(*I, SymbolID("ns::nonono")), UnorderedElementsAre());
 }
 
+TEST(DexTest, SymbolIndexOptionsFilter) {
+  auto CodeCompletionSymbol = symbol("Completion");
+  auto NonCodeCompletionSymbol = symbol("NoCompletion");
+  std::vector Symbols{CodeCompletionSymbol, NonCodeCompletionSymbol};
+  Dex I(Symbols, URISchemes);
+  FuzzyFindRequest Req;
+  Req.RestrictForCodeCompletion = false;
+  EXPECT_THAT(match(I, Req), ElementsAre("Completion", "NoCompletion"));
+  CodeCompletionSymbol.Flags = Symbol::SymbolFlag::IndexedForCodeCompletion;
+  NonCodeCompletionSymbol.Flags = Symbol::SymbolFlag::None;
+  Symbols = {CodeCompletionSymbol, NonCodeCompletionSymbol};
+  I = Dex(Symbols, URISchemes);
+  Req.RestrictForCodeCompletion = true;
+  EXPECT_THAT(match(I, Req), ElementsAre("Completion"));
+}
+
 TEST(DexTest, ProximityPathsBoosting) {
   auto RootSymbol = symbol("root::abc");
   RootSymbol.CanonicalDeclaration.FileURI = "unittest:///file.h";
Index: clang-tools-extra/clangd/index/dex/Dex.cpp
===
--- clang-tools-extra/clangd/index/dex/Dex.cpp
+++ clang-tools-extra/clangd/index/dex/Dex.cpp
@@ -22,6 +22,10 @@
 
 namespace {
 
+// Mark symbols which are can be used for code completion.
+static const Token RestrictedForCodeCompletion =
+Token(Token::Kind::Sentinel, "Restricted For Code Completion");
+
 // Returns the tokens which are given symbol's characteristics. Currently, the
 // generated tokens only contain fuzzy matching trigrams and symbol's scope,
 // but in the future this will also return path proximity tokens and other
@@ -39,6 +43,8 @@
 for (const auto &ProximityURI :

[PATCH] D52308: [Sema][CodeCompletion] Fix return type of C++ destructors in code completion

2018-09-21 Thread Jan Korous via Phabricator via cfe-commits
jkorous abandoned this revision.
jkorous added a comment.

Allright, I will remove destructor from clangd completion results which solves 
this particular issue.

Also good point about return type being used in ranking - I incorrectly assumed 
it's just a presentational matter.


Repository:
  rC Clang

https://reviews.llvm.org/D52308



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


[PATCH] D52360: [clang-tidy] Fix for performance-unnecessary-value-param, performance-unnecessary-copy-initialization and performance-for-range-copy

2018-09-21 Thread Balogh , Ádám via Phabricator via cfe-commits
baloghadamsoftware created this revision.
baloghadamsoftware added reviewers: alexfh, aaron.ballman, flx.
baloghadamsoftware added a project: clang-tools-extra.
baloghadamsoftware added a comment.

This is an alternative approach to https://reviews.llvm.org/D52315.


The three checks mentioned in the Title are two noisy if the code uses custom 
(e.g. smart) pointers or references. LLVM/Clang is such a code, it has lots of 
such types, e.g. StringRef, SymbolRef or ProgramStateRef, all of them based 
llvm::IntrusiveRefCntPtr. Every time such a type is passed as parameter, used 
for initialization or in a range-based for loop a false positive warning is 
issued together with an (unnecessary) fix.

This patch excludes pointer types (e.g. smart pointers) by their name: if the 
name of the type ends on `Pointer`, `pointer`, `Ptr`, `ptr`, `Reference`, 
`reference`, `Ref` or `ref` the type is considered a pointer/reference type.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D52360

Files:
  clang-tidy/performance/ForRangeCopyCheck.cpp
  clang-tidy/performance/UnnecessaryCopyInitialization.cpp
  clang-tidy/performance/UnnecessaryValueParamCheck.cpp
  docs/clang-tidy/checks/performance-for-range-copy.rst
  docs/clang-tidy/checks/performance-unnecessary-copy-initialization.rst
  docs/clang-tidy/checks/performance-unnecessary-value-param.rst
  test/clang-tidy/performance-for-range-copy.cpp
  test/clang-tidy/performance-unnecessary-copy-initialization.cpp
  test/clang-tidy/performance-unnecessary-value-param.cpp

Index: test/clang-tidy/performance-unnecessary-value-param.cpp
===
--- test/clang-tidy/performance-unnecessary-value-param.cpp
+++ test/clang-tidy/performance-unnecessary-value-param.cpp
@@ -55,6 +55,38 @@
   ~ExpensiveMovableType();
 };
 
+struct SmartPointer {
+  ~SmartPointer();
+};
+
+struct smart_pointer {
+  ~smart_pointer();
+};
+
+struct SmartPtr {
+  ~SmartPtr();
+};
+
+struct smart_ptr {
+  ~smart_ptr();
+};
+
+struct SmartReference {
+  ~SmartReference();
+};
+
+struct smart_reference {
+  ~smart_reference();
+};
+
+struct SmartRef {
+  ~SmartRef();
+};
+
+struct smart_ref {
+  ~smart_ref();
+};
+
 void positiveExpensiveConstValue(const ExpensiveToCopyType Obj);
 // CHECK-FIXES: void positiveExpensiveConstValue(const ExpensiveToCopyType& Obj);
 void positiveExpensiveConstValue(const ExpensiveToCopyType Obj) {
@@ -381,3 +413,27 @@
   // CHECK-FIXES: void templateFunction(ExpensiveToCopyType E) {
   E.constReference();
 }
+
+void negativeSmartPointer(SmartPointer P) {
+}
+
+void negative_smart_pointer(smart_pointer p) {
+}
+
+void negativeSmartPtr(SmartPtr P) {
+}
+
+void negative_smart_ptr(smart_ptr p) {
+}
+
+void negativeSmartReference(SmartReference R) {
+}
+
+void negative_smart_reference(smart_reference r) {
+}
+
+void negativeSmartRef(SmartRef R) {
+}
+
+void negative_smart_ref(smart_ref r) {
+}
Index: test/clang-tidy/performance-unnecessary-copy-initialization.cpp
===
--- test/clang-tidy/performance-unnecessary-copy-initialization.cpp
+++ test/clang-tidy/performance-unnecessary-copy-initialization.cpp
@@ -20,11 +20,52 @@
   bool constMethod() const;
 };
 
+struct SmartPointer {
+  ~SmartPointer();
+};
+
+struct smart_pointer {
+  ~smart_pointer();
+};
+
+struct SmartPtr {
+  ~SmartPtr();
+};
+
+struct smart_ptr {
+  ~smart_ptr();
+};
+
+struct SmartReference {
+  ~SmartReference();
+};
+
+struct smart_reference {
+  ~smart_reference();
+};
+
+struct SmartRef {
+  ~SmartRef();
+};
+
+struct smart_ref {
+  ~smart_ref();
+};
+
 ExpensiveToCopyType global_expensive_to_copy_type;
 
 const ExpensiveToCopyType &ExpensiveTypeReference();
 const TrivialToCopyType &TrivialTypeReference();
 
+const SmartPointer &getSmartPointer();
+const smart_pointer &get_smart_pointer();
+const SmartPtr &getSmartPtr();
+const smart_ptr &get_smart_ptr();
+const SmartReference &getSmartReference();
+const smart_reference &get_smart_reference();
+const SmartRef &getSmartRef();
+const smart_ref &get_smart_ref();
+
 void mutate(ExpensiveToCopyType &);
 void mutate(ExpensiveToCopyType *);
 void useAsConstPointer(const ExpensiveToCopyType *);
@@ -387,3 +428,35 @@
   for (const Element &E : Container()) {
   }
 }
+
+void negativeSmartPointer() {
+  const auto P = getSmartPointer();
+}
+
+void negative_smart_pointer() {
+  const auto p = get_smart_pointer();
+}
+
+void negativeSmartPtr() {
+  const auto P = getSmartPtr();
+}
+
+void negative_smart_ptr() {
+  const auto p = get_smart_ptr();
+}
+
+void negativeSmartReference() {
+  const auto R = getSmartReference();
+}
+
+void negative_smart_reference() {
+  const auto r = get_smart_reference();
+}
+
+void negativeSmartRef() {
+  const auto R = getSmartRef();
+}
+
+void negative_smart_ref() {
+  const auto r = get_smart_ref();
+}
Index: test/clang-tidy/performance-for-range-copy.cpp

[PATCH] D52360: [clang-tidy] Fix for performance-unnecessary-value-param, performance-unnecessary-copy-initialization and performance-for-range-copy

2018-09-21 Thread Balogh , Ádám via Phabricator via cfe-commits
baloghadamsoftware added a comment.

This is an alternative approach to https://reviews.llvm.org/D52315.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D52360



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


[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.

2018-09-21 Thread Paul Robinson via Phabricator via cfe-commits
probinson added a comment.

Do we generate the .dwo file directly these days?  If not, I can imagine 
wanting to avoid the overhead of the objcopy hack; as long as the linker is 
smart enough not to bother with the .debug_*.dwo sections this seems like a 
build-time win.


https://reviews.llvm.org/D52296



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


r342738 - [OPENMP][NVPTX] Enable support for lastprivates in SPMD constructs.

2018-09-21 Thread Alexey Bataev via cfe-commits
Author: abataev
Date: Fri Sep 21 07:22:53 2018
New Revision: 342738

URL: http://llvm.org/viewvc/llvm-project?rev=342738&view=rev
Log:
[OPENMP][NVPTX] Enable support for lastprivates in SPMD constructs.

Previously we could not use lastprivates in SPMD constructs, patch
allows supporting lastprivates in SPMD with uninitialized runtime.

Modified:
cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
cfe/trunk/test/OpenMP/nvptx_SPMD_codegen.cpp
cfe/trunk/test/OpenMP/nvptx_force_full_runtime_SPMD_codegen.cpp
cfe/trunk/test/OpenMP/nvptx_target_teams_distribute_parallel_for_codegen.cpp

cfe/trunk/test/OpenMP/nvptx_target_teams_distribute_parallel_for_simd_codegen.cpp

Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp?rev=342738&r1=342737&r2=342738&view=diff
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp Fri Sep 21 07:22:53 2018
@@ -179,6 +179,54 @@ enum NamedBarrier : unsigned {
   NB_Parallel = 1,
 };
 
+typedef std::pair VarsDataTy;
+static bool stable_sort_comparator(const VarsDataTy P1, const VarsDataTy P2) {
+  return P1.first > P2.first;
+}
+
+static RecordDecl *buildRecordForGlobalizedVars(
+ASTContext &C, ArrayRef EscapedDecls,
+llvm::SmallDenseMap
+&MappedDeclsFields) {
+  if (EscapedDecls.empty())
+return nullptr;
+  SmallVector GlobalizedVars;
+  for (const ValueDecl *D : EscapedDecls)
+GlobalizedVars.emplace_back(C.getDeclAlign(D), D);
+  std::stable_sort(GlobalizedVars.begin(), GlobalizedVars.end(),
+   stable_sort_comparator);
+  // Build struct _globalized_locals_ty {
+  // /*  globalized vars  */
+  //   };
+  RecordDecl *GlobalizedRD = C.buildImplicitRecord("_globalized_locals_ty");
+  GlobalizedRD->startDefinition();
+  for (const auto &Pair : GlobalizedVars) {
+const ValueDecl *VD = Pair.second;
+QualType Type = VD->getType();
+if (Type->isLValueReferenceType())
+  Type = C.getPointerType(Type.getNonReferenceType());
+else
+  Type = Type.getNonReferenceType();
+SourceLocation Loc = VD->getLocation();
+auto *Field =
+FieldDecl::Create(C, GlobalizedRD, Loc, Loc, VD->getIdentifier(), Type,
+  C.getTrivialTypeSourceInfo(Type, SourceLocation()),
+  /*BW=*/nullptr, /*Mutable=*/false,
+  /*InitStyle=*/ICIS_NoInit);
+Field->setAccess(AS_public);
+GlobalizedRD->addDecl(Field);
+if (VD->hasAttrs()) {
+  for (specific_attr_iterator I(VD->getAttrs().begin()),
+   E(VD->getAttrs().end());
+   I != E; ++I)
+Field->addAttr(*I);
+}
+MappedDeclsFields.try_emplace(VD, Field);
+  }
+  GlobalizedRD->completeDefinition();
+  return GlobalizedRD;
+}
+
 /// Get the list of variables that can escape their declaration context.
 class CheckVarsEscapingDeclContext final
 : public ConstStmtVisitor {
@@ -292,51 +340,11 @@ class CheckVarsEscapingDeclContext final
 }
   }
 
-  typedef std::pair VarsDataTy;
-  static bool stable_sort_comparator(const VarsDataTy P1, const VarsDataTy P2) 
{
-return P1.first > P2.first;
-  }
-
   void buildRecordForGlobalizedVars() {
 assert(!GlobalizedRD &&
"Record for globalized variables is built already.");
-if (EscapedDecls.empty())
-  return;
-ASTContext &C = CGF.getContext();
-SmallVector GlobalizedVars;
-for (const ValueDecl *D : EscapedDecls)
-  GlobalizedVars.emplace_back(C.getDeclAlign(D), D);
-std::stable_sort(GlobalizedVars.begin(), GlobalizedVars.end(),
- stable_sort_comparator);
-// Build struct _globalized_locals_ty {
-// /*  globalized vars  */
-//   };
-GlobalizedRD = C.buildImplicitRecord("_globalized_locals_ty");
-GlobalizedRD->startDefinition();
-for (const auto &Pair : GlobalizedVars) {
-  const ValueDecl *VD = Pair.second;
-  QualType Type = VD->getType();
-  if (Type->isLValueReferenceType())
-Type = C.getPointerType(Type.getNonReferenceType());
-  else
-Type = Type.getNonReferenceType();
-  SourceLocation Loc = VD->getLocation();
-  auto *Field = FieldDecl::Create(
-  C, GlobalizedRD, Loc, Loc, VD->getIdentifier(), Type,
-  C.getTrivialTypeSourceInfo(Type, SourceLocation()),
-  /*BW=*/nullptr, /*Mutable=*/false,
-  /*InitStyle=*/ICIS_NoInit);
-  Field->setAccess(AS_public);
-  GlobalizedRD->addDecl(Field);
-  if (VD->hasAttrs()) {
-for (specific_attr_iterator I(VD->getAttrs().begin()),
- E(VD->getAttrs().end());
- I != E; ++I)
-  Field->addAttr(*I);
-  }
-  MappedDeclsFields.try_emplace(VD, Field);
-}
-GlobalizedRD->completeDefinition();
+GlobalizedRD = ::buil

[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.

2018-09-21 Thread George Rimar via Phabricator via cfe-commits
grimar added a comment.

We want to take the benefit that debug fission provides, but keep the debug 
information in the objects.
That is a bit less intrusive way than using regular split dwarf flow.

For a regular build and debug cycle that allows the linker to do minimal 
processing of the .debug_str.
Since .debug_str.dwo is ignored, that allows to significantly reduce the link 
time,
as strings processing is slow and string sections are large by themselves to 
handle them.

And at the same time the build system still does not see anything 
unusual/strange
as it sees only .o files like it is just a regular non-split-dwarf flow.


https://reviews.llvm.org/D52296



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


[PATCH] D52360: [clang-tidy] Fix for performance-unnecessary-value-param, performance-unnecessary-copy-initialization and performance-for-range-copy

2018-09-21 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a reviewer: lebedev.ri.
lebedev.ri added a comment.

Better, but these blacklists need to be config options, not random hardcoded 
globs.
See e.g. `google-runtime-references.WhiteListTypes`.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D52360



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


r342717 - [CodeGen] Add to emitted DebugLoc information about coverage when it's required

2018-09-21 Thread Calixte Denizet via cfe-commits
Author: calixte
Date: Fri Sep 21 02:17:06 2018
New Revision: 342717

URL: http://llvm.org/viewvc/llvm-project?rev=342717&view=rev
Log:
[CodeGen] Add to emitted DebugLoc information about coverage when it's required

Summary:
Some lines have a hit counter where they should not have one.
Cleanup stuff is located to the last line of the body which is most of the time 
a '}'.
And Exception stuff is added at the beginning of a function and at the end 
(represented by '{' and '}').
So in such cases, the DebugLoc used in GCOVProfiling.cpp must be marked as not 
covered.
This patch is a followup of https://reviews.llvm.org/D49915.
Tests in projects/compiler_rt are fixed by: https://reviews.llvm.org/D49917

Reviewers: marco-c, davidxl

Reviewed By: marco-c

Subscribers: dblaikie, cfe-commits, sylvestre.ledru

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

Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/CodeGen/CGDebugInfo.h
cfe/trunk/lib/CodeGen/CGException.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.h
cfe/trunk/test/CodeGen/debug-info-scope-file.c
cfe/trunk/test/CodeGenCXX/debug-info-inheriting-constructor.cpp
cfe/trunk/test/CodeGenCXX/linetable-virtual-variadic.cpp
cfe/trunk/test/CodeGenObjC/arc-linetable.m
cfe/trunk/test/CodeGenObjC/debug-info-blocks.m

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=342717&r1=342716&r2=342717&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Fri Sep 21 02:17:06 2018
@@ -76,20 +76,22 @@ CGDebugInfo::~CGDebugInfo() {
 }
 
 ApplyDebugLocation::ApplyDebugLocation(CodeGenFunction &CGF,
-   SourceLocation TemporaryLocation)
+   SourceLocation TemporaryLocation,
+   bool ImplicitCode)
 : CGF(&CGF) {
-  init(TemporaryLocation);
+  init(TemporaryLocation, false /* DefaultToEmpty */, ImplicitCode);
 }
 
 ApplyDebugLocation::ApplyDebugLocation(CodeGenFunction &CGF,
bool DefaultToEmpty,
-   SourceLocation TemporaryLocation)
+   SourceLocation TemporaryLocation,
+   bool ImplicitCode)
 : CGF(&CGF) {
-  init(TemporaryLocation, DefaultToEmpty);
+  init(TemporaryLocation, DefaultToEmpty, ImplicitCode);
 }
 
 void ApplyDebugLocation::init(SourceLocation TemporaryLocation,
-  bool DefaultToEmpty) {
+  bool DefaultToEmpty, bool ImplicitCode) {
   auto *DI = CGF->getDebugInfo();
   if (!DI) {
 CGF = nullptr;
@@ -102,7 +104,7 @@ void ApplyDebugLocation::init(SourceLoca
 return;
 
   if (TemporaryLocation.isValid()) {
-DI->EmitLocation(CGF->Builder, TemporaryLocation);
+DI->EmitLocation(CGF->Builder, TemporaryLocation, ImplicitCode);
 return;
   }
 
@@ -3484,7 +3486,8 @@ void CGDebugInfo::EmitInlineFunctionEnd(
   setInlinedAt(llvm::DebugLoc(CurInlinedAt).getInlinedAt());
 }
 
-void CGDebugInfo::EmitLocation(CGBuilderTy &Builder, SourceLocation Loc) {
+void CGDebugInfo::EmitLocation(CGBuilderTy &Builder, SourceLocation Loc,
+   bool ImplicitCode) {
   // Update our current location
   setLocation(Loc);
 
@@ -3492,8 +3495,9 @@ void CGDebugInfo::EmitLocation(CGBuilder
 return;
 
   llvm::MDNode *Scope = LexicalBlockStack.back();
-  Builder.SetCurrentDebugLocation(llvm::DebugLoc::get(
-  getLineNumber(CurLoc), getColumnNumber(CurLoc), Scope, CurInlinedAt));
+  Builder.SetCurrentDebugLocation(
+  llvm::DebugLoc::get(getLineNumber(CurLoc), getColumnNumber(CurLoc), 
Scope,
+  CurInlinedAt, ImplicitCode));
 }
 
 void CGDebugInfo::CreateLexicalBlock(SourceLocation Loc) {
@@ -3540,7 +3544,7 @@ void CGDebugInfo::EmitLexicalBlockEnd(CG
   assert(!LexicalBlockStack.empty() && "Region stack mismatch, stack empty!");
 
   // Provide an entry in the line table for the end of the block.
-  EmitLocation(Builder, Loc);
+  EmitLocation(Builder, Loc, true /* ImplicitCode */);
 
   if (DebugKind <= codegenoptions::DebugLineTablesOnly)
 return;
@@ -3556,7 +3560,7 @@ void CGDebugInfo::EmitFunctionEnd(CGBuil
   // Pop all regions for this function.
   while (LexicalBlockStack.size() != RCount) {
 // Provide an entry in the line table for the end of the block.
-EmitLocation(Builder, CurLoc);
+EmitLocation(Builder, CurLoc, true /* ImplicitCode */);
 LexicalBlockStack.pop_back();
   }
   FnBeginRegionCount.pop_back();

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.h?rev=342717&r1=342716&r2=342717&view=diff
==

[PATCH] D52357: [clangd] Force Dex to respect symbol collector flags

2018-09-21 Thread Eric Liu via Phabricator via cfe-commits
ioeric accepted this revision.
ioeric added inline comments.
This revision is now accepted and ready to land.



Comment at: clang-tools-extra/clangd/index/dex/Dex.cpp:184
 
+  // Filter symbols which are not indexed for code completion.
+  if (Req.RestrictForCodeCompletion)

nit: the comment seems trivial from the if-condition. Maybe remove?



Comment at: clang-tools-extra/unittests/clangd/DexTests.cpp:594
+  EXPECT_THAT(match(I, Req), ElementsAre("Completion", "NoCompletion"));
+  CodeCompletionSymbol.Flags = Symbol::SymbolFlag::IndexedForCodeCompletion;
+  NonCodeCompletionSymbol.Flags = Symbol::SymbolFlag::None;

I think the symbol flags should be set before both requests.


https://reviews.llvm.org/D52357



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


[PATCH] D52047: [clangd] Add building benchmark and memory consumption tracking

2018-09-21 Thread Kirill Bobyrev via Phabricator via cfe-commits
kbobyrev updated this revision to Diff 166481.
kbobyrev marked 3 inline comments as done.
kbobyrev added a comment.

- Be more explicit about the nature of "benchmarks" with memory tracking logic 
via `State::SetLabel(...)`.
- Force single iteration for "benchmarks" with memory usage tracking
- Add another "benchmark" with `Dex` memory overhead over plain `SymbolSlab`

Huge thanks to @lebedev.ri for helping! This looks much better to me now.


https://reviews.llvm.org/D52047

Files:
  clang-tools-extra/clangd/benchmarks/IndexBenchmark.cpp
  clang-tools-extra/clangd/index/Serialization.cpp
  clang-tools-extra/clangd/index/SymbolYAML.cpp
  clang-tools-extra/clangd/index/SymbolYAML.h
  clang-tools-extra/clangd/index/dex/Dex.cpp

Index: clang-tools-extra/clangd/index/dex/Dex.cpp
===
--- clang-tools-extra/clangd/index/dex/Dex.cpp
+++ clang-tools-extra/clangd/index/dex/Dex.cpp
@@ -124,9 +124,6 @@
   for (const auto &TokenToPostingList : TempInvertedIndex)
 InvertedIndex.insert({TokenToPostingList.first,
   PostingList(move(TokenToPostingList.second))});
-
-  vlog("Built Dex with estimated memory usage {0} bytes.",
-   estimateMemoryUsage());
 }
 
 /// Constructs iterators over tokens extracted from the query and exhausts it
@@ -238,8 +235,9 @@
   Bytes += SymbolQuality.size() * sizeof(float);
   Bytes += LookupTable.getMemorySize();
   Bytes += InvertedIndex.getMemorySize();
-  for (const auto &P : InvertedIndex)
-Bytes += P.second.bytes();
+  for (const auto &TokenAndPostingList : InvertedIndex)
+Bytes += TokenAndPostingList.first.Data.size() +
+ TokenAndPostingList.second.bytes();
   return Bytes + BackingDataSize;
 }
 
Index: clang-tools-extra/clangd/index/SymbolYAML.h
===
--- clang-tools-extra/clangd/index/SymbolYAML.h
+++ clang-tools-extra/clangd/index/SymbolYAML.h
@@ -29,6 +29,9 @@
 // Read symbols from a YAML-format string.
 SymbolSlab symbolsFromYAML(llvm::StringRef YAMLContent);
 
+// Read symbols from YAML or RIFF file.
+llvm::Expected symbolsFromFile(llvm::StringRef SymbolFilename);
+
 // Read one symbol from a YAML-stream.
 // The returned symbol is backed by Input.
 Symbol SymbolFromYAML(llvm::yaml::Input &Input);
Index: clang-tools-extra/clangd/index/SymbolYAML.cpp
===
--- clang-tools-extra/clangd/index/SymbolYAML.cpp
+++ clang-tools-extra/clangd/index/SymbolYAML.cpp
@@ -9,6 +9,7 @@
 
 #include "SymbolYAML.h"
 #include "Index.h"
+#include "Logger.h"
 #include "Serialization.h"
 #include "Trace.h"
 #include "dex/Dex.h"
@@ -172,6 +173,7 @@
 namespace clangd {
 
 SymbolSlab symbolsFromYAML(llvm::StringRef YAMLContent) {
+  trace::Span Tracer("ParseYAML");
   llvm::yaml::Input Yin(YAMLContent);
   std::vector S;
   Yin >> S;
@@ -182,6 +184,24 @@
   return std::move(Syms).build();
 }
 
+llvm::Expected symbolsFromFile(llvm::StringRef SymbolFilename) {
+  auto Buffer = llvm::MemoryBuffer::getFile(SymbolFilename);
+  if (!Buffer)
+return llvm::make_error(
+("Can't open " + SymbolFilename).str(), llvm::errc::invalid_argument);
+
+  StringRef Data = Buffer->get()->getBuffer();
+
+  if (!Data.startswith("RIFF")) { // Magic for binary index file.
+return symbolsFromYAML(Data);
+  }
+  auto RIFF = readIndexFile(Data);
+  return RIFF ? llvm::Expected(std::move(*RIFF->Symbols))
+  : llvm::make_error(
+("Can't open " + SymbolFilename).str(),
+llvm::errc::invalid_argument);
+}
+
 Symbol SymbolFromYAML(llvm::yaml::Input &Input) {
   Symbol S;
   Input >> S;
@@ -206,30 +226,16 @@
llvm::ArrayRef URISchemes,
bool UseDex) {
   trace::Span OverallTracer("LoadIndex");
-  auto Buffer = llvm::MemoryBuffer::getFile(SymbolFilename);
-  if (!Buffer) {
-llvm::errs() << "Can't open " << SymbolFilename << "\n";
-return nullptr;
-  }
-  StringRef Data = Buffer->get()->getBuffer();
-
-  llvm::Optional Slab;
-  if (Data.startswith("RIFF")) { // Magic for binary index file.
-trace::Span Tracer("ParseRIFF");
-if (auto RIFF = readIndexFile(Data))
-  Slab = std::move(RIFF->Symbols);
-else
-  llvm::errs() << "Bad RIFF: " << llvm::toString(RIFF.takeError()) << "\n";
-  } else {
-trace::Span Tracer("ParseYAML");
-Slab = symbolsFromYAML(Data);
-  }
-
+  auto Slab = symbolsFromFile(SymbolFilename);
   if (!Slab)
 return nullptr;
   trace::Span Tracer("BuildIndex");
-  return UseDex ? dex::Dex::build(std::move(*Slab), URISchemes)
-: MemIndex::build(std::move(*Slab), RefSlab());
+  auto Index = UseDex ? dex::Dex::build(std::move(*Slab), URISchemes)
+  : MemIndex::build(std::move(*Slab), RefSlab());
+  vlog("Loaded {0} from {1} with estimated memory usage {2}",
+   UseDex ? "Dex" :

[PATCH] D52357: [clangd] Force Dex to respect symbol collector flags

2018-09-21 Thread Kirill Bobyrev via Phabricator via cfe-commits
kbobyrev updated this revision to Diff 166482.
kbobyrev marked 2 inline comments as done.

https://reviews.llvm.org/D52357

Files:
  clang-tools-extra/clangd/index/dex/Dex.cpp
  clang-tools-extra/unittests/clangd/DexTests.cpp


Index: clang-tools-extra/unittests/clangd/DexTests.cpp
===
--- clang-tools-extra/unittests/clangd/DexTests.cpp
+++ clang-tools-extra/unittests/clangd/DexTests.cpp
@@ -583,6 +583,20 @@
   EXPECT_THAT(lookup(*I, SymbolID("ns::nonono")), UnorderedElementsAre());
 }
 
+TEST(DexTest, SymbolIndexOptionsFilter) {
+  auto CodeCompletionSymbol = symbol("Completion");
+  auto NonCodeCompletionSymbol = symbol("NoCompletion");
+  CodeCompletionSymbol.Flags = Symbol::SymbolFlag::IndexedForCodeCompletion;
+  NonCodeCompletionSymbol.Flags = Symbol::SymbolFlag::None;
+  std::vector Symbols{CodeCompletionSymbol, NonCodeCompletionSymbol};
+  Dex I(Symbols, URISchemes);
+  FuzzyFindRequest Req;
+  Req.RestrictForCodeCompletion = false;
+  EXPECT_THAT(match(I, Req), ElementsAre("Completion", "NoCompletion"));
+  Req.RestrictForCodeCompletion = true;
+  EXPECT_THAT(match(I, Req), ElementsAre("Completion"));
+}
+
 TEST(DexTest, ProximityPathsBoosting) {
   auto RootSymbol = symbol("root::abc");
   RootSymbol.CanonicalDeclaration.FileURI = "unittest:///file.h";
Index: clang-tools-extra/clangd/index/dex/Dex.cpp
===
--- clang-tools-extra/clangd/index/dex/Dex.cpp
+++ clang-tools-extra/clangd/index/dex/Dex.cpp
@@ -22,6 +22,10 @@
 
 namespace {
 
+// Mark symbols which are can be used for code completion.
+static const Token RestrictedForCodeCompletion =
+Token(Token::Kind::Sentinel, "Restricted For Code Completion");
+
 // Returns the tokens which are given symbol's characteristics. Currently, the
 // generated tokens only contain fuzzy matching trigrams and symbol's scope,
 // but in the future this will also return path proximity tokens and other
@@ -39,6 +43,8 @@
 for (const auto &ProximityURI :
  generateProximityURIs(Sym.CanonicalDeclaration.FileURI))
   Result.emplace_back(Token::Kind::ProximityURI, ProximityURI);
+  if (Sym.Flags & Symbol::IndexedForCodeCompletion)
+Result.emplace_back(RestrictedForCodeCompletion);
   return Result;
 }
 
@@ -175,6 +181,10 @@
 TopLevelChildren.push_back(createOr(move(BoostingIterators)));
   }
 
+  if (Req.RestrictForCodeCompletion)
+TopLevelChildren.push_back(
+InvertedIndex.find(RestrictedForCodeCompletion)->second.iterator());
+
   // Use TRUE iterator if both trigrams and scopes from the query are not
   // present in the symbol index.
   auto QueryIterator = TopLevelChildren.empty()


Index: clang-tools-extra/unittests/clangd/DexTests.cpp
===
--- clang-tools-extra/unittests/clangd/DexTests.cpp
+++ clang-tools-extra/unittests/clangd/DexTests.cpp
@@ -583,6 +583,20 @@
   EXPECT_THAT(lookup(*I, SymbolID("ns::nonono")), UnorderedElementsAre());
 }
 
+TEST(DexTest, SymbolIndexOptionsFilter) {
+  auto CodeCompletionSymbol = symbol("Completion");
+  auto NonCodeCompletionSymbol = symbol("NoCompletion");
+  CodeCompletionSymbol.Flags = Symbol::SymbolFlag::IndexedForCodeCompletion;
+  NonCodeCompletionSymbol.Flags = Symbol::SymbolFlag::None;
+  std::vector Symbols{CodeCompletionSymbol, NonCodeCompletionSymbol};
+  Dex I(Symbols, URISchemes);
+  FuzzyFindRequest Req;
+  Req.RestrictForCodeCompletion = false;
+  EXPECT_THAT(match(I, Req), ElementsAre("Completion", "NoCompletion"));
+  Req.RestrictForCodeCompletion = true;
+  EXPECT_THAT(match(I, Req), ElementsAre("Completion"));
+}
+
 TEST(DexTest, ProximityPathsBoosting) {
   auto RootSymbol = symbol("root::abc");
   RootSymbol.CanonicalDeclaration.FileURI = "unittest:///file.h";
Index: clang-tools-extra/clangd/index/dex/Dex.cpp
===
--- clang-tools-extra/clangd/index/dex/Dex.cpp
+++ clang-tools-extra/clangd/index/dex/Dex.cpp
@@ -22,6 +22,10 @@
 
 namespace {
 
+// Mark symbols which are can be used for code completion.
+static const Token RestrictedForCodeCompletion =
+Token(Token::Kind::Sentinel, "Restricted For Code Completion");
+
 // Returns the tokens which are given symbol's characteristics. Currently, the
 // generated tokens only contain fuzzy matching trigrams and symbol's scope,
 // but in the future this will also return path proximity tokens and other
@@ -39,6 +43,8 @@
 for (const auto &ProximityURI :
  generateProximityURIs(Sym.CanonicalDeclaration.FileURI))
   Result.emplace_back(Token::Kind::ProximityURI, ProximityURI);
+  if (Sym.Flags & Symbol::IndexedForCodeCompletion)
+Result.emplace_back(RestrictedForCodeCompletion);
   return Result;
 }
 
@@ -175,6 +181,10 @@
 TopLevelChildren.push_back(createOr(move(BoostingIterators)));
   }
 
+  if (Req.RestrictForCodeCompletion)
+TopLevelChildren

[PATCH] D52084: [clangd] Improve PostingList iterator string representation

2018-09-21 Thread Kirill Bobyrev via Phabricator via cfe-commits
kbobyrev closed this revision.
kbobyrev added a comment.

I think this one is addressed in the VByte patch, so I'm closing this revision 
in order to prevent conflicts between these two.


https://reviews.llvm.org/D52084



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


[PATCH] D52300: [clangd] Implement VByte PostingList compression

2018-09-21 Thread Kirill Bobyrev via Phabricator via cfe-commits
kbobyrev added inline comments.



Comment at: clang-tools-extra/clangd/index/dex/PostingList.cpp:29
+  DecompressedChunk = ChunkIndex->decompress();
+  InnerIndex = begin(DecompressedChunk);
+}

sammccall wrote:
> nit: we generally use members (DecompressedChunk.begin()) unless actually 
> dealing with arrays or templates, since lookup rules are simpler
>  
I thought using `std::begin(Container)`, `std::end(Container)` is way more 
robust because the API is essentially the same if the code changes, so I used 
it everywhere in Dex. Do you think I should change this patch or keep it to 
keep the codebase more consistent?



Comment at: clang-tools-extra/clangd/index/dex/PostingList.cpp:121
 
+/// Single-byte masks used for VByte compression bit manipulations.
+constexpr uint8_t SevenBytesMask = 0x7f;  // 0b0111

sammccall wrote:
> move to the function where they're used
But they're used both in `encodeStream()` and `decompress()`. I tried to move 
as much static constants to functions where they're used, but these masks are 
useful for both encoding and decoding. Is there something I should do instead 
(e.g. make them members of `PostingList`)?


https://reviews.llvm.org/D52300



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


r342741 - [OPENMP] Disable emission of the class with vptr if they are not used in

2018-09-21 Thread Alexey Bataev via cfe-commits
Author: abataev
Date: Fri Sep 21 07:55:26 2018
New Revision: 342741

URL: http://llvm.org/viewvc/llvm-project?rev=342741&view=rev
Log:
[OPENMP] Disable emission of the class with vptr if they are not used in
target constructs.

Prevent compilation of the classes with the virtual tables when
compiling for the device.

Modified:
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
cfe/trunk/test/OpenMP/declare_target_codegen.cpp

Modified: cfe/trunk/lib/Sema/SemaDeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclCXX.cpp?rev=342741&r1=342740&r2=342741&view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Fri Sep 21 07:55:26 2018
@@ -14918,7 +14918,8 @@ void Sema::MarkVTableUsed(SourceLocation
   // Do not mark as used if compiling for the device outside of the target
   // region.
   if (LangOpts.OpenMP && LangOpts.OpenMPIsDevice &&
-  !isInOpenMPDeclareTargetContext() && !getCurFunctionDecl())
+  !isInOpenMPDeclareTargetContext() &&
+  !isInOpenMPTargetExecutionDirective())
 return;
 
   // Try to insert this class into the map.

Modified: cfe/trunk/test/OpenMP/declare_target_codegen.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/declare_target_codegen.cpp?rev=342741&r1=342740&r2=342741&view=diff
==
--- cfe/trunk/test/OpenMP/declare_target_codegen.cpp (original)
+++ cfe/trunk/test/OpenMP/declare_target_codegen.cpp Fri Sep 21 07:55:26 2018
@@ -157,6 +157,16 @@ struct Bake {
 template class Bake;
 #pragma omp end declare target
 
+struct BaseNonT {
+  virtual ~BaseNonT() {}
+};
+
+#pragma omp declare target
+struct BakeNonT {
+  virtual ~BakeNonT() {}
+};
+#pragma omp end declare target
+
 // CHECK-DAG: declare extern_weak signext i32 @__create()
 
 // CHECK-NOT: define {{.*}}{{baz1|baz4|maini1|Base}}


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


[PATCH] D52339: Support enums with a fixed underlying type in all language modes

2018-09-21 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a reviewer: aaron.ballman.
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

I really like this idea in general, thank you for proposing this patch!




Comment at: clang/include/clang/Basic/Features.def:90
 FEATURE(objc_default_synthesize_properties, LangOpts.ObjC2)
-FEATURE(objc_fixed_enum, LangOpts.ObjC2)
+FEATURE(objc_fixed_enum, true)
 FEATURE(objc_instancetype, LangOpts.ObjC2)

Is this really supported in ObjC1, or is there no longer a distinction to be 
made there?



Comment at: clang/include/clang/Basic/Features.def:233
 EXTENSION(cxx_variadic_templates, LangOpts.CPlusPlus)
+EXTENSION(cxx_fixed_enum, true)
 // C++14 features supported by other languages as extensions.

Are we sure we want to make this decision for things like OpenCL, Cuda, etc?


Repository:
  rC Clang

https://reviews.llvm.org/D52339



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


[PATCH] D52339: Support enums with a fixed underlying type in all language modes

2018-09-21 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman requested changes to this revision.
aaron.ballman added a comment.
This revision now requires changes to proceed.

Whoops, that acceptance was accidental. Pretending I want changes just to make 
it clear in Phab. :-)


Repository:
  rC Clang

https://reviews.llvm.org/D52339



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


[PATCH] D52047: [clangd] Add building benchmark and memory consumption tracking

2018-09-21 Thread Eric Liu via Phabricator via cfe-commits
ioeric added inline comments.



Comment at: clang-tools-extra/clangd/benchmarks/IndexBenchmark.cpp:78
 
+static void DexQueries(benchmark::State &State) {
+  const auto Dex = buildDex();

Why did we move this benchmark (`DexQueries`)? It seems unnecessary.



Comment at: clang-tools-extra/clangd/benchmarks/IndexBenchmark.cpp:106
+// benchmark report (possible options for time units are ms, ns and us).
+State.SetIterationTime(/*double Seconds=*/Mem->estimateMemoryUsage() /
+   1000);

nit: maybe divide by `1000.0` to avoid precision loss?



Comment at: clang-tools-extra/clangd/index/SymbolYAML.cpp:187
 
+llvm::Expected symbolsFromFile(llvm::StringRef SymbolFilename) {
+  auto Buffer = llvm::MemoryBuffer::getFile(SymbolFilename);

Could you put this near the old `loadIndex` to preserve the revision history?


https://reviews.llvm.org/D52047



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


[PATCH] D52300: [clangd] Implement VByte PostingList compression

2018-09-21 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

In https://reviews.llvm.org/D52300#1241754, @kbobyrev wrote:

> I addressed the easiest issues. I'll try to implement separate storage 
> structure for `Head`s and `Payload`s which would potentially make the 
> implementation cleaner and easier to understand (and also more maintainable 
> since that would be way easier to go for SIMD instructions speedups and other 
> encoding schemes if we do that).


That doesn't sound more maintainable, that sounds like a performance hack that 
will hurt the layering.
Which is ok :-) but please don't do that until you measure a nontrivial 
performance improvement from it.

> Also, I'll refine https://reviews.llvm.org/D52047 a little bit and I believe 
> that is should be way easier to understand performance + memory consumption 
> once we have these benchmarks in. Both @ioeric and @ilya-biryukov expressed 
> their concern with regard to the memory consumption "benchmark" and suggested 
> a separate binary. While this seems fine to me, I think it's important to 
> keep performance + memory tracking infrastructure easy to use (in this sense 
> scattering different metrics across multiple binaries makes it less 
> accessible and probably introduce some code duplication) and therefore using 
> this "trick" is OK to me, but I don't have a strong opinion about this. What 
> do you think, @sammccall?

I may be missing some context, but you're talking about index idle memory usage 
right?
Can't this just be a dexp command?
No objection to annotating benchmark runs with memory usage too, but I wouldn't 
jump through hoops unless there's a strong reason.




Comment at: clang-tools-extra/clangd/index/dex/PostingList.cpp:121
 
+/// Single-byte masks used for VByte compression bit manipulations.
+constexpr uint8_t SevenBytesMask = 0x7f;  // 0b0111

kbobyrev wrote:
> sammccall wrote:
> > move to the function where they're used
> But they're used both in `encodeStream()` and `decompress()`. I tried to move 
> as much static constants to functions where they're used, but these masks are 
> useful for both encoding and decoding. Is there something I should do instead 
> (e.g. make them members of `PostingList`)?
You're right.
My real objection here is that these decls are hard to understand here, and the 
code that uses them is also hard to understand.

I think this is because they aren't very powerful abstractions (the detail 
abstracted is limited, and it's not strongly abstracted) and the names aren't 
sufficiently good. (I don't have great ones, though not confusing bits and 
bytes would be a start :-)

My top suggestion is to inline these everywhere they're used. This is bit 
twiddling code, not knowing what the bits are can obscure understanding hard, 
and encourage you to write the code in a falsely general way.

Failing that, SevenBytesMask -> LowBits and ContinuationBit -> More or HighBit?
FourBytesMask isn't needed, you won't be decoding any invalid data.



https://reviews.llvm.org/D52300



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


[PATCH] D52323: Add necessary support for storing code-model to module IR.

2018-09-21 Thread Teresa Johnson via Phabricator via cfe-commits
tejohnson added a comment.

Note that if you add a line like:

"Depends on https://reviews.llvm.org/D52322"; in the summary that Phabricator 
will automatically link the two in the right way.




Comment at: lib/CodeGen/CodeGenModule.cpp:569
+  .Default(~0u);
+if ((CM != ~0u) && (CM != ~1u)) {
+  llvm::CodeModel::Model codeModel = 
static_cast(CM);

Can you simplify by using a single constant for both of these (since handling 
the same)?



Comment at: lib/CodeGen/CodeGenModule.h:38
 #include "llvm/IR/ValueHandle.h"
+#include "llvm/Support/CodeGen.h"
 #include "llvm/Transforms/Utils/SanitizerStats.h"

Since nothing changed in this header, should this new include be moved to 
CodeGenModule.cpp?



Comment at: test/CodeGen/codemodels.c:2
+// RUN: %clang_cc1 -emit-llvm  %s -o - | FileCheck %s 
-check-prefix=CHECK-NOMODEL
+// RUN: %clang_cc1 -emit-llvm -mcode-model small %s -o - | FileCheck %s 
-check-prefix=CHECK-SMALL
+// RUN: %clang_cc1 -emit-llvm -mcode-model kernel %s -o - | FileCheck %s 
-check-prefix=CHECK-KERNEL

Might as well check "tiny" and "default" as well for completeness.


Repository:
  rC Clang

https://reviews.llvm.org/D52323



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


[PATCH] D52047: [clangd] Add building benchmark and memory consumption tracking

2018-09-21 Thread Sam McCall via Phabricator via cfe-commits
sammccall requested changes to this revision.
sammccall added a comment.
This revision now requires changes to proceed.

This change does several things, and I think most of them need further thought. 
Can we discuss Monday?




Comment at: clang-tools-extra/clangd/benchmarks/IndexBenchmark.cpp:96
 
-static void DexQueries(benchmark::State &State) {
+// This is not a *real* benchmark: it shows size of built MemIndex (in bytes).
+// Same for the next "benchmark".

This looks like it'll be really stable, why does it need to be a benchmark vs 
say a dexp subcommand?


https://reviews.llvm.org/D52047



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


[PATCH] D52339: Support enums with a fixed underlying type in all language modes

2018-09-21 Thread JF Bastien via Phabricator via cfe-commits
jfb added a comment.

I think we should consider proposing this to the C committee. @aaron.ballman I 
can help Erik write the paper, would you be able to present it? Too tight for 
the upcoming meeting, but I'm guessing we have *plenty* of time for ++C17.


Repository:
  rC Clang

https://reviews.llvm.org/D52339



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


[PATCH] D52364: [clangd] Initial supoprt for cross-namespace global code completion.

2018-09-21 Thread Eric Liu via Phabricator via cfe-commits
ioeric created this revision.
ioeric added a reviewer: sammccall.
Herald added subscribers: cfe-commits, kadircet, arphaman, jkorous, MaskRay, 
ilya-biryukov.

When no scope qualifier is specified, allow completing index symbols
from any scope and insert proper automatically. This is still experimental and
hidden behind a flag.

Things missing:

- Scope proximity based scoring.
- FuzzyFind supports weighted scopes.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D52364

Files:
  clangd/CodeComplete.cpp
  clangd/CodeComplete.h
  clangd/index/Index.h
  clangd/index/MemIndex.cpp
  clangd/index/dex/Dex.cpp
  clangd/tool/ClangdMain.cpp
  unittests/clangd/CodeCompleteTests.cpp
  unittests/clangd/DexTests.cpp

Index: unittests/clangd/DexTests.cpp
===
--- unittests/clangd/DexTests.cpp
+++ unittests/clangd/DexTests.cpp
@@ -565,6 +565,16 @@
   EXPECT_THAT(match(*I, Req), UnorderedElementsAre("a::y1"));
 }
 
+TEST(DexTest, WildcardScope) {
+  auto I =
+  Dex::build(generateSymbols({"a::y1", "a::b::y2", "c::y3"}), URISchemes);
+  FuzzyFindRequest Req;
+  Req.Query = "y";
+  Req.Scopes = {"a::", "*"};
+  EXPECT_THAT(match(*I, Req),
+  UnorderedElementsAre("a::y1", "a::b::y2", "c::y3"));
+}
+
 TEST(DexTest, IgnoreCases) {
   auto I = Dex::build(generateSymbols({"ns::ABC", "ns::abc"}), URISchemes);
   FuzzyFindRequest Req;
Index: unittests/clangd/CodeCompleteTests.cpp
===
--- unittests/clangd/CodeCompleteTests.cpp
+++ unittests/clangd/CodeCompleteTests.cpp
@@ -2040,6 +2040,41 @@
   }
 }
 
+TEST(CompletionTest, CrossNamespaceCompletion) {
+  clangd::CodeCompleteOptions Opts = {};
+  Opts.IncludeIndexSymbolsFromAllScopes = true;
+
+  auto Results = completions(
+  R"cpp(
+namespace na {
+void f() { Clangd^ }
+}
+  )cpp",
+  {cls("nx::Clangd1"), cls("ny::Clangd2"), cls("Clangd3"),
+   cls("na::nb::Clangd4")},
+  Opts);
+  EXPECT_THAT(Results.Completions,
+  UnorderedElementsAre(AllOf(Qualifier("nx::"), Named("Clangd1")),
+   AllOf(Qualifier("ny::"), Named("Clangd2")),
+   AllOf(Qualifier(""), Named("Clangd3")),
+   AllOf(Qualifier("nb::"), Named("Clangd4";
+}
+
+TEST(CompletionTest, NoQualifierIfShadowed) {
+  clangd::CodeCompleteOptions Opts = {};
+  Opts.IncludeIndexSymbolsFromAllScopes = true;
+
+  auto Results = completions(R"cpp(
+namespace nx { class Clangd1 {}; }
+using nx::Clangd1;
+void f() { Clangd^ }
+  )cpp",
+ {cls("nx::Clangd1"), cls("nx::Clangd2")}, Opts);
+  EXPECT_THAT(Results.Completions,
+  UnorderedElementsAre(AllOf(Qualifier(""), Named("Clangd1")),
+   AllOf(Qualifier("nx::"), Named("Clangd2";
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clangd/tool/ClangdMain.cpp
===
--- clangd/tool/ClangdMain.cpp
+++ clangd/tool/ClangdMain.cpp
@@ -136,6 +136,15 @@
 "enabled separatedly."),
 llvm::cl::init(true), llvm::cl::Hidden);
 
+static llvm::cl::opt CrossNamespaceCompletion(
+"cross-namespace-completion",
+llvm::cl::desc(
+"This is an experimental feature. If set to true, code completion will "
+"include index symbols that are not defined in the scopes (e.g. "
+"namespaces) visible from the code completion point. Such completions "
+"can insert scope qualifiers."),
+llvm::cl::init(false), llvm::cl::Hidden);
+
 static llvm::cl::opt
 ShowOrigins("debug-origin",
 llvm::cl::desc("Show origins of completion items"),
@@ -304,6 +313,7 @@
   }
   CCOpts.SpeculativeIndexRequest = Opts.StaticIndex;
   CCOpts.EnableFunctionArgSnippets = EnableFunctionArgSnippets;
+  CCOpts.IncludeIndexSymbolsFromAllScopes = CrossNamespaceCompletion;
 
   // Initialize and run ClangdLSPServer.
   ClangdLSPServer LSPServer(
Index: clangd/index/dex/Dex.cpp
===
--- clangd/index/dex/Dex.cpp
+++ clangd/index/dex/Dex.cpp
@@ -12,6 +12,7 @@
 #include "FuzzyMatch.h"
 #include "Logger.h"
 #include "Quality.h"
+#include "index/Index.h"
 #include "llvm/ADT/StringSet.h"
 #include 
 #include 
@@ -156,6 +157,10 @@
   // Generate scope tokens for search query.
   std::vector> ScopeIterators;
   for (const auto &Scope : Req.Scopes) {
+if (Scope == "*") {
+  ScopeIterators.push_back(createTrue(Symbols.size()));
+  continue;
+}
 const auto It = InvertedIndex.find(Token(Token::Kind::Scope, Scope));
 if (It != InvertedIndex.end())
   ScopeIterators.push_back(It->second.iterator());
Index: clangd/index/MemIndex.cpp
===
--- clangd/index/MemIndex.cpp
+++ clangd/inde

[PATCH] D52339: Support enums with a fixed underlying type in all language modes

2018-09-21 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In https://reviews.llvm.org/D52339#1242086, @jfb wrote:

> I think we should consider proposing this to the C committee. @aaron.ballman 
> I can help Erik write the paper, would you be able to present it? Too tight 
> for the upcoming meeting, but I'm guessing we have *plenty* of time for ++C17.


It's already been proposed to WG14 and is currently on the SD-3 list of 
features to consider for C2x. See 
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2008.pdf. I know Clive and am 
happy to point him towards this patch (when it lands) as demonstration of 
industry desire for the feature, in case he needs to provide updated papers.


Repository:
  rC Clang

https://reviews.llvm.org/D52339



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


[PATCH] D52323: Add necessary support for storing code-model to module IR.

2018-09-21 Thread Caroline Tice via Phabricator via cfe-commits
cmtice marked an inline comment as done.
cmtice added inline comments.



Comment at: lib/CodeGen/CodeGenModule.cpp:569
+  .Default(~0u);
+if ((CM != ~0u) && (CM != ~1u)) {
+  llvm::CodeModel::Model codeModel = 
static_cast(CM);

tejohnson wrote:
> Can you simplify by using a single constant for both of these (since handling 
> the same)?
I just realized .Case("default") is not a valid case, so I will remove that and 
there will only be 1 constant.



Comment at: test/CodeGen/codemodels.c:2
+// RUN: %clang_cc1 -emit-llvm  %s -o - | FileCheck %s 
-check-prefix=CHECK-NOMODEL
+// RUN: %clang_cc1 -emit-llvm -mcode-model small %s -o - | FileCheck %s 
-check-prefix=CHECK-SMALL
+// RUN: %clang_cc1 -emit-llvm -mcode-model kernel %s -o - | FileCheck %s 
-check-prefix=CHECK-KERNEL

tejohnson wrote:
> Might as well check "tiny" and "default" as well for completeness.
I will add a check for "tiny".  "default" turns out not to be a valid option.


Repository:
  rC Clang

https://reviews.llvm.org/D52323



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


[PATCH] D52323: Add necessary support for storing code-model to module IR.

2018-09-21 Thread Caroline Tice via Phabricator via cfe-commits
cmtice updated this revision to Diff 166492.
cmtice edited the summary of this revision.
cmtice added a comment.

Move include statement from  CodeGenModule.h to CodeGenModule.cpp
Remove incorrect "default" case statement.
Add test for "tiny" code model.


https://reviews.llvm.org/D52323

Files:
  lib/CodeGen/CodeGenModule.cpp
  test/CodeGen/codemodels.c


Index: test/CodeGen/codemodels.c
===
--- test/CodeGen/codemodels.c
+++ test/CodeGen/codemodels.c
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -emit-llvm  %s -o - | FileCheck %s 
-check-prefix=CHECK-NOMODEL
+// RUN: %clang_cc1 -emit-llvm -mcode-model tiny %s -o - | FileCheck %s 
-check-prefix=CHECK-TINY
+// RUN: %clang_cc1 -emit-llvm -mcode-model small %s -o - | FileCheck %s 
-check-prefix=CHECK-SMALL
+// RUN: %clang_cc1 -emit-llvm -mcode-model kernel %s -o - | FileCheck %s 
-check-prefix=CHECK-KERNEL
+// RUN: %clang_cc1 -emit-llvm -mcode-model medium %s -o - | FileCheck %s 
-check-prefix=CHECK-MEDIUM
+// RUN: %clang_cc1 -emit-llvm -mcode-model large %s -o - | FileCheck %s 
-check-prefix=CHECK-LARGE
+
+// CHECK-TINY: !llvm.module.flags = !{{{.*}}}
+// CHECK-TINY: !{{[0-9]+}} = !{i32 1, !"Code Model", i32 0}
+// CHECK-SMALL: !llvm.module.flags = !{{{.*}}}
+// CHECK-SMALL: !{{[0-9]+}} = !{i32 1, !"Code Model", i32 1}
+// CHECK-KERNEL: !llvm.module.flags = !{{{.*}}}
+// CHECK-KERNEL: !{{[0-9]+}} = !{i32 1, !"Code Model", i32 2}
+// CHECK-MEDIUM: !llvm.module.flags = !{{{.*}}}
+// CHECK-MEDIUM: !{{[0-9]+}} = !{i32 1, !"Code Model", i32 3}
+// CHECK-LARGE: !llvm.module.flags = !{{{.*}}}
+// CHECK-LARGE: !{{[0-9]+}} = !{i32 1, !"Code Model", i32 4}
+// CHECK-NOMODEL-NOT: Code Model
Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -44,6 +44,7 @@
 #include "clang/CodeGen/ConstantInitBuilder.h"
 #include "clang/Frontend/CodeGenOptions.h"
 #include "clang/Sema/SemaDiagnostic.h"
+#include "llvm/ADT/StringSwitch.h"
 #include "llvm/ADT/Triple.h"
 #include "llvm/Analysis/TargetLibraryInfo.h"
 #include "llvm/IR/CallSite.h"
@@ -53,6 +54,7 @@
 #include "llvm/IR/LLVMContext.h"
 #include "llvm/IR/Module.h"
 #include "llvm/ProfileData/InstrProfReader.h"
+#include "llvm/Support/CodeGen.h"
 #include "llvm/Support/ConvertUTF.h"
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/MD5.h"
@@ -556,6 +558,20 @@
   getModule().setPIELevel(static_cast(PLevel));
   }
 
+  if (getCodeGenOpts().CodeModel.size() > 0) {
+unsigned CM = llvm::StringSwitch(getCodeGenOpts().CodeModel)
+  .Case("tiny", llvm::CodeModel::Tiny)
+  .Case("small", llvm::CodeModel::Small)
+  .Case("kernel", llvm::CodeModel::Kernel)
+  .Case("medium", llvm::CodeModel::Medium)
+  .Case("large", llvm::CodeModel::Large)
+  .Default(~0u);
+if (CM != ~0u) {
+  llvm::CodeModel::Model codeModel = 
static_cast(CM);
+  getModule().setCodeModel(codeModel);
+}
+  }
+
   if (CodeGenOpts.NoPLT)
 getModule().setRtLibUseGOT();
 


Index: test/CodeGen/codemodels.c
===
--- test/CodeGen/codemodels.c
+++ test/CodeGen/codemodels.c
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -emit-llvm  %s -o - | FileCheck %s -check-prefix=CHECK-NOMODEL
+// RUN: %clang_cc1 -emit-llvm -mcode-model tiny %s -o - | FileCheck %s -check-prefix=CHECK-TINY
+// RUN: %clang_cc1 -emit-llvm -mcode-model small %s -o - | FileCheck %s -check-prefix=CHECK-SMALL
+// RUN: %clang_cc1 -emit-llvm -mcode-model kernel %s -o - | FileCheck %s -check-prefix=CHECK-KERNEL
+// RUN: %clang_cc1 -emit-llvm -mcode-model medium %s -o - | FileCheck %s -check-prefix=CHECK-MEDIUM
+// RUN: %clang_cc1 -emit-llvm -mcode-model large %s -o - | FileCheck %s -check-prefix=CHECK-LARGE
+
+// CHECK-TINY: !llvm.module.flags = !{{{.*}}}
+// CHECK-TINY: !{{[0-9]+}} = !{i32 1, !"Code Model", i32 0}
+// CHECK-SMALL: !llvm.module.flags = !{{{.*}}}
+// CHECK-SMALL: !{{[0-9]+}} = !{i32 1, !"Code Model", i32 1}
+// CHECK-KERNEL: !llvm.module.flags = !{{{.*}}}
+// CHECK-KERNEL: !{{[0-9]+}} = !{i32 1, !"Code Model", i32 2}
+// CHECK-MEDIUM: !llvm.module.flags = !{{{.*}}}
+// CHECK-MEDIUM: !{{[0-9]+}} = !{i32 1, !"Code Model", i32 3}
+// CHECK-LARGE: !llvm.module.flags = !{{{.*}}}
+// CHECK-LARGE: !{{[0-9]+}} = !{i32 1, !"Code Model", i32 4}
+// CHECK-NOMODEL-NOT: Code Model
Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -44,6 +44,7 @@
 #include "clang/CodeGen/ConstantInitBuilder.h"
 #include "clang/Frontend/CodeGenOptions.h"
 #include "clang/Sema/SemaDiagnostic.h"
+#include "llvm/ADT/StringSwitch.h"
 #include "llvm/ADT/Triple.h"
 #include "llvm/Analysis/TargetLibraryInfo.h"
 #include "llvm/IR/CallSite.h"
@@ -53,6 +5

[PATCH] D52339: Support enums with a fixed underlying type in all language modes

2018-09-21 Thread JF Bastien via Phabricator via cfe-commits
jfb added a comment.

In https://reviews.llvm.org/D52339#1242103, @aaron.ballman wrote:

> In https://reviews.llvm.org/D52339#1242086, @jfb wrote:
>
> > I think we should consider proposing this to the C committee. 
> > @aaron.ballman I can help Erik write the paper, would you be able to 
> > present it? Too tight for the upcoming meeting, but I'm guessing we have 
> > *plenty* of time for ++C17.
>
>
> It's already been proposed to WG14 and is currently on the SD-3 list of 
> features to consider for C2x. See 
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2008.pdf. I know Clive and 
> am happy to point him towards this patch (when it lands) as demonstration of 
> industry desire for the feature, in case he needs to provide updated papers.


Wonderful! Does this match he proposed C2x semantics? Once voted in we'll want 
to change this from just an extension to also be a `-std=c2x` thing, better 
have them match now.


Repository:
  rC Clang

https://reviews.llvm.org/D52339



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


[PATCH] D52339: Support enums with a fixed underlying type in all language modes

2018-09-21 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In https://reviews.llvm.org/D52339#1242118, @jfb wrote:

> In https://reviews.llvm.org/D52339#1242103, @aaron.ballman wrote:
>
> > In https://reviews.llvm.org/D52339#1242086, @jfb wrote:
> >
> > > I think we should consider proposing this to the C committee. 
> > > @aaron.ballman I can help Erik write the paper, would you be able to 
> > > present it? Too tight for the upcoming meeting, but I'm guessing we have 
> > > *plenty* of time for ++C17.
> >
> >
> > It's already been proposed to WG14 and is currently on the SD-3 list of 
> > features to consider for C2x. See 
> > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2008.pdf. I know Clive and 
> > am happy to point him towards this patch (when it lands) as demonstration 
> > of industry desire for the feature, in case he needs to provide updated 
> > papers.
>
>
> Wonderful! Does this match he proposed C2x semantics? Once voted in we'll 
> want to change this from just an extension to also be a `-std=c2x` thing, 
> better have them match now.


I have to validate that still, but from a quick look, I think we're in the 
ballpark if not outright compatible.


Repository:
  rC Clang

https://reviews.llvm.org/D52339



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


[PATCH] D52321: [CUDA] Fixed parsing of optional template-argument-list.

2018-09-21 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith accepted this revision.
rsmith added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/lib/Parse/ParseTemplate.cpp:949-950
 GreaterThanIsOperatorScope G(GreaterThanIsOperator, false);
-if (Tok.isNot(tok::greater) && Tok.isNot(tok::greatergreater))
+if (!Tok.isOneOf(tok::greater, tok::greatergreater,
+ tok::greatergreatergreater))
   Invalid = ParseTemplateArgumentList(TemplateArgs);

It'd be good to include the other tokens that start with `>` here (which we 
also split as an extension): `tok::greaterequal` and `tok::greatergreaterequal`.


https://reviews.llvm.org/D52321



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


[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.

2018-09-21 Thread George Rimar via Phabricator via cfe-commits
grimar added a comment.

To summarise:

- It shares most of the benefits with the .dwo solution.
- Unlike .dwo, there is no need to split the file and it is friendlier to other 
tools (ccache, distcc, etc)
- But unlike .dwo a distributed build system has to copy larger .o files.


https://reviews.llvm.org/D52296



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


[PATCH] D52281: [clang-tidy] Add modernize check to use std::invoke in generic code

2018-09-21 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang-tidy/modernize/ReplaceGenericFunctorCallCheck.cpp:27-32
+  // template
+  // void f(T func) {
+  //   func();
+  //   ^~~
+  //   ::std::invoke(func, 1)
+  Finder->addMatcher(callExpr(has(declRefExpr())).bind("functor"), this);

lebedev.ri wrote:
> aaron.ballman wrote:
> > lebedev.ri wrote:
> > > Bikeshedding: i do not understand the idea behind `std::invoke`.
> > > Why is the new version better/preferred?
> > It generically handles all the various kinds of "callable" objects 
> > (lambdas, functors, function pointers, pointer to member functions, etc).
> Thank you for answering, but i still do not understand.
> E.g. on that example, what benefits does it give?
> Even after looking at cppreference, i'm not sure..
> Just curious.
Genericity is the primary benefit. Here's the original paper with its 
motivation:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3727.html


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D52281



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


r342749 - [CUDA] Ignore uncallable functions when we check for usual deallocators.

2018-09-21 Thread Artem Belevich via cfe-commits
Author: tra
Date: Fri Sep 21 10:29:33 2018
New Revision: 342749

URL: http://llvm.org/viewvc/llvm-project?rev=342749&view=rev
Log:
[CUDA] Ignore uncallable functions when we check for usual deallocators.

Previously clang considered function variants from both sides of
compilation and that resulted in picking up wrong deallocation function.

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

Added:
cfe/trunk/test/CodeGenCUDA/usual-deallocators.cu
cfe/trunk/test/SemaCUDA/usual-deallocators.cu
Modified:
cfe/trunk/include/clang/AST/DeclCXX.h
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/AST/DeclCXX.cpp
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
cfe/trunk/lib/Sema/SemaExprCXX.cpp
cfe/trunk/test/SemaCUDA/call-host-fn-from-device.cu

Modified: cfe/trunk/include/clang/AST/DeclCXX.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclCXX.h?rev=342749&r1=342748&r2=342749&view=diff
==
--- cfe/trunk/include/clang/AST/DeclCXX.h (original)
+++ cfe/trunk/include/clang/AST/DeclCXX.h Fri Sep 21 10:29:33 2018
@@ -2109,10 +2109,15 @@ public:
 Base, IsAppleKext);
   }
 
-  /// Determine whether this is a usual deallocation function
-  /// (C++ [basic.stc.dynamic.deallocation]p2), which is an overloaded
-  /// delete or delete[] operator with a particular signature.
-  bool isUsualDeallocationFunction() const;
+  /// Determine whether this is a usual deallocation function (C++
+  /// [basic.stc.dynamic.deallocation]p2), which is an overloaded delete or
+  /// delete[] operator with a particular signature. Populates \p PreventedBy
+  /// with the declarations of the functions of the same kind if they were the
+  /// reason for this function returning false. This is used by
+  /// Sema::isUsualDeallocationFunction to reconsider the answer based on the
+  /// context.
+  bool isUsualDeallocationFunction(
+  SmallVectorImpl &PreventedBy) const;
 
   /// Determine whether this is a copy-assignment operator, regardless
   /// of whether it was declared implicitly or explicitly.

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=342749&r1=342748&r2=342749&view=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Fri Sep 21 10:29:33 2018
@@ -1619,6 +1619,8 @@ public:
   SourceLocation Loc, const NamedDecl *D,
   ArrayRef Equiv);
 
+  bool isUsualDeallocationFunction(const CXXMethodDecl *FD);
+
   bool isCompleteType(SourceLocation Loc, QualType T) {
 return !RequireCompleteTypeImpl(Loc, T, nullptr);
   }

Modified: cfe/trunk/lib/AST/DeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/DeclCXX.cpp?rev=342749&r1=342748&r2=342749&view=diff
==
--- cfe/trunk/lib/AST/DeclCXX.cpp (original)
+++ cfe/trunk/lib/AST/DeclCXX.cpp Fri Sep 21 10:29:33 2018
@@ -2005,7 +2005,9 @@ CXXMethodDecl *CXXMethodDecl::getDevirtu
   return nullptr;
 }
 
-bool CXXMethodDecl::isUsualDeallocationFunction() const {
+bool CXXMethodDecl::isUsualDeallocationFunction(
+SmallVectorImpl &PreventedBy) const {
+  assert(PreventedBy.empty() && "PreventedBy is expected to be empty");
   if (getOverloadedOperator() != OO_Delete &&
   getOverloadedOperator() != OO_Array_Delete)
 return false;
@@ -2063,14 +2065,16 @@ bool CXXMethodDecl::isUsualDeallocationF
   // This function is a usual deallocation function if there are no
   // single-parameter deallocation functions of the same kind.
   DeclContext::lookup_result R = getDeclContext()->lookup(getDeclName());
-  for (DeclContext::lookup_result::iterator I = R.begin(), E = R.end();
-   I != E; ++I) {
-if (const auto *FD = dyn_cast(*I))
-  if (FD->getNumParams() == 1)
-return false;
+  bool Result = true;
+  for (const auto *D : R) {
+if (const auto *FD = dyn_cast(D)) {
+  if (FD->getNumParams() == 1) {
+PreventedBy.push_back(FD);
+Result = false;
+  }
+}
   }
-
-  return true;
+  return Result;
 }
 
 bool CXXMethodDecl::isCopyAssignmentOperator() const {

Modified: cfe/trunk/lib/Sema/SemaDeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclCXX.cpp?rev=342749&r1=342748&r2=342749&view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Fri Sep 21 10:29:33 2018
@@ -13183,7 +13183,8 @@ CheckOperatorDeleteDeclaration(Sema &Sem
   // C++ P0722:
   //   A destroying operator delete shall be a usual deallocation function.
   if (MD && !MD->getParent()->isDependentContext() &&
-  MD->isDestroyingOperatorDelete() && !MD->isUsualDeallocationFunction()) {
+  MD->isDestroyingOpera

[PATCH] D52368: [libc++abi] is_strcmp parameter to is_equal is unused for WIN32

2018-09-21 Thread Pirama Arumuga Nainar via Phabricator via cfe-commits
pirama created this revision.
pirama added reviewers: EricWF, srhines, mstorsjo.
Herald added subscribers: libcxx-commits, ldionne, christof.

Mark it as unused to avoid -Wunused-parameter.


Repository:
  rCXXA libc++abi

https://reviews.llvm.org/D52368

Files:
  src/private_typeinfo.cpp


Index: src/private_typeinfo.cpp
===
--- src/private_typeinfo.cpp
+++ src/private_typeinfo.cpp
@@ -51,13 +51,17 @@
 // Defining _LIBCXX_DYNAMIC_FALLBACK does not help since can_catch() calls 
 // is_equal() with use_strcmp=false so the string names are not compared.
 
+#define _UNUSED_IN_WIN32
 #ifdef _WIN32
 #include 
+#define _UNUSED_IN_WIN32 __attribute__((unused))
 #endif
 
 static inline
 bool
-is_equal(const std::type_info* x, const std::type_info* y, bool use_strcmp)
+is_equal(const std::type_info* x,
+ const std::type_info* y,
+ _UNUSED_IN_WIN32 bool use_strcmp)
 {
 #ifndef _WIN32
 if (!use_strcmp)


Index: src/private_typeinfo.cpp
===
--- src/private_typeinfo.cpp
+++ src/private_typeinfo.cpp
@@ -51,13 +51,17 @@
 // Defining _LIBCXX_DYNAMIC_FALLBACK does not help since can_catch() calls 
 // is_equal() with use_strcmp=false so the string names are not compared.
 
+#define _UNUSED_IN_WIN32
 #ifdef _WIN32
 #include 
+#define _UNUSED_IN_WIN32 __attribute__((unused))
 #endif
 
 static inline
 bool
-is_equal(const std::type_info* x, const std::type_info* y, bool use_strcmp)
+is_equal(const std::type_info* x,
+ const std::type_info* y,
+ _UNUSED_IN_WIN32 bool use_strcmp)
 {
 #ifndef _WIN32
 if (!use_strcmp)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D51808: [CUDA] Ignore uncallable functions when we check for usual deallocators.

2018-09-21 Thread Artem Belevich via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL342749: [CUDA] Ignore uncallable functions when we check for 
usual deallocators. (authored by tra, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D51808?vs=166053&id=166504#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D51808

Files:
  cfe/trunk/include/clang/AST/DeclCXX.h
  cfe/trunk/include/clang/Sema/Sema.h
  cfe/trunk/lib/AST/DeclCXX.cpp
  cfe/trunk/lib/Sema/SemaDeclCXX.cpp
  cfe/trunk/lib/Sema/SemaExprCXX.cpp
  cfe/trunk/test/CodeGenCUDA/usual-deallocators.cu
  cfe/trunk/test/SemaCUDA/call-host-fn-from-device.cu
  cfe/trunk/test/SemaCUDA/usual-deallocators.cu

Index: cfe/trunk/include/clang/AST/DeclCXX.h
===
--- cfe/trunk/include/clang/AST/DeclCXX.h
+++ cfe/trunk/include/clang/AST/DeclCXX.h
@@ -2109,10 +2109,15 @@
 Base, IsAppleKext);
   }
 
-  /// Determine whether this is a usual deallocation function
-  /// (C++ [basic.stc.dynamic.deallocation]p2), which is an overloaded
-  /// delete or delete[] operator with a particular signature.
-  bool isUsualDeallocationFunction() const;
+  /// Determine whether this is a usual deallocation function (C++
+  /// [basic.stc.dynamic.deallocation]p2), which is an overloaded delete or
+  /// delete[] operator with a particular signature. Populates \p PreventedBy
+  /// with the declarations of the functions of the same kind if they were the
+  /// reason for this function returning false. This is used by
+  /// Sema::isUsualDeallocationFunction to reconsider the answer based on the
+  /// context.
+  bool isUsualDeallocationFunction(
+  SmallVectorImpl &PreventedBy) const;
 
   /// Determine whether this is a copy-assignment operator, regardless
   /// of whether it was declared implicitly or explicitly.
Index: cfe/trunk/include/clang/Sema/Sema.h
===
--- cfe/trunk/include/clang/Sema/Sema.h
+++ cfe/trunk/include/clang/Sema/Sema.h
@@ -1619,6 +1619,8 @@
   SourceLocation Loc, const NamedDecl *D,
   ArrayRef Equiv);
 
+  bool isUsualDeallocationFunction(const CXXMethodDecl *FD);
+
   bool isCompleteType(SourceLocation Loc, QualType T) {
 return !RequireCompleteTypeImpl(Loc, T, nullptr);
   }
Index: cfe/trunk/test/CodeGenCUDA/usual-deallocators.cu
===
--- cfe/trunk/test/CodeGenCUDA/usual-deallocators.cu
+++ cfe/trunk/test/CodeGenCUDA/usual-deallocators.cu
@@ -0,0 +1,133 @@
+// RUN: %clang_cc1 %s --std=c++11 -triple nvptx-unknown-unknown -fcuda-is-device \
+// RUN:   -emit-llvm -o - | FileCheck %s --check-prefixes=COMMON,DEVICE
+// RUN: %clang_cc1 %s --std=c++11 -triple nvptx-unknown-unknown \
+// RUN:   -emit-llvm -o - | FileCheck %s --check-prefixes=COMMON,HOST
+// RUN: %clang_cc1 %s --std=c++17 -triple nvptx-unknown-unknown -fcuda-is-device \
+// RUN:   -emit-llvm -o - | FileCheck %s --check-prefixes=COMMON,DEVICE
+// RUN: %clang_cc1 %s --std=c++17 -triple nvptx-unknown-unknown \
+// RUN:   -emit-llvm -o - | FileCheck %s --check-prefixes=COMMON,HOST
+
+#include "Inputs/cuda.h"
+extern "C" __host__ void host_fn();
+extern "C" __device__ void dev_fn();
+extern "C" __host__ __device__ void hd_fn();
+
+struct H1D1 {
+  __host__ void operator delete(void *) { host_fn(); };
+  __device__ void operator delete(void *) { dev_fn(); };
+};
+
+struct H1D2 {
+  __host__ void operator delete(void *) { host_fn(); };
+  __device__ void operator delete(void *, __SIZE_TYPE__) { dev_fn(); };
+};
+
+struct H2D1 {
+  __host__ void operator delete(void *, __SIZE_TYPE__) { host_fn(); };
+  __device__ void operator delete(void *) { dev_fn(); };
+};
+
+struct H2D2 {
+  __host__ void operator delete(void *, __SIZE_TYPE__) { host_fn(); };
+  __device__ void operator delete(void *, __SIZE_TYPE__) { dev_fn(); };
+};
+
+struct H1D1D2 {
+  __host__ void operator delete(void *) { host_fn(); };
+  __device__ void operator delete(void *) { dev_fn(); };
+  __device__ void operator delete(void *, __SIZE_TYPE__) { dev_fn(); };
+};
+
+struct H1H2D1 {
+  __host__ void operator delete(void *) { host_fn(); };
+  __host__ void operator delete(void *, __SIZE_TYPE__) { host_fn(); };
+  __device__ void operator delete(void *) { dev_fn(); };
+};
+
+struct H1H2D2 {
+  __host__ void operator delete(void *) { host_fn(); };
+  __host__ void operator delete(void *, __SIZE_TYPE__) { host_fn(); };
+  __device__ void operator delete(void *, __SIZE_TYPE__) { dev_fn(); };
+};
+
+struct H1H2D1D2 {
+  __host__ void operator delete(void *) { host_fn(); };
+  __host__ void operator delete(void *, __SIZE_TYPE__) { host_fn(); };
+  __device__ void operator delete(void *) { dev_fn(); };
+  __device__ void operator delete(void *, __SIZE_TYPE__) { dev_fn(); };
+};
+
+
+template 
+__host__ __device__ void test_hd(void *p) {
+  T *t = (T *)p;
+  delete t;
+}

[PATCH] D52339: Support enums with a fixed underlying type in all language modes

2018-09-21 Thread Erik Pilkington via Phabricator via cfe-commits
erik.pilkington added a comment.

In https://reviews.llvm.org/D52339#1242126, @aaron.ballman wrote:

> In https://reviews.llvm.org/D52339#1242118, @jfb wrote:
>
> > In https://reviews.llvm.org/D52339#1242103, @aaron.ballman wrote:
> >
> > > In https://reviews.llvm.org/D52339#1242086, @jfb wrote:
> > >
> > > > I think we should consider proposing this to the C committee. 
> > > > @aaron.ballman I can help Erik write the paper, would you be able to 
> > > > present it? Too tight for the upcoming meeting, but I'm guessing we 
> > > > have *plenty* of time for ++C17.
> > >
> > >
> > > It's already been proposed to WG14 and is currently on the SD-3 list of 
> > > features to consider for C2x. See 
> > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2008.pdf. I know Clive 
> > > and am happy to point him towards this patch (when it lands) as 
> > > demonstration of industry desire for the feature, in case he needs to 
> > > provide updated papers.
> >
> >
> > Wonderful! Does this match he proposed C2x semantics? Once voted in we'll 
> > want to change this from just an extension to also be a `-std=c2x` thing, 
> > better have them match now.
>
>
> I have to validate that still, but from a quick look, I think we're in the 
> ballpark if not outright compatible.


From the last line in the paper, it seems that C++ compatibility is a goal of 
the paper (or at least a consideration). We should probably think about this 
if/when the final wording gets accepted though.




Comment at: clang/include/clang/Basic/Features.def:90
 FEATURE(objc_default_synthesize_properties, LangOpts.ObjC2)
-FEATURE(objc_fixed_enum, LangOpts.ObjC2)
+FEATURE(objc_fixed_enum, true)
 FEATURE(objc_instancetype, LangOpts.ObjC2)

aaron.ballman wrote:
> Is this really supported in ObjC1, or is there no longer a distinction to be 
> made there?
I suppose it's a first class feature in ObjC2, but an extension in ObjC1. On 
second thought I should probably not change this, because ObjC1 doesn't have 
this as a feature, although it does have it as an extension. 



Comment at: clang/include/clang/Basic/Features.def:233
 EXTENSION(cxx_variadic_templates, LangOpts.CPlusPlus)
+EXTENSION(cxx_fixed_enum, true)
 // C++14 features supported by other languages as extensions.

aaron.ballman wrote:
> Are we sure we want to make this decision for things like OpenCL, Cuda, etc?
I can't think of any reason why not, seems there are a handful of other 
EXTENSION(*, true) features. Do you have a preference?


Repository:
  rC Clang

https://reviews.llvm.org/D52339



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


r342750 - [NFC] remove unused variable

2018-09-21 Thread JF Bastien via cfe-commits
Author: jfb
Date: Fri Sep 21 10:38:41 2018
New Revision: 342750

URL: http://llvm.org/viewvc/llvm-project?rev=342750&view=rev
Log:
[NFC] remove unused variable

It was causing a warning.

Modified:
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp

Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp?rev=342750&r1=342749&r2=342750&view=diff
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Fri Sep 21 10:38:41 2018
@@ -7571,7 +7571,6 @@ public:
   const MapData &BaseData = CI == CE ? L : L1;
   OMPClauseMappableExprCommon::MappableExprComponentListRef SubData =
   SI == SE ? Components : Components1;
-  auto It = CI == CE ? SI : CI;
   auto &OverlappedElements = 
OverlappedData.FindAndConstruct(&BaseData);
   OverlappedElements.getSecond().push_back(SubData);
 }


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


[PATCH] D52321: [CUDA] Fixed parsing of optional template-argument-list.

2018-09-21 Thread Artem Belevich via Phabricator via cfe-commits
tra updated this revision to Diff 166509.
tra added a comment.

Added '>=' and '>>=' to the list of tokens that may indicate the end of the
empty template argument list.


https://reviews.llvm.org/D52321

Files:
  clang/lib/Parse/ParseTemplate.cpp
  clang/test/Parser/cuda-kernel-call-c++11.cu
  clang/test/Parser/cuda-kernel-call.cu


Index: clang/test/Parser/cuda-kernel-call.cu
===
--- clang/test/Parser/cuda-kernel-call.cu
+++ clang/test/Parser/cuda-kernel-call.cu
@@ -1,6 +1,6 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s
 
-template struct S {};
+template struct S {};
 template void f();
 
 void foo(void) {
@@ -13,5 +13,7 @@
   // The following two are parse errors because -std=c++11 is not enabled.
 
   S>> s; // expected-error 2{{use '> >'}}
+  S>> s1; // expected-error 2{{use '> >'}}
   (void)(&f>>==0); // expected-error 2{{use '> >'}}
+  (void)(&f>>==0); // expected-error 2{{use '> >'}}
 }
Index: clang/test/Parser/cuda-kernel-call-c++11.cu
===
--- clang/test/Parser/cuda-kernel-call-c++11.cu
+++ clang/test/Parser/cuda-kernel-call-c++11.cu
@@ -1,6 +1,6 @@
 // RUN: %clang_cc1 -fsyntax-only -std=c++11 -verify %s
 
-template struct S {};
+template struct S {};
 template void f();
 
 
@@ -11,10 +11,14 @@
   // expected-no-diagnostics
 
   S>> s3;
+  S>> s30;
 
   S>>> s4;
+  S>>> s40;
 
   S s5;
+  S s50;
 
   (void)(&f>>==0);
+  (void)(&f>>==0);
 }
Index: clang/lib/Parse/ParseTemplate.cpp
===
--- clang/lib/Parse/ParseTemplate.cpp
+++ clang/lib/Parse/ParseTemplate.cpp
@@ -946,7 +946,9 @@
   bool Invalid = false;
   {
 GreaterThanIsOperatorScope G(GreaterThanIsOperator, false);
-if (Tok.isNot(tok::greater) && Tok.isNot(tok::greatergreater))
+if (!Tok.isOneOf(tok::greater, tok::greatergreater,
+ tok::greatergreatergreater, tok::greaterequal,
+ tok::greatergreaterequal))
   Invalid = ParseTemplateArgumentList(TemplateArgs);
 
 if (Invalid) {


Index: clang/test/Parser/cuda-kernel-call.cu
===
--- clang/test/Parser/cuda-kernel-call.cu
+++ clang/test/Parser/cuda-kernel-call.cu
@@ -1,6 +1,6 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s
 
-template struct S {};
+template struct S {};
 template void f();
 
 void foo(void) {
@@ -13,5 +13,7 @@
   // The following two are parse errors because -std=c++11 is not enabled.
 
   S>> s; // expected-error 2{{use '> >'}}
+  S>> s1; // expected-error 2{{use '> >'}}
   (void)(&f>>==0); // expected-error 2{{use '> >'}}
+  (void)(&f>>==0); // expected-error 2{{use '> >'}}
 }
Index: clang/test/Parser/cuda-kernel-call-c++11.cu
===
--- clang/test/Parser/cuda-kernel-call-c++11.cu
+++ clang/test/Parser/cuda-kernel-call-c++11.cu
@@ -1,6 +1,6 @@
 // RUN: %clang_cc1 -fsyntax-only -std=c++11 -verify %s
 
-template struct S {};
+template struct S {};
 template void f();
 
 
@@ -11,10 +11,14 @@
   // expected-no-diagnostics
 
   S>> s3;
+  S>> s30;
 
   S>>> s4;
+  S>>> s40;
 
   S s5;
+  S s50;
 
   (void)(&f>>==0);
+  (void)(&f>>==0);
 }
Index: clang/lib/Parse/ParseTemplate.cpp
===
--- clang/lib/Parse/ParseTemplate.cpp
+++ clang/lib/Parse/ParseTemplate.cpp
@@ -946,7 +946,9 @@
   bool Invalid = false;
   {
 GreaterThanIsOperatorScope G(GreaterThanIsOperator, false);
-if (Tok.isNot(tok::greater) && Tok.isNot(tok::greatergreater))
+if (!Tok.isOneOf(tok::greater, tok::greatergreater,
+ tok::greatergreatergreater, tok::greaterequal,
+ tok::greatergreaterequal))
   Invalid = ParseTemplateArgumentList(TemplateArgs);
 
 if (Invalid) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D52339: Support enums with a fixed underlying type in all language modes

2018-09-21 Thread Erik Pilkington via Phabricator via cfe-commits
erik.pilkington added inline comments.



Comment at: clang/include/clang/Basic/Features.def:90
 FEATURE(objc_default_synthesize_properties, LangOpts.ObjC2)
-FEATURE(objc_fixed_enum, LangOpts.ObjC2)
+FEATURE(objc_fixed_enum, true)
 FEATURE(objc_instancetype, LangOpts.ObjC2)

erik.pilkington wrote:
> aaron.ballman wrote:
> > Is this really supported in ObjC1, or is there no longer a distinction to 
> > be made there?
> I suppose it's a first class feature in ObjC2, but an extension in ObjC1. On 
> second thought I should probably not change this, because ObjC1 doesn't have 
> this as a feature, although it does have it as an extension. 
On third thought, it looks like we never even try to compile with ObjC1 = 1 and 
ObjC2 = 0, so I guess this is fine as-is.


Repository:
  rC Clang

https://reviews.llvm.org/D52339



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


[PATCH] D52339: Support enums with a fixed underlying type in all language modes

2018-09-21 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In https://reviews.llvm.org/D52339#1242202, @erik.pilkington wrote:

> From the last line in the paper, it seems that C++ compatibility is a goal of 
> the paper (or at least a consideration). We should probably think about this 
> if/when the final wording gets accepted though.


Agreed. WG14's charter explicitly prefers compatibility with C++ when possible.

The part that I wasn't quite sure on were the type constraints in the proposal. 
C++ allows any integral type and ignores cv qualifiers, but the proposal lists 
specific types and doesn't discuss qualifiers. By my reading, this is code 
allowed in C++ but prohibited in the proposed wording:

  enum E : const int32_t {
One
  };

(Because the type is int32_t and is cv-qualified.) However, it's possible 
that's an oversight rather than an intentional design. I'll bring it up with 
Clive to see, but perhaps we can spot other divergences and can provide him 
with a list of concerns on the implementation side.




Comment at: clang/include/clang/Basic/Features.def:233
 EXTENSION(cxx_variadic_templates, LangOpts.CPlusPlus)
+EXTENSION(cxx_fixed_enum, true)
 // C++14 features supported by other languages as extensions.

erik.pilkington wrote:
> aaron.ballman wrote:
> > Are we sure we want to make this decision for things like OpenCL, Cuda, etc?
> I can't think of any reason why not, seems there are a handful of other 
> EXTENSION(*, true) features. Do you have a preference?
I think we should probably ask folks from the projects to see if they're okay 
with the extension or not, but I'd guess this won't be contentious.


Repository:
  rC Clang

https://reviews.llvm.org/D52339



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


[PATCH] D52323: Add necessary support for storing code-model to module IR.

2018-09-21 Thread 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


https://reviews.llvm.org/D52323



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


r342752 - [CUDA] Fixed parsing of optional template-argument-list.

2018-09-21 Thread Artem Belevich via cfe-commits
Author: tra
Date: Fri Sep 21 10:46:28 2018
New Revision: 342752

URL: http://llvm.org/viewvc/llvm-project?rev=342752&view=rev
Log:
[CUDA] Fixed parsing of optional template-argument-list.

We need to consider all tokens that start with '>' when
we're checking for the end of an empty template argument list.

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

Modified:
cfe/trunk/lib/Parse/ParseTemplate.cpp
cfe/trunk/test/Parser/cuda-kernel-call-c++11.cu
cfe/trunk/test/Parser/cuda-kernel-call.cu

Modified: cfe/trunk/lib/Parse/ParseTemplate.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseTemplate.cpp?rev=342752&r1=342751&r2=342752&view=diff
==
--- cfe/trunk/lib/Parse/ParseTemplate.cpp (original)
+++ cfe/trunk/lib/Parse/ParseTemplate.cpp Fri Sep 21 10:46:28 2018
@@ -946,7 +946,9 @@ Parser::ParseTemplateIdAfterTemplateName
   bool Invalid = false;
   {
 GreaterThanIsOperatorScope G(GreaterThanIsOperator, false);
-if (Tok.isNot(tok::greater) && Tok.isNot(tok::greatergreater))
+if (!Tok.isOneOf(tok::greater, tok::greatergreater,
+ tok::greatergreatergreater, tok::greaterequal,
+ tok::greatergreaterequal))
   Invalid = ParseTemplateArgumentList(TemplateArgs);
 
 if (Invalid) {

Modified: cfe/trunk/test/Parser/cuda-kernel-call-c++11.cu
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Parser/cuda-kernel-call-c%2B%2B11.cu?rev=342752&r1=342751&r2=342752&view=diff
==
--- cfe/trunk/test/Parser/cuda-kernel-call-c++11.cu (original)
+++ cfe/trunk/test/Parser/cuda-kernel-call-c++11.cu Fri Sep 21 10:46:28 2018
@@ -1,6 +1,6 @@
 // RUN: %clang_cc1 -fsyntax-only -std=c++11 -verify %s
 
-template struct S {};
+template struct S {};
 template void f();
 
 
@@ -11,10 +11,14 @@ void foo(void) {
   // expected-no-diagnostics
 
   S>> s3;
+  S>> s30;
 
   S>>> s4;
+  S>>> s40;
 
   S s5;
+  S s50;
 
   (void)(&f>>==0);
+  (void)(&f>>==0);
 }

Modified: cfe/trunk/test/Parser/cuda-kernel-call.cu
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Parser/cuda-kernel-call.cu?rev=342752&r1=342751&r2=342752&view=diff
==
--- cfe/trunk/test/Parser/cuda-kernel-call.cu (original)
+++ cfe/trunk/test/Parser/cuda-kernel-call.cu Fri Sep 21 10:46:28 2018
@@ -1,6 +1,6 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s
 
-template struct S {};
+template struct S {};
 template void f();
 
 void foo(void) {
@@ -13,5 +13,7 @@ void foo(void) {
   // The following two are parse errors because -std=c++11 is not enabled.
 
   S>> s; // expected-error 2{{use '> >'}}
+  S>> s1; // expected-error 2{{use '> >'}}
   (void)(&f>>==0); // expected-error 2{{use '> >'}}
+  (void)(&f>>==0); // expected-error 2{{use '> >'}}
 }


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


[PATCH] D52321: [CUDA] Fixed parsing of optional template-argument-list.

2018-09-21 Thread Artem Belevich via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rC342752: [CUDA] Fixed parsing of optional 
template-argument-list. (authored by tra, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D52321?vs=166509&id=166512#toc

Repository:
  rC Clang

https://reviews.llvm.org/D52321

Files:
  lib/Parse/ParseTemplate.cpp
  test/Parser/cuda-kernel-call-c++11.cu
  test/Parser/cuda-kernel-call.cu


Index: test/Parser/cuda-kernel-call-c++11.cu
===
--- test/Parser/cuda-kernel-call-c++11.cu
+++ test/Parser/cuda-kernel-call-c++11.cu
@@ -1,6 +1,6 @@
 // RUN: %clang_cc1 -fsyntax-only -std=c++11 -verify %s
 
-template struct S {};
+template struct S {};
 template void f();
 
 
@@ -11,10 +11,14 @@
   // expected-no-diagnostics
 
   S>> s3;
+  S>> s30;
 
   S>>> s4;
+  S>>> s40;
 
   S s5;
+  S s50;
 
   (void)(&f>>==0);
+  (void)(&f>>==0);
 }
Index: test/Parser/cuda-kernel-call.cu
===
--- test/Parser/cuda-kernel-call.cu
+++ test/Parser/cuda-kernel-call.cu
@@ -1,6 +1,6 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s
 
-template struct S {};
+template struct S {};
 template void f();
 
 void foo(void) {
@@ -13,5 +13,7 @@
   // The following two are parse errors because -std=c++11 is not enabled.
 
   S>> s; // expected-error 2{{use '> >'}}
+  S>> s1; // expected-error 2{{use '> >'}}
   (void)(&f>>==0); // expected-error 2{{use '> >'}}
+  (void)(&f>>==0); // expected-error 2{{use '> >'}}
 }
Index: lib/Parse/ParseTemplate.cpp
===
--- lib/Parse/ParseTemplate.cpp
+++ lib/Parse/ParseTemplate.cpp
@@ -946,7 +946,9 @@
   bool Invalid = false;
   {
 GreaterThanIsOperatorScope G(GreaterThanIsOperator, false);
-if (Tok.isNot(tok::greater) && Tok.isNot(tok::greatergreater))
+if (!Tok.isOneOf(tok::greater, tok::greatergreater,
+ tok::greatergreatergreater, tok::greaterequal,
+ tok::greatergreaterequal))
   Invalid = ParseTemplateArgumentList(TemplateArgs);
 
 if (Invalid) {


Index: test/Parser/cuda-kernel-call-c++11.cu
===
--- test/Parser/cuda-kernel-call-c++11.cu
+++ test/Parser/cuda-kernel-call-c++11.cu
@@ -1,6 +1,6 @@
 // RUN: %clang_cc1 -fsyntax-only -std=c++11 -verify %s
 
-template struct S {};
+template struct S {};
 template void f();
 
 
@@ -11,10 +11,14 @@
   // expected-no-diagnostics
 
   S>> s3;
+  S>> s30;
 
   S>>> s4;
+  S>>> s40;
 
   S s5;
+  S s50;
 
   (void)(&f>>==0);
+  (void)(&f>>==0);
 }
Index: test/Parser/cuda-kernel-call.cu
===
--- test/Parser/cuda-kernel-call.cu
+++ test/Parser/cuda-kernel-call.cu
@@ -1,6 +1,6 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s
 
-template struct S {};
+template struct S {};
 template void f();
 
 void foo(void) {
@@ -13,5 +13,7 @@
   // The following two are parse errors because -std=c++11 is not enabled.
 
   S>> s; // expected-error 2{{use '> >'}}
+  S>> s1; // expected-error 2{{use '> >'}}
   (void)(&f>>==0); // expected-error 2{{use '> >'}}
+  (void)(&f>>==0); // expected-error 2{{use '> >'}}
 }
Index: lib/Parse/ParseTemplate.cpp
===
--- lib/Parse/ParseTemplate.cpp
+++ lib/Parse/ParseTemplate.cpp
@@ -946,7 +946,9 @@
   bool Invalid = false;
   {
 GreaterThanIsOperatorScope G(GreaterThanIsOperator, false);
-if (Tok.isNot(tok::greater) && Tok.isNot(tok::greatergreater))
+if (!Tok.isOneOf(tok::greater, tok::greatergreater,
+ tok::greatergreatergreater, tok::greaterequal,
+ tok::greatergreaterequal))
   Invalid = ParseTemplateArgumentList(TemplateArgs);
 
 if (Invalid) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D52268: [AST] Squeeze some bits in LinkageComputer

2018-09-21 Thread John McCall via Phabricator via cfe-commits
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.

In https://reviews.llvm.org/D52268#1241793, @riccibruno wrote:

> In https://reviews.llvm.org/D52268#1241033, @rjmccall wrote:
>
> > `LinkageComputer` isn't actually persisted anywhere, right?  And there's 
> > maybe one computer active at once?  So this compression is theoretically 
> > saving one pointer of stack space but forcing a bunch of bit-manipulation 
> > every time these fields are accessed.
>
>
> It is not persisted but this saves one pointer per entry in the map. Another 
> factor is that hashing a pair involves hashing
>  each component and then combining the result, which is comparatively much 
> more expansive than just hashing a `PointerIntPair`,
>  which involves only a shift and a xor. The field storing the 
> `LVComputationKind` is never directly read but only used to differentiate
>  various kinds of computations in the map. I went back and instrumented the 
> lookup function `LinkageComputer::lookup` with `rdtsc`,
>  and (with all the usual caveats about microbenchmarks and `rdtsc`) I get 
> that this cuts the number of ticks spent inside `lookup`
>  from about 8e6 to 3.5e6. Now of course taking a step back this represent 
> only milliseconds and is firmly in the category of
>  "way to small to bother",  but now we might as well do it.


Oh, I see, the commit summary is wrong.  You're not compressing 
`LinkageComputer`, you're compressing a lookup key type.  LGTM.


Repository:
  rC Clang

https://reviews.llvm.org/D52268



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


[PATCH] D52339: Support enums with a fixed underlying type in all language modes

2018-09-21 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

In https://reviews.llvm.org/D52339#1242241, @aaron.ballman wrote:

> In https://reviews.llvm.org/D52339#1242202, @erik.pilkington wrote:
>
> > From the last line in the paper, it seems that C++ compatibility is a goal 
> > of the paper (or at least a consideration). We should probably think about 
> > this if/when the final wording gets accepted though.
>
>
> Agreed. WG14's charter explicitly prefers compatibility with C++ when 
> possible.
>
> The part that I wasn't quite sure on were the type constraints in the 
> proposal. C++ allows any integral type and ignores cv qualifiers, but the 
> proposal lists specific types and doesn't discuss qualifiers. By my reading, 
> this is code allowed in C++ but prohibited in the proposed wording:
>
>   enum E : const int32_t {
> One
>   };
>
>
> (Because the type is int32_t and is cv-qualified.) However, it's possible 
> that's an oversight rather than an intentional design. I'll bring it up with 
> Clive to see, but perhaps we can spot other divergences and can provide him 
> with a list of concerns on the implementation side.


Not accepting `typedef`s would be negligence on behalf of the committee, since 
generally people use this feature specifically to control the size of the 
`enum`, which you can't do portably without a `typedef`.  Not accepting 
qualified types is a justifiable decision.

There's no reason to make this an `ObjC2`-only feature; we should probably 
eliminate that distinction throughout the compiler.


Repository:
  rC Clang

https://reviews.llvm.org/D52339



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


[PATCH] D52368: [libc++abi] is_strcmp parameter to is_equal is unused for WIN32

2018-09-21 Thread Marshall Clow via Phabricator via cfe-commits
mclow.lists added a comment.

This seems like overkill to me; why not add `(void) use_strcmp` right before 
line 67 instead?


Repository:
  rCXXA libc++abi

https://reviews.llvm.org/D52368



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


[PATCH] D50229: [ARM][AArch64] Add feature +fp16fml

2018-09-21 Thread 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


https://reviews.llvm.org/D50229



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


[PATCH] D52339: Support enums with a fixed underlying type in all language modes

2018-09-21 Thread Erik Pilkington via Phabricator via cfe-commits
erik.pilkington added a comment.

> There's no reason to make this an `ObjC2`-only feature; we should probably 
> eliminate that distinction throughout the compiler.

Sure, I was just writing a proposal to do that: 
http://lists.llvm.org/pipermail/cfe-dev/2018-September/059468.html


Repository:
  rC Clang

https://reviews.llvm.org/D52339



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


[PATCH] D52268: [AST] Squeeze some bits in LinkageComputer

2018-09-21 Thread George Burgess IV via Phabricator via cfe-commits
george.burgess.iv accepted this revision.
george.burgess.iv added a comment.

LGTM too.

Thanks again!


Repository:
  rC Clang

https://reviews.llvm.org/D52268



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


[PATCH] D51812: Simplify CheckFallThroughForBody

2018-09-21 Thread Geoffrey Romer via Phabricator via cfe-commits
gromer updated this revision to Diff 166521.
gromer marked 2 inline comments as done.

https://reviews.llvm.org/D51812

Files:
  B/llvm/tools/clang/lib/Sema/AnalysisBasedWarnings.cpp

Index: B/llvm/tools/clang/lib/Sema/AnalysisBasedWarnings.cpp
===
--- B/llvm/tools/clang/lib/Sema/AnalysisBasedWarnings.cpp
+++ B/llvm/tools/clang/lib/Sema/AnalysisBasedWarnings.cpp
@@ -509,8 +509,7 @@
   bool HasNoReturnAttr = FT->getNoReturnAttr();
 
   // Short circuit for compilation speed.
-  if (!ReturnsValue && !HasNoReturnAttr)
-  return;
+  if (!ReturnsValue && !HasNoReturnAttr) return;
 
   SourceLocation RBrace = Body->getEndLoc();
   switch (CheckFallThrough(AC)) {
@@ -535,25 +534,20 @@
   }
 }
 
-static void CheckFallThroughForLambda(
-Sema &S, const Decl *D, const Stmt *Body, AnalysisDeclContext &AC,
-sema::FunctionScopeInfo *FSI) {
+static void CheckFallThroughForLambda(Sema &S, const Decl *D, const Stmt *Body,
+  AnalysisDeclContext &AC,
+  sema::FunctionScopeInfo *FSI) {
   const auto *FD = dyn_cast(D);
   if (FD == nullptr) return;
 
-  // cpu_dispatch functions permit empty function bodies for ICC compatibility.
-  if (FD->isCPUDispatchMultiVersion())
-return;
-
   auto *LSI = cast(FSI);
   bool ReturnsValue = LSI->WrappedReturnType.isNull()
-  ? !FD->getReturnType()->isVoidType()
-  : LSI->CoroutineHasNonVoidReturn;
+  ? !FD->getReturnType()->isVoidType()
+  : LSI->CoroutineHasNonVoidReturn;
   bool HasNoReturnAttr = FD->isNoReturn();
 
   // Short circuit for compilation speed.
-  if (!ReturnsValue && !HasNoReturnAttr)
-  return;
+  if (!ReturnsValue && !HasNoReturnAttr) return;
 
   SourceLocation RBrace = Body->getEndLoc();
   switch (CheckFallThrough(AC)) {
@@ -576,9 +570,10 @@
   }
 }
 
-static void CheckFallThroughForCoroutine(
-Sema &S, const Decl *D, const Stmt *Body,
-AnalysisDeclContext &AC, sema::FunctionScopeInfo *FSI) {
+static void CheckFallThroughForCoroutine(Sema &S, const Decl *D,
+ const Stmt *Body,
+ AnalysisDeclContext &AC,
+ sema::FunctionScopeInfo *FSI) {
   const auto *FD = dyn_cast(D);
   if (FD == nullptr) return;
 
@@ -597,8 +592,8 @@
D->getLocation()) ||
Diags.isIgnored(diag::warn_maybe_falloff_nonvoid_coroutine,
D->getLocation())) &&
-  (!HasNoReturnAttr))
-  return;
+  !HasNoReturnAttr)
+return;
 
   SourceLocation RBrace = Body->getEndLoc();
   switch (CheckFallThrough(AC)) {
@@ -619,9 +614,9 @@
   }
 }
 
-static void CheckFallThroughForFunction(
-Sema &S, const Decl *D, const Stmt *Body,
-AnalysisDeclContext &AC) {
+static void CheckFallThroughForFunction(Sema &S, const Decl *D,
+const Stmt *Body,
+AnalysisDeclContext &AC) {
   bool ReturnsVoid = false;
   bool HasNoReturnAttr = false;
   bool SuggestNoReturn = true;
@@ -642,8 +637,7 @@
   isTemplateInstantiation = Function->isTemplateInstantiation();
 
 SuggestNoReturn = !isVirtualMethod && !isTemplateInstantiation;
-  }
-  else if (const auto *MD = dyn_cast(D)) {
+  } else if (const auto *MD = dyn_cast(D)) {
 ReturnsVoid = MD->getReturnType()->isVoidType();
 HasNoReturnAttr = MD->hasAttr();
   }
@@ -654,9 +648,8 @@
 
   // Short circuit for compilation speed.
   DiagnosticsEngine &Diags = S.getDiagnostics();
-  if ((ReturnsVoid ||
-   Diags.isIgnored(diag::warn_maybe_falloff_nonvoid_function,
-   D->getLocation())) &&
+  if ((ReturnsVoid || Diags.isIgnored(diag::warn_maybe_falloff_nonvoid_function,
+  D->getLocation())) &&
   (!HasNoReturnAttr ||
Diags.isIgnored(diag::warn_noreturn_function_has_return_expr,
D->getLocation())) &&
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


  1   2   >