[swift-dev] Protocol Devirtualizer Pass

[Slava Pestov]

Hi Raj,

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

@inline(never) internal func wrap_inc(a:SumProtocol, val:Int) -> Int{
 return a.increment(i:val)
}

Would become

@inline(always) internal func wrap_inc(a: SumProtocol, val: Int) -> Int {
  // opening an existential cannot be expressed in Swift, but it can in SIL…
  let _a = a open as T

  return _wrap_inc(_a, val)
}

@inline(never) internal func _wrap_inc<T : SumProtocol>(_a:T, val:Int) -> Int{
 let a: SomeProtocol = _a
 return a.increment(i:val)
}

(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.)

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):

@inline(always) internal func wrap_inc(a: SumProtocol, val: Int) -> Int {
  // opening an existential cannot be expressed in Swift, but it can in SIL…
  let _a = a open as T

  return _wrap_inc(_a, val)
}

@inline(never) internal func _wrap_inc<T : SumProtocol>(_a:T, val:Int) -> Int{
 return _a.increment(i:val)
}

Now, if I have a call to wrap_inc somewhere, 

internal let magic:SumProtocol = SumClass(base:10)
_ = wrap_inc(magic)

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.

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.

Slava

> On Nov 29, 2017, at 11:30 AM, Raj Barik via swift-dev <swift-dev at swift.org> wrote:
> 
> Hi,
> 
> 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?
> 
> Original code:
> 
> 
> protocol SumProtocol: class {
>   func increment(i:Int)  -> Int
> }
> 
> internal class SumClass: SumProtocol {
>   var a:Int
>   init(base:Int) {
>     self.a = base
>   }
>   func increment(i:Int) -> Int {
>    self.a += i
>    return self.a
>   }
> }
> 
> @inline(never) internal func wrap_inc(a:SumProtocol, val:Int) -> Int{
>  return a.increment(i:val)
> }
> 
> internal let magic:SumProtocol = SumClass(base:10)
> print("c=\(wrap_inc(a:magic,val:10))")
> 
> 
> After Step 1:
> 
> 
> protocol SumProtocol: class {
>   func increment(i:Int)  -> Int
> }
> 
> internal class SumClass: SumProtocol {
>   var a:Int
>   init(base:Int) {
>     self.a = base
>   }
>   func increment(i:Int) -> Int {
>    self.a += i
>    return self.a
>   }
> }
> 
> @inline(never) internal func wrap_inc(a:SumProtocol, val:Int) -> Int{
>  return a.increment(i:val)
> }
> 
> @inline(never) internal func wrap_inc_1(a:SumClass, val:Int) -> Int{
>  return a.increment(i:val)
> }
> 
> internal let magic:SumClass = SumClass(base:10)
> print("c=\(wrap_inc_1(a:magic,val:10))")
> 
> 
> After Step 2:
> 
> internal class SumClass {
>   var a:Int
>   init(base:Int) {
>     self.a = base
>   }
>   func increment(i:Int) -> Int {
>    self.a += i
>    return self.a
>   }
> }
> 
> @inline(never) internal func wrap_inc(a:SumClass, val:Int) -> Int{
>  return a.increment(i:val)
> }
> 
> internal let magic:SumClass = SumClass(base:10)
> print("c=\(wrap_inc(a:magic,val:10))")
> 
> Any comments/thought on this transformation?
> 
> Best,
> Raj 
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20171129/4e246c40/attachment.html>