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-7274] More UnsafePointer operations should be @transparent #49822

Closed
rjmccall opened this issue Mar 25, 2018 · 9 comments
Closed

[SR-7274] More UnsafePointer operations should be @transparent #49822

rjmccall opened this issue Mar 25, 2018 · 9 comments
Assignees
Labels
improvement standard library Area: Standard library umbrella

Comments

@rjmccall
Copy link
Member

Previous ID SR-7274
Radar None
Original Reporter @rjmccall
Type Improvement
Status Closed
Resolution Done
Additional Detail from JIRA
Votes 0
Component/s Standard Library
Labels Improvement
Assignee @belkadan
Priority Medium

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 for UnsafePointer<Int8>?. Since this is CommandLine.arguments, this means that we create multiple type metadata at the start of basically every Swift process.

@belkadan
Copy link
Contributor

"Transparent" isn't supposed to just be used for optimization, but in this case the semantic effects are probably desirable as well.

cc @moiseev, @atrick

@atrick
Copy link
Member

atrick commented Mar 26, 2018

I would think it's looking up Int8 metadata, not UnsafePointer. At any rate, it's something that we should optimize away at -Onone.

-Onone should have an inlining pass to handle things like @inline(__always) and noescape closures (-Onone is quite a misnomer anyway). I could have sworn I had a bug on that but can't find it now.

Then it's just a matter of the right stdlib annotations. I'm fine abusing @transparent a bit until @inline(__always) works.

@atrick
Copy link
Member

atrick commented Mar 26, 2018

I created SR-7277 -Onone should inline @inline(__always) and linked to that.

@belkadan
Copy link
Contributor

In this case I think it isn't really abuse. We don't want to treat a call to advanced(by:) as actually a call you can step into anyway.

@atrick
Copy link
Member

atrick commented Mar 26, 2018

Yes, I think this bug title is still accurate. The @inline(__always) issue is tangential.

@belkadan
Copy link
Contributor

I ran into this being necessary for parseable interfaces to get proper optimization behavior, so I think #21126 covers it.

@atrick
Copy link
Member

atrick commented Dec 10, 2018

@belkadan's PR above should fix this.

@belkadan
Copy link
Contributor

This probably shouldn't be closed until I merge the PR…

@belkadan
Copy link
Contributor

Okay, now it's merged (master only).

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
improvement standard library Area: Standard library umbrella
Projects
None yet
Development

No branches or pull requests

3 participants