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 · 4 comments
Open

cmd/compile: Need better type propagation #14018

dr2chase opened this issue Jan 19, 2016 · 4 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. Performance
Milestone

Comments

@dr2chase
Copy link
Contributor

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
Copy link
Contributor Author

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

@bradfitz
Copy link
Contributor

@griesemer too

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

navytux commented Apr 6, 2017

Related: #19361

@panmari
Copy link

panmari commented Dec 1, 2021

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

@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. Performance
Projects
None yet
Development

No branches or pull requests

5 participants