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

Jump to bottom

[SR-10461] Unable to type check expression, Xcode 10.2 regression #52861

Open
jepers opened this issue Apr 12, 2019 · 6 comments
Open

[SR-10461] Unable to type check expression, Xcode 10.2 regression #52861

jepers opened this issue Apr 12, 2019 · 6 comments
Assignees
@hborla
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself performance regression swift 5.0 type checker Area → compiler: Semantic analysis

Comments

@jepers
Copy link

jepers commented Apr 12, 2019

Previous ID SR-10461
Radar None
Original Reporter @jepers
Type Bug
Environment

macOS 10.14.4, Xcode 10.2 default toolchain and most recent dev (snapshot 2019-04-10).

Additional Detail from JIRA
Votes 2
Component/s Compiler
Labels Bug, 5.0Regression, Performance, TypeChecker
Assignee @hborla
Priority Medium

md5: 7ec31f46de8374f0ac7b8e482cbd440f

relates to:

Issue Description:

I know for certain that the three lines with i, j and k in test.swift did type check (quickly) prior to upgrading to Xcode 10.2 and macOS 10.14.4. But the compiler is now unable to type check them.

test.swift:

import simd

func test(_ p0: float2, _ p1: float2, _ p2: float2, _ p3: float2) {
    let i = 3*(-p0 + 3*p1) - (3*p2 + p3)
    let j = 6*(p0 - 2*p1 + p2)
    let k = 3*(p1 - p0)
    print(i, j, k)
}
test(float2(0.1, 1.2), float2(2.3, 3.4), float2(4.5, 5.6), float2(6.7, 7.8))

test.swift doesn't compile, although I know it did before I upgraded to Xcode 10.2 and macOS 10.14.4:

$ swiftc --version
Apple Swift version 5.0 (swiftlang-1001.0.69.5 clang-1001.0.46.3)
Target: x86_64-apple-darwin18.5.0
$ time swiftc test.swift 
test.swift:4:28: error: the compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions
    let i = 3*(-p0 + 3*p1) - (3*p2 + p3)
            ~~~~~~~~~~~~~~~^~~~~~~~~~~~~

real    0m17.296s
user    0m16.647s
sys 0m0.613s

A naive workaround like wrapping parts of the expressions in float2(…) will make this tiny program compile, but in 12 seconds!

testB.swift:

import simd

func test(_ p0: float2, _ p1: float2, _ p2: float2, _ p3: float2) {
    let i = 3*float2(-p0 + float2(3*p1)) - float2(3*p2 + p3)
    let j = float2(6*(p0 - 2*p1 + p2))
    let k = float2(3*(p1 - p0))
    print(i, j, k)
}
test(float2(0.1, 1.2), float2(2.3, 3.4), float2(4.5, 5.6), float2(6.7, 7.8))

testB.swift compiles, but veeery slowly:

$ time swiftc testB.swift 

real    0m12.477s
user    0m11.975s
sys 0m0.490s

A better workaround is possible, noting that it is only the first of the three that is deemed too complex to type check, it suffices to break up the expression for `i` into two parts `iA` and `iB`:

testC.swift:

import simd

func test(_ p0: float2, _ p1: float2, _ p2: float2, _ p3: float2) {
    let iA = 3*(-p0 + 3*p1)
    let iB = (3*p2 + p3)
    let i = iA - iB
    let j = 6*(p0 - 2*p1 + p2)
    let k = 3*(p1 - p0)
    print(i, j, k)
    print(i)
}
test(float2(0.1, 1.2), float2(2.3, 3.4), float2(4.5, 5.6), float2(6.7, 7.8))

But testC.swift still takes a long time to compile, 7 seconds!

That's much longer than it took Xcode 10.1 (and macOS 10.14.3) to compile an entire medium size project that included the exact unaltered expression for `i` from test.swift above, and lots and lots of other similar expressions.

Is this because float2 is now a typealias for the new generic SIMD2<Float> (cc @stephentyrone )?

We have had to go through and modify a lot of our code because of this, and the build time has increased dramatically, especially in release builds.
@zienag
Copy link

zienag commented Apr 12, 2019

I’ve discovered somewhat similar issue too, https://bugs.swift.org/browse/SR-10130

@jepers
Copy link
Author

jepers commented Apr 12, 2019

I added some more observations here:
https://forums.swift.org/t/unable-to-type-check-expressions-with-xcode-10-2-new-simd-api/22873/3?u=jens

In short: It does seem like this regression is caused by float2 now being generic when it previously wasn't, perhaps in conjunction with a regression in the type checkers ability to handle expressions like that of `let i = ...` when `p0, p1, …` are generic. I can't test this since I do not have a pre-Xcode10.2 compiler available.

@jepers
Copy link
Author

jepers commented Apr 19, 2019

Not fixed in Xcode 10.2.1. Also note that it might have more to do with the update from
macOS 10.14.3 to macOS 10.14.4 and not specific to SIMD, see the example program (and the results) of this post:
https://forums.swift.org/t/no-longer-able-to-type-check-expressions-with-xcode-10-2-caused-by-new-simd-api/22873/3?u=jens

@jepers
Copy link
Author

jepers commented Apr 20, 2019

Also see:
https://forums.swift.org/t/has-type-checking-operators-on-generic-types-always-been-this-slow/23413

@jepers
Copy link
Author

jepers commented Sep 11, 2019

Not fixed in 10.3 and it drives me crazy. I think fixing this would dramatically reduce compile/type checking times, and almost everybody would notice it.

Again, the compiler has become, as of Xcode 10.2 and is still in 10.3, unable to type-check the following simple program in reasonable time:

let u = SIMD2<Float>(0, 1)
let v = SIMD2<Float>(1, 2)
let r = [
    2*u + 3*v,
    4*u + 5*v
]
print(r)

And if we help the type checker by spelling out the type of the array, it will take eight❗ seconds to compile that tiny program on my MBP:

let u = SIMD2<Float>(0, 1)
let v = SIMD2<Float>(1, 2)
let r: [SIMD2<Float>] = [
    2*u + 3*v,
    4*u + 5*v
]
print(r)

// $ swiftc --version
// Apple Swift version 5.0.1 (swiftlang-1001.0.82.4 clang-1001.0.46.5)
// Target: x86_64-apple-darwin18.7.0
// $ time swiftc test.swift
// 
// real    0m8.773s
// user    0m8.517s
// sys 0m0.241s

That is seven lines of very simple code, taking eight seconds to compile!

This has put us in a situation where we have to choose between

  1. waiting for ever for our code to compile or
  2. constantly watching out for and investigating/identifying expressions that messes up the type checker and thus need to be broken up into "simpler" (Swift type checker's very specific definition of "simpler") ones in order to try and keep compile times down.

@hborla
Copy link
Member

hborla commented Jan 7, 2021

I've started to work on generic/SIMD operator type checking performance here: #35025

@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
Assignees

@hborla hborla

Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself performance regression swift 5.0 type checker Area → compiler: Semantic analysis
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@zienag @jepers @hborla @AnthonyLatsis