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-5756] Add a guaranteed partial apply elimination peephole to guaranteed passes and then simplify SILGenApply #48326

Open
gottesmm opened this issue Aug 23, 2017 · 3 comments
Assignees
Labels
compiler The Swift compiler in itself improvement performance SILGen Area → compiler: The SIL generation stage

Comments

@gottesmm
Copy link
Member

Previous ID SR-5756
Radar rdar://problem/34046413
Original Reporter @gottesmm
Type Improvement
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Improvement, Performance, SILGen
Assignee @gottesmm
Priority Medium

md5: 1e500ef1747ae510122b49d54d21e11b

Issue Description:

Today there is logic in SILGenApply that avoids forming a closure/emitting captures in the case where we immediately call the closure locally. This adds a bunch of complexity to SILGenApply that could be removed if we took our already written partial apply elimination logic and ran it as a guaranteed peephole (perhaps in constant propagation? not sure).

Then we can eliminate this "pseudo"-uncurry code from SILGenApply simplifying SILGen!

@gottesmm
Copy link
Member Author

@swift-ci create

@belkadan
Copy link
Contributor

I don't work on SILGen, but I'm concerned this could adversely affect -Onone compile time.

@gottesmm
Copy link
Member Author

Like with anything, I imagine we would have to measure compile time performance when implementing this.

@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
compiler The Swift compiler in itself improvement performance SILGen Area → compiler: The SIL generation stage
Projects
None yet
Development

No branches or pull requests

2 participants