[swift-dev] -whole-module-optimization with -Onone

[Ben Asher]

The build failed compiling 3 files in our project. Our app is crashing that
snapshot; here is some output from the failures:

- Assertion failed: (newType == type || (isa<TupleType>(newType) &&
cast<TupleType>(newType)->getNumElements() == 1 &&
cast<TupleType>(newType).getElementType(0) == type)), function rewriteType,
file /Users/buildn
ode/jenkins/workspace/oss-swift-package-osx/swift/lib/SILGen/RValue.h, line
207.

- SIL verification failed: method's Self parameter should be constrained by
protocol: selfRequirement.getKind() == RequirementKind::Conformance &&
selfRequirement.getFirstType()->isEqual(selfGenericParam) && selfR
equirement.getSecondType()->getAs<ProtocolType>() ->getDecl() == protocol

We're not getting all the way to linking, but compiling everything for that
snapshot took ~11min45s. Based on that, it appears that about a minute is
saved with the new fixes since the Swift 3.0 that shipped with Xcode 8.1
(App Store).

With Xcode 8.2 Beta 2, the app builds fine, and it takes about 12m15s. If
Xcode 8.2 Beta 2 also has those fixes that we expect to speed up the build,
the extra time here (compared to the snapshot) could be explained by
linking, signing, and a few other custom builds scripts that run after
compiling.

Thanks everyone for your help!

Ben


On Thu, Dec 1, 2016 at 4:16 PM, Ben Asher <benasher44 at gmail.com> wrote:

> I'm trying out DEVELOPMENT-SNAPSHOT-2016-11-29-a now. It's still going,
> so I don't have any time results yet. But, I did notice something new (or
> maybe existed before but didn't have this warning to expose it). For every
> Swift file that's compiled (only using -Onone here), it outputs the same 2
> warnings (easy to fix, but not related to any of this) from the same method
> in the same Obj-C header referring to the arguments and the return types in
> that method:
>
> - "array parameter is missing a nullability type specifier (_Nonnull,
> _Nullable, or _Null_unspecified)"
> - "inferring '_Nonnull' for pointer type within array is deprecated"
>
> Here's an example of what this method looks like:
>
> + (NSSet<SomeObject *> *)setWithSELs:(SEL[])sels count:(NSUInteger)count;
>
> Could this point to more duplicated work?
>
> Ben
>
> On Thu, Dec 1, 2016 at 2:50 PM, Ben Asher <benasher44 at gmail.com> wrote:
>
>> Sure! Thanks for reminding me. I'll follow up on that, test, and get back
>> to you.
>>
>> Ben
>>
>> On Thu, Dec 1, 2016 at 2:48 PM, Mark Lacey <mark_lacey at apple.com> wrote:
>>
>>>
>>> On Dec 1, 2016, at 3:13 PM, Ben Asher via swift-dev <swift-dev at swift.org>
>>> wrote:
>>>
>>> Just running a quick trial before and after I made this change in our
>>> project, we were previously seeing builds of our main target that took just
>>> under 13min. With this hack, a clean debug build takes about 4.5min.
>>>
>>>
>>> You may find that recent snapshot builds from swift.org help with your
>>> build times even without enabling -Owholemodule. The redundant type
>>> checking of synthesized accessors which we talked about a month or two
>>> should now be fixed on master, and it would be great to verify that’s the
>>> case with your code and to get an idea of how much it improves your build
>>> times.
>>>
>>> Mark
>>>
>>>
>>> Ben
>>>
>>> On Thu, Dec 1, 2016 at 1:33 PM, Ben Asher <benasher44 at gmail.com> wrote:
>>>
>>>> Okay I think that worked! And just to clarify, you meant set
>>>> SWIFT_OPTIMIZATION_LEVEL = -Owholemodule and OTHER_SWIFT_FLAGS = -Onone ?
>>>>
>>>> I'll file a radar this afternoon with some details and DM you the
>>>> number.
>>>>
>>>> Thanks again!
>>>>
>>>> Ben
>>>>
>>>> On Thu, Dec 1, 2016 at 1:10 PM, Jordan Rose <jordan_rose at apple.com> w
>>>> rote:
>>>>
>>>>> Xcode needs to know that you're building in WMO mode, so rather than
>>>>> putting -whole-module-optimization in your "Other Swift Flags", put -Onone
>>>>> there. It's an ugly hack but it should work in the near term.
>>>>>
>>>>> We do want to work to make this drastic speed difference go away, so
>>>>> if you're able we (at Apple) would love to have a source drop of your Swift
>>>>> 3 project, for additional data on where the problems are. Mind filing a
>>>>> Radar?
>>>>>
>>>>> Best,
>>>>> Jordan
>>>>>
>>>>>
>>>>> > On Dec 1, 2016, at 11:51, Ben Asher via swift-dev <
>>>>> swift-dev at swift.org> wrote:
>>>>> >
>>>>> > Hello! Someone recently tipped me off to using
>>>>> -whole-module-optimization flag with -Onone for use during debug builds to
>>>>> speed up compile times. In our project, the speedup feels quite dramatic,
>>>>> but when it gets to the linking step (after compiling both Swift and Obj-C
>>>>> in the project) it fails because ld can't find the individual object files
>>>>> that normally get emitted during the debug-type build presumably because
>>>>> -whole-module-optimization only emits one (and this isn't a normal
>>>>> "-Owholemodule"-type build which works fine).
>>>>> >
>>>>> > I can't seem to reproduce this outside of Xcode, but I was curious
>>>>> if anyone has tried this and knows of a workaround to get
>>>>> -whole-module-optimization to work with -Onone in Xcode?
>>>>> >
>>>>> > I'm currently using Xcode 8.1 (App Store build) and Swift 3 on macOS
>>>>> Sierra.
>>>>> >
>>>>> > Thanks!
>>>>> >
>>>>> > Ben
>>>>> > _______________________________________________
>>>>> > swift-dev mailing list
>>>>> > swift-dev at swift.org
>>>>> > https://lists.swift.org/mailman/listinfo/swift-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Ben
>>>>
>>>
>>>
>>>
>>> --
>>> Ben
>>> _______________________________________________
>>> swift-dev mailing list
>>> swift-dev at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-dev
>>>
>>>
>>>
>>
>>
>> --
>> Ben
>>
>
>
>
> --
> Ben
>



-- 
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20161201/8c8cde50/attachment.html>