Commit Graph

11 Commits

Author SHA1 Message Date
John McCall e68b8f4dcc At -O0, prefer objc_storeStrong with a null new value to the
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
2012-10-17 02:28:37 +00:00
John McCall b0433eeb2e During jump-scope checking, build an ExprWithCleanups immediately
into the enclosing scope;  this is a more accurate model but is
(I believe) unnecessary in my test case due to other flaws.
However, one of those flaws is now intentional:  blocks which
appear in return statements can be trivially observed to not
extend in lifetime past the return, and so we can allow a jump
past them.  Do the necessary magic in IR-generation to make
this work.

llvm-svn: 164589
2012-09-25 06:56:03 +00:00
Fariborz Jahanian 6362803cfe block literal irgen: several improvements on naming block
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
2012-06-26 16:06:38 +00:00
Fariborz Jahanian a36cbeb464 objc-arc: captured block variable accessed in its block literal
initializer need be null initialized before initializer takes
hold, just like any other initialized retainable object pointer. 
// rdar://11016025

llvm-svn: 158738
2012-06-19 20:53:26 +00:00
John McCall 3abee49d1c Enter an expression evaluation context when parsing
statement-expressions.  Prevents cleanups and such from being
claimed by the first full-expression in the block.

llvm-svn: 153989
2012-04-04 01:27:53 +00:00
Eli Friedman 91f5ae5022 Try to handle qualifiers more consistently for array InitListExprs. Fixes <rdar://problem/10907510>, and makes the ASTs a bit more self-consistent.
(I've chosen to keep the qualifiers, but it isn't a strong preference; if anyone prefers removing them, please yell.)

llvm-svn: 151229
2012-02-23 02:25:10 +00:00
John McCall f4beacd059 Whenever explicitly activating or deactivating a cleanup, we
need to provide a 'dominating IP' which is guaranteed to
dominate the (de)activation point but which cannot be avoided
along any execution path from the (de)activation point to
the push-point of the cleanup.  Using the entry block is
bad mojo.

llvm-svn: 144276
2011-11-10 10:43:54 +00:00
John McCall e63abb5d2b Fix a subtle bug with cleanups: when activating
a previously-inactive cleanup, not only do we need a
flag variable, but we should also force the cleanup to
query the flag variable.  However, we only need to do
this when we're activating in a context that's
conditionally executed;  otherwise, we may safely
assume that the cleanup is dominated by the activation
point.

llvm-svn: 144271
2011-11-10 09:22:44 +00:00
John McCall 08ef466048 Enter the cleanups for a block outside the enclosing
full-expression.  Naturally they're inactive before we enter
the block literal expression.  This restores the intended
behavior that blocks belong to their enclosing scope.

There's a useful -O0 / compile-time optimization that we're
missing here with activating cleanups following straight-line
code from their inactive beginnings.

llvm-svn: 144268
2011-11-10 08:15:53 +00:00
John McCall 3a237aa31c Emit the copy and dipose helpers for ARC __strong
block-typed __block variables using objc_retainBlock
and objc_dispose.  Previously we were using
_Block_object_assign and _Block_object_destroy
with BLOCK_BYREF_CALLER, which causes the runtime
to completely ignore the retain and release.
In most cases this doesn't cause catastrophe
because the retain/release are balanced and
because the block in the variable was copied
upon assignment there.  However, the stack
copy of the variable will be released when
it goes out of scope, which is a problem if
that value was released due to an assignment
to the heap copy.  Similarly, a leak can occur
if the variable is assigned after the copy to
the heap.

llvm-svn: 144162
2011-11-09 03:17:26 +00:00
John McCall d86532ee2c Extract the blocks-related ARC tests into their own file.
llvm-svn: 144158
2011-11-09 02:16:13 +00:00