[swift-dev] Faster debug builds?

[David Zarzycki]

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 at apple.com> wrote:
> 
> 
>> On Aug 6, 2017, at 2:55 PM, David Zarzycki <zarzycki at 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 at 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 at icloud.com> wrote:
>>>> 
>>>> 
>>>>> On Aug 6, 2017, at 16:16, Michael Gottesman <mgottesman at apple.com> wrote:
>>>>> 
>>>>> 
>>>>>> On Aug 6, 2017, at 11:11 AM, David Zarzycki via swift-dev <swift-dev at 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 at swift.org
>>>>>> https://lists.swift.org/mailman/listinfo/swift-dev
>>>>> 
>>>> 
>> 
>