-- a constructor list initialization that unpacked an initializer list into
constructor arguments and
-- a list initialization that created as std::initializer_list and passed it
as the first argument to a constructor
in the AST. Use this flag while instantiating templates to provide the right
semantics for the resulting initialization.
llvm-svn: 213224
ensure that querying the first declaration for its most recent declaration
checks for redeclarations from the imported module.
This works as follows:
* The 'most recent' pointer on a canonical declaration grows a pointer to the
external AST source and a generation number (space- and time-optimized for
the case where there is no external source).
* Each time the 'most recent' pointer is queried, if it has an external source,
we check whether it's up to date, and update it if not.
* The ancillary data stored on the canonical declaration is allocated lazily
to avoid filling it in for declarations that end up being non-canonical.
We'll still perform a redundant (ASTContext) allocation if someone asks for
the most recent declaration from a decl before setPreviousDecl is called,
but such cases are probably all bugs, and are now easy to find.
Some finessing is still in order here -- in particular, we use a very general
mechanism for handling the DefinitionData pointer on CXXRecordData, and a more
targeted approach would be more compact.
Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was
addressing only a corner of the full problem space here. That's not covered
by this patch.
Early performance benchmarks show that this makes no measurable difference to
Clang performance without modules enabled (and fixes a major correctness issue
with modules enabled). I'll revert if a full performance comparison shows any
problems.
llvm-svn: 209046
are not associated with any source lines.
Previously, if the Location of a Decl was empty, EmitFunctionStart would
just keep using CurLoc, which would sometimes be correct (e.g., thunks)
but in other cases would just point to a hilariously random location.
This patch fixes this by completely eliminating all uses of CurLoc from
EmitFunctionStart and rather have clients explicitly pass in a
SourceLocation for the function header and the function body.
rdar://problem/14985269
llvm-svn: 205999
Conceptually one of these loops is just a while-loop, but the actual code-gen
is more complicated. We don't instrument all the different control flow edges
to get accurate counts for each conditional branch, nor do I think it makes
sense to do so. Instead, make the simplifying assumption that the loop behaves
like a while-loop. Use the same branch weights for the first check for an
empty collection as would be used for the back-edge of a while loop, and use
that same weighting for the innermost loop, ignoring the possibility that there
may be some extra code to go fetch more elements.
llvm-svn: 204767
In instrumentation-based profiling, we need a set of data structures to
represent the counters. Previously, these were built up during static
initialization. Now, they're shoved into a specially-named section so
that they show up as an array.
As a consequence of the reorganizing symbols, instrumentation data
structures for linkonce functions are now correctly coalesced.
This is the first step in a larger project to minimize runtime overhead
and dependencies in instrumentation-based profilng. The larger picture
includes removing all initialization overhead and making the dependency
on libc optional.
<rdar://problem/15943240>
llvm-svn: 204080
We still don't use the PGO to set branch weights for these loops, but at
least this keeps the compiler from crashing. <rdar://problem/16137778>
llvm-svn: 202002
Previously, we made one traversal of the AST prior to codegen to assign
counters to the ASTs and then propagated the count values during codegen. This
patch now adds a separate AST traversal prior to codegen for the
-fprofile-instr-use option to propagate the count values. The counts are then
saved in a map from which they can be retrieved during codegen.
This new approach has several advantages:
1. It gets rid of a lot of extra PGO-related code that had previously been
added to codegen.
2. It fixes a serious bug. My original implementation (which was mailed to the
list but never committed) used 3 counters for every loop. Justin improved it to
move 2 of those counters into the less-frequently executed breaks and continues,
but that turned out to produce wrong count values in some cases. The solution
requires visiting a loop body before the condition so that the count for the
condition properly includes the break and continue counts. Changing codegen to
visit a loop body first would be a fairly invasive change, but with a separate
AST traversal, it is easy to control the order of traversal. I've added a
testcase (provided by Justin) to make sure this works correctly.
3. It improves the instrumentation overhead, reducing the number of counters for
a loop from 3 to 1. We no longer need dedicated counters for breaks and
continues, since we can just use the propagated count values when visiting
breaks and continues.
To make this work, I needed to make a change to the way we count case
statements, going back to my original approach of not including the fall-through
in the counter values. This was necessary because there isn't always an AST node
that can be used to record the fall-through count. Now case statements are
handled the same as default statements, with the fall-through paths branching
over the counter increments. While I was at it, I also went back to using this
approach for do-loops -- omitting the fall-through count into the loop body
simplifies some of the calculations and make them behave the same as other
loops. Whenever we start using this instrumentation for coverage, we'll need
to add the fall-through counts into the counter values.
llvm-svn: 201528
This fixes PR15768, where the sret parameter and the 'this' parameter
are in the wrong order.
Instance methods compiled by MSVC never return records in registers,
they always return indirectly through an sret pointer. That sret
pointer always comes after the 'this' parameter, for both __cdecl and
__thiscall methods.
Unfortunately, the same is true for other calling conventions, so we'll
have to change the overall approach here relatively soon.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D2664
llvm-svn: 200587
A return type is the declared or deduced part of the function type specified in
the declaration.
A result type is the (potentially adjusted) type of the value of an expression
that calls the function.
Rule of thumb:
* Declarations have return types and parameters.
* Expressions have result types and arguments.
llvm-svn: 200082
Debug info: Implement a cleaner version of r198461. For symmetry with
C and C++ don't emit an extra lexical scope for the compound statement
that is the body of an Objective-C method.
llvm-svn: 198715
C and C++ don't emit an extra lexical scope for the compound statement
that is the body of an Objective-C method.
rdar://problem/15010825
llvm-svn: 198699
encodes the canonical rules for LLVM's style. I noticed this had drifted
quite a bit when cleaning up LLVM, so wanted to clean up Clang as well.
llvm-svn: 198686
CodeGenABITypes is a wrapper built on top of CodeGenModule that exposes
some of the functionality of CodeGenTypes (held by CodeGenModule),
specifically methods that determine the LLVM types appropriate for
function argument and return values.
I addition to CodeGenABITypes.h, CGFunctionInfo.h is introduced, and the
definitions of ABIArgInfo, RequiredArgs, and CGFunctionInfo are moved
into this new header from the private headers ABIInfo.h and CGCall.h.
Exposing this functionality is one part of making it possible for LLDB
to determine the actual ABI locations of function arguments and return
values, making it possible for it to determine this for any supported
target without hard-coding ABI knowledge in the LLDB code.
llvm-svn: 193717
CodeGenFunction is run on only one function - a new object is made for
each new function. I would add an assertion/flag to this effect, but
there's an exception: ObjC properties involve emitting helper functions
that are all emitted by the same CodeGenFunction object, so such a check
is not possible/correct.
llvm-svn: 189277
a lambda.
Bug #1 is that CGF's CurFuncDecl was "stuck" at lambda invocation
functions. Fix that by generally improving getNonClosureContext
to look through lambdas and captured statements but only report
code contexts, which is generally what's wanted. Audit uses of
CurFuncDecl and getNonClosureAncestor for correctness.
Bug #2 is that lambdas weren't specially mapping 'self' when inside
an ObjC method. Fix that by removing the requirement for that
and using the normal EmitDeclRefLValue path in LoadObjCSelf.
rdar://13800041
llvm-svn: 181000
Model it as throwing so that the exception can be caught.
This is generally not expected to have significant code-size
impact because the contents of the @autoreleasepool block
are very likely to contain a call, very likely at the same
cleanup level as the @autoreleasepool itself.
rdar://13660038
llvm-svn: 179630
http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb went back green
before it processed the reverted 178663, so it could not have been the culprit.
Revert "Revert 178663."
This reverts commit 4f8a3eb2ce5d4ba422483439e20c8cbb4d953a41.
llvm-svn: 178682
For variables and functions clang used to store two storage classes. The one
"as written" in the code and a patched one, which, for example, propagates
static to the following decls.
This apparently is from the days clang lacked linkage computation. It is now
redundant and this patch removes it.
llvm-svn: 178663
to an out-parameter using the indirect-writeback conversion,
and we copied the current value of the variable to the temporary,
make sure that we register an intrinsic use of that value with
the optimizer so that the value won't get released until we have
a chance to retain it.
rdar://13195034
llvm-svn: 177813
aggregate types in a profoundly wrong way that has to be
worked around in every call site, to getEvaluationKind,
which classifies and distinguishes between all of these
cases.
Also, normalize the API for loading and storing complexes.
I'm working on a larger patch and wanted to pull these
changes out, but it would have be annoying to detangle
them from each other.
llvm-svn: 176656
calls and declarations.
LLVM has a default CC determined by the target triple. This is
not always the actual default CC for the ABI we've been asked to
target, and so we sometimes find ourselves annotating all user
functions with an explicit calling convention. Since these
calling conventions usually agree for the simple set of argument
types passed to most runtime functions, using the LLVM-default CC
in principle has no effect. However, the LLVM optimizer goes
into histrionics if it sees this kind of formal CC mismatch,
since it has no concept of CC compatibility. Therefore, if this
module happens to define the "runtime" function, or got LTO'ed
with such a definition, we can miscompile; so it's quite
important to get this right.
Defining runtime functions locally is quite common in embedded
applications.
llvm-svn: 176286
call sites as tail calls unconditionally. While it's theoretically true that
this is just an optimization, it's an optimization that we very much want to
happen even at -O0, or else ARC applications become substantially harder to
debug. See r169796 for the llvm/fast-isel side of things.
rdar://12553082
llvm-svn: 169996
combination of a load+objc_release; this is generally better
for tools that try to track why values are retained and
released. Also use objc_storeStrong when copying a block
(again, only at -O0), which requires us to do a preliminary
store of null in order to compensate for objc_storeStrong's
assign semantics.
llvm-svn: 166085
if (CGM.getModuleDebugInfo())
DebugInfo = CGM.getModuleDebugInfo()
into a call:
maybeInitializeDebugInfo();
This is a simplification for a possible future fix of PR13942.
llvm-svn: 166019
Clang will now honor the FP_CONTRACT pragma and emit LLVM
fmuladd intrinsics for expressions of the form A * B + C (when they occur in a
single statement).
llvm-svn: 164989
diagnostics for bad deployment targets and adding a few
more predicates. Includes a patch by Jonathan Schleifer
to enable ARC for ObjFW.
llvm-svn: 162252
First, when synthesizing an explicitly strong/retain/copy property
of Class type, don't pretend during compatibility checking that the
property is actually assign. Instead, resolve incompatibilities
by secretly changing the type of *implicitly* __unsafe_unretained
Class ivars to be strong. This is moderately evil but better than
what we were doing.
Second, when synthesizing the setter for a strong property of
non-retainable type, be sure to use objc_setProperty. This is
possible when the property is decorated with the NSObject
attribute. This is an ugly, ugly corner of the language, and
we probably ought to deprecate it.
The first is rdar://problem/12039404; the second was noticed by
inspection while fixing the first.
llvm-svn: 162244
in the ABI arrangement, and leave a hook behind so that we can easily
tweak CCs on platforms that use different CCs by default for C++
instance methods.
llvm-svn: 159894
target Objective-C runtime down to the frontend: break this
down into a single target runtime kind and version, and compute
all the relevant information from that. This makes it
relatively painless to add support for new runtimes to the
compiler. Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z,
available at the driver level as a better and more general
alternative to -fgnu-runtime and -fnext-runtime. This new
concept of an Objective-C runtime also encompasses what we
were previously separating out as the "Objective-C ABI", so
fragile vs. non-fragile runtimes are now really modelled as
different kinds of runtime, paving the way for better overall
differentiation.
As a sort of special case, continue to accept the -cc1 flag
-fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak.
I won't go so far as to say "no functionality change", even
ignoring the new driver flag, but subtle changes in driver
semantics are almost certainly not intended.
llvm-svn: 158793
getter result type is safe but does not match with property
type resulting in spurious warning followed by crash in
IRGen. // rdar://11515196
llvm-svn: 157641
property file/line rather than the @synthesize file/line. Avoids
some nasty confusing-ness with conflating the file from the scope
and the line from the original declaration. Use the current scope
location as a separate parameter so that we can match it up
better in the line table with the beginning of the scope.
Update a couple of testcases accordingly since I had to change
that we actually use the passed in location in EmitFunctionStart
and for the new metadata parameter and add a new testcase to
make sure we've got the right line numbers for synthesized
properties.
Part of rdar://11026482
llvm-svn: 153917
property file/line rather than the @synthesize file/line. Avoids
some nasty confusing-ness with conflating the file from the scope
and the line from the original declaration.
Update a couple of testcases accordingly since I had to change
that we actually use the passed in location in EmitFunctionStart.
Fixes rdar://11026482
llvm-svn: 153714
track whether the referenced declaration comes from an enclosing
local context. I'm amenable to suggestions about the exact meaning
of this bit.
llvm-svn: 152491
NSNumber, and boolean literals. This includes both Sema and Codegen support.
Included is also support for new Objective-C container subscripting.
My apologies for the large patch. It was very difficult to break apart.
The patch introduces changes to the driver as well to cause clang to link
in additional runtime support when needed to support the new language features.
Docs are forthcoming to document the implementation and behavior of these features.
llvm-svn: 152137
optional argument passed through the variadic ellipsis)
potentially affects how we need to lower it. Propagate
this information down to the various getFunctionInfo(...)
overloads on CodeGenTypes. Furthermore, rename those
overloads to clarify their distinct purposes, and make
sure we're calling the right one in the right place.
This has a nice side-effect of making it easier to construct
a function type, since the 'variadic' bit is no longer
separable.
This shouldn't really change anything for our existing
platforms, with one minor exception --- we should now call
variadic ObjC methods with the ... in the "right place"
(see the test case), which I guess matters for anyone
running GNUStep on MIPS. Mostly it's just a substantial
clean-up.
llvm-svn: 150788
instead of having a special-purpose function.
- ActOnCXXDirectInitializer, which was mostly duplication of
AddInitializerToDecl (leading e.g. to PR10620, which Eli fixed a few days
ago), is dropped completely.
- MultiInitializer, which was an ugly hack I added, is dropped again.
- We now have the infrastructure in place to distinguish between
int x = {1};
int x({1});
int x{1};
-- VarDecl now has getInitStyle(), which indicates which of the above was used.
-- CXXConstructExpr now has a flag to indicate that it represents list-
initialization, although this is not yet used.
- InstantiateInitializer was renamed to SubstInitializer and simplified.
- ActOnParenOrParenListExpr has been replaced by ActOnParenListExpr, which
always produces a ParenListExpr. Placed that so far failed to convert that
back to a ParenExpr containing comma operators have been fixed. I'm pretty
sure I could have made a crashing test case before this.
The end result is a (I hope) considerably cleaner design of initializers.
More importantly, the fact that I can now distinguish between the various
initialization kinds means that I can get the tricky generalized initializer
test cases Johannes Schaub supplied to work. (This is not yet done.)
This commit passed self-host, with the resulting compiler passing the tests. I
hope it doesn't break more complicated code. It's a pretty big change, but one
that I feel is necessary.
llvm-svn: 150318
consume one or more of their arguments. If not done, this will cause a leak
as method will not consume the argument when receiver is null.
// rdar://10444474
llvm-svn: 149184
Craig Topper