FAQ
[1] combines the loads into a MOVQ. But the bounds checks are all still
there.

func f(a []byte) uint64 {
if len(a) > 8 {
return binary.LittleEndian.Uint64(a)
}
return 0
}

0x000f 00015 (/home/khr/go/tmp1.go:6) MOVQ "".a+16(FP), CX
0x0014 00020 (/home/khr/go/tmp1.go:6) CMPQ CX, $8
0x0018 00024 (/home/khr/go/tmp1.go:6) JLE $0, 95
0x001a 00026 (/home/khr/go/tmp1.go:7) CMPQ CX, $0
0x001e 00030 (/home/khr/go/tmp1.go:7) JLS $0, 88
0x0020 00032 (/home/khr/go/tmp1.go:7) CMPQ CX, $1
0x0024 00036 (/home/khr/go/tmp1.go:7) JLS $0, 88
0x0026 00038 (/home/khr/go/tmp1.go:7) CMPQ CX, $2
0x002a 00042 (/home/khr/go/tmp1.go:7) JLS $0, 88
0x002c 00044 (/home/khr/go/tmp1.go:7) CMPQ CX, $3
0x0030 00048 (/home/khr/go/tmp1.go:7) JLS $0, 88
0x0032 00050 (/home/khr/go/tmp1.go:7) CMPQ CX, $4
0x0036 00054 (/home/khr/go/tmp1.go:7) JLS $0, 88
0x0038 00056 (/home/khr/go/tmp1.go:7) CMPQ CX, $5
0x003c 00060 (/home/khr/go/tmp1.go:7) JLS $0, 88
0x003e 00062 (/home/khr/go/tmp1.go:7) CMPQ CX, $6
0x0042 00066 (/home/khr/go/tmp1.go:7) JLS $0, 88
0x0044 00068 (/home/khr/go/tmp1.go:7) CMPQ CX, $7
0x0048 00072 (/home/khr/go/tmp1.go:7) JLS $0, 88
0x004a 00074 (/home/khr/go/tmp1.go:7) MOVQ "".a+8(FP), CX
0x004f 00079 (/home/khr/go/tmp1.go:7) MOVQ (CX), CX
0x0052 00082 (/home/khr/go/tmp1.go:7) MOVQ CX, "".~r1+32(FP)
0x0057 00087 (/home/khr/go/tmp1.go:7) RET
0x0058 00088 (/home/khr/go/tmp1.go:7) PCDATA $0, $0
0x0058 00088 (/home/khr/go/tmp1.go:7) CALL runtime.panicindex(SB)
0x005d 00093 (/home/khr/go/tmp1.go:7) UNDEF
0x005f 00095 (/home/khr/go/tmp1.go:9) MOVQ $0, "".~r1+32(FP)
0x0068 00104 (/home/khr/go/tmp1.go:9) RET

On Thu, Mar 10, 2016 at 10:21 AM, Alexandru Moșoi wrote:

Isn't that already optimized after [1]?

[1]
https://github.com/golang/go/commit/12e60452e9f7c21933aad1a864e1433736de807e

2016-03-10 19:18 GMT+01:00 Giovanni Bajo <giovannibajo@gmail.com>:
Another common example in my code

for len(a) > 8 {
// this should generate zero bound checks
data := binary.LittleEndian.Uint64(a)

// and should eventually generate code equivalent to:
// data := *(*uint64)(unsafe.Pointer(&a[0]))

}
On Thursday, March 10, 2016 at 7:16:35 PM UTC+1, Giovanni Bajo wrote:

In general, it would be great if a dominant check on len(slice) would
eliminate bound checks on dominated accesses, including those in loops.

For instance:

if len(a) < 128 {
panic("programming error")
}

// Now we know that a is at least 128, so the following loop should
// generate zero bound checks
for i := 0; i < 128; i++ {
a[i] = whatever
}


Giovanni

On Thursday, March 10, 2016 at 5:36:06 PM UTC+1, Alexandru Moșoi wrote:

Hi,

Can the bounds checks be eliminated for "if len(a) >= i+2 && a[:i+2]"
(assume i is non-negative)?

This pattern is very common, see for example: nextStdChunk in
time/format.go <https://golang.org/src/time/format.go>. I think the
code is buggy in the extreme case when i+2 overflows. If that's the case,
should we fix the code?

Regards,
--
You received this message because you are subscribed to a topic in the
Google Groups "golang-dev" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/golang-dev/jVP6h21OyL8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
Alexandru Moșoi
http://www.alexandru.mosoi.ro/
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 8 of 38 | next ›
Discussion Overview
groupgolang-dev @
categoriesgo
postedMar 10, '16 at 4:36p
activeMar 21, '16 at 1:09p
posts38
users11
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase