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

[Michael Gottesman]

Felix, on a completely different note. Do you think you could contribute these workloads to the swift benchmark suite. Then we can track it over time.

Michael

> On Dec 30, 2017, at 10:03 PM, Michael Gottesman via swift-dev <swift-dev at swift.org> wrote:
> 
> 
> 
>> On Dec 30, 2017, at 9:41 PM, Félix Cloutier <felixcloutier at icloud.com> wrote:
>> 
>> 
>>> Le 30 déc. 2017 à 14:22, Michael Gottesman <mgottesman at apple.com> a écrit :
>>>> That sounds fun. I'll have to check with my manager after the holidays.
>>> 
>>> Nerd snipe success? = p
>> 
>> I guess so? 🤓 I'm an easy target.
>> 
>>>> 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 =><=.
>> 
>> That makes sense, I hadn't thought about it.
>> 
>>> 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.
>> 
>> My limited testing was basically checking this program:
>> 
>>> final class Foo {
>>> 	var bar = 4
>>> }
>>> 
>>> let instance = Foo()
>>> 
>>> @inline(never)
>>> func print(_ x: Int) {
>>> 	Swift.print(x)
>>> }
>>> 
>>> func main() {
>>> 	let foo = instance
>>> 	print(foo.bar)
>>> 	print(0)
>>> }
>> 
>> 
>> On my first pass I noticed that foo is released at the end of the function (hence the rest of my message), but upon closer inspection I see that it is, in fact, retained after `foo.bar` is accessed:
>> 
>>> sil hidden @_T04test4mainyyF : $@convention(thin) () -> () {
>>> bb0:
>>> %0 = global_addr @_T04test8instanceAA3FooCv : $*Foo // user: %1
>>> %1 = load %0 : $*Foo                            // users: %11, %6, %4, %2
>>> debug_value %1 : $Foo, let, name "foo"          // id: %2
>>> // function_ref print(_:)
>>> %3 = function_ref @_T04test5printySiF : $@convention(thin) (Int) -> () // users: %10, %7
>>> %4 = ref_element_addr %1 : $Foo, #Foo.bar       // user: %5
>>> %5 = load %4 : $*Int                            // user: %7
>>> strong_retain %1 : $Foo                         // id: %6
>>> %7 = apply %3(%5) : $@convention(thin) (Int) -> ()
>>> %8 = integer_literal $Builtin.Int64, 0          // user: %9
>>> %9 = struct $Int (%8 : $Builtin.Int64)          // user: %10
>>> %10 = apply %3(%9) : $@convention(thin) (Int) -> ()
>>> strong_release %1 : $Foo                        // id: %11
>>> %12 = tuple ()                                  // user: %13
>>> return %12 : $()                                // id: %13
>>> } // end sil function '_T04test4mainyyF'
>> 
>> 
>> So while I thought earlier that I didn't know why it wasn't released, I guess that the better question is why it's retained at all!
>> 
>>>> 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.
>> 
>> Of course. I think that I was being a bit aggressive with "what is the benefit of this"; I knew there was a fair chance that it was "we had other things to do".
> 
> I do not believe in bad questions and I think that you asked said questions in an appropriate/respectful way. So don't worry about it: everything's good. = ).
> 
> That being said, if you want to take me up on the "nerd snipe", just send an email to swift-dev and +CC me. I may be the appropriate person to help you, but if not I will hook you up with the right person to help you.
> 
> Michael
> 
>> 
>> Félix
>> 
> 
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev