Hello,
Unless I’m missing a build-script flag, it seems to me that compiling the Swift stdlib with the unoptimized debug swift compiler takes about 15 minutes on a fast machine. Other than forcing the type checker to be optimized, what if any tricks can I use to building the stdlib faster with the debug compiler? Is there a way to tell Clang to enable the inliner and only the inliner during -O0 builds? I have an anecdotal experiment[1] that suggests that this would yield appreciably faster Swift stdlib builds with the debug compiler (and selfishly speaking, I can tolerate the minor impact on debugging that inlining does to otherwise unoptimized code).
Thanks!
Dave
[1] – If one force inlines LLVM’s casting logic and associated callbacks (like classof() and getKind()), then the Swift stdlib builds 18% faster on my machine with the debug Swift compiler. One can imagine how much faster the whole stdlib would compile if all trivial functions were inlined automatically.
Hello,
Unless I’m missing a build-script flag, it seems to me that compiling the Swift stdlib with the unoptimized debug swift compiler takes about 15 minutes on a fast machine.
I am assuming that you mean a debug swift compiler building an optimized stdlib?
Other than forcing the type checker to be optimized, what if any tricks can I use to building the stdlib faster with the debug compiler? Is there a way to tell Clang to enable the inliner and only the inliner during -O0 builds? I have an anecdotal experiment[1] that suggests that this would yield appreciably faster Swift stdlib builds with the debug compiler (and selfishly speaking, I can tolerate the minor impact on debugging that inlining does to otherwise unoptimized code).
Are building LLVM in release + Swift in debug? I.e.:
--release-debuginfo --debug-swift --force-optimized-typechecker
···
On Aug 6, 2017, at 11:11 AM, David Zarzycki via swift-dev <swift-dev@swift.org> wrote:
Thanks!
Dave
[1] – If one force inlines LLVM’s casting logic and associated callbacks (like classof() and getKind()), then the Swift stdlib builds 18% faster on my machine with the debug Swift compiler. One can imagine how much faster the whole stdlib would compile if all trivial functions were inlined automatically.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
1 Like
Hello,
Unless I’m missing a build-script flag, it seems to me that compiling the Swift stdlib with the unoptimized debug swift compiler takes about 15 minutes on a fast machine.
I am assuming that you mean a debug swift compiler building an optimized stdlib?
Hi Michael,
I’m building the debug swift compiler via ./utils/build-script -r —debug-swift. I assume, perhaps wrongly, that implies a debug stdlib.
Other than forcing the type checker to be optimized, what if any tricks can I use to building the stdlib faster with the debug compiler? Is there a way to tell Clang to enable the inliner and only the inliner during -O0 builds? I have an anecdotal experiment[1] that suggests that this would yield appreciably faster Swift stdlib builds with the debug compiler (and selfishly speaking, I can tolerate the minor impact on debugging that inlining does to otherwise unoptimized code).
Are building LLVM in release + Swift in debug? I.e.:
—release-debuginfo --debug-swift --force-optimized-typechecker
Yes, with the exception that I cannot use —force-optimized-typechecker because I’m hacking on the type checker. Otherwise, this is what I’m doing to make debug builds go as fast as possible:
./utils/build-script \
--llvm-targets-to-build X86 \
--skip-ios --skip-tvos --skip-watchos \
--skip-build-benchmarks true \
--build-swift-static-stdlib false \
--build-swift-static-sdk-overlay false \
--build-swift-dynamic-sdk-overlay false \
--build-swift-stdlib-unittest-extra false \
--extra-cmake-options \\-DCMAKE_CXX_FLAGS=-Werror=switch \
-r \
--debug-swift \
"$@"
···
On Aug 6, 2017, at 16:16, Michael Gottesman <mgottesman@apple.com> wrote:
On Aug 6, 2017, at 11:11 AM, David Zarzycki via swift-dev <swift-dev@swift.org> wrote:
Thanks!
Dave
[1] – If one force inlines LLVM’s casting logic and associated callbacks (like classof() and getKind()), then the Swift stdlib builds 18% faster on my machine with the debug Swift compiler. One can imagine how much faster the whole stdlib would compile if all trivial functions were inlined automatically.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
You need an additional flag for the stdlib. —debug-swift-stdlib
···
Sent from my iPhone
On Aug 6, 2017, at 1:50 PM, David Zarzycki <zarzycki@icloud.com> wrote:
On Aug 6, 2017, at 16:16, Michael Gottesman <mgottesman@apple.com> wrote:
On Aug 6, 2017, at 11:11 AM, David Zarzycki via swift-dev <swift-dev@swift.org> wrote:
Hello,
Unless I’m missing a build-script flag, it seems to me that compiling the Swift stdlib with the unoptimized debug swift compiler takes about 15 minutes on a fast machine.
I am assuming that you mean a debug swift compiler building an optimized stdlib?
Hi Michael,
I’m building the debug swift compiler via ./utils/build-script -r —debug-swift. I assume, perhaps wrongly, that implies a debug stdlib.
Other than forcing the type checker to be optimized, what if any tricks can I use to building the stdlib faster with the debug compiler? Is there a way to tell Clang to enable the inliner and only the inliner during -O0 builds? I have an anecdotal experiment[1] that suggests that this would yield appreciably faster Swift stdlib builds with the debug compiler (and selfishly speaking, I can tolerate the minor impact on debugging that inlining does to otherwise unoptimized code).
Are building LLVM in release + Swift in debug? I.e.:
—release-debuginfo --debug-swift --force-optimized-typechecker
Yes, with the exception that I cannot use —force-optimized-typechecker because I’m hacking on the type checker. Otherwise, this is what I’m doing to make debug builds go as fast as possible:
./utils/build-script \
--llvm-targets-to-build X86 \
--skip-ios --skip-tvos --skip-watchos \
--skip-build-benchmarks true \
--build-swift-static-stdlib false \
--build-swift-static-sdk-overlay false \
--build-swift-dynamic-sdk-overlay false \
--build-swift-stdlib-unittest-extra false \
--extra-cmake-options \\-DCMAKE_CXX_FLAGS=-Werror=switch \
-r \
--debug-swift \
"$@"
Thanks!
Dave
[1] – If one force inlines LLVM’s casting logic and associated callbacks (like classof() and getKind()), then the Swift stdlib builds 18% faster on my machine with the debug Swift compiler. One can imagine how much faster the whole stdlib would compile if all trivial functions were inlined automatically.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
I tried that before responding and I found that the stdlib build time to be unchanged (still about 15 minutes).
···
On Aug 6, 2017, at 17:25, Michael Gottesman <mgottesman@apple.com> wrote:
You need an additional flag for the stdlib. —debug-swift-stdlib
Sent from my iPhone
On Aug 6, 2017, at 1:50 PM, David Zarzycki <zarzycki@icloud.com> wrote:
On Aug 6, 2017, at 16:16, Michael Gottesman <mgottesman@apple.com> wrote:
On Aug 6, 2017, at 11:11 AM, David Zarzycki via swift-dev <swift-dev@swift.org> wrote:
Hello,
Unless I’m missing a build-script flag, it seems to me that compiling the Swift stdlib with the unoptimized debug swift compiler takes about 15 minutes on a fast machine.
I am assuming that you mean a debug swift compiler building an optimized stdlib?
Hi Michael,
I’m building the debug swift compiler via ./utils/build-script -r —debug-swift. I assume, perhaps wrongly, that implies a debug stdlib.
Other than forcing the type checker to be optimized, what if any tricks can I use to building the stdlib faster with the debug compiler? Is there a way to tell Clang to enable the inliner and only the inliner during -O0 builds? I have an anecdotal experiment[1] that suggests that this would yield appreciably faster Swift stdlib builds with the debug compiler (and selfishly speaking, I can tolerate the minor impact on debugging that inlining does to otherwise unoptimized code).
Are building LLVM in release + Swift in debug? I.e.:
—release-debuginfo --debug-swift --force-optimized-typechecker
Yes, with the exception that I cannot use —force-optimized-typechecker because I’m hacking on the type checker. Otherwise, this is what I’m doing to make debug builds go as fast as possible:
./utils/build-script \
--llvm-targets-to-build X86 \
--skip-ios --skip-tvos --skip-watchos \
--skip-build-benchmarks true \
--build-swift-static-stdlib false \
--build-swift-static-sdk-overlay false \
--build-swift-dynamic-sdk-overlay false \
--build-swift-stdlib-unittest-extra false \
--extra-cmake-options \\-DCMAKE_CXX_FLAGS=-Werror=switch \
-r \
--debug-swift \
"$@"
Thanks!
Dave
[1] – If one force inlines LLVM’s casting logic and associated callbacks (like classof() and getKind()), then the Swift stdlib builds 18% faster on my machine with the debug Swift compiler. One can imagine how much faster the whole stdlib would compile if all trivial functions were inlined automatically.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
I tried that before responding and I found that the stdlib build time to be unchanged (still about 15 minutes).
Did you try reconfiguring via --reconfigure. Also, before you do that can you go into your swift build directory and run this:
ninja -t commands | grep swiftc | grep Swift.o
That should dump the swiftc line without you having to build everything. Can you check for the optimization flag?
Michael
···
On Aug 6, 2017, at 2:55 PM, David Zarzycki <zarzycki@icloud.com> wrote:
On Aug 6, 2017, at 17:25, Michael Gottesman <mgottesman@apple.com> wrote:
You need an additional flag for the stdlib. —debug-swift-stdlib
Sent from my iPhone
On Aug 6, 2017, at 1:50 PM, David Zarzycki <zarzycki@icloud.com> wrote:
On Aug 6, 2017, at 16:16, Michael Gottesman <mgottesman@apple.com> wrote:
On Aug 6, 2017, at 11:11 AM, David Zarzycki via swift-dev <swift-dev@swift.org> wrote:
Hello,
Unless I’m missing a build-script flag, it seems to me that compiling the Swift stdlib with the unoptimized debug swift compiler takes about 15 minutes on a fast machine.
I am assuming that you mean a debug swift compiler building an optimized stdlib?
Hi Michael,
I’m building the debug swift compiler via ./utils/build-script -r —debug-swift. I assume, perhaps wrongly, that implies a debug stdlib.
Other than forcing the type checker to be optimized, what if any tricks can I use to building the stdlib faster with the debug compiler? Is there a way to tell Clang to enable the inliner and only the inliner during -O0 builds? I have an anecdotal experiment[1] that suggests that this would yield appreciably faster Swift stdlib builds with the debug compiler (and selfishly speaking, I can tolerate the minor impact on debugging that inlining does to otherwise unoptimized code).
Are building LLVM in release + Swift in debug? I.e.:
—release-debuginfo --debug-swift --force-optimized-typechecker
Yes, with the exception that I cannot use —force-optimized-typechecker because I’m hacking on the type checker. Otherwise, this is what I’m doing to make debug builds go as fast as possible:
./utils/build-script \
--llvm-targets-to-build X86 \
--skip-ios --skip-tvos --skip-watchos \
--skip-build-benchmarks true \
--build-swift-static-stdlib false \
--build-swift-static-sdk-overlay false \
--build-swift-dynamic-sdk-overlay false \
--build-swift-stdlib-unittest-extra false \
--extra-cmake-options \\-DCMAKE_CXX_FLAGS=-Werror=switch \
-r \
--debug-swift \
"$@"
Thanks!
Dave
[1] – If one force inlines LLVM’s casting logic and associated callbacks (like classof() and getKind()), then the Swift stdlib builds 18% faster on my machine with the debug Swift compiler. One can imagine how much faster the whole stdlib would compile if all trivial functions were inlined automatically.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
Thanks Michael,
Now the stdlib builds in 5.5 minutes. My mistake was trusting ~/utils/build-script to automatically reconfigure the build.
Dave
···
On Aug 6, 2017, at 18:11, Michael Gottesman <mgottesman@apple.com> wrote:
On Aug 6, 2017, at 2:55 PM, David Zarzycki <zarzycki@icloud.com> wrote:
I tried that before responding and I found that the stdlib build time to be unchanged (still about 15 minutes).
Did you try reconfiguring via --reconfigure. Also, before you do that can you go into your swift build directory and run this:
ninja -t commands | grep swiftc | grep Swift.o
That should dump the swiftc line without you having to build everything. Can you check for the optimization flag?
Michael
On Aug 6, 2017, at 17:25, Michael Gottesman <mgottesman@apple.com> wrote:
You need an additional flag for the stdlib. —debug-swift-stdlib
Sent from my iPhone
On Aug 6, 2017, at 1:50 PM, David Zarzycki <zarzycki@icloud.com> wrote:
On Aug 6, 2017, at 16:16, Michael Gottesman <mgottesman@apple.com> wrote:
On Aug 6, 2017, at 11:11 AM, David Zarzycki via swift-dev <swift-dev@swift.org> wrote:
Hello,
Unless I’m missing a build-script flag, it seems to me that compiling the Swift stdlib with the unoptimized debug swift compiler takes about 15 minutes on a fast machine.
I am assuming that you mean a debug swift compiler building an optimized stdlib?
Hi Michael,
I’m building the debug swift compiler via ./utils/build-script -r —debug-swift. I assume, perhaps wrongly, that implies a debug stdlib.
Other than forcing the type checker to be optimized, what if any tricks can I use to building the stdlib faster with the debug compiler? Is there a way to tell Clang to enable the inliner and only the inliner during -O0 builds? I have an anecdotal experiment[1] that suggests that this would yield appreciably faster Swift stdlib builds with the debug compiler (and selfishly speaking, I can tolerate the minor impact on debugging that inlining does to otherwise unoptimized code).
Are building LLVM in release + Swift in debug? I.e.:
—release-debuginfo --debug-swift --force-optimized-typechecker
Yes, with the exception that I cannot use —force-optimized-typechecker because I’m hacking on the type checker. Otherwise, this is what I’m doing to make debug builds go as fast as possible:
./utils/build-script \
--llvm-targets-to-build X86 \
--skip-ios --skip-tvos --skip-watchos \
--skip-build-benchmarks true \
--build-swift-static-stdlib false \
--build-swift-static-sdk-overlay false \
--build-swift-dynamic-sdk-overlay false \
--build-swift-stdlib-unittest-extra false \
--extra-cmake-options \\-DCMAKE_CXX_FLAGS=-Werror=switch \
-r \
--debug-swift \
"$@"
Thanks!
Dave
[1] – If one force inlines LLVM’s casting logic and associated callbacks (like classof() and getKind()), then the Swift stdlib builds 18% faster on my machine with the debug Swift compiler. One can imagine how much faster the whole stdlib would compile if all trivial functions were inlined automatically.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev