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-11301] docs/ABI/CallingConvention.rst doesn't actually document the swiftcc #53702

Open
swift-ci opened this issue Aug 13, 2019 · 5 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-11301
Radar None
Original Reporter Gankro (JIRA User)
Type Bug
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug
Assignee None
Priority Medium

md5: f43cc5c46467285169802ed182b18035

Issue Description:

There is a calling convention inside of llvm called swiftcc, along with the swiftself and swifterror parameter attributes. However CallingConvention.rst only contains high level descriptions of potential approaches for the calling convention. It would be nice if it were updated to reflect the final implementation. It would be extra nice if this documentation also explained how the llvm features that were added to support this ABI should be used. I'm mostly interested in the swifterror feature, which is the most interesting/novel part (with swiftself a close second).

Context: y'all did a bunch of heroics and research to implement this new ABI, and it would be nice if other languages could use it to make themselves go faster, and also interop with Swift. Notably Rust's Result-based error handling is very similar to Swift's, and the C++ standards committee is currently investigating adding calling conventions for their "Lightweight Exceptions" proposal, which is another version of the Rust/Swift model: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r3.pdf

I am currently working on writing a document explaining the performance issues that arise from Result-based error-handling, and how better ABIs can be used to fix this (as y'all determined). This would ideally be used by both the Rust and C++ teams to improve their implementations, while also potentially allowing the three to interoperate (in the (zero-cost?) bridging sense).

Some useful links I have collected in my current research:

@swift-ci
Copy link
Collaborator Author

Comment by Alexis Beingessner (JIRA)

update: the Register Usage doc is apparently also wrong wrt Float80

@stephentyrone
Copy link
Member

Less "wrong", more "doesn't cover". Apparently passed on (memory) stack, returned on (register) stack: https://godbolt.org/z/DkzvdF

@swift-ci
Copy link
Collaborator Author

Comment by Alexis Beingessner (JIRA)

I'm guessing Rust will need to make some tweeks to the calling convention so that Result's methods (unwrap, expect, map, etc) have a favourable ABI, otherwise we'll end up needing to constantly rematerialize a proper Result in memory whenever someone observes it. Swift ostensibly doesn't have this issue because the main error-handling operations are language builtins like `throw`, `try?`, and `try!`, so nowhere is a Result logically constructed and passed as the self argument of a method. Or did you also have to solve this problem?

@swift-ci
Copy link
Collaborator Author

Comment by Alexis Beingessner (JIRA)

related: is there any documentation that properly explains the modern flavours of errors and error-handling in swift? I lost track of all the different "typed throws" / "make a real Result type for concurrent code" proposals and I have no idea which are actually accepted/implemented.

@belkadan
Copy link
Contributor

cc @rjmccall

@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
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself
Projects
None yet
Development

No branches or pull requests

3 participants