I asked the OP to log this bug. I wondered if it were possible for the
compiler, knowing that the cap var was effectively a single assignment
could the make function that operates on a constant bound be used.

I don't think example 3.go is relevant to this discussion.

On Thu, 29 Sep 2016, 18:10 Garfiled notifications@github.com wrote:

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?

go1.7
What operating system and processor architecture are you using (go env)?

amd64
What did you do?

// example1.go
package main

func main() {
s := make([]byte, 1024, 1024)
_ = s
}
s will be allocated in stack and lookup assemble code not call
runtime.makeslice

// example2.go
package main

func main() {
cap := 1024
s := make([]byte, 1024, cap)
_ = s
}
s will be allocated in heap and lookup assemble code there is
runtime.makeslice why this ??

// example3.go
package main

func main() {
a := 100
if a>1 {
a = 1000
}
b := interface{}(a)
_ = b
}
lookup the assemble code and see the compiler is very clever to opt that
but in example2.go why don't do this

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#17275, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAcA2PdzEMeBqS-HPjEmBqP1Z-RQ0mVks5qu3JegaJpZM4KJsdG
.

This is a "phase order problem", aka "stupid compiler trick". Constant propagation happens in SSA, which happens after escape analysis. Not clear if the better approach to this is to move escape analysis towards the SSA phase (note that one goal of escape analysis is to find those things that cannot be SSA-analyzed, so this is a fundamental change) or to do some simple constant propagation in the earlier phase of the compiler.

This is essentially a dup of #20533 (cmd/compile: improve escape analysis of make([]T, n) where n is non-constant). I know this one is older, but the other thread has a little more discussion, so let's keep that one. Closing here.