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-9809] swiftc appears to make some sub-optimal optimization choices #52229

Closed
liscio opened this issue Jan 30, 2019 · 3 comments
Closed

[SR-9809] swiftc appears to make some sub-optimal optimization choices #52229

liscio opened this issue Jan 30, 2019 · 3 comments
Assignees
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself performance

Comments

@liscio
Copy link

liscio commented Jan 30, 2019

Previous ID SR-9809
Radar None
Original Reporter @liscio
Type Bug
Status Closed
Resolution Done

Attachment: Download

Environment

I have tested this out with both swift 4.2.1 (Xcode 10.1), and swift 5 (Xcode 10.2b1).

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, Performance
Assignee @atrick
Priority Medium

md5: 8253cbbd63b4aa9d3b4b4607f09e3f48

Issue Description:

I was playing around with the compiler the other day in an attempt to discover techniques for getting Swift to produce faster code, and then I encountered a bit of a head-scratcher along the way.

Attached is some simple code that demonstrates a case where Swift appears to produce sub-optimal assembly for code that uses an UnsafeBufferPointer<Float> compared to the same code using [Float].

Specifically, when compiling with -O, the version using [Float] is optimized how I would expect, and -Ounchecked appears to produce identical code. But the version that uses UnsafeBufferPointer<Float> produces assembly that does not unroll the loop when I specify -O, however it unrolls the loop (and produces identical assembly to [Float]) when I specify -Ounchecked.

I have included the sample code, and a script that will run the Swift compiler to produce assembly for both pieces of code, with both of the optimization flags.

@belkadan
Copy link
Contributor

cc @atrick, @eeckstein

@atrick
Copy link
Member

atrick commented Feb 4, 2019

PR: #22338

@atrick
Copy link
Member

atrick commented Feb 6, 2019

I merged this into master. The benchmark regressions are incidental and will be fixed by a separate PR. The specific case described in this bug has a unit test now which is better than adding a benchmark.

@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
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself performance
Projects
None yet
Development

No branches or pull requests

3 participants