> Le 30 déc. 2017 à 14:22, Michael Gottesman <[email protected]> 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".
Félix
_______________________________________________
swift-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-dev
