erik.pilkington added a comment. In D58514#1429713 <https://reviews.llvm.org/D58514#1429713>, @rjmccall wrote:
> 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. Lol, we're really running out of names, eh? We could still do a version of this without the O'Neill/Maritime problem, to optimize the performance on the following: void f(int (^blk)()) { // implicitly copy the block somehow... } int main() { int cap; auto p = ^{ return cap; }; for (int i = 0; i != N; ++i) f(p); } Where we used to do 1 _Block_copy, but now we do N. If we stored a strong reference to the heap block in the stack block, then made _Block_copy just hand back the first heap block it allocated, we could save that cost. That way we could still preserve the crash here, then maybe once macOS Maritime is at EOL we could adopt the forwarding behaviour. WDYT? 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
