mirror of
https://github.com/apple/swift.git
synced 2026-02-27 18:26:24 +01:00
9d0b6c8417
As RedundantLoadElimination processing the loads in reverse control flow order, the replaced loads might accumulate quite a lot of users. This happens if the are many loads from the same location in a row. To void quadratic complexity in `uses.replaceAll`, we swap both load instructions and move the uses from the `existingLoad` (which usually has a small number of uses) to this load - and delete the `existingLoad`. This came up in the Sema/large_int_array.swift.gyb test, which tests a 64k large Int array. With this fix, the compile time gets down from 3 minutes to 5 seconds. I also changed the test: * run the compiler with the timeout script to detect build time regressions * re-enabled the SIL verifier because the problem there is already fixed (https://github.com/swiftlang/swift/pull/86781) * run the compiler with -O to also test the whole optimizer pipeline and not only the mandatory pipeline * assigned the array to a real variable (instead of `_`) to not let the optimizer remove the whole array too early * run the compiler with and without `-parse-as-library` because this makes a huge difference how the global array is being generated
19 lines
674 B
Swift
19 lines
674 B
Swift
// RUN: %empty-directory(%t)
|
|
// RUN: %gyb %s -o %t/large_int_array.swift
|
|
|
|
// The compiler should finish in less than 10 seconds. To give some slack,
|
|
// specify a timeout of 1 minute.
|
|
|
|
// RUN: %{python} %S/../../test/Inputs/timeout.py 60 %target-swift-frontend -typecheck -verify %t/large_int_array.swift
|
|
// RUN: %{python} %S/../../test/Inputs/timeout.py 60 %target-swift-frontend -O %t/large_int_array.swift -emit-sil -o /dev/null
|
|
// RUN: %{python} %S/../../test/Inputs/timeout.py 60 %target-swift-frontend -parse-as-library -O %t/large_int_array.swift -emit-sil -o /dev/null
|
|
|
|
% num_elements = 65537
|
|
|
|
let v = 0
|
|
let x : [Int] = [
|
|
% for i in range(num_elements):
|
|
v,
|
|
% end
|
|
]
|