Skip to content
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
Open

cmd/compile: Need better type propagation #14018

dr2chase opened this issue Jan 19, 2016 · 3 comments
Labels
Milestone

Comments

@dr2chase
Copy link
Contributor

@dr2chase 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.

Copy link
Contributor Author

@dr2chase dr2chase commented Jan 19, 2016

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

@bradfitz

This comment has been minimized.

Copy link
Contributor

@bradfitz bradfitz commented Jan 19, 2016

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

This comment has been minimized.

Copy link
Contributor

@navytux 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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.