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

[jepers]

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:

• SR-10130 Type-check time regression

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]

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

[jepers]

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]

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]

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

[jepers]

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]

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

[slavapestov]

The first test case has improved over time:

• Swift 6.1: 4.6 seconds
• Swift 6.2: 3.4 seconds
• main: 700 ms

Still slow though, I'll add it to the suite.