8000 simd: incorrect swift binding: Int64 != simd_long (aka Int) · Issue #81804 · swiftlang/swift · GitHub
[go: up one dir, main page]
Skip to content

simd: incorrect swift binding: Int64 != simd_long (aka Int) #81804

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.

Sign up for GitHub

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

Jump to bottom
Closed
Jerry1144 opened this issue May 28, 2025 · 2 comments
Closed

simd: incorrect swift binding: Int64 != simd_long (aka Int) #81804

Jerry1144 opened this issue May 28, 2025 · 2 comments
Labels < 8000 div class="min-width-0 d-flex flex-wrap mt-n1"> bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.

Comments

@Jerry1144
Copy link

Description

From simd/logic.h, there's this set of simd_select(float,float,int) functions:
simd_select(simd_half8 x, simd_half8 y, simd_short8 mask)
simd_select(simd_float8 x, simd_float8 y, simd_int8 mask)
simd_select(simd_double8 x, simd_double8 y, simd_long8 mask)

You'd expect the 3 operands to have the same width, but it isn't on the Swift side!

error: cannot convert value of type 'SIMD_i' (aka 'SIMD8<Int64>') to expected argument type 'simd_long8' (aka 'SIMD8<Int>')

Defining LP64 also does not work.

Reproduction

import simd

typealias SIMD_f = SIMD8<Double>
typealias SIMD_i = SIMD8<Int64>
func clamp_up_to_zero(_ pack : inout SIMD_f) {
    pack = simd_select(pack, SIMD_f(repeating: 0), unsafeBitCast(pack, to: SIMD_i.self))
}

Expected behavior

It should compile, just like when SIMD_f = SIMD8<Float>; SIMD_i = SIMD8<Int32> and SIMD_f = SIMD8<Float16>; SIMD_i == SIMD8<Int16>

Environment

swift-driver version: 1.120.5 Apple Swift version 6.1 (swiftlang-6.1.0.110.21 clang-1700.0.13.3)
Target: arm64-apple-macosx15.0

Additional information

Was trying to mimic f / 2^64, by doing f.bitPattern &- Double(sign: .plus, exponentBitPattern: UInt(64), significandBitPattern: UInt64(0)).bitPattern and then handling the case where f = 0.

It'd be the only case when f becomes negative, so simd_select(f, 0, unsafeBitCast(f, to: Int64.self) came to the rescue.
@Jerry1144 Jerry1144 added bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. triage needed This issue needs more specific labels labels May 28, 2025
@stephentyrone
Copy link
Contributor

Behaves correctly; the definition of simd_long8 comes from Apple's simd.h headers, which are outside the Swift project's purview, and we faithfully import that into Swift. (And the definition of simd_long8 there was deliberately chosen to be the same type as MetalSL's long8 type, so their definition is also correct).

The three operands do always have the same size. On 32b platforms, where Int would be only 32b, simd_long8 is instead a vector of CLongLong, which is 64b. So the way to avoid this is to use the C name instead:

import simd

typealias SIMD_f = SIMD8<Double>
func clamp_up_to_zero(_ pack : inout SIMD_f) {
    pack = simd_select(pack, SIMD_f(repeating: 0), unsafeBitCast(pack, to: simd_long8.self))
}

@stephentyrone stephentyrone removed the triage needed This issue needs more specific labels label May 28, 2025
@Jerry1144
Copy link
Author
Jerry1144 commented May 29, 2025 •
edited
Loading

The three operands do always have the same size. On 32b platforms, where Int would be only 32b, simd_long8 is instead a vector of CLongLong, which is 64b. So the way to avoid this is to use the C name instead:

Indeed. The C side essentially defined simd_long like this:

typealias simd_long = (Int == Int64) ? Int : Int64

we faithfully import that into Swift.

Please tell me how is letting Swift complain simd_long != Int64 faithful. If the Swift auto conversion process cannot handle these ifdef __LP64__s, then just bind simd_long to Int64 to let the intention through.

EDIT: Nevermind. I guess this falls outside the scope of Swift Standard Library. Gone Feedback Assistant

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@stephentyrone @Jerry1144
0