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-7274] More UnsafePointer operations should be @transparent #49822
Comments
"Transparent" isn't supposed to just be used for optimization, but in this case the semantic effects are probably desirable as well. |
I would think it's looking up
Then it's just a matter of the right stdlib annotations. I'm fine abusing |
In this case I think it isn't really abuse. We don't want to treat a call to |
Yes, I think this bug title is still accurate. The |
I ran into this being necessary for parseable interfaces to get proper optimization behavior, so I think #21126 covers it. |
@belkadan's PR above should fix this. |
This probably shouldn't be closed until I merge the PR… |
Okay, now it's merged (master only). |
Additional Detail from JIRA
md5: 836bb66959851c430085bd51b2dd3190
relates to:
Issue Description:
Unoptimized code involving UnsafePointers still very frequently results in calls into the library, which in turns forces the compiler to produce type metadata for the generic call.
For example, CommandLine.arguments contains a call to
UnsafePointer.advanced(by: )
and therefore a call to get metadata forUnsafePointer<Int8>?
. Since this is CommandLine.arguments, this means that we create multiple type metadata at the start of basically every Swift process.The text was updated successfully, but these errors were encountered: