| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
dominated by a 'noreturn' call, where literal becomes an std::string.
I have mixed feelings about this one. It's used all over the codebase,
and is analogous to the current heuristic for ordinary C string literals.
This requires some ad hoc pattern matching of the AST. While the
test case mirrors what we see std::string in libc++, it's not really
testing the libc++ headers.
llvm-svn: 203091
|
| |
|
|
| |
llvm-svn: 203087
|
| |
|
|
| |
llvm-svn: 203085
|
| |
|
|
| |
llvm-svn: 203081
|
| |
|
|
| |
llvm-svn: 203080
|
| |
|
|
|
|
| |
inconsistent, making this hard to see.
llvm-svn: 203079
|
| |
|
|
| |
llvm-svn: 203078
|
| |
|
|
| |
llvm-svn: 203077
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In addition, for all functions, use the name from the llvm::Function to
identify the function in the profile data. Compute that "function name",
including the file name for local functions, once when assigning the PGO
counters and store it in the CodeGenPGO class.
Move the code to add InlineHint and Cold attributes out of StartFunction(),
because the "function name" string isn't available at that point.
llvm-svn: 203075
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For C++ functions, we will continue to use the mangled name to identify
functions in the PGO profile data, but this name is confusing for things like
Objective-C methods. For functions with local linkage, we're also going to
include the file name to help distinguish those functions, so this changes to
use more generic variable names.
No functional changes.
llvm-svn: 203074
|
| |
|
|
|
|
|
|
|
|
|
| |
Move the PGO.assignRegionCounters() call out of StartFunction, because that
function is called from many places where it does not make sense to do PGO
instrumentation (e.g., compiler-generated helper functions). Change several
functions to take a StringRef argument for the unique name associated with
a function, so that the name can be set differently for things like Objective-C
methods and block literals.
llvm-svn: 203073
|
| |
|
|
|
|
|
|
| |
I hit this while debugging another issue where my sources were in an
inconsistent state, so I don't have a testcase. Regardless, this check is
simpler and more direct than checking if the option is enabled.
llvm-svn: 203072
|
| |
|
|
|
|
| |
subdirectory in LLVM r203065.
llvm-svn: 203067
|
| |
|
|
|
|
|
|
| |
submodule macro overriding within the same top-level module (necessary for the
testcase to be remotely reasonable). Incidentally reduces the number of libc++
testsuite regressions with modules enabled from 7 to 6.
llvm-svn: 203063
|
| |
|
|
| |
llvm-svn: 203061
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch changes the remaining GlobalVariables using "\01L" and
"\01l" prefixes to use private linkage. What is strange about them is
that they currently use WeakAnyLinkage. There is no comment stating
why and that is really odd since the symbols are completely hidden, so
it doesn't make sense for them to be weak.
Clang revisions like r63329, r63408, r63770, r65761 set the linkage to
weak, but don't say why. I suspect they were just copying llvm-gcc.
In llvm-gcc I found r58599 and r56322 that set DECL_WEAK, but they
were just syncing from the apple gcc. I am not exactly sure what that
means, since the last commit to
svn://gcc.gnu.org/svn/gcc/branches/apple was in 2006, 2 years earlier.
In summary, I have no idea why weak linkage was being used :-(
To quote John McCall, "Let’s try without it and see" :-)
llvm-svn: 203059
|
| |
|
|
| |
llvm-svn: 203052
|
| |
|
|
|
|
|
|
|
|
| |
condition.
Sometimes do..while() is used to create a scope that can be left early.
In such cases, the unreachable 'while()' test is not usually interesting
unless it actually does something that is observable.
llvm-svn: 203051
|
| |
|
|
|
|
|
| |
a white background is difficult to read. Also include a chart showing which
colors are used by which elements in the AST dump.
llvm-svn: 203050
|
| |
|
|
|
|
| |
in LLVM r203046.
llvm-svn: 203047
|
| |
|
|
|
|
|
| |
the property assignment is an lvalue for an incomplete type.
// rdar://15118128. Reviewed offline by John McCall.
llvm-svn: 203043
|
| |
|
|
|
|
|
| |
process (I don't believe it's possible to write a testcase for the bug with
a non-checking STL implementation).
llvm-svn: 203042
|
| |
|
|
|
|
| |
in LLVM r203038.
llvm-svn: 203039
|
| |
|
|
|
|
|
|
|
|
| |
condition.
Sometimes do..while() is used to create a scope that can be left early.
In such cases, the unreachable 'while()' test is not usually interesting
unless it actually does something that is observable.
llvm-svn: 203036
|
| |
|
|
|
|
|
|
| |
Previously we only pruned dead returns preceded by a call to a
'noreturn' function. After looking at the results of the LLVM codebase,
there are many others that should be pruned as well.
llvm-svn: 203029
|
| |
|
|
|
|
|
| |
synthesizing protocol properties if class's super class
implements them. // rdar://16089191
llvm-svn: 203028
|
| |
|
|
|
|
| |
heuristic
llvm-svn: 203026
|
| |
|
|
|
|
| |
evaluating trivial default initialization of a literal class type.
llvm-svn: 203025
|
| |
|
|
|
|
| |
'objc_protocol_requires_explicit_implementation' conformance.
llvm-svn: 203024
|
| |
|
|
|
|
|
| |
Also promote a couple of Warnings on ill-formed code found by this testing to
ExtWarns.
llvm-svn: 203021
|
| |
|
|
|
|
| |
comparison operators.
llvm-svn: 203016
|
| |
|
|
|
|
|
|
| |
is being annotated. There are currently only two supported names: mutex and role. Adding functionality to check for the capability name and diagnose when it's unexpected.
Note that for backwards compatibility, an unnamed capability will default to being a "mutex." This allows the deprecated lockable attribute to continue to function.
llvm-svn: 203012
|
| |
|
|
|
|
|
| |
Using a //net/ path to hopefully avoid problems with non-absolute paths
on Windows.
llvm-svn: 203010
|
| |
|
|
|
|
| |
Fixes pr19007.
llvm-svn: 203007
|
| |
|
|
|
|
|
| |
the module build stack for the module being built, so we can correctly detect
recursive module builds.
llvm-svn: 203006
|
| |
|
|
|
|
| |
whether it's part of a module.
llvm-svn: 203005
|
| |
|
|
|
|
| |
Scope lives in Sema and cannot be used in AST. Shuffle things around.
llvm-svn: 202993
|
| |
|
|
| |
llvm-svn: 202978
|
| |
|
|
|
|
| |
MSVC2013's standard library is too broken to understand this pattern.
llvm-svn: 202971
|
| |
|
|
| |
llvm-svn: 202968
|
| |
|
|
| |
llvm-svn: 202964
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use a scheme inspired by the Itanium ABI to properly implement the
mangling of lambdas.
N.B. The incredibly astute observer will notice that we do not generate
external names that are identical, or even compatible with, MSVC.
This is fine because they don't generate names that they can use across
translation units. Technically, we can generate any name we'd like so
long as that name wouldn't conflict with any other and would be stable
across translation units.
This fixes PR15512.
llvm-svn: 202962
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The MSVC ABI appears to mangle the lexical scope into the names of
statics. Specifically, a counter is incremented whenever a scope is
entered where things can be declared in such a way that an ambiguity can
arise. For example, a class scope inside of a class scope doesn't do
anything interesting because the nested class cannot collide with
another nested class.
There are problems with this scheme:
- It is unreliable. The counter is only incremented when a previously
never encountered scope is entered. There are cases where this will
cause ambiguity amongst declarations that have the same name where one
was introduced in a deep scope while the other was introduced right
after in the previous lexical scope.
- It is wasteful. Statements like: {{{{{{{ static int foo = a; }}}}}}}
will make the mangling of "foo" larger than it need be because the
scope counter has been incremented many times.
Because of these problems, and practical implementation concerns. We
choose not to implement this scheme if the local static or local type
isn't visible. The mangling of these declarations will look very
similar but the numbering will make far more sense, this scheme is
lifted from the Itanium ABI implementation.
Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x
Reviewed By: rnk
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2953
llvm-svn: 202951
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inherited protocols and protocols already conformed in the class hierarchy.
Per more discussion, 'objc_protocol_requires_explicit_implementation' is
refinement that it mainly adds that requirement that a protocol must be
explicitly satisfied at the moment the first class in the class hierarchy
conforms to it. Any subclasses that also conform to that protocol,
either directly or via conforming to a protocol that inherits that protocol,
do not need to re-implement that protocol.
Doing this requires first doing a pass on the super class hierarchy,
gathering the set of protocols conformed to by the super classes,
and then culling those out when determining conformance. This
two-pass algorithm could be generalized for all protocol checking,
and could possibly be a performance win in some cases. For now
we restrict this change to protocols with this attribute to isolate
the change in logic (especially as the design continues to evolve).
This change needs to be adjusted for properties as well; this
only impacts methods right now.
llvm-svn: 202948
|
| |
|
|
| |
llvm-svn: 202942
|
| |
|
|
|
|
| |
rdar://14309030
llvm-svn: 202941
|
| |
|
|
| |
llvm-svn: 202940
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
value".
Some unreachable code is only "sometimes unreachable" because it
is guarded by a configuration value that is determined at compile
time and is always constant. Sometimes those represent real bugs,
but often they do not. This patch causes the reachability analysis
to cover such branches even if they are technically unreachable
in the CFG itself. There are some conservative heuristics at
play here to determine a "configuration value"; these are intended
to be refined over time.
llvm-svn: 202912
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Our usual definition of max_align_t wouldn't match up with MSVC if it
was used in a template argument.
Reviewers: chandlerc, rsmith, rnk
Reviewed By: chandlerc
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2924
llvm-svn: 202911
|
| |
|
|
| |
llvm-svn: 202909
|