-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[IRGen][runtime] Simplify runtime CCs and entry point ABIs #14175
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
[IRGen][runtime] Simplify runtime CCs and entry point ABIs #14175
Conversation
… ABI. * Remove RegisterPreservingCC. It was unused. * Remove DefaultCC from the runtime. The distinction between C_CC and DefaultCC was unused and inconsistently applied. Separate C_CC and DefaultCC are still present in the compiler. * Remove function pointer indirection from runtime functions except those that are used by Instruments. The remaining Instruments interface is expected to change later due to function pointer liability. * Remove swift_rt_ wrappers. Function pointers are an ABI liability that we don't want, and there are better ways to get nonlazy binding if we need it. The fully custom wrappers were only needed for RegisterPreservingCC and for optimizing the Instruments function pointers.
@swift-ci please test |
Build failed |
Not a major point, but I think this touches a few areas that the TwoWordPair removal also touched. If the issue there was a simple missing |
@swift-ci please test |
Build failed |
Build failed |
I suspect that the total number of merge conflicts would be about the same. This fix should prevent the problem that broke #13299 so we'll be able to reinstate that with no additional bug fixes. |
@swift-ci please test macos |
@swift-ci please test os x platform |
Build failed |
@swift-ci please clean test os x platform |
was unused and inconsistently applied. Separate C_CC and DefaultCC are
still present in the compiler.
that are used by Instruments. The remaining Instruments interface is
expected to change later due to function pointer liability.
don't want, and there are better ways to get nonlazy binding if we need it.
The fully custom wrappers were only needed for RegisterPreservingCC and
for optimizing the Instruments function pointers.
rdar://35611235
rdar://35611185
rdar://36755525