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

dr2chase opened this issue Jan 19, 2016 · 3 comments


None yet
3 participants
Copy link

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 (

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:
        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
        case bool:
            if v {
            } else {
    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.


This comment has been minimized.

Copy link
Contributor Author

commented Jan 19, 2016

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


This comment has been minimized.

Copy link

commented Jan 19, 2016

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


This comment has been minimized.

Copy link

commented Apr 6, 2017

Related: #19361

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.