New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/compile: Need better type propagation #14018

Open
dr2chase opened this Issue Jan 19, 2016 · 3 comments

Comments

Projects
None yet
3 participants
@dr2chase
Contributor

dr2chase commented Jan 19, 2016

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

This comment has been minimized.

Contributor

dr2chase commented Jan 19, 2016

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

@bradfitz

This comment has been minimized.

Member

bradfitz commented Jan 19, 2016

@bradfitz bradfitz added this to the Unplanned milestone Jan 21, 2016

@navytux

This comment has been minimized.

Contributor

navytux commented Apr 6, 2017

Related: #19361

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment