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-15259] Should be possible to statically optimise out calls to swift_isUniquelyReferenced_nonNull_native immediately after retain call #57581

Closed
Lukasa opened this issue Sep 29, 2021 · 2 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself performance

Comments

@Lukasa
Copy link
Contributor

Lukasa commented Sep 29, 2021

Previous ID SR-15259
Radar rdar://problem/83825776
Original Reporter @Lukasa
Type Bug
Status Resolved
Resolution Done
Environment

Swift 5.5 RELEASE

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

md5: cae4a3377826580828afb9b77121337e

Issue Description:

Consider the following function:

func foo(_ x: Int) -> [Int] {
    var results: [Int] = []
    results.reserveCapacity(x)

    for _ in 0..<x {
        results.append(x)
    }

    return results
}

When compiled (see this godbolt page) this includes the following lines of assembly for part of the first two lines:

        mov     r15, qword ptr [rip + _swiftEmptyArrayStorage@GOTPCREL]
        mov     rdi, r15
        call    swift_retain@PLT
        mov     rdi, r15
        call    swift_isUniquelyReferenced_nonNull_native@PLT
        test    al, al
        je      .LBB1_1

In this instance, we load the empty array storage into r15. We then retain r15 and then pass it to swift_isUniquelyReferenced_nonNull_native.

This pattern has a statically-known result: the call to isUniquelyReferenced can only return false. In this instance, we have issued a retain call on a strong reference and, without any intervening release, we have then asked if it is uniquely referenced. Of course, it cannot be: we just issued a +1 and the object was already held strongly (at +1).

In principle we could have safely elided the call to isUniquelyReferenced, the jump, and just hit the resize operation in straight-line code. This would be a bit of a code size win.

@eeckstein
Copy link
Member

@swift-ci create

@eeckstein
Copy link
Member

Fixed with #40291

@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

2 participants