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

Sure thing! I’ll see if I can put small reproducers together tomorrow. Ben On Thu, Dec 1, 2016 at 7:08 PM, Mark Lacey wrote: > > On Dec 1, 2016, at 5:48 PM, Ben Asher via swift-dev > wrote: > > The build failed compiling 3 files in our project. Our app is crashing > that snapshot; here is some

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

> On Dec 1, 2016, at 5:48 PM, Ben Asher via swift-dev > 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.

Re: [swift-dev] Questions about ARC

> On Dec 1, 2016, at 4:55 PM, Jiho Choi wrote: > > Thanks for the explanation. > One last question is why non-atomic ARC operations still use atomic load and > store. Wouldn't regular memory operations be enough? They use atomic operations with __ATOMIC_RELAXED, which basically means that th

Re: [swift-dev] Questions about ARC

Thanks for the explanation. One last question is why non-atomic ARC operations still use atomic load and store. Wouldn't regular memory operations be enough? On Thu, Dec 1, 2016 at 11:46 AM Roman Levenstein wrote: > On Nov 30, 2016, at 9:40 PM, Jiho Choi wrote: > > Thanks for providing the poi

[swift-dev] [Swift CI] Build Failure: 0. OSS - LLDB Incremental - OS X (master) #4921

Title: Report [FAILURE] oss-lldb-incremental-osx [#4921] Build URL:https://ci.swift.org/job/oss-lldb-incremental-osx/4921/ Project:oss-lldb-incremental-osx Date of build:Thu, 01 Dec 2016 15:23:45 -0800 Build duration:1 hr 29 min Identified problems:Assertion failure: This

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

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(newType) && cast(newType)->getNumElements() == 1 && cast(newType).getElementType(0) == type)), function rewriteType, file /Users

Re: [swift-dev] No commit emails

FWIW most commits go through GitHub pull requests nowadays, so setting up GitHub's notifications for the apple/swift repository will keep you informed of most changes. > On Dec 1, 2016, at 11:53 AM, Kenny Leung via swift-dev > wrote: > > Hi All. > > Just a heads up. > > We got a big bolus

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

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 war

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

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 wrote: > > On Dec 1, 2016, at 3:13 PM, Ben Asher via swift-dev > wrote: > > Just running a quick trial before and after I made this change in our > project, we were

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

> On Dec 1, 2016, at 3:13 PM, Ben Asher via swift-dev > 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 ma

[swift-dev] Details of what source compatibility with Swift 3 means

Hi, (I already sent this to swift-evolution yesterday but cross-posting.) One of the Stage 1 goals of Swift 4 is source compatibility with Swift 3, but what does that precisely mean and how will we determine if the goal is achieved? This is the current proposal of how this goal ties back to th

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

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. Ben On Thu, Dec 1, 2016 at 1:33 PM, Ben Asher wrote: > Okay I think that worked!

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

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 wrote: > Xcode needs t

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

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 (a

Re: [swift-dev] -Onone @inline(__always)?

> On Dec 1, 2016, at 12:11 PM, Andrew Trick wrote: > > >> On Dec 1, 2016, at 11:55 AM, Joe Groff wrote: >> >> >>> On Dec 1, 2016, at 11:48 AM, Andrew Trick wrote: >>> >>> Responding on swift-dev to what turned into an interesting discussion… >>> On Dec 1, 2016, at 11:19 AM, Joe Groff

Re: [swift-dev] -Onone @inline(__always)?

> On Dec 1, 2016, at 11:55 AM, Joe Groff wrote: > > >> On Dec 1, 2016, at 11:48 AM, Andrew Trick > > wrote: >> >> Responding on swift-dev to what turned into an interesting discussion… >> >>> On Dec 1, 2016, at 11:19 AM, Joe Groff >> > wrote:

Re: [swift-dev] -Onone @inline(__always)?

> On Dec 1, 2016, at 11:48 AM, Andrew Trick wrote: > > Responding on swift-dev to what turned into an interesting discussion… > >> On Dec 1, 2016, at 11:19 AM, Joe Groff wrote: >> >>> >>> On Dec 1, 2016, at 11:18 AM, Joe Groff wrote: >>> On Dec 1, 2016, at 11:16 AM, Andrew Trick

Re: [swift-dev] No commit emails

Hi All. Just a heads up. We got a big bolus on November 18, and then nothing after that. Thanks. -Kenny > On Nov 18, 2016, at 4:18 PM, Jordan Rose wrote: > > Thanks for the heads-up. I think our old notifier system is finally invalid > after a network reconfiguration. We've been meaning to

Re: [swift-dev] -Onone @inline(__always)?

> On Dec 1, 2016, at 11:48 AM, Andrew Trick wrote: > > Responding on swift-dev to what turned into an interesting discussion… > >> On Dec 1, 2016, at 11:19 AM, Joe Groff > > wrote: >> >>> >>> On Dec 1, 2016, at 11:18 AM, Joe Groff >> > wrote:

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

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 bec

Re: [swift-dev] -Onone @inline(__always)?

Responding on swift-dev to what turned into an interesting discussion… > On Dec 1, 2016, at 11:19 AM, Joe Groff wrote: > >> >> On Dec 1, 2016, at 11:18 AM, Joe Groff wrote: >> >>> >>> On Dec 1, 2016, at 11:16 AM, Andrew Trick wrote: >>> >>> On Dec 1, 2016, at 10:34 AM, Jordan Rose w

Re: [swift-dev] Questions about ARC

> On Nov 30, 2016, at 9:40 PM, Jiho Choi wrote: > > Thanks for providing the pointer. > Do you have any preliminary result or goal (e.g. the replacement ratio) of > the optimization? > Is it going to replace all ARC operations with non-atomic ones for > single-threaded applications? In the i

Re: [swift-dev] COW for non-mutating methods

> On Dec 1, 2016, at 3:29 AM, Patrick Pijnappel via swift-dev > wrote: > > I'm implementing a COW big int type but am running into problems with > non-mutating functions (e.g. the + operator). Simplified example code below > shows AFAIK the default way to implement COW, but the non-mutating m

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 16.10 (master) #695

That was me changing an llvm API, I added a compatibility cludge in 209698dc097f5c1836445f778992f2e5f6cff404 that should unbreak the build (and not regress anything). I'll create a pull request with a proper fix for swift. - Matthias > On Nov 30, 2016, at 6:37 PM, no-re...@swift.org wrote: >

Re: [swift-dev] Automatically building SourceKit on Linux

So the 5861/5862 have been merged now, which means that we can build SourceKit on Linux with: swift/utils/build-script -R -T --libdispatch -- --reconfigure swift/utils/build-script -R -T --libdispatch --extra-cmake-options="-DSWIFT_BUILD_SOURCEKIT:BOOL=TRUE" -- --reconfigure I'd like to get S

[swift-dev] COW for non-mutating methods

I'm implementing a COW big int type but am running into problems with non-mutating functions (e.g. the + operator). Simplified example code below shows AFAIK the default way to implement COW, but the non-mutating method doesn't identify the reference as unique (even with -O), resulting in a needles