rjmccall added a comment. In D58514#1429652 <https://reviews.llvm.org/D58514#1429652>, @erik.pilkington wrote:
> In D58514#1429606 <https://reviews.llvm.org/D58514#1429606>, @rjmccall wrote: > > > 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. > > > Do you think thats worth doing? We could add a forwarding pointer to the end > of a block literal on the stack (after all the captures) and flip an unused > bit to track it, preserving ABI. Seems like now that we're delaying > `_Block_copy`ies this might be a bigger issue. We've always delayed `_Block_copy` in a bunch of places. Now we're just delaying it in a place that ARC used to be more conservative about. I guess we could actually make forwarding work at some code-size cost (functions that emitted forwardable blocks would have to zero the forwarding slot and release it when destroying the stack copy). But it'd just silently do nothing without a runtime update, so it'd be somewhat treacherous, especially after a couple of releases: e.g. if we made the runtime change in macOS 20 Eugene O'Neill National Historic Site, and Chromium eventually only ran tests on macOS 20 and higher but still supported deploying to macOS 19 San Francisco Maritime National Historical Park, then Chromium might not catch that it was still necessary to include an explicit copy here. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58514/new/ https://reviews.llvm.org/D58514 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
