cmd/compile: Need better type propagation

[dr2chase]

When this code is compiled with -m, several heap allocations can be seen because hash.Hash64 is an interface type and it's not possible (in general) to know how the parameters to its methods are treated:

package foo

import (
    "hash"
    "hash/fnv"
)

func harsh(fieldVals []interface{}) uint64 {
    if len(fieldVals) == 0 {
        // Avoid allocating the hasher if there are no fieldVals
        return 0
    }

    h := fnv.New64a() // .(*fnv.Sum64a)

    for _, v := range fieldVals {
        switch v := v.(type) {
        case string:
            h.Write([]byte(v))
        case int, int32:
            vi, ok := v.(int32)
            if !ok {
                vi = int32(v.(int))
            }
            b := [4]byte{}
            for i := 0; i < 4; i++ {
                b[i] = byte(vi & 0xFF)
                vi >>= 8
            }
            h.Write(b[:])
        case bool:
            if v {
                h.Write([]byte{1})
            } else {
                h.Write([]byte{0})
            }
        }
    }
    return h.Sum64()
}

If the package-private type actually allocated by fnv.New64a is exposed and cast to (see the commented out .(*fnv.Sum64a) ), it becomes possible to see which functions are actually called and either inline them or determine that they do not leak their parameters, and heap allocations are avoided. This type information is available and can be propagated forward in tandem with the declared type, and used to better escape-analyze interface method calls (that are really monomorphic). Right now inlining can reveal it, ideally the summary information can include more precise information about returned types if there is any to be had.

[dr2chase]

Thought you guys might be interested in this: @randall77 @rsc @bcmills

[bradfitz]

@griesemer too

[navytux]

Related: #19361

[panmari]

Since #20380 is resolved, I think this can be closed as well.