Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-9701] Stack allocated Objective-C no escape closures #52141

Open
aschwaighofer opened this issue Jan 18, 2019 · 2 comments
Open

[SR-9701] Stack allocated Objective-C no escape closures #52141

aschwaighofer opened this issue Jan 18, 2019 · 2 comments
Labels
compiler The Swift compiler in itself improvement

Comments

@aschwaighofer
Copy link
Member

Previous ID SR-9701
Radar None
Original Reporter @aschwaighofer
Type Improvement
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Improvement
Assignee None
Priority Medium

md5: fd60c5edf6ddc3d03a27ac1f2a14393b

Issue Description:

When we pass closures to @NoEscape objective c block arguments the closures are allocated on the heap. We should also stack allocate them.

@belkadan
Copy link
Contributor

The Objective-C convention is actually fine with you stack-allocating all block arguments; it's considered the callee's responsibility to Block_copy them. cc @rjmccall

https://clang.llvm.org/docs/BlockLanguageSpec.html
https://clang.llvm.org/docs/AutomaticReferenceCounting.html#blocks

@rjmccall
Copy link
Member

Correct. We don't do this only because we're being cautious about lifetimes. If we had a reliable way of detecting that the copy is unnecessary, it would be a significant win.

Clang has actually implemented an optimization where it eliminates the copying logic from `noescape` blocks entirely, essentially generating them as global blocks that happen to be allocated on the stack.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler The Swift compiler in itself improvement
Projects
None yet
Development

No branches or pull requests

3 participants