summaryrefslogtreecommitdiff
path: root/include
Commit message (Collapse)AuthorAgeFilesLines
* Refactor DependencyScanningTool to its own fileKousik Kumar2019-10-221-0/+48
| | | | | | | | | | | | | | | | | Summary: There's no behavior change - just moving DependencyScanningTool to its own file since this tool can be reused across both clang-scan-deps binary and an interface exposed as part of libClang APIs. Reviewers: arphaman, jkorous, Bigcheese, dexonsmith Subscribers: mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69186 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375483 91177308-0d34-0410-b5e6-96231b3b80d8
* [Implicit Modules] Add -cc1 option -fmodules-strict-context-hash which ↵Michael J. Spencer2019-10-212-1/+22
| | | | | | | | includes search paths and diagnostics. This is a recommit of r375322 and r375327 with a fix for the Windows test breakage. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375466 91177308-0d34-0410-b5e6-96231b3b80d8
* [Clang] Add VerboseOutputStream to CompilerInstanceScott Linder2019-10-211-3/+21
| | | | | | | | | | | | Remove one instance of a hardcoded output stream in CompilerInstance::ExecuteAction. There are still other cases of output being hard-coded to standard streams in ExecuteCompilerInvocation, but this patch covers the case when no flags like -version or -help are passed, namely the "X warnings and Y errors generated." diagnostic. Differential Revision: https://reviews.llvm.org/D53768 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375442 91177308-0d34-0410-b5e6-96231b3b80d8
* Prune include of DataLayout.h from include/clang/Basic/TargetInfo.h. NFCBjorn Pettersson2019-10-211-4/+4
| | | | | | | | | | | | | | | | | | | | | | | Summary: Use a forward declaration of DataLayout instead of including DataLayout.h in clangs TargetInfo.h. This reduces include dependencies toward DataLayout.h (and other headers such as DerivedTypes.h, Type.h that is included by DataLayout.h). Needed to move implemantation of TargetInfo::resetDataLayout from TargetInfo.h to TargetInfo.cpp. Reviewers: rnk Reviewed By: rnk Subscribers: jvesely, nhaehnle, cfe-commits, llvm-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69262 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375438 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix Wdocumentation warning. NFCI.Simon Pilgrim2019-10-211-2/+2
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375434 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "[Implicit Modules] Add -cc1 option -fmodules-strict-context-hash ↵Michael J. Spencer2019-10-192-22/+1
| | | | | | | | which includes search paths and diagnostics." and "[Docs] Fix header level." The test doesn't work on Windows. I'll fix it and recommit later. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375338 91177308-0d34-0410-b5e6-96231b3b80d8
* Add -Wbitwise-conditional-parentheses to warn on mixing '|' and '&' with "?:"Richard Trieu2019-10-192-0/+5
| | | | | | | | | | | | | | | | | | | | | | Extend -Wparentheses to cover mixing bitwise-and and bitwise-or with the conditional operator. There's two main cases seen with this: unsigned bits1 = 0xf0 | cond ? 0x4 : 0x1; unsigned bits2 = cond1 ? 0xf0 : 0x10 | cond2 ? 0x5 : 0x2; // Intended order of evaluation: unsigned bits1 = 0xf0 | (cond ? 0x4 : 0x1); unsigned bits2 = (cond1 ? 0xf0 : 0x10) | (cond2 ? 0x5 : 0x2); // Actual order of evaluation: unsigned bits1 = (0xf0 | cond) ? 0x4 : 0x1; unsigned bits2 = cond1 ? 0xf0 : ((0x10 | cond2) ? 0x5 : 0x2); Differential Revision: https://reviews.llvm.org/D66043 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375326 91177308-0d34-0410-b5e6-96231b3b80d8
* [Implicit Modules] Add -cc1 option -fmodules-strict-context-hash which ↵Michael J. Spencer2019-10-192-1/+22
| | | | | | | | includes search paths and diagnostics. Differential Revision: https://reviews.llvm.org/D68528 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375322 91177308-0d34-0410-b5e6-96231b3b80d8
* New tautological warning for bitwise-or with non-zero constant always true.Richard Trieu2019-10-193-1/+7
| | | | | | | | | | | | | | | | | | | | Taking a value and the bitwise-or it with a non-zero constant will always result in a non-zero value. In a boolean context, this is always true. if (x | 0x4) {} // always true, intended '&' This patch creates a new warning group -Wtautological-bitwise-compare for this warning. It also moves in the existing tautological bitwise comparisons into this group. A few other changes were needed to the CFGBuilder so that all bool contexts would be checked. The warnings in -Wtautological-bitwise-compare will be off by default due to using the CFG. Fixes: https://bugs.llvm.org/show_bug.cgi?id=42666 Differential Revision: https://reviews.llvm.org/D66046 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375318 91177308-0d34-0410-b5e6-96231b3b80d8
* Sema: Create a no-op implicit cast for lvalue function conversions.Peter Collingbourne2019-10-191-5/+5
| | | | | | | | | | This fixes an assertion failure in the case where an implicit conversion for a function call involves an lvalue function conversion, and makes the AST for initializations involving implicit lvalue function conversions more accurate. Differential Revision: https://reviews.llvm.org/D66437 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375313 91177308-0d34-0410-b5e6-96231b3b80d8
* [hip][cuda] Fix the extended lambda name mangling issue.Michael Liao2019-10-192-14/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: - HIP/CUDA host side needs to use device kernel symbol name to match the device side binaries. Without a consistent naming between host- and device-side compilations, it's risky that wrong device binaries are executed. Consistent naming is usually not an issue until unnamed types are used, especially the lambda. In this patch, the consistent name mangling is addressed for the extended lambdas, i.e. the lambdas annotated with `__device__`. - In [Itanium C++ ABI][1], the mangling of the lambda is generally unspecified unless, in certain cases, ODR rule is required to ensure consisent naming cross TUs. The extended lambda is such a case as its name may be part of a device kernel function, e.g., the extended lambda is used as a template argument and etc. Thus, we need to force ODR for extended lambdas as they are referenced in both device- and host-side TUs. Furthermore, if a extended lambda is nested in other (extended or not) lambdas, those lambdas are required to follow ODR naming as well. This patch revises the current lambda mangle numbering to force ODR from an extended lambda to all its parent lambdas. - On the other side, the aforementioned ODR naming should not change those lambdas' original linkages, i.e., we cannot replace the original `internal` with `linkonce_odr`; otherwise, we may violate ODR in general. This patch introduces a new field `HasKnownInternalLinkage` in lambda data to decouple the current linkage calculation based on mangling number assigned. [1]: https://itanium-cxx-abi.github.io/cxx-abi/abi.html Reviewers: tra, rsmith, yaxunl, martong, shafik Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68818 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375309 91177308-0d34-0410-b5e6-96231b3b80d8
* [c++20] Add rewriting from comparison operators to <=> / ==.Richard Smith2019-10-195-63/+188
| | | | | | | | | | | | | | | | | This adds support for rewriting <, >, <=, and >= to a normal or reversed call to operator<=>, for rewriting != to a normal or reversed call to operator==, and for rewriting <=> and == to reversed forms of those same operators. Note that this is a breaking change for various C++17 code patterns, including some in use in LLVM. The most common patterns (where an operator== becomes ambiguous with a reversed form of itself) are still accepted under this patch, as an extension (with a warning). I'm hopeful that we can get the language rules fixed before C++20 ships, and the extension warning is aimed primarily at providing data to inform that decision. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375306 91177308-0d34-0410-b5e6-96231b3b80d8
* [c++20] Add CXXRewrittenBinaryOperator to represent a comparisonRichard Smith2019-10-195-0/+113
| | | | | | | | operator that is rewritten as a call to multiple other operators. No functionality change yet: nothing creates these expressions. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375305 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP50]Add support for master taskloop simd.Alexey Bataev2019-10-188-2/+114
| | | | | | Added trsing/semantics/codegen for combined construct master taskloop simd. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375255 91177308-0d34-0410-b5e6-96231b3b80d8
* [analyzer] Assign truly stable identifiers to exploded nodes.Artem Dergachev2019-10-171-4/+7
| | | | | | | | | | | ExplodedGraph nodes will now have a numeric identifier stored in them which will keep track of the order in which the nodes were created and it will be fully deterministic both accross runs and across machines. This is extremely useful for debugging as it allows reliably setting conditional breakpoints by node IDs. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375186 91177308-0d34-0410-b5e6-96231b3b80d8
* Reland: Dead Virtual Function EliminationOliver Stannard2019-10-172-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove dead virtual functions from vtables with replaceNonMetadataUsesWith, so that CGProfile metadata gets cleaned up correctly. Original commit message: Currently, it is hard for the compiler to remove unused C++ virtual functions, because they are all referenced from vtables, which are referenced by constructors. This means that if the constructor is called from any live code, then we keep every virtual function in the final link, even if there are no call sites which can use it. This patch allows unused virtual functions to be removed during LTO (and regular compilation in limited circumstances) by using type metadata to match virtual function call sites to the vtable slots they might load from. This information can then be used in the global dead code elimination pass instead of the references from vtables to virtual functions, to more accurately determine which functions are reachable. To make this transformation safe, I have changed clang's code-generation to always load virtual function pointers using the llvm.type.checked.load intrinsic, instead of regular load instructions. I originally tried writing this using clang's existing code-generation, which uses the llvm.type.test and llvm.assume intrinsics after doing a normal load. However, it is possible for optimisations to obscure the relationship between the GEP, load and llvm.type.test, causing GlobalDCE to fail to find virtual function call sites. The existing linkage and visibility types don't accurately describe the scope in which a virtual call could be made which uses a given vtable. This is wider than the visibility of the type itself, because a virtual function call could be made using a more-visible base class. I've added a new !vcall_visibility metadata type to represent this, described in TypeMetadata.rst. The internalization pass and libLTO have been updated to change this metadata when linking is performed. This doesn't currently work with ThinLTO, because it needs to see every call to llvm.type.checked.load in the linkage unit. It might be possible to extend this optimisation to be able to use the ThinLTO summary, as was done for devirtualization, but until then that combination is rejected in the clang driver. To test this, I've written a fuzzer which generates random C++ programs with complex class inheritance graphs, and virtual functions called through object and function pointers of different types. The programs are spread across multiple translation units and DSOs to test the different visibility restrictions. I've also tried doing bootstrap builds of LLVM to test this. This isn't ideal, because only classes in anonymous namespaces can be optimised with -fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not work correctly with -fvisibility=hidden. However, there are only 12 test failures when building with -fvisibility=hidden (and an unmodified compiler), and this change does not cause any new failures for either value of -fvisibility. On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size reduction of ~6%, over a baseline compiled with "-O2 -flto -fvisibility=hidden -fwhole-program-vtables". The best cases are reductions of ~14% in 450.soplex and 483.xalancbmk, and there are no code size increases. I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which show a geomean size reduction of ~3%, again with no size increases. I had hoped that this would have no effect on performance, which would allow it to awlays be enabled (when using -fwhole-program-vtables). However, the changes in clang to use the llvm.type.checked.load intrinsic are causing ~1% performance regression in the C++ parts of SPEC2006. It should be possible to recover some of this perf loss by teaching optimisations about the llvm.type.checked.load intrinsic, which would make it worth turning this on by default (though it's still dependent on -fwhole-program-vtables). Differential revision: https://reviews.llvm.org/D63932 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375094 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP]Allow priority clause in combined task-based directives.Alexey Bataev2019-10-162-11/+18
| | | | | | | The expression of the priority clause must be captured in the combined task-based directives, like 'parallel master taskloop' directive. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375026 91177308-0d34-0410-b5e6-96231b3b80d8
* [libTooling] Fix r374962: add more Transformer forwarding decls.Yitzhak Mandelbaum2019-10-163-8/+16
| | | | | | | | | | | | | | | | | | Summary: The move to a new, single namespace in r374962 left out some type definitions from the old namespace and resulted in one naming conflict (`text`). This revision adds aliases for those definitions and removes one of the `text` functions from the new namespace. Reviewers: alexfh Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69036 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375003 91177308-0d34-0410-b5e6-96231b3b80d8
* [libTooling] Put all Transformer declarations in a single namespace.Yitzhak Mandelbaum2019-10-165-16/+71
| | | | | | | | | | | | | | | | Summary: This revision introduces a new namespace, `clang::transformer`, to hold the declarations for the Transformer library. Reviewers: gribozavr Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68876 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374962 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove unnecessary and inappropriate forward-declaration of Sema fromRichard Smith2019-10-151-1/+0
| | | | | | AST. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374952 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP]Fix comments/params, NFC.Alexey Bataev2019-10-151-4/+3
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374943 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP]Allow final clause in combined task-based directives.Alexey Bataev2019-10-152-10/+18
| | | | | | | The condition of the final clause must be captured in the combined task-based directives, like 'parallel master taskloop' directive. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374942 91177308-0d34-0410-b5e6-96231b3b80d8
* [Concept] Associated Constraints InfrastructureSaar Raz2019-10-155-116/+81
| | | | | | | | | Add code to correctly calculate the associated constraints of a template (no enforcement yet). D41284 on Phabricator. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374938 91177308-0d34-0410-b5e6-96231b3b80d8
* Added support for "#pragma clang section relro=<name>"Dmitry Mikulin2019-10-153-3/+13
| | | | | | Differential Revision: https://reviews.llvm.org/D68806 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374934 91177308-0d34-0410-b5e6-96231b3b80d8
* Reland [Driver] Fix -working-directory issuesJan Korous2019-10-151-0/+2
| | | | | | | | Don't change the default VFS in Driver, update tests & reland. This reverts commit 999f8a7416f8edc54ef92e715fd23c532bcc74d4. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374926 91177308-0d34-0410-b5e6-96231b3b80d8
* Add more information to JSON AST dumping of source locations.Aaron Ballman2019-10-151-0/+2
| | | | | | This adds information about the offset within the source file to the given source location as well as information about the include file a location is from. These pieces of information allow for more efficient post-processing of JSON AST dumps. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374921 91177308-0d34-0410-b5e6-96231b3b80d8
* [Concepts] Concept Specialization ExpressionsSaar Raz2019-10-156-6/+179
| | | | | | | | | | | | Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is refe$ D41217 on Phabricator. (recommit after fixing failing Parser test on windows) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374903 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert 374882 "[Concepts] Concept Specialization Expressions"Nico Weber2019-10-156-179/+6
| | | | | | | | | | This reverts commit ec87b003823d63f3342cf648f55a134c1522e612. The test fails on Windows, see e.g. http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/11533/steps/stage%201%20check/logs/stdio Also revert follow-up r374893. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374899 91177308-0d34-0410-b5e6-96231b3b80d8
* Reapply: [Modules][PCH] Hash input files contentBruno Cardoso Lopes2019-10-155-6/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When files often get touched during builds, the mtime based validation leads to different problems in implicit modules builds, even when the content doesn't actually change: - Modules only: module invalidation due to out of date files. Usually causing rebuild traffic. - Modules + PCH: build failures because clang cannot rebuild a module if it comes from building a PCH. - PCH: build failures because clang cannot rebuild a PCH in case one of the input headers has different mtime. This patch proposes hashing the content of input files (headers and module maps), which is performed during serialization time. When looking at input files for validation, clang only computes the hash in case there's a mtime mismatch. I've tested a couple of different hash algorithms availble in LLVM in face of building modules+pch for `#import <Cocoa/Cocoa.h>`: - `hash_code`: performace diff within the noise, total module cache increased by 0.07%. - `SHA1`: 5% slowdown. Haven't done real size measurements, but it'd be BLOCK_ID+20 bytes per input file, instead of BLOCK_ID+8 bytes from `hash_code`. - `MD5`: 3% slowdown. Like above, but BLOCK_ID+16 bytes per input file. Given the numbers above, the patch uses `hash_code`. The patch also improves invalidation error msgs to point out which type of problem the user is facing: "mtime", "size" or "content". rdar://problem/29320105 Reviewers: dexonsmith, arphaman, rsmith, aprantl Subscribers: jkorous, cfe-commits, ributzka Tags: #clang Differential Revision: https://reviews.llvm.org/D67249 llvm-svn: 374841 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374895 91177308-0d34-0410-b5e6-96231b3b80d8
* [Concepts] Concept Specialization ExpressionsSaar Raz2019-10-156-6/+179
| | | | | | | | | Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is referenced with arguments, and tests thereof. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374882 91177308-0d34-0410-b5e6-96231b3b80d8
* [WebAssembly] Trapping fptoint builtins and intrinsicsThomas Lively2019-10-151-0/+10
| | | | | | | | | | | | | | | | | | | | | Summary: The WebAssembly backend lowers fptoint instructions to a code sequence that checks for overflow to avoid traps because fptoint is supposed to be speculatable. These new builtins and intrinsics give users a way to depend on the trapping semantics of the underlying instructions and avoid the extra code generated normally. Patch by coffee and tlively. Reviewers: aheejin Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D68902 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374856 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "Dead Virtual Function Elimination"Jorge Gorbe Moya2019-10-142-11/+0
| | | | | | This reverts commit 9f6a873268e1ad9855873d9d8007086c0d01cf4f. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374844 91177308-0d34-0410-b5e6-96231b3b80d8
* Temporarily Revert [Modules][PCH] Hash input files contentEric Christopher2019-10-145-49/+6
| | | | | | | | as it's breaking a few bots. This reverts r374841 (git commit 2a1386c81de504b5bda44fbecf3f7b4cdfd748fc) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374842 91177308-0d34-0410-b5e6-96231b3b80d8
* [Modules][PCH] Hash input files contentBruno Cardoso Lopes2019-10-145-6/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When files often get touched during builds, the mtime based validation leads to different problems in implicit modules builds, even when the content doesn't actually change: - Modules only: module invalidation due to out of date files. Usually causing rebuild traffic. - Modules + PCH: build failures because clang cannot rebuild a module if it comes from building a PCH. - PCH: build failures because clang cannot rebuild a PCH in case one of the input headers has different mtime. This patch proposes hashing the content of input files (headers and module maps), which is performed during serialization time. When looking at input files for validation, clang only computes the hash in case there's a mtime mismatch. I've tested a couple of different hash algorithms availble in LLVM in face of building modules+pch for `#import <Cocoa/Cocoa.h>`: - `hash_code`: performace diff within the noise, total module cache increased by 0.07%. - `SHA1`: 5% slowdown. Haven't done real size measurements, but it'd be BLOCK_ID+20 bytes per input file, instead of BLOCK_ID+8 bytes from `hash_code`. - `MD5`: 3% slowdown. Like above, but BLOCK_ID+16 bytes per input file. Given the numbers above, the patch uses `hash_code`. The patch also improves invalidation error msgs to point out which type of problem the user is facing: "mtime", "size" or "content". rdar://problem/29320105 Reviewers: dexonsmith, arphaman, rsmith, aprantl Subscribers: jkorous, cfe-commits, ributzka Tags: #clang Differential Revision: https://reviews.llvm.org/D67249 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374841 91177308-0d34-0410-b5e6-96231b3b80d8
* PR43080: Do not build context-sensitive expressions during name classification.Richard Smith2019-10-143-19/+100
| | | | | | | | | | | | | | | | | | | | | | | Summary: We don't know what context to use until the classification result is consumed by the parser, which could happen in a different semantic context. So don't build the expression that results from name classification until we get to that point and can handle it properly. This covers everything except C++ implicit class member access, which is a little awkward to handle properly in the face of the protected member access check. But it at least fixes all the currently-filed instances of PR43080. Reviewers: efriedma Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68896 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374826 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPNEMP]Allow num_tasks clause in combined task-based directives.Alexey Bataev2019-10-142-9/+16
| | | | | | | The expression of the num_tasks clause must be captured in the combined task-based directives, like 'parallel master taskloop' directive. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374819 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-scan-deps] Support for clang --analyze in clang-scan-depsJan Korous2019-10-142-0/+5
| | | | | | | | | | | | | | | The goal is to have 100% fidelity in clang-scan-deps behavior when --analyze is present in compilation command. At the same time I don't want to break clang-tidy which expects __static_analyzer__ macro defined as built-in. I introduce new cc1 options (-setup-static-analyzer) that controls the macro definition and is conditionally set in driver. Differential Revision: https://reviews.llvm.org/D68093 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374815 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPNEMP]Allow grainsize clause in combined task-based directives.Alexey Bataev2019-10-142-9/+16
| | | | | | | The expression of the grainsize clause must be captured in the combined task-based directives, like 'parallel master taskloop' directive. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374810 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP50]Add support for 'parallel master taskloop' construct.Alexey Bataev2019-10-147-1/+111
| | | | | | | | | Added parsing/sema/codegen support for 'parallel master taskloop' constructs. Some of the clauses, like 'grainsize', 'num_tasks', 'final' and 'priority' are not supported in full, only constant expressions can be used currently in these clauses. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374791 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP]Fix codegen for private variably length vars in combinedAlexey Bataev2019-10-141-0/+4
| | | | | | | | | | | constructs. If OpenMP construct includes several capturing regions and the variable is declared as private, the length of the inner variable length array is not captured in outer captured regions, only in the innermost region. Patch fixes this bug. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374787 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang][IFS] Fixing spelling errors in interface-stubs OPT flag (NFC).Puyan Lotfi2019-10-121-2/+2
| | | | | | | This is just a long standing spelling error that was found recently. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374638 91177308-0d34-0410-b5e6-96231b3b80d8
* [ObjC] Remove default parameter no caller was providing. NFC intended.Volodymyr Sapsai2019-10-111-2/+1
| | | | | | | | | Currently there is no need to make ObjCTypeParamType have a canonical type different from the one in corresponding ObjCTypeParamDecl. So remove the corresponding unused API. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374596 91177308-0d34-0410-b5e6-96231b3b80d8
* [Stats] Convert some ad-hoc header search stats to ALWAYS_ENABLED_STATISTIC.Volodymyr Sapsai2019-10-112-12/+0
| | | | | | | | | | | | | | | | | rdar://problem/55715134 Reviewers: dsanders, bogner, rtereshin Reviewed By: dsanders Subscribers: hiraditya, jkorous, dexonsmith, ributzka, cfe-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68252 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374581 91177308-0d34-0410-b5e6-96231b3b80d8
* Update clang module map for new excluded .def file.Richard Smith2019-10-111-0/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374571 91177308-0d34-0410-b5e6-96231b3b80d8
* Reland r374450 with Richard Smith's comments and test fixed.Erich Keane2019-10-111-0/+4
| | | | | | | | | | The behavior from the original patch has changed, since we're no longer allowing LLVM to just ignore the alignment. Instead, we're just assuming the maximum possible alignment. Differential Revision: https://reviews.llvm.org/D68824 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374562 91177308-0d34-0410-b5e6-96231b3b80d8
* [libTooling] Move `RewriteRule` abstraction into its own header and impl.Yitzhak Mandelbaum2019-10-112-271/+291
| | | | | | | | | | | | | | | | | | | Summary: Move the `RewriteRule` class and related declarations into its own set of files (header, implementation). Only the `Transformer` class is left in the Transformer-named files. This change clarifies the distinction between the `RewriteRule` class, which is essential to the Transformer library, and the `Transformer` class, which is only one possible `RewriteRule` interpreter (compare to `TransformerClangTidyCheck`, a clang-tidy based interpreter). Reviewers: gribozavr Subscribers: jfb, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68795 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374558 91177308-0d34-0410-b5e6-96231b3b80d8
* [libTooling] Change Stencil equality to use `toString()`Yitzhak Mandelbaum2019-10-111-24/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Removes the `isEqual` method from StencilPartInterface and modifies equality to use the string representation returned by the `toString` method for comparison. This means the `run` and `selection` stencils return true by default, and clients should be cautious in relying on equality operator for comparison of stencils containing parts generated by these functions. It also means we no longer need the custom RTTI support (typeId() and down_cast()), so it has been removed. Patch by Harshal T. Lehri. Reviewers: gribozavr Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68825 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374552 91177308-0d34-0410-b5e6-96231b3b80d8
* Dead Virtual Function EliminationOliver Stannard2019-10-112-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, it is hard for the compiler to remove unused C++ virtual functions, because they are all referenced from vtables, which are referenced by constructors. This means that if the constructor is called from any live code, then we keep every virtual function in the final link, even if there are no call sites which can use it. This patch allows unused virtual functions to be removed during LTO (and regular compilation in limited circumstances) by using type metadata to match virtual function call sites to the vtable slots they might load from. This information can then be used in the global dead code elimination pass instead of the references from vtables to virtual functions, to more accurately determine which functions are reachable. To make this transformation safe, I have changed clang's code-generation to always load virtual function pointers using the llvm.type.checked.load intrinsic, instead of regular load instructions. I originally tried writing this using clang's existing code-generation, which uses the llvm.type.test and llvm.assume intrinsics after doing a normal load. However, it is possible for optimisations to obscure the relationship between the GEP, load and llvm.type.test, causing GlobalDCE to fail to find virtual function call sites. The existing linkage and visibility types don't accurately describe the scope in which a virtual call could be made which uses a given vtable. This is wider than the visibility of the type itself, because a virtual function call could be made using a more-visible base class. I've added a new !vcall_visibility metadata type to represent this, described in TypeMetadata.rst. The internalization pass and libLTO have been updated to change this metadata when linking is performed. This doesn't currently work with ThinLTO, because it needs to see every call to llvm.type.checked.load in the linkage unit. It might be possible to extend this optimisation to be able to use the ThinLTO summary, as was done for devirtualization, but until then that combination is rejected in the clang driver. To test this, I've written a fuzzer which generates random C++ programs with complex class inheritance graphs, and virtual functions called through object and function pointers of different types. The programs are spread across multiple translation units and DSOs to test the different visibility restrictions. I've also tried doing bootstrap builds of LLVM to test this. This isn't ideal, because only classes in anonymous namespaces can be optimised with -fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not work correctly with -fvisibility=hidden. However, there are only 12 test failures when building with -fvisibility=hidden (and an unmodified compiler), and this change does not cause any new failures for either value of -fvisibility. On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size reduction of ~6%, over a baseline compiled with "-O2 -flto -fvisibility=hidden -fwhole-program-vtables". The best cases are reductions of ~14% in 450.soplex and 483.xalancbmk, and there are no code size increases. I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which show a geomean size reduction of ~3%, again with no size increases. I had hoped that this would have no effect on performance, which would allow it to awlays be enabled (when using -fwhole-program-vtables). However, the changes in clang to use the llvm.type.checked.load intrinsic are causing ~1% performance regression in the C++ parts of SPEC2006. It should be possible to recover some of this perf loss by teaching optimisations about the llvm.type.checked.load intrinsic, which would make it worth turning this on by default (though it's still dependent on -fwhole-program-vtables). Differential revision: https://reviews.llvm.org/D63932 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374539 91177308-0d34-0410-b5e6-96231b3b80d8
* Move most CXXRecordDecl::DefinitionData bit-fields out into a separateRichard Smith2019-10-112-204/+243
| | | | | | | | | | | file. Reduces duplication and thereby reduces the risk that someone will forget to update one of these places, as I did when adding DefaultedDestructorIsConstexpr (though I've been unable to produce a testcase for which that matters so far). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374484 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix help message for -ffp-contractYaxun Liu2019-10-101-1/+2
| | | | | | | Differential Revision: https://reviews.llvm.org/D68823 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374467 91177308-0d34-0410-b5e6-96231b3b80d8
View Lorry Controller Status