<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 20, 2017, at 3:56 PM, Raj Barik <<a href="mailto:rkbarik@gmail.com" class="">rkbarik@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Thank you Arnold & Slava! The protocol devirtualizer pass works fine now for most cases. I should be creating a PR soon (after some more testing).<div class=""><br class=""></div><div class="">I am thinking about extending this to Optional types as well, i.e., </div></div></div></blockquote><div><br class=""></div>I’m not sure if its possible in the general case. What you might think of doing is rewriting this into a function that takes an Optional<T> where T : SumProtocol. But the trouble is if the value of ‘a’ is nil, then there’s no concrete type to bind to the type parameter T at runtime. What you really want is a way to write</div><div><br class=""></div><div>enum WeirdOptional {</div><div> case <T> some(T)</div><div> case none</div><div>}</div><div><br class=""></div><div>But we don’t allow this.</div><div><br class=""></div><div>I think even without handling optionals though, this optimization definitely has value.</div><div><br class=""></div><div>Are you implementing it as a separate pass, or is it part of function signature specialization?</div><div><br class=""></div><div>Slava</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">@inline(never) internal func wrap_inc_optional(a:SumProtocol?, val:Int) -> Int?{</div><div style="font-size:12.8px" class=""> return a?.increment(i:val)</div><div style="font-size:12.8px" class="">}</div></div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">The generated SIL looks something like this:</div><div style="font-size:12.8px" class=""><br class=""></div><div class=""><div class=""><div class=""><span style="font-size:12.8px" class="">sil hidden [noinline] @_T04main21wrap_inc_optionalSiSgAA11SumProtocol_pSg1a_Si3valtF : $@convention(thin) (@owned Optional<SumProtocol>, Int) -> Optional<Int> {</span></div><div class=""><span style="font-size:12.8px" class="">// %0 // users: %11, %4, %7, %2</span></div><div class=""><span style="font-size:12.8px" class="">// %1 // users: %10, %3</span></div><div class=""><span style="font-size:12.8px" class="">bb0(%0 : $Optional<SumProtocol>, %1 : $Int):</span></div><div class=""><span style="font-size:12.8px" class=""> debug_value %0 : $Optional<SumProtocol>, let, name "a", argno 1 // id: %2</span></div><div class=""><span style="font-size:12.8px" class=""> debug_value %1 : $Int, let, name "val", argno 2 // id: %3</span></div><div class=""><span style="font-size:12.8px" class=""> <font color="#ff0000" class=""> switch_enum %0 : $Optional<SumProtocol>, case #Optional.some!enumelt.1: bb2, case #Optional.none!enumelt: bb1 // id: %4</font></span></div><div class=""><span style="font-size:12.8px" class=""><font color="#ff0000" class=""><br class=""></font></span></div><div class=""><span style="font-size:12.8px" class=""><font color="#ff0000" class="">bb1: // Preds: bb0</font></span></div><div class=""><span style="font-size:12.8px" class=""><font color="#ff0000" class=""> %5 = enum $Optional<Int>, #Optional.none!enumelt // user: %6</font></span></div><div class=""><span style="font-size:12.8px" class=""><font color="#ff0000" class=""> br bb3(%5 : $Optional<Int>) // id: %6</font></span></div><div class=""><span style="font-size:12.8px" class=""><font color="#ff0000" class=""><br class=""></font></span></div><div class=""><span style="font-size:12.8px" class=""><font color="#ff0000" class="">bb2: // Preds: bb0</font></span></div><div class=""><span style="font-size:12.8px" class=""> %7 = unchecked_enum_data %0 : $Optional<SumProtocol>, #Optional.some!enumelt.1 // user: %8</span></div><div class=""><span style="font-size:12.8px" class=""> %8 = open_existential_ref %7 : $SumProtocol to $@opened("F0395A0A-E5DE-11E7-A06A-420039484801") SumProtocol // users: %10, %10, %9</span></div><div class=""><span style="font-size:12.8px" class=""> %9 = witness_method $@opened("F0395A0A-E5DE-11E7-A06A-420039484801") SumProtocol, #SumProtocol.increment!1 : <Self where Self : SumProtocol> (Self) -> (Int) -> Int, %8 : $@opened("F0395A0A-E5DE-11E7-A06A-420039484801") SumProtocol : $@convention(witness_method) <τ_0_0 where τ_0_0 : SumProtocol> (Int, @guaranteed τ_0_0) -> Int // type-defs: %8; user: %10</span></div><div class=""><span style="font-size:12.8px" class=""> %10 = apply %9<@opened("F0395A0A-E5DE-11E7-A06A-420039484801") SumProtocol>(%1, %8) : $@convention(witness_method) <τ_0_0 where τ_0_0 : SumProtocol> (Int, @guaranteed τ_0_0) -> Int // type-defs: %8; user: %12</span></div><div class=""><span style="font-size:12.8px" class=""> release_value %0 : $Optional<SumProtocol> // id: %11</span></div><div class=""><span style="font-size:12.8px" class=""> %12 = enum $Optional<Int>, #Optional.some!enumelt.1, %10 : $Int // user: %13</span></div><div class=""><span style="font-size:12.8px" class=""> br bb3(%12 : $Optional<Int>) // id: %13</span></div><div class=""><span style="font-size:12.8px" class=""><br class=""></span></div><div class=""><span style="font-size:12.8px" class="">// %14 // user: %15</span></div><div class=""><span style="font-size:12.8px" class="">bb3(%14 : $Optional<Int>): // Preds: bb1 bb2</span></div><div class=""><span style="font-size:12.8px" class=""> return %14 : $Optional<Int> // id: %15</span></div></div></div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">The above branching code (in red) in the SIL makes it non-trivial to abstract out the non-nil path to a generic outlined method while keeping the branching code in the thunk and also its not clear if the SILCombiner peephole optimizer will actually come into affect for this scenario (because of the branching code getting inlined in the caller). It also gets more complicated if there are more than one optional types as parameter to wrap_inc_optional. Any clue on how one can handle optional types for devirtualization or if there are any existing transformations in Swift compiler that can help implement this easily? Thanks.</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">-R</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Dec 13, 2017 at 3:28 PM, Arnold Schwaighofer <span dir="ltr" class=""><<a href="mailto:aschwaighofer@apple.com" target="_blank" class="">aschwaighofer@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You don’t need a second open_existential_ref in the _wrap_inc<T: SumProtocol> function. It should look something like this:<br class="">
<br class="">
sil @_wrap_inc : $@convention(thin) <T where T : SumProtocol> (@owned T, Int) -> Int {<br class="">
bb0(%0 : $T, %1 : $Int):<br class="">
%5 = witness_method $T, #SumProtocol.inc!1 : <Self where Self : SumProtocol> (Self) -> (Int) -> Int : $@convention(witness_method: SumProtocol) <τ_0_0 where τ_0_0 : SumProtocol> (Int, @guaranteed τ_0_0) -> Int<br class="">
%6 = apply %5<T>(%1, %0) : $@convention(witness_method: SumProtocol) <τ_0_0 where τ_0_0 : SumProtocol> (Int, @guaranteed τ_0_0) -> Int<br class="">
destroy_value %0 : $T<br class="">
return %6 : $Int<br class="">
}<br class="">
<br class="">
In the other function it looks like you need to apply the proper substitution list to the apply instruction:<br class="">
<span class=""><br class="">
sil hidden [thunk] [always_inline] @_T04main8wrap_<wbr class="">incSiAA11SumProtocol_p1a_<wbr class="">Si3valtF : $@convention(thin) (@owned SumProtocol, Int) -> Int {<br class="">
</span><span class="">bb0(%0 : $SumProtocol, %1 : $Int):<br class="">
// function_ref specialized wrap_inc(a:val:)<br class="">
%2 = function_ref @_T04main8wrap_<wbr class="">incSiAA11SumProtocol_p1a_<wbr class="">Si3valtFTf4nn_n<br class="">
</span><span class=""> %3 = open_existential_ref %0 : $SumProtocol to $@opened("E6196082-DF72-11E7-<wbr class="">8C84-420039484801") SumProtocol<br class="">
</span><span class=""> %4 = apply %2<τ_0_0>(%3, %1) : $@convention(thin) <τ_0_0 where τ_0_0 : SumProtocol> (@owned τ_0_0, Int) -> Int // user: %5<br class="">
<br class="">
</span>τ_0_0 should have been substituted by the opened type: $@opened("E6196082-DF72-11E7-<wbr class="">8C84-420039484801”) SumProtocol.<br class="">
<span class=""><br class="">
%3 = open_existential_ref %0 : $SumProtocol to $@opened("E6196082-DF72-11E7-<wbr class="">8C84-420039484801") SumProtocol<br class="">
</span> %4 = apply %2<@opened("E6196082-DF72-<wbr class="">11E7-8C84-420039484801”) SumProtocol>(%3, %1) : $@convention(thin) <τ_0_0 where τ_0_0 : SumProtocol> (@owned τ_0_0, Int) -> Int<br class="">
<br class="">
<br class="">
Probably, you have to pass the right SubstitutionList to the createApplyInst call.<br class="">
<br class="">
<br class="">
The peephole that propagates types from an init existential Slava referred to is here:<br class="">
<br class="">
<a href="https://github.com/apple/swift/blob/master/lib/SILOptimizer/SILCombiner/SILCombinerApplyVisitors.cpp#L974" rel="noreferrer" target="_blank" class="">https://github.com/apple/<wbr class="">swift/blob/master/lib/<wbr class="">SILOptimizer/SILCombiner/<wbr class="">SILCombinerApplyVisitors.cpp#<wbr class="">L974</a> (SILCombiner::<wbr class="">propagateConcreteTypeOfInitExi<wbr class="">stential)<br class="">
<br class="">
Here is a test case that shows how the type from the init existential is propagated (instead of a generic type ’T’ as in the test case, in your case it would be the class type SumClass):<br class="">
<br class="">
<a href="https://github.com/apple/swift/blob/master/test/SILOptimizer/sil_combine.sil#L2569" rel="noreferrer" target="_blank" class="">https://github.com/apple/<wbr class="">swift/blob/master/test/<wbr class="">SILOptimizer/sil_combine.sil#<wbr class="">L2569</a><br class="">
<div class="HOEnZb"><div class="h5"><br class="">
> On Dec 13, 2017, at 11:39 AM, Raj Barik via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:<br class="">
><br class="">
> Slava,<br class="">
><br class="">
> I have two (clarification) questions in your proposed implementation:<br class="">
><br class="">
> Original Function:<br class="">
> @inline(never) internal func wrap_inc(a:SumProtocol, val:Int) -> Int{<br class="">
> return a.increment(i:val)<br class="">
> }<br class="">
> Transformed code:<br class="">
> @inline(always) internal func wrap_inc(a: SumProtocol, val: Int) -> Int {<br class="">
> // opening an existential cannot be expressed in Swift, but it can in SIL…<br class="">
> let _a = a open as T<br class="">
><br class="">
> return _wrap_inc(_a, val)<br class="">
> }<br class="">
><br class="">
> @inline(never) internal func _wrap_inc<T : SumProtocol>(_a:T, val:Int) -> Int{<br class="">
> return _a.increment(i:val)<br class="">
> }<br class="">
> ******************************<wbr class="">******************************<wbr class="">****************************<br class="">
> In the above code sequence, did you mean that "let _a = a open as T" opens "a:SumProtocol" using open_existential_ref instruction as "SumClass" which is the concrete type of a or it is opened as the "$@opened SumProtocol". In both cases, the open_existential_ref in the original function is still there and giving rise to opening the existential twice. Did you also intended that the _wrap_inc function is rewritten to eliminate the open_existential_ref as well (this is more complicated if the protocol is passed down a call chain)? So, I do not really understand what the "let _a = a open as T" is suggesting. The other part of the confusion is about the peephole optimization which optimizes the code sequence consisting of the creation of object for SumClass and then the init_existential_ref and followed by the open_existential_ref. Can you clarify?<br class="">
><br class="">
> Thanks.<br class="">
><br class="">
><br class="">
> On Wed, Nov 29, 2017 at 1:43 PM, Slava Pestov <<a href="mailto:spestov@apple.com" class="">spestov@apple.com</a>> wrote:<br class="">
> Hi Raj,<br class="">
><br class="">
> The way I would approach this problem is first, turn a function taking a protocol value into one taking a protocol-constrained generic parameter. So<br class="">
><br class="">
> @inline(never) internal func wrap_inc(a:SumProtocol, val:Int) -> Int{<br class="">
> return a.increment(i:val)<br class="">
> }<br class="">
><br class="">
> Would become<br class="">
><br class="">
> @inline(always) internal func wrap_inc(a: SumProtocol, val: Int) -> Int {<br class="">
> // opening an existential cannot be expressed in Swift, but it can in SIL…<br class="">
> let _a = a open as T<br class="">
><br class="">
> return _wrap_inc(_a, val)<br class="">
> }<br class="">
><br class="">
> @inline(never) internal func _wrap_inc<T : SumProtocol>(_a:T, val:Int) -> Int{<br class="">
> let a: SomeProtocol = _a<br class="">
> return a.increment(i:val)<br class="">
> }<br class="">
><br class="">
> (Note that the existing function signature specialization pass performs a similar transformation where it creates a new function with the same body as the old function but a different signature, and replaces the old function with a short thunk that transforms arguments and results and calls the new function.)<br class="">
><br class="">
> At this point, the existing “initialize existential with concrete type” peephole in the SILCombiner should eliminate the existential (but the peephole doesn’t work in 100% of cases yet):<br class="">
><br class="">
> @inline(always) internal func wrap_inc(a: SumProtocol, val: Int) -> Int {<br class="">
> // opening an existential cannot be expressed in Swift, but it can in SIL…<br class="">
> let _a = a open as T<br class="">
><br class="">
> return _wrap_inc(_a, val)<br class="">
> }<br class="">
><br class="">
> @inline(never) internal func _wrap_inc<T : SumProtocol>(_a:T, val:Int) -> Int{<br class="">
> return _a.increment(i:val)<br class="">
> }<br class="">
><br class="">
> Now, if I have a call to wrap_inc somewhere,<br class="">
><br class="">
> internal let magic:SumProtocol = SumClass(base:10)<br class="">
> _ = wrap_inc(magic)<br class="">
><br class="">
> Then the optimizer will inline the thunk, giving you a call to _wrap_inc. The existential value built from the SumClass instance is immediately opened so it will be peepholed away. At this point you have a call of a generic function _wrap_inc with a concrete type SumClass, and the generic specializer can produce a specialization of it.<br class="">
><br class="">
> Notice how this approach combines several existing optimizations and only requires adding a relatively simple new transformation, and possibly improving some of the existing optimizations to cover more cases.<br class="">
><br class="">
> Slava<br class="">
><br class="">
>> On Nov 29, 2017, at 11:30 AM, Raj Barik via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:<br class="">
>><br class="">
>> Hi,<br class="">
>><br class="">
>> I am thinking about writing a Protocol Devirtualizer Pass that specializes functions that take Protocols as arguments to transform them with concrete types instead of protocol types when the concrete types can be determined statically by some compiler analysis. This is the first step of the transformation that I am proposing. My goal is to extend this to eliminate the original function implementation and also to remove the corresponding protocol type (by deleting it from the witness table), if possible. For simple cases, where the protocol is only used for mocking for example and that there is just one class that conforms to it, we should be able to eliminate the protocol altogether. This is the second and final step of the transformation. Does anyone see any issues with both these steps? Arnold from Apple pointed out that there might be demangling issues when the protocol is eliminated. Any ideas on how to fix the demangling issues? Moreover, would such a pass be helpful to Swift folks?<br class="">
>><br class="">
>> Original code:<br class="">
>><br class="">
>><br class="">
>> protocol SumProtocol: class {<br class="">
>> func increment(i:Int) -> Int<br class="">
>> }<br class="">
>><br class="">
>> internal class SumClass: SumProtocol {<br class="">
>> var a:Int<br class="">
>> init(base:Int) {<br class="">
>> self.a = base<br class="">
>> }<br class="">
>> func increment(i:Int) -> Int {<br class="">
>> self.a += i<br class="">
>> return self.a<br class="">
>> }<br class="">
>> }<br class="">
>><br class="">
>> @inline(never) internal func wrap_inc(a:SumProtocol, val:Int) -> Int{<br class="">
>> return a.increment(i:val)<br class="">
>> }<br class="">
>><br class="">
>> internal let magic:SumProtocol = SumClass(base:10)<br class="">
>> print("c=\(wrap_inc(a:magic,<wbr class="">val:10))")<br class="">
>><br class="">
>><br class="">
>> After Step 1:<br class="">
>><br class="">
>><br class="">
>> protocol SumProtocol: class {<br class="">
>> func increment(i:Int) -> Int<br class="">
>> }<br class="">
>><br class="">
>> internal class SumClass: SumProtocol {<br class="">
>> var a:Int<br class="">
>> init(base:Int) {<br class="">
>> self.a = base<br class="">
>> }<br class="">
>> func increment(i:Int) -> Int {<br class="">
>> self.a += i<br class="">
>> return self.a<br class="">
>> }<br class="">
>> }<br class="">
>><br class="">
>> @inline(never) internal func wrap_inc(a:SumProtocol, val:Int) -> Int{<br class="">
>> return a.increment(i:val)<br class="">
>> }<br class="">
>><br class="">
>> @inline(never) internal func wrap_inc_1(a:SumClass, val:Int) -> Int{<br class="">
>> return a.increment(i:val)<br class="">
>> }<br class="">
>><br class="">
>> internal let magic:SumClass = SumClass(base:10)<br class="">
>> print("c=\(wrap_inc_1(a:magic,<wbr class="">val:10))")<br class="">
>><br class="">
>><br class="">
>> After Step 2:<br class="">
>><br class="">
>> internal class SumClass {<br class="">
>> var a:Int<br class="">
>> init(base:Int) {<br class="">
>> self.a = base<br class="">
>> }<br class="">
>> func increment(i:Int) -> Int {<br class="">
>> self.a += i<br class="">
>> return self.a<br class="">
>> }<br class="">
>> }<br class="">
>><br class="">
>> @inline(never) internal func wrap_inc(a:SumClass, val:Int) -> Int{<br class="">
>> return a.increment(i:val)<br class="">
>> }<br class="">
>><br class="">
>> internal let magic:SumClass = SumClass(base:10)<br class="">
>> print("c=\(wrap_inc(a:magic,<wbr class="">val:10))")<br class="">
>><br class="">
>> Any comments/thought on this transformation?<br class="">
>><br class="">
>> Best,<br class="">
>> Raj<br class="">
>> ______________________________<wbr class="">_________________<br class="">
>> swift-dev mailing list<br class="">
>> <a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class="">
>> <a href="https://lists.swift.org/mailman/listinfo/swift-dev" rel="noreferrer" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-dev</a><br class="">
><br class="">
><br class="">
> ______________________________<wbr class="">_________________<br class="">
> swift-dev mailing list<br class="">
> <a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class="">
> <a href="https://lists.swift.org/mailman/listinfo/swift-dev" rel="noreferrer" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-dev</a><br class="">
<br class="">
</div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>