Re: [swift-dev] SILNode versus C++

apple.com> wrote: >> >> >> >>>> On Dec 16, 2017, at 10:31 AM, John McCall via swift-dev >>>> <swift-dev@swift.org> wrote: >>>> >>>> >>>> On Dec 16, 2017, at 9:08 AM, David Zarzycki via swift-dev >&g

Re: [swift-dev] Weird dyn_cast code gen / performance problem

> On Jan 1, 2018, at 5:51 PM, David Zarzycki via swift-dev > wrote: > > Hi Michael, > > I reduced it down to a simple test case. I was wrong about this requiring two > or more dyn_casts. This actually affects any C++ code that uses the “if (auto > x = y(z))” convention.

Re: [swift-dev] Preserving and Applying CC in Imported Decls

> On Dec 18, 2017, at 9:34 PM, Greg Parker <gpar...@apple.com> wrote: > > >> On Dec 13, 2017, at 10:28 PM, John McCall via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@swift.org>> wrote: >> >>> On Dec 13, 2017, at 8:35 PM, Saleem

Re: [swift-dev] SILNode versus C++

> On Dec 16, 2017, at 9:08 AM, David Zarzycki via swift-dev > wrote: > > Hello, > > I’m trying to improve SILNode memory layout density by adopting the AST > bitfield macros. Unfortunately, multiple inheritance doesn’t seem to get > along with anonymous/unnamed unions.

Re: [swift-dev] [PITCH] Improve Optional Chain Assignment on Tuple Assignment

> On Dec 16, 2017, at 2:21 AM, Cao, Jiannan via swift-dev > wrote: > > Hi all, > > I have come up an improvement point about Optional Chain Assignment > > 1. Optional Chain Assignment not working with tuple assignment > > optional chain assignment only work for directly

Re: [swift-dev] Preserving and Applying CC in Imported Decls

> On Dec 13, 2017, at 8:35 PM, Saleem Abdulrasool wrote: > > On Wed, Dec 13, 2017 at 4:14 PM, John McCall > wrote: > >> On Dec 13, 2017, at 6:42 PM, Saleem Abdulrasool >

Re: [swift-dev] Preserving and Applying CC in Imported Decls

> On Dec 13, 2017, at 6:42 PM, Saleem Abdulrasool wrote: > > > >> On Dec 13, 2017, at 12:46 PM, John McCall > > wrote: >> >>> >>> On Dec 13, 2017, at 3:22 PM, Saleem Abdulrasool >>

Re: [swift-dev] [SE-0143] Dynamic casting for conditional conformances

> On Dec 7, 2017, at 1:03 AM, Slava Pestov wrote: > > > >> On Dec 6, 2017, at 10:00 PM, John McCall wrote: >> >> Yes, I can see how there's some nice synergy there, and it would certainly >> be good to avoid having to eagerly generate code for this

Re: [swift-dev] [SE-0143] Dynamic casting for conditional conformances

> On Dec 5, 2017, at 7:01 PM, Slava Pestov <spes...@apple.com> wrote: > > > >> On Dec 5, 2017, at 3:42 PM, John McCall via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@swift.org>> wrote: >> >>> On Dec 5, 2017, at 5:28 P

Re: [swift-dev] [SE-0143] Dynamic casting for conditional conformances

> On Dec 5, 2017, at 5:28 PM, Douglas Gregor via swift-dev > wrote: > Hi all, > > The main missing piece for conditional conformances > (https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md > >

Re: [swift-dev] Generalizing nominal type descriptors into "context descriptors"; encoding generic requirements

> On Nov 14, 2017, at 2:36 PM, Joe Groff via swift-dev > wrote: > The type metadata that gets emitted for struct, enum, and class types > includes a reference to a nominal type descriptor. The descriptor carries > information that pertains to the nominal type declaration

Re: [swift-dev] RFC: AST representation for coroutine types

> On Nov 14, 2017, at 2:50 PM, Joe Groff <jgr...@apple.com> wrote: > > > >> On Nov 13, 2017, at 9:52 PM, John McCall via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@swift.org>> wrote: >> >> SIL now has some minimal represen

Re: [swift-dev] Preparing metadata records for ABI stability

> On Nov 13, 2017, at 5:19 PM, Joe Groff wrote: > >> On Nov 13, 2017, at 2:16 PM, John McCall > > wrote: >> >>> >>> On Nov 13, 2017, at 4:30 PM, Joe Groff >> > wrote: >>> >>> On Nov

[swift-dev] RFC: AST representation for coroutine types

SIL now has some minimal representational support for coroutines, and while there's significantly more to do there, I'd like to simultaneously kick off a conversation about how best to represent them at the AST level. Only special kinds of declarations can be coroutines. In the first stage,

Re: [swift-dev] Preparing metadata records for ABI stability

> On Nov 13, 2017, at 4:30 PM, Joe Groff wrote: > > On Nov 13, 2017, at 11:40 AM, John McCall > wrote: >> >> >>> On Nov 7, 2017, at 8:58 PM, Joe Groff via swift-dev >> >

Re: [swift-dev] Preparing metadata records for ABI stability

> On Nov 13, 2017, at 2:42 PM, Slava Pestov <spes...@apple.com> wrote: > > >> On Nov 13, 2017, at 11:40 AM, John McCall via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@swift.org>> wrote: >> >> - I feel like we're not boxing ourselve

Re: [swift-dev] deprecating -Ounchecked

> On Nov 2, 2017, at 4:35 PM, Johannes Weiß via swift-dev > wrote: >> On 2 Nov 2017, at 1:33 pm, Erik Eckstein wrote: >> >> >> >>> On Nov 2, 2017, at 10:51 AM, Johannes Weiß wrote: >>> >>> Definitely a +1 from me, a haven't

Re: [swift-dev] Todo cleanups & such

> On Nov 1, 2017, at 8:05 PM, David Sweeris via swift-dev > wrote: > > In "SILFunction.h", line 171, it says, > /// The function's set of semantics attributes. > /// > /// TODO: Why is this using a std::string? Why don't we use uniqued > /// StringRefs? >

Re: [swift-dev] Exclusivity checker hacking?

> On Oct 5, 2017, at 6:34 PM, Jordan Rose via swift-dev > wrote: > > > >> On Oct 5, 2017, at 15:23, David Zarzycki > >> wrote: >> >> >> >>> On Oct 5, 2017, at 18:08, Jordan Rose >>

Re: [swift-dev] Metadata Representation

> On Sep 28, 2017, at 5:23 PM, Saleem Abdulrasool wrote: > > > > On Thu, Sep 28, 2017 at 10:59 AM, John McCall > wrote: > >> On Sep 28, 2017, at 1:01 PM, Saleem Abdulrasool >

Re: [swift-dev] Metadata Representation

> On Sep 28, 2017, at 1:01 PM, Saleem Abdulrasool wrote: > > On Mon, Sep 25, 2017 at 10:18 PM, John McCall > wrote: >> On Sep 26, 2017, at 12:35 AM, Saleem Abdulrasool >

Re: [swift-dev] Adding a field to StrongRefCount class

> On Sep 27, 2017, at 1:24 PM, Jiho Choi wrote: > > Thanks for the explanation. I modified those two locations you mentioned but > the build failed during tests. I've been browsing the source code to figure > out other dependences but didn't succeed yet. Could you please

Re: [swift-dev] Adding a field to StrongRefCount class

> On Sep 26, 2017, at 12:56 AM, Jiho Choi via swift-dev > wrote: > I want to add a field to StrongRefCount class for some experiment, but the > build fails while building self-hosted 'swift-build'. I am using the version > 3.1.1. > > Does the shape of StrongRefCount

Re: [swift-dev] Metadata Representation

> On Sep 26, 2017, at 12:35 AM, Saleem Abdulrasool > wrote: > On Mon, Sep 25, 2017 at 11:47 AM, John McCall > wrote: > > On Sep 25, 2017, at 12:24 PM, Joe Groff > > wrote: > >>

Re: [swift-dev] Metadata Representation

> On Sep 25, 2017, at 12:24 PM, Joe Groff wrote: >> On Sep 24, 2017, at 10:30 PM, John McCall wrote: >>> On Sep 22, 2017, at 8:39 PM, Saleem Abdulrasool >>> wrote: >>> >>> On Thu, Sep 21, 2017 at 10:28 PM, John McCall

Re: [swift-dev] Metadata Representation

> On Sep 25, 2017, at 1:28 PM, Jordan Rose wrote: >> On Sep 25, 2017, at 09:24, Joe Groff via swift-dev > > wrote: >>> On Sep 24, 2017, at 10:30 PM, John McCall >> > wrote:

Re: [swift-dev] Metadata Representation

> On Sep 25, 2017, at 1:30 AM, John McCall via swift-dev <swift-dev@swift.org> > wrote: > > >> On Sep 22, 2017, at 8:39 PM, Saleem Abdulrasool <compn...@compnerd.org >> <mailto:compn...@compnerd.org>> wrote: >> >> On Thu, Sep

Re: [swift-dev] Metadata Representation

> On Sep 22, 2017, at 8:39 PM, Saleem Abdulrasool wrote: > > On Thu, Sep 21, 2017 at 10:28 PM, John McCall > wrote: > >> On Sep 21, 2017, at 10:10 PM, Saleem Abdulrasool >

Re: [swift-dev] A constraint system / type variable question

> On Sep 24, 2017, at 1:13 AM, David Zarzycki via swift-dev > wrote: > Hi Robert, > > As a prerequisite to some other hacking I’m doing, I have an experimental > implementation of value semantics; where (among other details), all functions > have a bit in ExtInfo that

Re: [swift-dev] Metadata Representation

> On Sep 21, 2017, at 10:10 PM, Saleem Abdulrasool > wrote: > > On Thu, Sep 21, 2017 at 5:18 PM, John McCall > wrote: >> On Sep 21, 2017, at 1:26 PM, Saleem Abdulrasool via swift-dev >>

Re: [swift-dev] Changing ELF layout

> On Sep 17, 2017, at 10:15 AM, Saleem Abdulrasool > wrote: > > On Sat, Sep 16, 2017 at 6:19 PM, John McCall > wrote: > > On Sep 16, 2017, at 6:06 PM, Saleem Abdulrasool via swift-dev > >

Re: [swift-dev] Changing ELF layout

> On Sep 16, 2017, at 6:06 PM, Saleem Abdulrasool via swift-dev > wrote: > Hello, > > I'd like to propose that we change the locations that we use to store the > type metadata, protocol conformances, type references, reflection strings, > field metadata, and associated

[swift-dev] Notes on the coroutines ABI

Even if we don't do coroutines as a user feature in Swift 5, we want to make sure we implement coroutine-esque features (like materializeForSet) with an ABI that we're satisfied with. Joe Groff and I were talking about the low-level structure of that ABI, and I wanted to make sure that it was

Re: [swift-dev] Swift build on ppc64le platform

> On Sep 6, 2017, at 3:28 AM, Meghali Dhoble wrote: > Thanks John, for the response. > We have a patch added already for ppc64 support at llvm, however still the > failures seen, > Did you change Clang? John. > I will try to opt for 2nd option and see if that helps. > >

Re: [swift-dev] What can you change in a fixed-contents struct?

> On Sep 5, 2017, at 2:58 PM, Jordan Rose wrote: > Hey, all. In preparation for the several proposals we have to come this year, > I cleaned up docs/LibraryEvolution.rst > a little bit based on what's > changed in Swift 4. This

Re: [swift-dev] What can you change in a fixed-contents struct?

> On Sep 5, 2017, at 9:41 PM, Slava Pestov via swift-dev > wrote: > > >> On Sep 5, 2017, at 6:37 PM, Nevin Brackett-Rozinsky via swift-dev >> > wrote: >> >> On Tue, Sep 5, 2017 at 6:08 PM, Slava Pestov via swift-dev >>

Re: [swift-dev] Compiling Swift for Android x86

> On Aug 31, 2017, at 4:24 PM, Max Rose via swift-dev > wrote: > Hi Everybody, > > We're working on adding Android x86 to the available targets for Swift. > Currently we're able to compile an executable through the toolchain. However, > running the executable leads to a

Re: [swift-dev] Swift build on ppc64le platform

> On Aug 28, 2017, at 9:08 AM, Meghali Dhoble via swift-dev > wrote: > Hi, > I have been working towards getting the swift source code built on my power > (ppc64le) platform on Ubuntu16.04 OS. > I am observing build issues and looking for some help here. Please redirect

Re: [swift-dev] RFC: Better diagnostics through simplification

> On Aug 24, 2017, at 10:41 AM, David Zarzycki wrote: >> On Aug 24, 2017, at 00:08, John McCall > > wrote: >> >>> >>> What do people think? The meat of the change is tiny and below. The vast >>> majority of the work is the

Re: [swift-dev] swift module format

> On Aug 25, 2017, at 2:34 AM, Slava Pestov <spes...@apple.com> wrote: >> On Aug 24, 2017, at 10:56 PM, John McCall via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@swift.org>> wrote: >> >> Or if you really want to avoid the FFI, you could

Re: [swift-dev] swift module format

> On Aug 25, 2017, at 1:41 AM, Coder via swift-dev wrote: > I’m working on a swift target for haxe and want it to use the interfaces in > swift modules. The haxe compiler is written in ocml and so far I’ve created > an llvm bitcode parser in ocaml which can read all the

Re: [swift-dev] switches versus the visitor pattern?

> On Aug 12, 2017, at 6:45 AM, David Zarzycki wrote: >> On Aug 11, 2017, at 19:21, John McCall wrote: >> >>> On Aug 11, 2017, at 7:05 PM, David Zarzycki via swift-dev >>> wrote: >>> Hi Slava, >>> >>> Thanks. I’m not planning on

Re: [swift-dev] switches versus the visitor pattern?

> On Aug 11, 2017, at 7:05 PM, David Zarzycki via swift-dev > wrote: > Hi Slava, > > Thanks. I’m not planning on seeking them out. I just want to minimize future > merge conflicts with an experimental branch I’m working on. The visitor > pattern helps people like me by

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

> On Jul 31, 2017, at 12:13 PM, Joe Groff <jgr...@apple.com> wrote: > > >> On Jul 30, 2017, at 7:55 PM, John McCall via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@swift.org>> wrote: >> >>> On Jul 30, 2017, at 9:08 PM, Slava Pe

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

> <mailto:spes...@apple.com>> wrote: >>>> On Jul 29, 2017, at 12:53 PM, John McCall via swift-dev >>>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: >>>>> On Jul 29, 2017, at 12:48 AM, Andrew Trick <atr...@a

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

> On Jul 29, 2017, at 4:33 PM, Chris Lattner wrote: >> On Jul 29, 2017, at 1:32 PM, John McCall wrote: >> >>> On Jul 29, 2017, at 4:24 PM, Chris Lattner via swift-dev >>> wrote: >>> >>> On Jul 28, 2017, at 2:20 PM, Joe Groff via

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

> On Jul 29, 2017, at 12:48 AM, Andrew Trick <atr...@apple.com> wrote: >> On Jul 28, 2017, at 8:13 PM, John McCall <rjmcc...@apple.com >> <mailto:rjmcc...@apple.com>> wrote: >>> On Jul 28, 2017, at 11:11 PM, John McCall via swift-dev >>> <s

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

> On Jul 28, 2017, at 11:11 PM, John McCall via swift-dev <swift-dev@swift.org> > wrote: >> On Jul 28, 2017, at 10:38 PM, Andrew Trick <atr...@apple.com >> <mailto:atr...@apple.com>> wrote: >>> On Jul 28, 2017, at 3:15 PM, John McCall <rjmcc...@a

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

> On Jul 28, 2017, at 6:34 PM, Joe Groff wrote: >> On Jul 28, 2017, at 3:30 PM, John McCall wrote: >>> On Jul 28, 2017, at 6:24 PM, Joe Groff wrote: On Jul 28, 2017, at 3:15 PM, John McCall wrote:

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

> On Jul 28, 2017, at 6:24 PM, Joe Groff wrote: >> On Jul 28, 2017, at 3:15 PM, John McCall wrote: >> >> >>> On Jul 28, 2017, at 6:02 PM, Andrew Trick via swift-dev >>> wrote: >>> >>> On Jul 28, 2017, at 2:20 PM, Joe Groff via

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

> On Jul 28, 2017, at 6:02 PM, Andrew Trick via swift-dev > wrote: > > >> On Jul 28, 2017, at 2:20 PM, Joe Groff via swift-dev >> wrote: >> >> The Swift runtime currently maintains globally unique pointer identities for >> type metadata and

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

> On Jul 25, 2017, at 12:55 PM, Johannes Weiß via swift-dev > wrote: > > Thanks very much Eric & Michael for your help! And thanks for merging it. > Will this automatically be part of Swift 4 or do I need to make another PR > against a swift 4 branch? It's very hard to

Re: [swift-dev] Name mangling of subscripts

> 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 internally by the identifier "subscript" but by a DeclBaseName > with

Re: [swift-dev] [Swift CI] Build Failure: 2. Swift Source Compatibility Suite (master) #779

> On Jul 11, 2017, at 10:23 PM, John McCall wrote: > >> >> On Jul 11, 2017, at 6:44 PM, Mishal Shah > > wrote: >> >> Hi, >> >> Source Compatibility Suite failed due to Segmentation fault 11, please see >> the log

Re: [swift-dev] statically initialized arrays

> On Jun 15, 2017, at 10:52 AM, Arnold via swift-dev > wrote: > > > >> On Jun 14, 2017, at 2:56 PM, Dave Abrahams via swift-dev >> wrote: >> >> >>> on Wed Jun 14 2017, Erik Eckstein wrote: >>> >>> Hi, >>> >>> I’m about implementing statically

Re: [swift-dev] RFC: bridging peephole for "as" casts

> On Jun 13, 2017, at 7:32 PM, Jordan Rose <jordan_r...@apple.com> wrote: >> On Jun 13, 2017, at 16:11, John McCall via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@swift.org>> wrote: >> >> So, there's a longstanding issue that we're planning t

[swift-dev] RFC: bridging peephole for "as" casts

So, there's a longstanding issue that we're planning to fix in Swift 4, and I want to both make sure that the plan is documented publicly and give people a chance to disagree with it. A bridging conversion is a conversion between a Swift type and a foreign type (C / ObjC / whatever) which can

Re: [swift-dev] Property modification not taking effect

e pass was disabled because it was causing miscompiles like this. John. > > Regards, > Will Stanton > >> On May 10, 2017, at 1:08 PM, John McCall via swift-dev <swift-dev@swift.org> >> wrote: >> >>> On May 10, 2017, at 11:06 AM, Pushkar N Kulkarni &l

Re: [swift-dev] Property modification not taking effect

> On May 9, 2017, at 3:07 PM, Pushkar N Kulkarni via swift-dev > wrote: > In the process of debugging a bunch of consistent failures in > TestFoundation/TestNSURLSession, I came across a weird problem symptom in > this line of code >

Re: [swift-dev] Swift root meta-class

> On May 8, 2017, at 6:21 PM, Giacomo Leopizzi via swift-dev > wrote: > Hello everyone! > I was discussing with a friend about metaclasses in Objective-C. In Obj-C the > root meta-class was the NSObject's one. ObjC does not have a single root class. Most ObjC classes

Re: [swift-dev] New global constructor warnings in runtime GlobalObjects.cpp

> On May 2, 2017, at 1:07 PM, John McCall via swift-dev <swift-dev@swift.org> > wrote: >> On May 2, 2017, at 12:57 PM, Joe Groff <jgr...@apple.com> wrote: >> >> >>> On May 2, 2017, at 9:36 AM, John McCall <rjmcc...@apple.com> wrote: >>>

Re: [swift-dev] New global constructor warnings in runtime GlobalObjects.cpp

> On May 2, 2017, at 12:57 PM, Joe Groff wrote: > > >> On May 2, 2017, at 9:36 AM, John McCall wrote: >> >>> On May 2, 2017, at 12:02 PM, Joe Groff via swift-dev >>> wrote: >>> After updating clang recently, I'm seeing these

Re: [swift-dev] New global constructor warnings in runtime GlobalObjects.cpp

> On May 2, 2017, at 12:02 PM, Joe Groff via swift-dev > wrote: > After updating clang recently, I'm seeing these warnings: > > /Users/jgroff/src/s/swift/stdlib/public/stubs/GlobalObjects.cpp:40:39: > warning: declaration requires a global constructor

Re: [swift-dev] Guarantees of Tuples as Fixed Sized (stack allocated) Arrays

> On Apr 28, 2017, at 7:03 AM, Johannes Weiss via swift-dev > wrote: > Hi swift-users, > > (sorry for the cross post to swift-dev, but wasn't sure where it belongs) > > I tried to find guarantees about the memory layout Swift tuples but couldn't > find anything. The

Re: [swift-dev] Miscompile with protocol compositions

> On Apr 27, 2017, at 3:35 AM, Slava Pestov via swift-dev > wrote: > Hi all, > > I’ve spent most of the last two days debugging various issues with property > and subscript accesses on class-constrained existentials and I’ve just now > realized the root cause is a much

Re: [swift-dev] Renaming SILSuccessor -> SILCFGEdge

> On Apr 26, 2017, at 6:11 PM, Michael Gottesman wrote: >> On Apr 26, 2017, at 1:44 PM, John McCall wrote: >> >>> On Apr 26, 2017, at 4:24 PM, Michael Gottesman via swift-dev >>> wrote: >>> Hey everyone. >>> >>> I am currently

Re: [swift-dev] Renaming SILSuccessor -> SILCFGEdge

> On Apr 26, 2017, at 4:24 PM, Michael Gottesman via swift-dev > wrote: > Hey everyone. > > I am currently doing some small fixes to SILSuccessor (adding some comments > and fixing some issues exposed by LLVM upstream). As I read the code it > became pretty apparent that

Re: [swift-dev] IRGen variadic function declaration

> On Apr 11, 2017, at 5:33 PM, Slava Pestov via swift-dev > wrote: > Please don’t use @_silgen_name. Soon it will only be available within the > standard library. > > Instead, write C wrappers around your intrinsics and create a Clang module > that you can import from

Re: [swift-dev] Statically-emitted or statically-allocated objects with new refcounting

> On Mar 14, 2017, at 5:08 PM, Jordan Rose via swift-dev > wrote: >> On Mar 14, 2017, at 13:52, Greg Parker via swift-dev > > wrote: >> >> >>> On Mar 14, 2017, at 1:34 PM, Greg Parker via swift-dev

Re: [swift-dev] [swift-evolution] Inefficiency in recursive value types

> On Mar 13, 2017, at 8:55 AM, Dimitri Racordon via swift-evolution > wrote: > Hello fellow evolutionists, > > I’m not sure this list is the best place to talk about this, so please > redirect me if it should be discussed elsewhere. More of a swift-dev topic.

Re: [swift-dev] Why doesn't CaptureListExpr hold a ClosureExpr?

> On Feb 8, 2017, at 12:33 AM, Slava Pestov wrote: >> On Feb 7, 2017, at 9:30 PM, Jacob Bandes-Storch > > wrote: >> >> Thanks to the magic of git blame: >> >> >>

Re: [swift-dev] Why doesn't CaptureListExpr hold a ClosureExpr?

> On Feb 8, 2017, at 12:18 AM, Jacob Bandes-Storch via swift-dev > wrote: > I don't think it would be a very big parser change to invert the > relationship. Maybe I'll try it out and put up another PR. > > On the other hand, noticed the header comment says: > > ///

Re: [swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

> On Feb 4, 2017, at 5:35 AM, Andrew Trick wrote: > > >> On Feb 3, 2017, at 9:37 PM, John McCall > > wrote: >> IV. The function that performs the lookup: IV1) is parameterized by an isa IV2) is not

Re: [swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

> On Feb 4, 2017, at 6:45 PM, Dave Abrahams via swift-dev > wrote: > on Fri Feb 03 2017, John McCall wrote: > >>> On Feb 3, 2017, at 7:12 PM, Joe Groff via swift-dev >>> wrote: >>> Given that most open-coded resilient method lookup paths require an

Re: [swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

> On Feb 6, 2017, at 1:23 PM, Joe Groff wrote: >> On Feb 3, 2017, at 8:47 PM, John McCall > > wrote: >> >>> On Feb 3, 2017, at 7:12 PM, Joe Groff via swift-dev >> > wrote: >>>

Re: [swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

> On Feb 3, 2017, at 7:06 PM, Andrew Trick wrote: >> On Feb 3, 2017, at 3:12 PM, John McCall > > wrote: >> >> I think we can generalize this discussion a bit by describing some >> mostly-independent axes of variation: > >

Re: [swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

> On Feb 3, 2017, at 7:12 PM, Joe Groff via swift-dev > wrote: > Given that most open-coded resilient method lookup paths require an extra > load dependency to grab the method offset before loading the method address > itself, we might possibly consider indirecting the

Re: [swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

> On Feb 3, 2017, at 4:18 PM, Andrew Trick wrote: >> On Feb 3, 2017, at 11:55 AM, Andrew Trick via swift-dev > > wrote: >> #3b. (lazy resolution) Offset tables can be completely localized. method_index =

Re: [swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

> On Feb 2, 2017, at 9:57 PM, Andrew Trick via swift-dev > wrote: > > I'm following up on a resilient dynamic dispatch discussion kicked off by > Slava during a performance team meeting to summarize some key > points on public [swift-dev]. > > It's easy to get sidetracked

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

> On Jan 26, 2017, at 5:07 AM, Andrew Trick via swift-dev > wrote: > Before I pull in a large PR that "accidentally" reformats a bunch of code, I > want to get feedback on how Swift compiler devs plan to use `clang-format`. > (BTW, here's the PR

Re: [swift-dev] Proposal: Opaque SIL values

> On Jan 24, 2017, at 2:10 PM, Andrew Trick via swift-dev > wrote: > I’m sending out a proposal for fundamentally changing SIL. This work feeds > into generic code optimization, resilience, semantic ARC, and SIL ownership. > This was discussed at length back in

Re: [swift-dev] Proposal: Opaque SIL values

> On Jan 25, 2017, at 9:13 PM, Joe Groff via swift-dev > wrote: > Looks great. One nitpick: > >> Naturally, opaque types must limit some optimizations, such as inlining. > > I don't see how opaque types by themselves prevent inlining. You can inline a > generic into

Re: [swift-dev] Questions about Struct's memory allocation

> On Dec 20, 2016, at 9:14 AM, Sergo Bero via swift-dev > wrote: > Hello everyone, > > I have a question about Swift Structs, regarding memory usage... > as WWDC talk ( Session 416 ) says, Swift uses heap memory to store large > values ( contain more than 3 words as

Re: [swift-dev] Questions related to Chris's IBM talk

> On Dec 17, 2016, at 1:25 PM, Nabeel Imtiaz via swift-dev > wrote: > Hi, > > I went through the speaker deck of Chris's talk @ IBM (would be great if > video was also available). What got me really excited, among all other > things, was the the manual memory management

Re: [swift-dev] Proposal: SIL Ownership Model + Verifier

> On Dec 8, 2016, at 1:53 PM, Andrew Trick <atr...@apple.com> wrote: >> On Dec 7, 2016, at 11:25 PM, John McCall via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@swift.org>> wrote: >> >>> >>> On Dec 7, 2016, at 2:13 PM,

Re: [swift-dev] Proposal: SIL Ownership Model + Verifier

> On Dec 7, 2016, at 2:13 PM, Michael Gottesman via swift-dev > wrote: > > This is a proposal for a new SIL Ownership Model and verifier. An online HTML > version of the document is available here: > > https://gottesmm.github.io/proposals/sil-ownership-model.html >

Re: [swift-dev] Proposal: SILValue SSA Instructions

> On Dec 6, 2016, at 10:17 AM, Joe Groff via swift-dev > wrote: >> On Dec 5, 2016, at 4:24 PM, Michael Gottesman via swift-dev >> wrote: >> >> Hello everyone! >> >> This is a proposal for 2 instructions needed to express borrowing via SSA at >> the

Re: [swift-dev] Questions about ARC

> On Nov 30, 2016, at 11:58 AM, Alexis <abeingess...@apple.com> wrote: >> On Nov 30, 2016, at 12:41 PM, John McCall via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@swift.org>> wrote: >> >> When we say that we don't have a concurrency model, we

Re: [swift-dev] Continuation-based versus nested-function-based materializeForSet

> On Oct 31, 2016, at 12:22 PM, Joe Groff via swift-dev > wrote: > We currently abstract over mutable property accesses using what I’ll call a > continuation-based model–the materializeForSet accessor is called before an > inout access, and returns a continuation callback

Re: [swift-dev] SE-0047 - Defaulting non-Void functions so they warn on unused results

> On Oct 30, 2016, at 5:49 AM, Jody Schofield via swift-dev > wrote: > Sorry, I'm sure this has been discussed before, but what the heck??? > > This feature is killing me. Now I have go add @discardableResult to every > function that returns a non-Void or use the ugly

Re: [swift-dev] Making the sign of NaNs unspecified to enable enum layout optimization

gt;>> <mailto:sca...@apple.com>> wrote: >>>> On Oct 24, 2016, at 2:55 PM, John McCall via swift-dev >>>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: >>>> >>>>> On Oct 24, 2016, at 8:49 AM, Joe Groff via

Re: [swift-dev] Making the sign of NaNs unspecified to enable enum layout optimization

> On Oct 24, 2016, at 12:30 PM, Stephen Canon <sca...@apple.com> wrote: >> On Oct 24, 2016, at 2:55 PM, John McCall via swift-dev <swift-dev@swift.org> >> wrote: >> >>> On Oct 24, 2016, at 8:49 AM, Joe Groff via swift-dev <swift-dev@swift.org> >

Re: [swift-dev] Making the sign of NaNs unspecified to enable enum layout optimization

> On Oct 24, 2016, at 8:49 AM, Joe Groff via swift-dev > wrote: >> On Oct 22, 2016, at 10:39 AM, Chris Lattner wrote: >> >>> On Oct 20, 2016, at 2:59 PM, Joe Groff via swift-dev >>> wrote: copysign( ) is a reason to not

Re: [swift-dev] Cleaning up stale branches?

> On Oct 21, 2016, at 10:39 AM, Dave Abrahams via swift-dev > wrote: > on Fri Oct 21 2016, Daniel Dunbar wrote: > >> While on this topic... >> >> GitHub's support for doing cross-repo pull requests is >> excellent. Anyone can easily fork the main repo, and push to their

Re: [swift-dev] Making the sign of NaNs unspecified to enable enum layout optimization

> On Oct 20, 2016, at 10:50 AM, Joe Groff wrote: >> On Oct 20, 2016, at 10:45 AM, John McCall > > wrote: >> >>> On Oct 19, 2016, at 8:42 PM, Joe Groff via swift-dev >> > wrote:

Re: [swift-dev] Making the sign of NaNs unspecified to enable enum layout optimization

> On Oct 19, 2016, at 8:42 PM, Joe Groff via swift-dev > wrote: > I had a discussion with Steve this morning about the potential for enum > layout optimization with floating-point payloads. One great thing about > floating-point is that it has NaNs, and lots of them. For

Re: [swift-dev] Semantic ARC and enum projection (Re: Having 64-bit swift_retain/release ignore all negative pointer values)

ift.org> >>> wrote: >>> >>> >>>> On Oct 16, 2016, at 1:10 PM, Dave Abrahams via swift-dev >>>> <swift-dev@swift.org> wrote: >>>> >>>> >>>> on Thu Oct 13 2016, Joe Groff wrote: >>>&

Re: [swift-dev] Having 64-bit swift_retain/release ignore all negative pointer values

> On Oct 13, 2016, at 2:14 PM, Joe Groff via swift-dev > wrote: > > >> On Oct 13, 2016, at 2:04 PM, Alexis wrote: >> >> Correct me if I’m wrong, but aren’t all kernel addresses negative on x64 and >> AArch64? Would this then mean any attempt to

Re: [swift-dev] Validating ABI consistency between runtime C++ and standard library Swift code

> On Oct 12, 2016, at 3:46 PM, Greg Parker <gpar...@apple.com> wrote: >> On Oct 12, 2016, at 11:11 AM, John McCall via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@swift.org>> wrote: >> >>> On Oct 11, 2016, at 8:10 PM, Joe Groff via swift

Re: [swift-dev] [discussion notes] SIL address types and borrowing

> On Oct 11, 2016, at 4:48 PM, Andrew Trick wrote: >> On Oct 11, 2016, at 2:14 PM, John McCall wrote: >> >>> On Oct 11, 2016, at 11:49 AM, Joe Groff wrote: On Oct 11, 2016, at 11:44 AM, John McCall wrote:

  1   2   >