FAQ
Well, I had missed that commit and I checked. It does collate the loads
correctly but still obviously generates 4 bound checks, and a dominant
check is not sufficient right now (though I understand you're working on
this).

It also doesn't handle writes (PutUint32, PutUint64).

And BTW, in the cases where the compiler can't eliminate bound checks, the
generated code is:

main.go:55 0x213f 4883f900 CMPQ $0x0, CX
main.go:55 0x2143 0f8601020000 JBE 0x234a
main.go:55 0x2149 4883f901 CMPQ $0x1, CX
main.go:55 0x214d 0f86f7010000 JBE 0x234a
main.go:55 0x2153 4883f902 CMPQ $0x2, CX
main.go:55 0x2157 0f86ed010000 JBE 0x234a
main.go:55 0x215d 4883f903 CMPQ $0x3, CX
main.go:55 0x2161 0f86e3010000 JBE 0x234a
main.go:55 0x2167 8b0a MOVL 0(DX), CX

obviously 1 bound check (for a[3]) would be sufficient in this case.

Generically speaking, if the code is accessing values 1..n of a slice (in
linear code or in a loop), a single bound check (for n) at the beginning
should be sufficient, but that of course brings the question that the
program would mutate the observable behavior of when exactly the panic is
generated. I'm not sure what the guarantees are on this respect. The
alternative is asking the programmer to add an explicit bound check + panic
before the loop to optimize it; similar to LLVM's __builtin_assume, in a
way.

Giovanni Bajo

On Thursday, March 10, 2016 at 7:21:52 PM UTC+1, 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 <giovan...@gmail.com
<javascript:>>:
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+...@googlegroups.com <javascript:>.
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 | 7 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