Original commit message:
Add -fdiagnostics-show-hotness
Summary:
I've recently added the ability for optimization remarks to include the
hotness of the corresponding code region. This uses PGO and allows
filtering of the optimization remarks by relevance. The idea was first
discussed here:
http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334
The general goal is to produce a YAML file with the remarks. Then, an
external tool could dynamically filter these by hotness and perhaps by
other things.
That said it makes sense to also expose this at the more basic level
where we just include the hotness info with each optimization remark.
For example, in D22694, the clang flag was pretty useful to measure the
overhead of the additional analyses required to include hotness.
(Without the flag we don't even run the analyses.)
For the record, Hal has already expressed support for the idea of this
patch on IRC.
Differential Revision: https://reviews.llvm.org/D23284
llvm-svn: 281293
In c++1z, static_assert is not required to have a StringLiteral message, where
previously it was required. Update the AST Reader to be able to handle a
null StringLiteral.
llvm-svn: 281286
We should be doing the same checks when a type is completed as we do
when a complete type is used during emission. Previously, we duplicated
the logic, and it got out of sync. This could be observed with
dllimported classes.
Also reduce a test case for this slightly.
Implementing review feedback from David Blaikie on r281057.
llvm-svn: 281278
This patch makes us act more conservatively when trying to determine
the objectsize for an array at the end of an object. This is in
response to code like the following:
```
struct sockaddr {
/* snip */
char sa_data[14];
};
void foo(const char *s) {
size_t slen = strlen(s) + 1;
size_t added_len = slen <= 14 ? 0 : slen - 14;
struct sockaddr *sa = malloc(sizeof(struct sockaddr) + added_len);
strcpy(sa->sa_data, s);
// ...
}
```
`__builtin_object_size(sa->sa_data, 1)` would return 14, when there
could be more than 14 bytes at `sa->sa_data`.
Code like this is apparently not uncommon. FreeBSD's manual even
explicitly mentions this pattern:
https://www.freebsd.org/doc/en/books/developers-handbook/sockets-essential-functions.html
(section 7.5.1.1.2).
In light of this, we now just give up on any array at the end of an
object if we can't find the object's initial allocation.
I lack numbers for how much more conservative we actually become as a
result of this change, so I chose the fix that would make us as
compatible with GCC as possible. If we want to be more aggressive, I'm
happy to consider some kind of whitelist or something instead.
llvm-svn: 281277
Summary:
I've recently added the ability for optimization remarks to include the
hotness of the corresponding code region. This uses PGO and allows
filtering of the optimization remarks by relevance. The idea was first
discussed here:
http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334
The general goal is to produce a YAML file with the remarks. Then, an
external tool could dynamically filter these by hotness and perhaps by
other things.
That said it makes sense to also expose this at the more basic level
where we just include the hotness info with each optimization remark.
For example, in D22694, the clang flag was pretty useful to measure the
overhead of the additional analyses required to include hotness.
(Without the flag we don't even run the analyses.)
For the record, Hal has already expressed support for the idea of this
patch on IRC.
Differential Revision: https://reviews.llvm.org/D23284
llvm-svn: 281276
MSVC emits /include directives in the .drective section for the
__dyn_tls_init function (decorated as ___dyn_tls_init@12 for 32-bit).
This fixes PR30347.
llvm-svn: 281189
provided before trying to print it.
This fixes a segfault that occurs when function printPretty generated by
tablegen tries to print an optional argument of attribute
objc_bridge_related.
rdar://problem/28155469
llvm-svn: 281132
When deserializing ObjCInterfaceDecl with definition data, if we already have
a definition, try to keep the definition invariant; also pull in the
categories even if it is not what getDefinition returns (this effectively
combines categories).
rdar://27926200
rdar://26708823
llvm-svn: 281119
Summary:
This fixes a bug where we were unable to compile the following CUDA
file with libstdc++ (didn't try libc++):
#include <future>
void foo() { std::shared_future<int> x; }
The problem is that <future> only defines std::shared_future if
__GCC_ATOMIC_INT_LOCK_FREE > 1. When we compiled this file for device,
the macro was set to 1, and then the class didn't exist at all.
Reviewers: tra
Subscribers: cfe-commits, jhen
Differential Revision: https://reviews.llvm.org/D24407
llvm-svn: 281089
The logic for upgrading a class from a forward decl to a complete type
was not checking the debug info emission level before applying the
vtable optimization. This meant we ended up without debug info for a
class which was required to be complete. I noticed it because it
triggered an assertion during CodeView emission, but that's a separate
issue.
llvm-svn: 281057
Our limited debug info optimizations are breaking down at DLL
boundaries, so we're going to evaluate the size impact of these
settings, and possibly change the default.
Users should be able to override our settings, though.
llvm-svn: 281056
If a dynamic class contains a dllimport method, then assume the class
may not be constructed in this DLL, and therefore the vtable will live
in a different PDB.
This heuristic is still incomplete, and will miss things like abstract
base classes that are only constructed on one side of the DLL interface.
That said, this heuristic does detect some cases that are currently
problematic, and may be useful to other projects that don't use many
DLLs.
llvm-svn: 281053
In C mode, if we have a visible declaration but not a visible definition, a tag
defined in the declaration should be have a visible definition. In C++ we rely
on the ODR merging, whereas in C we cannot because each declaration of a
function gets its own set of declarations in its prototype scope.
Patch developed in collaboration with Richard Smith!
llvm-svn: 280984
r280553 introduced an issue where we'd emit ambiguity errors for code
like:
```
void foo(int *, int);
void foo(unsigned int *, unsigned int);
void callFoo() {
unsigned int i;
foo(&i, 0); // ambiguous: int->unsigned int is worse than int->int,
// but unsigned int*->unsigned int* is better than
// int*->int*.
}
```
This patch fixes this issue by changing how we handle ill-formed (but
valid) implicit conversions. Candidates with said conversions now always
rank worse than candidates without them, and two candidates are
considered to be equally bad if they both have these conversions for
the same argument.
Additionally, this fixes a case in C++11 where we'd complain about an
ambiguity in a case like:
```
void f(char *, int);
void f(const char *, unsigned);
void g() { f("abc", 0); }
```
...Since conversion to char* from a string literal is considered
ill-formed in C++11 (and deprecated in C++03), but we accept it as an
extension.
llvm-svn: 280847
- Should diag on a function (clang-cl warns; it's an error in cl)
- Test the attribute on nested classes (clang-cl is more permissive and more
self-consistent than cl here)
llvm-svn: 280845
There is a bug causing pch to be validated even though -fno-validate-pch is set. This patch fixes it.
ASTReader relies on ASTReaderListener to initialize SuggestedPredefines, which is required for compilations using PCH. Before this change, PCHValidator is the default ASTReaderListener. After this change, when -fno-validate-pch is set, PCHValidator is disabled, but we need a replacement ASTReaderListener to initialize SuggestedPredefines. Class SimpleASTReaderListener is implemented for this purpose.
This change only affects -fno-validate-pch. There is no functional change if -fno-validate-pch is not set.
If -fno-validate-pch is not set, conflicts in predefined macros between pch and current compiler instance causes error.
If -fno-validate-pch is set, predefine macros in current compiler override those in pch so that compilation can continue.
Differential Revision: https://reviews.llvm.org/D24054
llvm-svn: 280842
Summary:
C++1z 6.4.1/p2:
If the if statement is of the form if constexpr, the value of the
condition shall be a contextually converted constant expression of type
bool [...]
C++1z 5.20/p4:
[...] A contextually converted constant expression of type bool is an
expression, contextually converted to bool (Clause4), where the
converted expression is a constant expression and the conversion
sequence contains only the conversions above. [...]
Contextually converting result of an expression `e` to a Boolean value
requires `bool t(e)` to be well-formed.
An explicit conversion function is only considered as a user-defined
conversion for direct-initialization, which is essentially what
//contextually converted to bool// requires.
Also, fixes PR28470.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24158
llvm-svn: 280838
Move the logic for doing this from the ABI argument lowering into
EmitParmDecl, which runs for all parameters. Our codegen is slightly
suboptimal in this case, as we may leave behind a dead store after
optimization, but it's 32-bit inalloca, and this fixes the bug in a
robust way.
Fixes PR30293
llvm-svn: 280836
Summary: There was no definition for __nop function - added inline
assembly.
Patch by Albert Gutowski!
Reviewers: rnk, thakis
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24286
llvm-svn: 280826
Parse pragma intrinsic, display warning if the function isn't a builtin
function in clang and suggest including intrin.h.
Patch by Albert Gutowski!
Reviewers: aaron.ballman, rnk
Subscribers: aaron.ballman, cfe-commits
Differential Revision: https://reviews.llvm.org/D23944
llvm-svn: 280825
If the virtual method comes from a secondary vtable, then the type of
the 'this' parameter should be i8*, and not a pointer to the complete
class. In the MS ABI, the 'this' parameter on entry points to the vptr
containing the virtual method that was called, so we use i8* instead of
the normal type. We had a mismatch where the CGFunctionInfo of the call
didn't match the CGFunctionInfo of the declaration, and this resulted in
some assertions, but now both sides agree the type of 'this' is i8*.
Fixes one issue raised in PR30293
llvm-svn: 280815
OpenCL requires __ENDIAN_LITTLE__ be set for little endian targets.
The default for targets was also apparently big endian, so AMDGPU
was incorrectly reported as big endian. Set this from the triple
so targets don't have another place to set the endianness.
llvm-svn: 280787
copy-initialization. We previously got this wrong in a couple of ways:
- we only looked for copy / move constructors and constructor templates for
this copy, and thus would fail to copy in cases where doing so should use
some other constructor (but see core issue 670),
- we mishandled the special case for disabling user-defined conversions that
blocks infinite recursion through repeated application of a copy constructor
(applying it in slightly too many cases) -- though as far as I can tell,
this does not ever actually affect the result of overload resolution, and
- we misapplied the special-case rules for constructors taking a parameter
whose type is a (reference to) the same class type by incorrectly assuming
that only happens for copy/move constructors (it also happens for
constructors instantiated from templates and those inherited from base
classes).
These changes should only affect strange corner cases (for instance, where the
copy constructor exists but has a non-const-qualified parameter type), so for
the most part it only causes us to produce more 'candidate' notes, but see the
test changes for other cases whose behavior is affected.
llvm-svn: 280776
When calling getMostRecentDecl, we can pull in more definitions from
a module. We call getPrimaryContext afterwards to make sure that
we buildLookup on a primary context.
rdar://27926200
llvm-svn: 280728
Checking for the type of the command line tokenizer should not be the criteria to enable support for the CL environment variable, this change checks that we are in clang-cl mode instead.
Differential Revision: https://reviews.llvm.org/D23503
llvm-svn: 280702
Summary:
Remove access qualifiers on images in arg info metadata:
* kernel_arg_type
* kernel_arg_base_type
Image access qualifiers are inseparable from type in clang implementation,
but OpenCL spec provides a special query to get access qualifier
via clGetKernelArgInfo with CL_KERNEL_ARG_ACCESS_QUALIFIER.
Besides that OpenCL conformance test_api get_kernel_arg_info expects
image types without access qualifier.
Patch by Evgeniy Tyurin.
Reviewers: bader, yaxunl, Anastasia
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D23915
llvm-svn: 280699
I'm in the progress of adding ARMv6 support to CloudABI. On the compiler
side, everything seems to work properly with this tiny change applied.
llvm-svn: 280672
r280613 introduced failures for all builds that don't target x86 by default. Add an explicit target to avoid a missing feature diagnostic.
llvm-svn: 280658
This adds support for modules that require (non-)freestanding
environment, such as the compiler builtin mm_malloc submodule.
Differential Revision: https://reviews.llvm.org/D23871
llvm-svn: 280613
Nikola Smiljanic