| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 240353
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
llvm-svn: 240270
|
|
|
|
|
|
|
| |
append will resize the vector to the optimal size. No functional change
intended.
llvm-svn: 239607
|
|
|
|
|
|
| |
ArrayRef/initializer_list+braced init
llvm-svn: 237625
|
|
|
|
|
|
|
|
| |
The fact that PGO has a say in how these branch weights are determined
isn't interesting to most of CodeGen, so it makes more sense for this
API to be accessible via CodeGenFunction rather than CodeGenPGO.
llvm-svn: 236380
|
|
|
|
|
|
|
|
|
| |
The RegionCounter type does a lot of legwork, but most of it is only
meaningful within the implementation of CodeGenPGO. The uses elsewhere
in CodeGen generally just want to increment or read counters, so do
that directly.
llvm-svn: 235664
|
|
|
|
|
|
|
| |
Looks like the VTable code in particular will need some work to pass
around the pointee type explicitly.
llvm-svn: 234128
|
|
|
|
|
|
| |
Same functionality, but hoists the vector growth out of the loop.
llvm-svn: 229508
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and ObjC methods
Without setting the CurEHLocation these cleanups would be attributed to
whatever the last active debug line location was (the 'fn' call in the
included test cases). By setting CurEHLocation correctly the line
information is improved/corrected.
This quality bug turned into a crasher with r225000 when, instead of
allowing the last location to persist, it would be zero'd out. This
could lead to a function call (such as the dtor) being made without a
debug location - if that call was subsequently inlined (and the caller
and callee had debug info, just not the call instruction) the inliner
would violate important constraints about the debug location chains by
not updating the inlined instructions to chain up to the callee
locations.
So, by fixing this bug, I am addressing the assertion failures
introduced by r225000 and should be able to recommit that patch with
impunity...
llvm-svn: 225955
|
|
|
|
|
|
| |
terms of another parameter
llvm-svn: 225856
|
|
|
|
|
|
| |
Patch by Alex Denisov. NFC.
llvm-svn: 224525
|
|
|
|
|
|
| |
Match LLVM API changes from r223802.
llvm-svn: 223803
|
|
|
|
|
|
|
|
| |
The logic for lowering profiling counters has been moved to an LLVM
pass. Emit the intrinsics rather than duplicating the whole pass in
clang.
llvm-svn: 223683
|
|
|
|
| |
llvm-svn: 220812
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
prologue of the next function.
CodeGenFunction objects aren't really designed to be reused for more
than one function, and doing so can leak debug info location information
from one function into the prologue of the next.
Add an assertion in to catch reuses of CodeGenFunction, which
surprisingly only caught the ObjC atomic getter/setter cases. Fix those
and add a test to demonstrate the issue.
The test is a bit slim, because we're just testing for the absence of a
debug location on the prologue instructions, which by itself probably
wouldn't be the end of the world - but the particular debug location
that was ending up there was for the previous function's last
instruction. This produced debug info for another function within this
function, which is something I'm trying to remove all cases of as its a
substantial source of bugs, especially around inlining (see r219215).
llvm-svn: 219690
|
|
|
|
|
|
| |
just letting them be implicitly created.
llvm-svn: 216528
|
|
|
|
|
|
|
| |
to use non-retain/autorelease API variants of ObjC objects. wip.
rdar://17554063
llvm-svn: 215146
|
|
|
|
|
|
|
| |
for Objective-C's array and dictionary literals.
rdar://17554063. This is wip.
llvm-svn: 214983
|
|
|
|
|
|
|
|
|
|
|
|
| |
-- 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
|
|
|
|
| |
llvm-svn: 209272
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Thanks dblaikie for the suggestion!
llvm-svn: 206012
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
iterator_range body(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 204040
|
|
|
|
|
|
| |
init_end() with iterator_range inits(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203820
|
|
|
|
|
|
| |
class.
llvm-svn: 203643
|
|
|
|
|
|
| |
with iterator_range params(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203255
|
|
|
|
| |
llvm-svn: 203085
|
|
|
|
|
|
| |
LLVM r202816.
llvm-svn: 202817
|
|
|
|
| |
llvm-svn: 202639
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
synthesized getters for performance improvement.
// rdar://15884113
llvm-svn: 200430
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This reverts commit 198699 so we can get a cleaner patch.
llvm-svn: 198713
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 198640
|
|
|
|
|
|
|
| |
There are about 30 removed in this patch, generated by a new FixIt I haven't
got round to submitting yet.
llvm-svn: 195814
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 191809
|
|
|
|
|
|
| |
when scalars are loaded / undergo lvalue-to-rvalue conversion.
llvm-svn: 191808
|
|
|
|
|
|
| |
that had 80-column violations. Remove spurious emacs mode markers on .cpp files.
llvm-svn: 191797
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Patch by Stephen Lin!
llvm-svn: 179638
|