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

Thu Dec 1 21:08:34 CST 2016

> On Dec 1, 2016, at 5:48 PM, Ben Asher via swift-dev <swift-dev at swift.org> wrote:
> 
> The build failed compiling 3 files in our project. Our app is crashing that snapshot; here is some output from the failures:

It would be awesome if you could come up with small reproducers for these and open bugs for them. Alternately, opening a radar with the full project attached will give us an opportunity to get these fixed ASAP!

Mark

> 
> - 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 <mailto: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 <mailto: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 <mailto:mark_lacey at apple.com>> wrote:
> 
>> On Dec 1, 2016, at 3:13 PM, Ben Asher via swift-dev <swift-dev at swift.org <mailto: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 <http://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 <mailto: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 <mailto:jordan_rose at apple.com>> wrote:
>> 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 <mailto: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 <mailto:swift-dev at swift.org>
>> > https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
>> 
>> 
>> 
>> 
>> -- 
>> Ben
>> 
>> 
>> 
>> -- 
>> Ben
>> _______________________________________________
>> swift-dev mailing list
>> swift-dev at swift.org <mailto:swift-dev at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
> 
> 
> 
> -- 
> Ben
> 
> 
> 
> -- 
> Ben
> 
> 
> 
> -- 
> Ben
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

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