cmd/compile: fix ordering for short-circuiting ops

Make sure the side effects inside short-circuited operations (&& and ||)
happen correctly.

Before this CL, we attached the side effects to the node itself using
exprInPlace. That caused other side effects in sibling expressions
to get reordered with respect to the short circuit side effect.

Instead, rewrite a && b like:

r := a
if r {
  r = b
}

That code we can keep correctly ordered with respect to other
side-effects extracted from part of a big expression.

exprInPlace seems generally unsafe. But this was the only case where
exprInPlace is called not at the top level of an expression, so I
don't think the other uses can actually trigger an issue (there can't
be a sibling expression). TODO: maybe those cases don't need "in
place", and we can retire that function generally.

This CL needed a small tweak to the SSA generation of OIF so that the
short circuit optimization still triggers. The short circuit optimization
looks for triangle but not diamonds, so don't bother allocating a block
if it will be empty.

Go 1 benchmarks are in the noise.

Fixes #30566

Change-Id: I19c04296bea63cbd6ad05f87a63b005029123610
Reviewed-on: https://go-review.googlesource.com/c/go/+/165617
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>

1 files changed, 1 insertions, 3 deletions

diff --git a/test/checkbce.go b/test/checkbce.go
index a8f060aa72..6a126099bc 100644
--- a/test/checkbce.go
+++ b/test/checkbce.go
@@ -33,9 +33,7 @@ func f1(a [256]int, i int) {
 
 	if 4 <= i && i < len(a) {
 		useInt(a[i])
-		useInt(a[i-1]) // ERROR "Found IsInBounds$"
-		// TODO: 'if 4 <= i && i < len(a)' gets rewritten to 'if uint(i - 4) < 256 - 4',
-		// which the bounds checker cannot yet use to infer that the next line doesn't need a bounds check.
+		useInt(a[i-1])
 		useInt(a[i-4])
 	}
 }