[swift-dev] inout and aliasing in the optimizer

Hi, I'm currently working on improving alias analysis in the optimizer and I run into following problem: If alias analysis assumes that inout may not alias any other object, we may violate memory safety. Note that currently it's not always assumed, e.g. not in computeMemoryBehavior for apply i

[swift-dev] changes in the inliner

Hi, I'd like to give some more information about the inliner changes I landed this week. The goal was to restrict inlining to improve code size while not degrade performance (too much). This was mainly achieved by improving the heuristic for the inlining decisions. Some of our optimizations are

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

This looks like there is some kind of non-determinism in the compilation. > On Apr 19, 2016, at 8:14 PM, Greg Parker wrote: > > >> On Apr 19, 2016, at 12:45 PM, no-re...@swift.org wrote: >> >> [FAILURE] oss-swift-incremental-RA-osx [#3504] >> >> Tests: >> >> Name: Swift >> Failed: 1 test(s)

Re: [swift-dev] [Swift CI] Build Still Failing: OSS - Swift Package - Ubuntu 15.10 (master) #1059

Xin and I working on a fix for the original problem. I think we should _disable_ this test on linux in the meantime and not _xfail_ it. Erik > On Apr 20, 2016, at 2:10 PM, Greg Parker via swift-dev > wrote: > > Nope, not your fault. This is a pre-existing problem. I'm not sure why the CI >

Re: [swift-dev] [Swift CI] Build Still Failing: OSS - Swift Package - Ubuntu 15.10 (master) #1059

BTW, this is the radar: rdar://problem/25842757 > On Apr 20, 2016, at 5:03 PM, Erik Eckstein via swift-dev > wrote: > > Xin and I working on a fix for the original problem. > I think we should _disable_ this test on linux in the meantime and not > _xfail_ it. > >

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 15.10 - Long Test (master) #70

(resending with less recipients) I could not reproduce it locally. But I noticed that foundation tests (foundation-linux-x86_64/TestFoundation/TestFoundation) were not recompiled in my local build, although the compiler changed. After I did a clean build all foundation tests passed. Can we try

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 15.10 - Long Test (master) #70

I could not reproduce it locally. But I noticed that foundation tests (foundation-linux-x86_64/TestFoundation/TestFoundation) were not recompiled in my local build, although the compiler changed. After I did a clean build all foundation tests passed. Can we try a clean build on the bot? Erik >

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

Hi Mishal, this might be a problem with incremental. I’d like to rebuild with a clean workspace. How can I clean the workspace? Thanks, Erik > On Jun 16, 2016, at 5:13 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#5724] > > Build URL: > https://

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

I just reproduced it locally. It's a swift compiler crash > On Jul 27, 2016, at 9:59 AM, Andrew Trick via swift-dev > wrote: > > Mishal, > > Can you tell me what happened here? > > -Andy > >> On Jul 27, 2016, at 9:57 AM, no-re...@swift.org >> wrote: >> >> [FAIL

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

Actually, what I reproduced is the other problem, which Michael already investigated > On Jul 27, 2016, at 10:23 AM, Andrew Trick wrote: > > FYI: Swift CI just passed on this commit minutes before this crash (it was > automerged). Of course validation tests also pass for me locally on linux an

Re: [swift-dev] End of source-breaking changes for Swift 3

> On Jul 27, 2016, at 2:01 PM, Roman Levenstein wrote: > > > SE-0130 - Replace repeating Character and UnicodeScalar forms of String.init > > > This one was implemented by me. It was committed

Re: [swift-dev] Advice on adding PGO support

Hi Vedant, nice work! > On Sep 6, 2016, at 12:36 PM, Vedant Kumar via swift-dev > wrote: > > Hi swift-dev, > > I've been working on some patches which add basic support for PGO to swift > [1]. > What I have so far is just a proof-of-concept. I'd like to get some feedback > on > the approach

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

The test itself is problematic: rdar://problem/28337667 > On Sep 16, 2016, at 12:33 AM, Slava Pestov via swift-dev > wrote: > > This is a random one-off failure. > > Also my PR for the swift-3.0-branch hit a set of segfaults in the Dictionary > tests, but this time in the iphone simulator t

Re: [swift-dev] Are there any Swift/LLVM optimizations I could be assigned to?

Hi Eddie, > On Sep 19, 2016, at 6:10 PM, Eddie Santos via swift-dev > wrote: > > Hi all, > > Are there any moderately do-able optimizations that can be done in the Swift > compiler that have not been done yet? > > I am a masters student at the University of Alberta in Dr. J. Nelson Amaral's

[swift-dev] copy-on-write proposal

This is a proposal for representing copy-on-write buffers in SIL. Actually it’s still a draft for a proposal. It also heavily depends on how we move forward with SIL ownership. CopyOnWrite.rst Description: Binary data If you have any comments, please let me know. Erik __

Re: [swift-dev] copy-on-write proposal

ayStorage >> >>// Write some data into the CoW buffer. >>// (For simplicity, pretend ArrayStorage has a "someData" field). >>// A single-use _addr instruction, so no scope. >>%somedata_addr = ref_element_addr %arrayref._storage, #som

Re: [swift-dev] copy-on-write proposal

heavily rely on inlining. I would say that originally almost everything is inside a called function, just think of all the generated getters/setters. But usually this is not a problem because most of the relevant functions are quite small and always inlined anyway. > >> On Oct 11, 2016,

Re: [swift-dev] copy-on-write proposal

> On Oct 13, 2016, at 10:36 AM, Joe Groff wrote: > > >> On Oct 11, 2016, at 4:48 PM, Erik Eckstein via swift-dev >> wrote: >> >> This is a proposal for representing copy-on-write buffers in SIL. Actually >> it’s still a draft for a proposal.

Re: [swift-dev] copy-on-write proposal

On Oct 16, 2016, at 2:05 PM, Dave Abrahams via swift-dev wrote: > on Thu Oct 13 2016, Joe Groff <http://swift-dev-at-swift.org/>> wrote: > >>> On Oct 11, 2016, at 4:48 PM, Erik Eckstein via swift-dev >>> wrote: >>> >>> This is a proposa

Re: [swift-dev] copy-on-write proposal

t.org/>> wrote: >>> >>>>> On Oct 11, 2016, at 4:48 PM, Erik Eckstein via swift-dev >>>>> wrote: >>>>> >>>>> This is a proposal for representing copy-on-write buffers in >>>>> SIL. Actually it’s still a dra

Re: [swift-dev] copy-on-write proposal

> wrote: >>>> >>> >>>>> On Oct 16, 2016, at 2:05 PM, Dave Abrahams via swift-dev >>>>> mailto:swift-dev@swift.org>> wrote: >>>>> >>>>>> on Thu Oct 13 2016, Joe Groff >>>>> <http://swi

Re: [swift-dev] copy-on-write proposal

gt;> on Mon Oct 17 2016, Erik Eckstein >>>>> <http://eeckstein-at-apple.com/>> wrote: >>>>>> >>>>> >>>>>>> On Oct 16, 2016, at 2:05 PM, Dave Abrahams via swift-dev >>>>>>> mailto:swift-dev@swif

Re: [swift-dev] copy-on-write proposal

> On Oct 20, 2016, at 10:11 AM, Andrew Trick wrote: > > >> On Oct 20, 2016, at 8:41 AM, Erik Eckstein > > wrote: >> >>> To clarify: I proposed an alternate approach in which the @sil_cow >>> reference is only mutable during the Array’s @inout scope—to be >>> autom

Re: [swift-dev] Inability to leverage privacy in the stdlib

> On Oct 27, 2016, at 1:44 PM, Jordan Rose via swift-dev > wrote: > > >> On Oct 23, 2016, at 16:13, Michael Gottesman > > wrote: >> >> >>> On Oct 23, 2016, at 3:30 PM, Alexis Beingessner via swift-dev >>> mailto:swift-dev@swift.org>> wrote: >>> >>> Dave pointed

Re: [swift-dev] Inability to leverage privacy in the stdlib

> On Oct 28, 2016, at 5:01 PM, Jordan Rose wrote: > > >> On Oct 28, 2016, at 17:00, Erik Eckstein > > wrote: >> >>> >>> On Oct 27, 2016, at 1:44 PM, Jordan Rose via swift-dev >> > wrote: >>> >>> On Oct 23, 2016, at 16:13, Michael

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

> On Jan 24, 2017, at 10:52 PM, Andrew Trick wrote: > > So it looks like the Foundation tests haven’t been run for a few builds. > Taking a wild guess, could this have something to do with mangling Erik? > Unlikely___ swift-dev mailing list swift-de

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

Is there a workaround? PR testing is blocked on this. > On Feb 3, 2017, at 11:13 AM, Douglas Gregor via swift-dev > wrote: > > >> On Feb 3, 2017, at 11:12 AM, Michael Ilseman > > wrote: >> >> Is that a missing dependency in CMake then? > > They’re totally separate

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

> On Feb 6, 2017, at 2:17 PM, mishal_shah wrote: > > Hi Erik, > > Please try “@swift-ci Please clean test”. This will clean up the workspace > before building. Thanks! That worked! > > Thanks, > Mishal Shah >> On Feb 6, 2017, at 2:08 PM, Erik Eckstein

Re: [swift-dev] No return functions and program exit

I’m not sure if I understood. What if there is a call to a function and that conditionally calls a noreturn function: func foo() { let x = Myclass() bar(true) // release x here? } func bar(_ dontReturn: Bool) { if (dontReturn) { noreturn_func() } } Is it even possible to “clean up

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

That’s me. I’m going to revert > On Feb 15, 2017, at 1:30 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#1923] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/1923/ >

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

Well, it might be a build-problem. I cannot reproduce it locally. I’ll try to make a clean build first before I revert. > On Feb 15, 2017, at 1:36 PM, Erik Eckstein via swift-dev > wrote: > > That’s me. > I’m going to revert > >> On Feb 15, 2017, at 1:30 PM, no-re...

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

The clean build passed. > On Feb 15, 2017, at 2:44 PM, Erik Eckstein wrote: > > Well, it might be a build-problem. I cannot reproduce it locally. > I’ll try to make a clean build first before I revert. > >> On Feb 15, 2017, at 1:36 PM, Erik Eckstein via swift-dev >>

[swift-dev] linux pr testing is broken

Hi Danial, Looks like your recent merge in libdispatch broke the linux PR bot: https://ci.swift.org/job/swift-PR-Linux-smoke-test/5126/ /home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/branch-master/buildbot_linux/libdispatc

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

Now there is a fail in the tests: https://ci.swift.org/job/swift-PR-Linux-smoke-test/5128/ FAIL: dispatch_context_for_key == == [TEST] Dispatch Queue Specific

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

but one of the Linux guys > will probably have to debug (we certainly don’t see this on Darwin internally) yes, please > >> On Feb 22, 2017, at 10:41, Erik Eckstein via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >> Now there is a fail in the tests:

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

Thanks! I’ll give it a try > On Feb 22, 2017, at 10:55 AM, Daniel A. Steffen wrote: > > >> On Feb 22, 2017, at 10:48, Erik Eckstein via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >>> >>> On Feb 22, 2017, at 10:47 AM, Dani

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

more. > > Can you adjust the CI scripts to make sure this dependency is added ? > Forwarding this question to Mishal > Thanks. > > -Pierre > >> On Feb 22, 2017, at 10:56 AM, Erik Eckstein via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >>

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

Should be fixed by https://github.com/apple/swift/pull/7767 > On Feb 24, 2017, at 8:18 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-osx [#8561] > > Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/8561/ >

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

Mishal, can you trigger a clean build for this? Thanks, Erik > On Mar 16, 2017, at 2:31 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#2428] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/2428/ >

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

> On Mar 16, 2017, at 2:32 PM, Adrian Prantl wrote: > > I'm somewhat confused why this failed? It needs a clean build. > > -- adrian > >> On Mar 16, 2017, at 2:31 PM, no-re...@swift.org >> wrote: >> >> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#2428

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

Mishal, can you please clean the workspace for this job? It’s again the same issue of missing build dependencies from swiftc -> foundation Thanks, Erik > On Mar 26, 2017, at 1:03 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#2646] > > Build URL:

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

Mishal, can you please clean the workspace? Another missing build dependency. Thanks > On Mar 27, 2017, at 11:25 AM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#2664] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16

Re: [swift-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - OS X (master) #9070

And please for this as well Thanks > On Mar 27, 2017, at 11:38 AM, no-re...@swift.org wrote: > > New issue found! > > [FAILURE] oss-swift-incremental-RA-osx [#9070] > > Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/9070/ >

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

> On Mar 27, 2017, at 12:20 PM, Mishal Shah wrote: > > Please file a bug for missing dependency. I already did 2 month ago: rdar://problem/30315400 > > Workspace deleted. > > Thanks, > Mishal Sha >> On Mar 27, 2017, at 11:43 AM, Erik Eckstein > > wrote: >> >>

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

I’ll fix this. > On Apr 13, 2017, at 11:22 AM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-osx [#9379] > > Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/9379/ > > Project: oss-swift-inc

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

Hi Ankit, this timed out in the swiftpm tests. Can your changes caused this? Can you please check? Thanks, Erik > On Apr 17, 2017, at 3:51 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-4.0-incremental-RA-linux-ubuntu-16_10 [#74] > > Build URL: > https://ci.swift.org/job/oss-swift

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 16.04 - Long Test (swift 4.0) #40

Max, seems to be yours: long-test/swift-corelibs-xctest/Sources/XCTest/Private/WallClockTimeMetric.swift:66:43: error: cannot invoke initializer for type 'Int' with an argument list of type '(Self.IndexDistance)' return self.reduce(0, +) / Double(Int(count))

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

Never mind, the following build is okay again. > On Apr 17, 2017, at 4:15 PM, Erik Eckstein wrote: > > Hi Ankit, > > this timed out in the swiftpm tests. > > Can your changes caused this? > > Can you please check? > > Thanks, > Erik > >> On Apr 17, 2017, at 3:51 PM, no-re...@swift.org

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

Doug, only your changes are on the blame list. Can you please check this? The fail is: TEST 'Swift(linux-x86_64) :: TBD/protocol.swift' FAILED Script: -- /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/

Re: [swift-dev] [Swift CI] Build Failure: 1. OSS - Swift ASAN - OS X (master) #471

Does anyone feel responsible for this asan crash? = ==56579==ERROR: AddressSanitizer: heap-use-after-free on address 0x6020e6b8 at pc 0x000115dfdca9 bp 0x78f0 sp 0x78e8 READ of size 8 at 0x6020e6b8 thread T6 0

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

This test is flaky. It only fails in some builds. Slava, can you disable this test until it is fixed (means: stable)? Thanks, Erik > On Apr 18, 2017, at 8:15 PM, Slava Pestov via swift-dev > wrote: > > This is most definitely not your fault, because it is my fault, from the > subclass existen

Re: [swift-dev] [Swift CI] Build Still Failing: OSS - Swift Package - Ubuntu 16.04 (master) #845

Hi Philippe, this failing test seems to be flaky. Is it possible to fix this? Maybe increase the timeout? TestFoundation/TestNSURLSession.swift:254: error: TestURLSession.test_downloadTaskWithURLAndHandler : Asynchronous wait failed - Exceeded timeout of 12.0 seconds, with unfulfilled expectat

Re: [swift-dev] [Swift CI] Build Still Failing: OSS - Swift Package - Ubuntu 16.04 (master) #845

> IBM Runtimes > > Simplicity is prerequisite for reliability - Edsger W. Dijkstra > > > > -swift-dev-boun...@swift.org <mailto:-swift-dev-boun...@swift.org> > wrote: ----- > To: Philippe Hausler mailto:phaus...@apple.com>> > From: Er

Re: [swift-dev] [Swift CI] Build Failure: OSS - Swift Package - Ubuntu 16.04 (swift 4.0) #7

Jim, Jason, /home/buildnode/disk2/workspace/oss-swift-4.0-package-linux-ubuntu-16_04/lldb/source/Core/Mangled.cpp:20:9: warning: 'LLDB_USE_BUILTIN_DEMANGLER' macro redefined [-Wmacro-redefined] #define LLDB_USE_BUILTIN_DEMANGLER ^ :5:9: note: previous definition is here #define LLDB_USE_B

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

Huon, seems to be yours. In file included from /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/lib/Basic/JSONSerialization.cpp:13: <>/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/include/swift/Basic/JSONSerialization.h:

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

Thanks! > On Apr 21, 2017, at 3:10 PM, Huon Wilson wrote: > > https://github.com/apple/swift/pull/8928 > > > Huon > >> On Apr 21, 2017, at 14:05, Erik Eckstein > > wrote: >> >> Huon, >> >> seems to be yours. >> >> In f

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - OS X (swift 4.0) #228

I think this is rdar://problem/31746923 > On Apr 25, 2017, at 11:47 AM, Jordan Rose via swift-dev > wrote: > > I don’t think that’s any of us. Philippe, does this look familiar? > > [ RUN ] TestCharacterSet.test_moreSetOperations > stdout>>> check failed at > /Users/buildnode/jenkins/wor

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

Some non-determinsitic problem in sourcekit? *** Error in `/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/sourcekitd-test': corrupted double-linked > On Jun 1, 2017, at 12:02 PM, no-re...@swift.org wrote: > > [FAILURE

[swift-dev] statically initialized arrays

Hi, I’m about implementing statically initialized arrays. It’s about allocating storage for arrays in the data section rather than on the heap. Info: the array storage is a heap object. So in the following I’m using the general term “object” but the optimization will (probably) only handle arra

Re: [swift-dev] statically initialized arrays

> On Jun 14, 2017, at 12:03 PM, Jordan Rose wrote: > > > >> On Jun 14, 2017, at 11:24, Erik Eckstein via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >> Hi, >> >> I’m about implementing statically initialized arrays. It’s about

Re: [swift-dev] statically initialized arrays

> On Jun 14, 2017, at 4:04 PM, Michael Gottesman wrote: > >> >> On Jun 14, 2017, at 11:24 AM, Erik Eckstein via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >> Hi, >> >> I’m about implementing statically initialized arrays. It

Re: [swift-dev] statically initialized arrays

> On Jun 19, 2017, at 8:53 AM, Joe Groff wrote: > >> >> On Jun 14, 2017, at 11:24 AM, Erik Eckstein via swift-dev >> wrote: >> >> Hi, >> >> I’m about implementing statically initialized arrays. It’s about allocating >> storage

Re: [swift-dev] Name mangling of subscripts

> On Jul 14, 2017, at 12:02 PM, John McCall wrote: > >> On Jul 14, 2017, at 6:41 AM, Alex Hoppen via swift-dev > > wrote: >> Hi all, >> >> With a recent change of mine (#9989 >> ) subscripts are no longer >> represented int

Re: [swift-dev] SR-5403 / Memory Optimization Opportunity (Load/Store forwarding)

Hi Johannes, great that you want to work on this! Some ideas: SideEffectAnalysis currently does not have a notion of “this argument is not modified by the callee” if the callee is unknown or does anything non-trivial. Therefore I think it’s best to put the in_guarantee check directly into Memor

Re: [swift-dev] SR-5403 / Memory Optimization Opportunity (Load/Store forwarding)

> On Jul 18, 2017, at 10:40 AM, Johannes Weiß wrote: > > Thanks, both suggestions look great. Will work them in tomorrow and will also > try to add a test for the whole thing. > >> On 18 Jul 2017, at 5:53 pm, Michael Gottesman wrote: >> >>> >>> On Jul 18, 2017, at 8:39 AM, Johannes Weiß wr

Re: [swift-dev] [Swift CI] Build Failure: OSS - Swift Package - Ubuntu 16.04 (master) #1393

This is a “no space left on device” issue > On Jul 21, 2017, at 5:18 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-package-linux-ubuntu-16_04 [#1393] > > Build URL: > https://ci.swift.org/job/oss-swift-package-linux-ubuntu-16_04/1393/ >

Re: [swift-dev] SR-5403 / Memory Optimization Opportunity (Load/Store forwarding)

As John said, this is out of scope for swift 4. I think it’s find to just have it in master. Thanks again for your work! > On Jul 25, 2017, at 10:00 AM, John McCall via swift-dev > wrote: > > >> On Jul 25, 2017, at 12:55 PM, Johannes Weiß via swift-dev >> wrote: >> >> Thanks very much Eric

Re: [swift-dev] Question about demangling

> On Jul 25, 2017, at 4:44 PM, Ethan Arbuckle via swift-dev > wrote: > > The Swift runtime exports a function to demangle Swift symbols, > swift_demangle. See source: > https://github.com/apple/swift/blob/32d15d8539c43ff26b599f7c4a08a79a10d4bf98/stdlib/public/runtime/Reflection.mm#L1200 > >

Re: [swift-dev] Reconsidering the global uniqueness of type metadata and protocol conformance instances

Would it be possible that whenever a specialized class is instantiated and the metadata already exists with a generic vtable, it just overwrites the vtable pointer in the metadata with the specialized version? I didn’t think that through, but maybe the same could be done for witness tables? > O

Re: [swift-dev] Reducing array abstraction

> On Oct 8, 2017, at 3:14 PM, Chris Lattner wrote: > >> >> On Oct 8, 2017, at 11:57 AM, Michael Gottesman via swift-dev >> wrote: >> >> >>> On Oct 6, 2017, at 11:06 PM, Chris Lattner via swift-dev >>> wrote: >>> >>> This question is somewhere between swift-dev and swift-users, not sure

Re: [swift-dev] Reducing array abstraction

> On Oct 9, 2017, at 9:46 PM, Chris Lattner wrote: > > On Oct 8, 2017, at 3:30 PM, Erik Eckstein > wrote: We definitely already have a heap->stack for classes in the guise of the StackPromotion optimization is that what you are talking about with the >>>

[swift-dev] sharing tips and tricks and scripts

I recently had some discussions about how to share those little tips and tricks which everyone has to make building, debugging, etc. the swift compiler easier. And actually we already have a central place for this: it’s the docs folder in the swift repo. Especially the DebuggingTheCompiler.rst d

Re: [swift-dev] sharing tips and tricks and scripts

t;> wrote: > > > > I always dislike wrapper scripts because it means that people are working > > around undesirable behavior in a tool rather than fixing it. But that > > doesn't seem to be a practical answer, because people are already using > > wrapp

[swift-dev] deprecating -Ounchecked

Hi, I’d like to propose to deprecate the -Ounchecked swift optimization mode. The -Ounchecked mode actually contradicts one of the main goals of swift: to be a safe language. In the past we didn’t see lot of significant performance differences compared to -O (there were some improvements but al

Re: [swift-dev] [Swift CI] Build Failure: 1. OSS - Swift ASAN - OS X (master) #526

Any update on this? Can you revert in the meantime if you’re not able to fix it within the next hour? > On Nov 2, 2017, at 9:26 AM, Xi Ge wrote: > > Ack, will take a look soon. > > Xi > >> On Nov 2, 2017, at 9:13 AM, Douglas Gregor > > wrote: >> >> Xi, this is fail

Re: [swift-dev] deprecating -Ounchecked

d add such an option. Daniel, I think that’s also what you were asking for. > But probably the 'no checks' mode adds too much complexity to just keep it > around for a questionable way to do performance baselines. > >> On 2 Nov 2017, at 9:52 am, Erik Eckstein via sw

Re: [swift-dev] [Swift CI] Build Failure: 1. OSS - Swift ASAN - OS X (master) #526

Thanks! > On Nov 2, 2017, at 3:26 PM, Xi Ge wrote: > > It seems my tentative fix doesn't fix this issue. As Erik suggested, I've > reverted the commit on master. > > > -- > Xi > > > >> On Nov 2, 2017, at 1:28 PM, Erik Eckstein > > wrote: >> >> Any update on thi

Re: [swift-dev] deprecating -Ounchecked

an optimisation as it clearly changes the semantics of the >>>> program quite a bit. I thought '-unsafe-remove-checks' or something >>>> describes it better, a bit like '-assume-single-threaded’. >>> >>> I like that idea. We could add

Re: [swift-dev] deprecating -Ounchecked

> On Nov 2, 2017, at 8:50 PM, Chris Lattner wrote: > > >> On Nov 2, 2017, at 9:52 AM, Erik Eckstein via swift-dev >> wrote: >> >> Hi, >> >> I’d like to propose to deprecate the -Ounchecked swift optimization mode. >> >> The -Ounc

Re: [swift-dev] deprecating -Ounchecked

> On Nov 3, 2017, at 10:51 PM, Chris Lattner via swift-dev > wrote: > > >> On Nov 3, 2017, at 10:23 PM, Slava Pestov via swift-dev > > wrote: >> >> >> >>> On Nov 3, 2017, at 8:57 PM, Chris Lattner via swift-dev >>> mailto:swift-dev@swift.org>> wrote: >>> >>> R

Re: [swift-dev] deprecating -Ounchecked

> On Nov 5, 2017, at 4:05 PM, Andrew Trick wrote: > > > >> On Nov 3, 2017, at 12:45 PM, Slava Pestov via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >> >>> On Nov 3, 2017, at 8:31 AM, Erik Eckstein via swift-dev >>> m

Re: [swift-dev] Zero-cost 'Service Provider Interface'/Signature Packages

> On Nov 8, 2017, at 5:27 PM, Johannes Weiß via swift-dev > wrote: > > Hi Daniel, > >> On 2 Nov 2017, at 8:15 pm, Daniel Dunbar wrote: >> >> My personal preference is to: >> 1. Do nothing for now, but encourage publishing standardized protocols to >> solve this need. >> 2. Hope for a futur

Re: [swift-dev] Zero-cost 'Service Provider Interface'/Signature Packages

> On Nov 10, 2017, at 3:05 PM, Joe Groff wrote: > > > >> On Nov 8, 2017, at 9:59 PM, Erik Eckstein via swift-dev >> wrote: >> >> >> >>> On Nov 8, 2017, at 5:27 PM, Johannes Weiß via swift-dev >>> wrote: >>> >

Re: [swift-dev] "available externally" vs build time

> On Jan 2, 2018, at 1:08 PM, Slava Pestov via swift-dev > wrote: > > > >> On Dec 28, 2017, at 4:32 PM, Chris Lattner via swift-dev >> wrote: >> >> Folks working on the SIL optimizer, particularly those interested in faster >> builds: >> >> If I understand the SIL optimizer correctly, i

Re: [swift-dev] "available externally" vs build time

> On Jan 4, 2018, at 1:14 PM, Slava Pestov wrote: > > > >> On Jan 4, 2018, at 1:08 PM, Erik Eckstein > > wrote: >> >> >> >>> On Jan 2, 2018, at 1:08 PM, Slava Pestov via swift-dev >> > wrote: >>> >>> >>> On Dec 28, 2017, at 4:

Re: [swift-dev] "available externally" vs build time

> On Jan 4, 2018, at 4:57 PM, Chris Lattner wrote: > >> On Jan 4, 2018, at 1:08 PM, Erik Eckstein > > wrote: 1. It looks like the MandatoryInliner is the biggest culprit at -O0 here: it deserializes the referenced function (MandatoryInlining.cpp:384) and

[swift-dev] heads-up: some temporary build failures

I just merged a mangling change into the swift repo. This will cause some build failures on linux until my foundation PR gets merged. Should be resolved in the next hours. Thanks, Erik ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.