> On Jun 23, 2016, at 2:02 PM, Andrew Trick <[email protected]> wrote:
>
>>
>> On Jun 23, 2016, at 1:48 PM, Slava Pestov <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>>> On Jun 23, 2016, at 1:46 PM, Andrew Trick <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>
>>>> On Jun 23, 2016, at 12:53 PM, Slava Pestov via swift-evolution
>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>
>>>> The proposal is to change the type of self to always be Self, which can be
>>>> thought of as a special generic type parameter bound to the dynamic type
>>>> of the instance.
>>>
>>> We’re currently specializing functions that take `self` as an argument. I
>>> don’t think that will be possible after your proposed change.
>>>
>>> - Andy
>>
>> I’m not sure what that means. Do you currently punt on certain optimizations
>> if a method returns ‘Self’?
>>
>> It should be possible to keep the reified type information around, by
>> passing in a metatype or something for example. Can you give a concrete code
>> snippet demonstrating the optimization and how this change would inhibit it?
>
> We bail out of generic specialization, inlining, and function signature
> specialization when a type substitution contains dynamic self.
> (hasDynamicSelfTypes). So, yes we currently almost entirely punt on
> optimization for methods that return Self.
I see. That makes sense.
I think the problem is that if we specialize a top-level function with a
substitution involving Self, we have no way to recover what the ‘Self’ type
actually is in IRGen. However I think it could be made to work by passing in a
metatype for Self, and somehow ensuring we don’t mix up Self from two different
contexts...
This is certainly a trickier change than I first imagined, but it would be nice
to figure out how to solve this in a principled way so that we can get these
optimizations to be more generally applicable. It seems even more surprising,
now, if changing the return type of a method inhibits optimizations in a
non-obvious way, especially ones that can have a drastic effect on performance.
I think next week I’ll try implementing this proposal behind a staging flag,
and play around with the optimizer to see how hard it would be plumb through
the relevant type information.
Slava
>
> I don’t have an interesting case to point out. You can look into any trivial
> example:
>
> func foo<T>(_: T) {}
>
> func method() {
> foo(self)
> }
>
> -Andy
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
