Skip to content

Don't include support for old mangling in runtimes without ObjC interop #39675

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

Merged

Conversation

kubamracek
Copy link
Contributor

This saves a surprising amount of codesize in the runtime (~25 kB on x86_64).

Copy link
Member

@compnerd compnerd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could see an argument for this being something that you could control rather than associating this with the stable ABI. Id like to see Windows aim for a stable ABI at some point, and wouldn't want to include the old decoration schemes since it pre-dated the cut point. I don't think that adding in the option needs to hold up this change though.

@kubamracek
Copy link
Contributor Author

@swift-ci please test

Copy link
Contributor

@mikeash mikeash left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we make this conditional on ObjC interop rather than the stable ABI? ObjC is why we keep the old mangling around, so that would probably make more sense. I'm fine with adjusting that later if you prefer, though.

@kubamracek kubamracek force-pushed the remove-old-mangler-from-freestanding branch from d21d934 to 561621a Compare October 12, 2021 23:15
@kubamracek
Copy link
Contributor Author

Changed this to be conditioned on ObjC interop. But it turns out that CMake didn't really know whether ObjC interop is enabled for the platform we're building, so I've added that. Please re-review, @mikeash, @compnerd, thanks!

@kubamracek
Copy link
Contributor Author

@swift-ci please test

@compnerd
Copy link
Member

Well, the interesting thing is that ObjC interop is not a build time constant - it is a runtime value (-enable-objc-interop or -disable-objc-interop).

@kubamracek kubamracek force-pushed the remove-old-mangler-from-freestanding branch from 561621a to c6b19d2 Compare October 13, 2021 00:42
@kubamracek kubamracek changed the title Don't include support for old mangling in runtimes without stable ABI Don't include support for old mangling in runtimes without ObjC interop Oct 13, 2021
@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 561621a97e03042f21ef6f2333e90458adc1a680

@kubamracek
Copy link
Contributor Author

@swift-ci please test

@kubamracek
Copy link
Contributor Author

preset=stdlib_S_standalone_minimal_macho_x86_64,build,test
@swift-ci please test with toolchain and preset

@kubamracek
Copy link
Contributor Author

@swift-ci please test Windows platform

@mikeash
Copy link
Contributor

mikeash commented Oct 13, 2021

It's both, right? ObjC interop is enabled or disabled in the stdlib at build time, and then you can override the default when building a program. I don't think we really support mismatched values, though. The flag seems to be there so the frontend doesn't have to embed the knowledge of which targets support ObjC interop, and for use by codegen tests.

@compnerd
Copy link
Member

compnerd commented Oct 13, 2021

@mikeash yes, and I think that this change moves to actually clean that up. The sinking of the option to the stdlib makes this better. The demangler is in lib/ rather than stdlib/ which is what I think is making me uncomfortable (the way that things are phrased). I think that the change itself is fine now.

@kubamracek kubamracek merged commit 557bf68 into swiftlang:main Oct 14, 2021
@kubamracek kubamracek deleted the remove-old-mangler-from-freestanding branch October 14, 2021 02:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants