I'm beginning to suspect that it's just too complicated to inline.

$ cat t.go
package f

import "unsafe"

func readUnaligned64(p unsafe.Pointer) uint64 {
q := (*[8]byte)(p)
return uint64(q[0]) + uint64(q[1])<<8 + uint64(q[2])<<16 + uint64(q[3])<<24

• uint64(q[4])<<32 + uint64(q[5])<<40 + uint64(q[6])<<48 + uint64(q[7])<<56
  }
  $ go version
  go version devel +3fa5d3a Thu Dec 11 15:23:18 2014 +0000 linux/amd64
  $ go tool 6g -m t.go
  t.go:5: readUnaligned64 p does not escape
  $ go tool 6g -m -l -l -l -l t.go
  t.go:5: readUnaligned64 p does not escape

$ cat t2.go
package f

import "unsafe"

func readUnaligned64(p unsafe.Pointer) uint64 {
return _(_uint64)(p)
}
$ go tool 6g -m t2.go
t2.go:5: can inline readUnaligned64
t2.go:5: readUnaligned64 p does not escape

At least when GOARCH=="amd64", it would be nice if it inlined.

On Thu, Dec 11, 2014 at 8:45 PM, randall77 notifications@github.com wrote:

At least when GOARCH=="amd64", it would be nice if it inlined.

Then we only need two copies. One for architecture that supports unaligned
load,
and one for the others.

You think unaligned1.go and unaligned2.go, each with appropriate build tags, is the way to go?

On Thu, Dec 11, 2014 at 10:12 PM, randall77 notifications@github.com
wrote:

You think unaligned1.go and unaligned2.go, each with appropriate build
tags, is the way to go?

Yes. And we should figure out why the portable version can not be inlined
even with 4 -l.

If the endian doesn't matter, I also recommend change the function name to
be more explicit about
the endian.

CL https://golang.org/cl/37499 mentions this issue.