| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
of an artificial function gets an artificial location as well.
llvm-svn: 187074
|
|
|
|
| |
llvm-svn: 186557
|
|
|
|
|
|
| |
__destroy_helper_block_, but do generate scope information.
llvm-svn: 186553
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inspired by CodegenFunction::LexicalScope.
- NoLocation temporarily turns off debug locations altogether.
This is useful for emitting instructions that should be
counted towards the function prologue.
- BuiltinLocation temporarily switches to an artificial debug location
that has a valid scope, but no line information. This is useful when
emitting compiler-generated helper functions that have no source
location associated with them.
llvm-svn: 186552
|
|
|
|
|
|
|
|
|
| |
Using CurFuncDecl is both correct and simple compared to crawling
the DeclContexts of the block.
Fixes <rdar://problem/14415072>.
llvm-svn: 186210
|
|
|
|
| |
llvm-svn: 181481
|
|
|
|
| |
llvm-svn: 181479
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 180931
|
|
|
|
|
|
| |
Patch by Stephen Lin!
llvm-svn: 179638
|
|
|
|
|
|
|
|
|
| |
It turns out that the optimizer can't eliminate this without extra
information, for which there's a separate bug.
rdar://13588325
llvm-svn: 179069
|
|
|
|
| |
llvm-svn: 179052
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
Looks like it broke http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb
Revert "Don't compute a patched/semantic storage class."
This reverts commit 8f187f62cb0487d31bc4afdfcd47e11fe9a51d05.
llvm-svn: 178681
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Make sure we do not generate line info for debugging-related frame setup.
Follow-up to r178361 / rdar://problem/12767564
llvm-svn: 178517
|
|
|
|
|
|
|
|
|
| |
* Store the .block_descriptor (instead of self) in the alloca so we
can guarantee that all captured variables are available at -O0.
* Add the missing OpDeref for the alloca.
rdar://problem/12767564
llvm-svn: 178361
|
|
|
|
|
|
|
|
|
| |
This way the register allocator will not optimize away the debug info
for captured variables.
Fixes rdar://problem/12767564
llvm-svn: 177086
|
|
|
|
|
|
|
|
| |
the requirements on the ARC optimizer.
rdar://13407451
llvm-svn: 176924
|
|
|
|
|
|
|
|
| |
from a lambda capture when the capture is not trivially-copyable.
rdar://13295759
llvm-svn: 176431
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were previously hard-coding a particular field index. This was
fine before (because we were obviously guaranteed the presence
of a copy/dispose member) except for (1) alignment padding and
(2) future extensions adding extra members to the header, such
as the extended-layout pointer.
Note that we only introduce the extended-layout pointer in the
presence of structs. (We also seem to be introducing it even
in the presence of an all-non-object layout, but that's a
different potential issue.)
llvm-svn: 173122
|
|
|
|
|
|
| |
produce more inline layout metadata. // rdar://12752901
llvm-svn: 172683
|
|
|
|
|
|
|
|
| |
before doing a storeStrong to it.
// rdar://12530881
llvm-svn: 171572
|
|
|
|
|
|
|
|
|
| |
__strong __block variables, perform objc_storeStrong on
source and destination instead of direct move. This
is done with -O0 and to improve some analysis.
// rdar://12530881
llvm-svn: 171555
|
|
|
|
|
|
|
|
|
|
| |
The line information was changed when emitting debug information for all the
DeclRefExprs and we should change it back to get ready for PopClenupBlocks
called from FinishFunction.
rdar://11562117
llvm-svn: 171493
|
|
|
|
|
|
|
|
| |
reflect the migration in r171366.
Re-sort the #include lines to reflect the new paths.
llvm-svn: 171369
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were emitting calls to blocks as if all arguments were
required --- i.e. with signature (A,B,C,D,...) rather than
(A,B,...). This patch fixes that and accounts for the
implicit block-context argument as a required argument.
In addition, this patch changes the function type under which
we call unprototyped functions on platforms like x86-64 that
guarantee compatibility of variadic functions with unprototyped
function types; previously we would always call such functions
under the LLVM type T (...)*, but now we will call them under
the type T (A,B,C,D,...)*. This last change should have no
material effect except for making the type conventions more
explicit; it was a side-effect of the most convenient implementation.
llvm-svn: 169588
|
|
|
|
|
|
|
| |
after the fixed size block header when generating
captured block variable info. // rdar://12773256
llvm-svn: 169285
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
|
|
|
|
|
|
|
|
|
|
| |
in deciding a copy/dispose field is needed in a byref structure
and when generating the copy/dispose helpers. In certain
cases, these fields were being added but no copy/dispose was
being generated. This was uncovered in ARC, but not in MRR.
// rdar://12759433
llvm-svn: 168825
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Separate out the notions of 'has a trivial special member' and 'has a
non-trivial special member', and use them appropriately. These are not
opposites of one another (there might be no special member, or in C++11 there
might be a trivial one and a non-trivial one). The CXXRecordDecl predicates
continue to produce incorrect results, but do so in fewer cases now, and
they document the cases where they might be wrong.
No functionality changes are intended here (they will come when the predicates
start producing the right answers...).
llvm-svn: 168119
|
|
|
|
| |
llvm-svn: 167934
|
|
|
|
|
|
| |
variables captured in a block. // rdar://12184410
llvm-svn: 167931
|
|
|
|
|
|
|
|
| |
generation for captured block variables in arc mode. This includes
inlined version of the meta-data when it can be done. It also includes
severat tests. This is wip. // rdar://12184410.
llvm-svn: 167241
|
|
|
|
|
|
| |
It is currently off (so no tests). This is wip.
llvm-svn: 166892
|
|
|
|
| |
llvm-svn: 166703
|
|
|
|
|
|
| |
and are generated by Clang (global initializers/destructors, thunks) . Fixes PR13942.
llvm-svn: 166676
|
|
|
|
| |
llvm-svn: 166497
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 165395
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
literal helper functions. All helper functions (global
and locals) use block_invoke as their prefix. Local literal
helper names are prefixed by their enclosing mangled function
names. Blocks in non-local initializers (e.g. a global variable
or a C++11 field) are prefixed by their mangled variable name.
The descriminator number added to end of the name starts off
with blank (for first block) and _<N> (for the N+2-th block).
llvm-svn: 159206
|
|
|
|
|
|
|
| |
blocks and lambdas, based heavily on a patch from Meador Inge. Fixes
PR12746 / <rdar://problem/11465120>.
llvm-svn: 156925
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It reduces the amount of emitted debug information:
1) DIEs in .debug_info have types DW_TAG_compile_unit, DW_TAG_subprogram,
DW_TAG_inlined_subroutine (for opt builds) and DW_TAG_lexical_block only.
2) .debug_str contains only function names.
3) No debug data for types/namespaces/variables is emitted.
4) The data in .debug_line is enough to produce valid stack traces with
function names and line numbers.
Reviewed by Eric Christopher.
llvm-svn: 156160
|
|
|
|
|
|
|
| |
the alignment might actually exceed the max field alignment; don't
assert in this case.
llvm-svn: 155937
|
|
|
|
|
|
|
|
|
|
|
|
| |
more aligned than the block header but also contains something
smaller than the block-header alignment but not exactly half
the difference between the large alignment and the header
alignment. Got that?
I'm really not sure what I was thinking with the buggy computation
here, but the fix is pretty obvious.
llvm-svn: 155662
|
|
|
|
|
|
|
|
| |
jump into these scopes, and the cleanup-entering code sometimes wants
to do some operations first (e.g. a GEP), which can leave us with
unparented IR.
llvm-svn: 154684
|
|
|
|
|
|
|
|
| |
FunctionDecl::Create calls as well.
rdar://11079003
llvm-svn: 154578
|