[PATCH] D58514: Avoid needlessly copying blocks that initialize or are assigned to local auto variables to the heap

Hao Wu via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Mar 14 11:23:29 PDT 2019


wuhao5 added a comment.

> The specified user model of blocks is that they stay on the stack until they get copied, and there can be multiple such copies.  ARC just automates that process.  So the address of a block is not consistent before you've forced a copy.
> 
> I tend to agree that a better user model would have been for blocks to be allocated in one place, without any of this copying business, and for the compiler to make an intelligent decision about stack vs. heap based on how the block is used.  That's the model we've used for closures in Swift.  But that  would've required the compiler to have a better ability to propagate information about how the block was used, which Clang isn't really set up for, and it would've required `noescape` annotations to be introduced and used reliably throughout the SDK, which seemed like a big request at the time.  So it's not how it works.
> 
> There is no way in the existing ABI for copying a block to cause other references to the block to become references to the heap block.  We do do that for `__block` variables, but not for block objects themselves.

I see - this makes sense. Right that I'd expect the compiler would know more about where the block is being used and make the variable consistent. my other worry is, although not realistically, that there can be other projects to use this weak/strong pointer trick to do a recursive block invocation. it becomes to me a bit counter-intuitive that I will need to know more about how block and where it should be copied, which currently we don't have to worry about it at all.

Right now we force an explicit copy before using it, but still like to request that this would be handled by Clang at some later point :)


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58514/new/

https://reviews.llvm.org/D58514





More information about the cfe-commits mailing list