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 <mgottes...@apple.com> wrote: > > >> On Aug 6, 2017, at 2:55 PM, David Zarzycki <zarzy...@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 <mgottes...@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 <zarzy...@icloud.com> wrote: >>>> >>>> >>>>> On Aug 6, 2017, at 16:16, Michael Gottesman <mgottes...@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 >>>>> >>>> >> > _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
