cmd/compile: combine small loads

[randall77]

encoding/binary/binary.go:

func (littleEndian) Uint64(b []byte) uint64 {
    return uint64(b[0]) | uint64(b[1])<<8 | uint64(b[2])<<16 | uint64(b[3])<<24 |
        uint64(b[4])<<32 | uint64(b[5])<<40 | uint64(b[6])<<48 | uint64(b[7])<<56
}

It would be nice to combine the small loads into one larger load, at least for architectures with unaligned loads.

See #14266 for the bug about combining the bounds checks. This bug is about combining the loads themselves. We could use rewrite rules something like:

(Or64 (Load <t> ptr mem) (Shl64x64 (Load <t> (Add64 ptr (Const64 [t.Size()])) mem) (Const64 [8*t.Size()]))) -> (Load ptr mem)

These rules would probably work independent of whether the bounds checks are fixed or not.

Maybe we could do stores also. That would require the bounds checks to go first, and the user to write to the max index first (otherwise partial writes would be observable).

[dsnet]

Is this a duplicate of #11819?

[minux]

I think we must recognize both high to low and low to high index order as otherwise it's impossible to write code that perform equally well on both endianness.

[dsnet]

@minux, I don't see the relationship between memory access order and endianness; you can load from higher or lower address first regardless of the endianness. Unless you mean for code already in production with compatibility agreements?

As in the case of encoding/binary.PutUint64, where the indexes already start from a lower address, can't we do an initial bounds check that the length is >= 8? If yes, combine the stores, otherwise, fall back the original code.

That is, the compiler will implicitly convert the code to be:

func (bigEndian) PutUint64(b []byte, v uint64) {
    if len(b) >= 8 {
        // Combined store version of the code below.
        return
    }
    b[0] = byte(v >> 56)
    b[1] = byte(v >> 48)
    b[2] = byte(v >> 40)
    b[3] = byte(v >> 32)
    b[4] = byte(v >> 24)
    b[5] = byte(v >> 16)
    b[6] = byte(v >> 8)
    b[7] = byte(v)
}

This, ensures that we preserve the behavior of partial stores, but remains fast in the vastly-common case.

[gopherbot]

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

[gopherbot]

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