cmd/compile: multiple LittleEndian.Uint* calls on the same buffer block load merging #52708
Comments
dr2chase
added
Performance
NeedsInvestigation
|
Workaround: But when I want to read a BE integer from t.buf, this doesn't work anymore: has the same problem as the LE version, while becomes eight byte loads on both amd64 and arm64. The workaround that works is |
|
The issue here is that before the lowering step the optimizer finds a way to have multiple uses of your Our load merging rules rely on having Or in other words. // Slightly reformated binary.LittleEndian.Uint16 impl
y := uint16(b[1])<<8
x := uint16(b[0])
return x | yBut not: yByte := b[1]
y := uint16(yByte)<<8
x := uint16(b[0])
return x | y, yByteBecause the second step have two uses of The reason your loads have two uses to begin with is that that previous optimization steps inline the type T struct {
buf [16]byte
}
func (t *T) readU32() uint32 {
x0 := b[0]
x1 := b[1]
x2 := b[2]
x3 := b[3]
// InlMark
xLow64 := uint64(x0) | uint64(x1)<<8 | uint64(x2)<<16 | uint64(x3)<<24
x := xLow64 | uint64(binary.LittleEndian.Uint32(t.buf[4:])) << 32
y := binary.LittleEndian.Uint64(t.buf[8:])
shift := 8 * n
x >>= shift
x |= y << ((64 - shift) % 64)
y >>= shift
binary.LittleEndian.PutUint64(t.buf[:], x)
binary.LittleEndian.PutUint64(t.buf[8:], y)
// End Inl
xLow32 := uint32(x0) | uint32(x1)<<8 | uint32(x2)<<16 | uint32(x3)<<24
return xLow32
}Whats sad in that code is that it is not capable to realise that it can merge I'm not sure what need to happen here.
type T struct {
buf [16]byte
}
func (t *T) readU32() uint32 {
xLow := binary.LittleEndian.Uint32(t.buf[4:])
// InlMark
x := uint64(xLow) | uint64(binary.LittleEndian.Uint32(t.buf[4:])) << 32 // A single shift & or assemble here
y := binary.LittleEndian.Uint64(t.buf[8:])
shift := 8 * n
x >>= shift
x |= y << ((64 - shift) % 64)
y >>= shift
binary.LittleEndian.PutUint64(t.buf[:], x)
binary.LittleEndian.PutUint64(t.buf[8:], y)
// End Inl
return xLow
} |
What version of Go are you using (
go version)?What did you do?
What did you expect to see?
A single MOVL for LittleEndian.Uint32, and a single MOVQ for each LittleEndian.(Put)?Uint64, or something similar.
What did you see instead?
(*T).shiftBuf gets inlined. The Uint32 call then gets broken up into four byte loads. The first Uint64 becomes a MOVL to fetch the upper word, which is then combined with the Uint32 result. The final PutUint64 is broken up into two MOVLs. With gotip:
GOARCH=arm64 produces byte loads and shifts too.
The text was updated successfully, but these errors were encountered: