[swift-dev] [arc optimization] Why doesn't enum destructuring use guaranteed references?

[Michael Gottesman]

> On Dec 30, 2017, at 1:21 PM, Félix Cloutier <felixcloutier at icloud.com> wrote:
> 
> 
>> Le 29 déc. 2017 à 20:50, Michael Gottesman <mgottesman at apple.com> a écrit :
>> 
>> No worries. Happy to help = ). If you are interested, I would be happy to help guide you in implementing one of these optimizations.
> 
> That sounds fun. I'll have to check with my manager after the holidays.

Nerd snipe success? = p. In general, we haven't had as many people from oss work on the optimizer. This is unfortunate, so I am more than happy to help.

> 
>> The main downside is that in some cases you do want to have +1 parameters, namely places where you are forwarding values into a function for storage. An example of such a case is a value passed to a setter or an initializer. I would think of it more as an engineering trade-off.
>> 
>> I am currently experimenting with changing normal function arguments to +0 for this purpose, leaving initializers and setters as taking values at +1. Regardless of the default, we can always provide an attribute for the purpose of allowing the user to specify such behavior.
> 
> It sounds like having flexible parameter ownership rules doesn't have too much overhead if it can be user-specified (in some future). Would it be feasible to use escape analysis to decide if a parameter should be +0 or +1?

No. A parameter's convention is ABI. You don't want to change ABI related things like that via escape analysis since it means that as a function changes, due to the optimizer, the ABI can change =><=. *BUT* recently Adam Nemet has added support for LLVM's opt remark infrastructure to Swift. Something like that /could/ provide suggestions when it is run that this might be a profitable parameter to change from +0 to +1 or vis-a-versa. Then the user could make that change via annotation. Keep in mind that this would most likely be an ABI breaking change.

> 
> More ARC questions! I remember that some time ago, someone else (John McCall?) said that references aren't tied to a scope. This was in the context of deterministic deallocation, and the point was that contrary to C++, an object could potentially be released immediately after its last use in the function rather than at the end of its scope. However, that's not really what you said ("When the assignment to xhat occurs we retain x and at the end of the function [...], we release xhat")

You are extrapolating too far from my example. That being said, I was unclear. What I was trying to show was the difference in between a case where xhat is passed off to another function, e.g.:

func g(x) {
  let xhat = x
  h(xhat)
}

and a situation where xhat is not consumed and is destroyed within g.

> , and it's not how Swift 4 works from what I can tell (release is not called "as soon as possible" from my limited testing).

Cases like this are due to the optimizer seeing some use that it can not understand. The optimizer must be conservative so sometimes things that the user thinks the optimizer should see through/understand, it can not. The way to see that is to look at the SIL level and see what is stopping the code motion. There are ways that you can get debug output from the optimizer. This additionally may be a case where an opt-remark like system could help guide the user on why code motion has stopped.

> 
> It seems to me that this penalizes functional-style programming in at least two ways:
> 
> 	• This kills tail call optimizations, because often the compiler will put a release call in the tail position
> 	• Especially in recursion-heavy algorithms, objects can be kept around for longer than they need to
> 
> Here's an example where both hit:
> 
>> class Foo {
>> 	var value: [Int]
>> 	
>> 	init() {
>> 		value = Array<Int>(repeating: 0, count: 10000)
>> 	}
>> 	
>> 	init(from foo: Foo) {
>> 		value = foo.value
>> 		value[0] += 1
>> 	}
>> }
>> 
>> func silly(loop: Int, foo: Foo) -> Foo {
>> 	guard loop != 0 else { return foo }
>> 	let copy = Foo(from: foo)
>> 	return silly(loop: loop - 1, foo: copy)
>> }
>> 
>> print(silly(loop: 10000, foo: Foo()).value[0])
> 
> I wouldn't call that "expert Swift code" (indeed, if I come to my senses and use a regular loop, it does just fine), but in this form, it does need about 800MB of memory, and it can't use tail calls.
> 
> The function has the opposite problem from the pattern matching case. It is specialized such that `foo` is passed at +0: it is retained at `return foo` and released (in the caller) after the call to `silly`. However, the optimal implementation would pass it at +1, do nothing for `return foo`, and release it (in the callee) after the call to `Foo(from: foo)`. (Or, even better, it would release it after `value = foo.value` in the init function.)
> 
> I'll note that escape analysis would correctly find that +1 is the "optimal" ownership convention for `foo` in `silly` :) but it won't actually solve either the memory use problem or the missed tail call unless the release call is also moved up.
> 
> I guess that the question is: what does Swift gain by keeping objects around for longer than they need to? Is it all about matching C++ or is there something else?

Again, I think you are extrapolating a bit. Swift is not attempting to keep objects around for longer than they need to be at all. Such situations are more likely due to optimizer inadequacies or unimplemented optimizations [again, nerd snipe alert, patches welcome ; )]. All of these things take engineering time to do and engineering time is something that must be prioritized with respect to the overall needs of the project.

When I compile this on my machine. Here is what the SIL looks like:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: viewcfg.pdf
Type: application/pdf
Size: 30249 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20171230/a29a1dd6/attachment.pdf>
-------------- next part --------------


From looking at this, it seems that perhaps function signature optimization is being too aggressive. One could write a heuristic that attempts to identify this case and not perform +0->+1 in this case.

Additionally, if/when we switch from +1->+0 as the default argument convention for "normal argument parameters", this shows a pattern where we would need an opposite form of function signature optimization that transforms a +0 argument to +1.

Did I answer your questions?
Michael

> 
> Félix
>