| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
- The return type should be a pointer to the class type.
- Make the condition more specific.
rdar://problem/13359718
llvm-svn: 182504
|
| |
|
|
|
|
|
|
| |
properties declared in a protocol.
rdar://problem/13798000
llvm-svn: 182176
|
| |
|
|
|
|
|
|
| |
a related type (e.g., if they use the instancetype keyword).
rdar://problem/13359718
llvm-svn: 181629
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If there is cleanup code, the cleanup code gets the debug location of
the closing '}'. The subsequent ret IR-instruction does not get a
debug location. The return _expression_ will get the debug location
of the return statement.
If the function contains only a single, simple return statement,
the cleanup code may become the first breakpoint in the function.
In this case we set the debug location for the cleanup code
to the location of the return statement.
rdar://problem/13442648
llvm-svn: 180932
|
| |
|
|
|
|
| |
documentation change.
llvm-svn: 179898
|
| |
|
|
| |
llvm-svn: 179897
|
| |
|
|
| |
llvm-svn: 179896
|
| |
|
|
|
|
|
|
| |
instead of only C++11-scoped-with-class-tag enums.
rdar://problem/13463793
llvm-svn: 179879
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 179629
|
| |
|
|
| |
llvm-svn: 179606
|
| |
|
|
|
|
|
|
|
|
| |
for caching couple of global symbols used
for generation of CF/NS string meta-data
so they are not released prematuely in certain
corner cases. // rdar:// 13598026.
Reviewed by John M.
llvm-svn: 179599
|
| |
|
|
|
|
|
|
| |
This required some tedious reordering to match clang's order.
Presumably these ObjC tests were generated based on llvm-gcc's output
ordering.
llvm-svn: 179282
|
| |
|
|
|
|
|
| |
The escaping interaction between Python and grep doesn't work on my
system. This change fixes the tests for me.
llvm-svn: 179214
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
of a property just in case the property's getter happens to be +1.
We won't synthesize a getter for such a property, but we will allow
the user to define a +1 method for it.
rdar://13115896
llvm-svn: 178731
|
| |
|
|
|
|
|
|
|
|
| |
ARC optimizer while they're held in local unsafe buffers.
Based on a patch by Jesse Rusak!
rdar://13573224
llvm-svn: 178721
|
| |
|
|
|
|
|
|
|
|
|
|
| |
a normal cleanup when entering a @try or @synchronized to
ensure that we clean that up if an exception is triggered.
Apparently GCC did this, so it's hard to argue that we shouldn't
do at least as much.
rdar://12364847
llvm-svn: 178599
|
| |
|
|
| |
llvm-svn: 178383
|
| |
|
|
|
|
|
|
|
| |
* 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
|
| |
|
|
|
|
|
|
|
| |
a more aggressive stack coloring.
Patch by John McCall with help by Shuxin Yang.
rdar://13115369
llvm-svn: 177819
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
DISubprogram changes
llvm-svn: 177659
|
| |
|
|
|
|
|
|
|
| |
Mostly, try to depend on the annotation comments more so these tests are more
legible, brief, and agnostic to schema changes in the future (sure, they're not
agnostic to changes to the comment annotations but since they're easier to read
they should be easier to update if that happens).
llvm-svn: 177457
|
| |
|
|
|
|
|
|
| |
we expect a related result type.
rdar://12493140
llvm-svn: 177378
|
| |
|
|
|
|
|
|
| |
Checking for the annotation comment rather than the metadata values makes these
tests resilient to a coming refactor that will pull these fields out into a
separate metadata node.
llvm-svn: 177237
|
| |
|
|
| |
llvm-svn: 177124
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
Generate forward declarations that are RAUW'd by finalize().
We thus avoid outputting the same type several times in multiple
stages of completion.
llvm-svn: 176820
|
| |
|
|
|
|
|
|
|
|
| |
that adds ivars to an interface.
Fixes rdar://13175234
This is an update to r176116 that performs a smart caching of interfaces.
llvm-svn: 176584
|
| |
|
|
|
|
| |
These can be easily queried by the back-end.
llvm-svn: 176304
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
This reverts commit ea95e4587fd13606fbf63b10a07a7d02026aa39c.
llvm-svn: 176151
|
| |
|
|
| |
llvm-svn: 176145
|
| |
|
|
|
|
| |
adds ivars to an interface. Fixes rdar://13175234
llvm-svn: 176116
|
| |
|
|
|
|
|
|
| |
This reverts commit 176009.
The commit is a likely cause of several buildbot failures.
llvm-svn: 176044
|
| |
|
|
|
|
|
| |
This is an ongoing process. Any command line option which a back-end cares about
should be added here.
llvm-svn: 176009
|
| |
|
|
| |
llvm-svn: 175921
|
| |
|
|
|
|
| |
attributes on the call/invoke instructions.
llvm-svn: 175878
|
| |
|
|
|
|
| |
By Adrian Pranti.
llvm-svn: 175793
|
| |
|
|
|
|
|
|
|
|
| |
arguments in function prologue is done
with objc_StoreStrong to pair it with
similar objc_StoreStrong for release in function
epilogue. This is done with -O0 only.
// rdar://13145317
llvm-svn: 175698
|
| |
|
|
|
|
| |
function attributes.
llvm-svn: 175606
|
| |
|
|
|
|
|
|
| |
not the global visibility mode.
Noticed by inspection.
llvm-svn: 175479
|
| |
|
|
| |
llvm-svn: 175448
|
| |
|
|
|
|
| |
Paired commit with LLVM, may produce temporary build breakage.
llvm-svn: 175427
|
| |
|
|
|
|
| |
by matching the function name first
llvm-svn: 175395
|
| |
|
|
|
| |
Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
llvm-svn: 175387
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An ivar ofset cannot be marked as invariant load in all cases. The ivar offset
is a lazily initialised constant, which is dependent on an objc_msgSend
invocation to perform a fixup of the offset. If the load is being performed on
a method implemented by the class then this load can safely be marked as an
inviarant because a message must have been passed to the class at some point,
forcing the ivar offset to be resolved.
An additional heuristic that can be used to identify an invariant load would be
if the ivar offset base is a parameter to an objc method. However, without the
parameters available at hand, this is currently not possible.
Reviewed-by: John McCall <rjmccall@apple.com>
Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
llvm-svn: 175386
|