Related Issues

• cmd/compile: BCE optimizes less for string than slice #27585
• cmd/compile: missing BCE case #41335
• cmd/compile: generic functions are significantly slower than identical non-generic functions in some cases #50182 (closed)
• cmd/compile: missed trivial bound check elimination #66826 (closed)
• cmd/compile: missed BCE in multi expression switch cases #67329 (closed)
• cmd/compile: unnecessary bounds check in a loop passed as a closure #39756
• cmd/compile: Improve BCE when using positive int as slice index #28885 (closed)
• cmd/compile: bounds check not removed after "if index < length" #15074 (closed)
• cmd/compile: gcflags="-d=ssa/check_bce" doesn't work or doesn't work well for generic functions #58139 (closed)
• cmd/compile: BCE does not take transitivity into account #19714 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

I think that's just a line numbering problem. There are bounds checks in all the examples.
(Look for panicIndex calls.)

@randall77 There are bounds checks in all examples, but (unless I'm missing something) double the amount in the string version. Search for "panicindex" on godbolt:

• 4 hits for the int version;
• 8 hits for the string version.

Ah, ok, I see it now. Somehow the bounds checks in the loop condition are not making the bounds checks in the swap line redundant.

I suspect this has something to do with the cmpstring call that's needed for string <.

Note this has nothing to do with generics, replacing E with string shows the same behavior.

Here's a simpler reproducer:

package p

func f(x []string, i int, b bool) {
	if b && x[i] < "foo" {
		x[i] = "bar"
	}
}

This has 2 bounds checks. Remove b && and it has only one.

@randall77 Thanks! Glad I'm not hallucinating. 😌

By looking at the discussion, this looks like WAI, closing.

Edit: 😰 I am very sorry for closing without evaluating thoroughly... Yesterday I closed this issue because I was thinking maybe the "<" comparator(if internally it was implemented as a function) is "inlined" there, so that the bounds check of string comparison appears in line 10. But @randall77's comment confirm that when collocated with other conditions, the behavior of string comparison will have issues with BCE.

Thanks for @as and @mvdan to reopen this. 👍

@JunyangShao What? No...

Edit: Even though the problem appears unrelated to generics, this issue could be re-purposed to track down those spurious bounds checks (confirmed by @randall77 in #72132 (comment)). I'm not aware of any open issue about that.

Please reopen the issue at this time.

I printed out @randall77 's example in SSA and find out that the fact runtime.cmpstring not being considered pure might be the cause of this redundant check:

Here to select the 3 different memory states for the return block caused by the 2 string comparisons, b2 is created and decouples b7 from the dominance relation from b4. We can still statically infer that whenever b2->b7 is taken, the memory state will always be v22 when entering b4. But the fact that b6 needs knowledge of the memory state along different control flow paths makes it impossible to decouple b2 from b7, because for the same condition value we cannot have two successor blocks in SSA.

Maybe some other analysis is needed in the prove pass that looks outside the dominance tree.

Change https://go.dev/cl/656255 mentions this issue: cmd/compile: match more patterns for shortcircuit