> 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

Reply via email to