cmd/compile: fix CSE with commutative ops

CSE opportunities were being missed for commutative ops. We used to
order the args of commutative ops (by arg ID) once at the start of CSE.
But that may not be enough.

i1 = (Load ptr mem)
i2 = (Load ptr mem)
x1 = (Add i1 j)
x2 = (Add i2 j)

Equivalent commutative ops x1 and x2 may not get their args ordered in
the same way because because at the start of CSE, we don't know that
the i values will be CSEd. If x1 and x2 get opposite orders we won't
CSE them.

Instead, (re)order the args of commutative operations by their
equivalence class IDs each time we partition an equivalence class.

Change-Id: Ic609fa83b85299782a5e85bf93dc6023fccf4b0c
Reviewed-on: https://go-review.googlesource.com/33632
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Todd Neal <todd@tneal.org>

1 files changed, 14 insertions, 1 deletions

diff --git a/test/prove.go b/test/prove.go
index 9ced6166e0..9ef8949e1c 100644
--- a/test/prove.go
+++ b/test/prove.go
@@ -273,7 +273,7 @@ func f11c(a []int, i int) {
 
 func f11d(a []int, i int) {
 	useInt(a[2*i+7])
-	useInt(a[2*i+7])
+	useInt(a[2*i+7]) // ERROR "Proved boolean IsInBounds$"
 }
 
 func f12(a []int, b int) {
@@ -438,6 +438,19 @@ func f13i(a uint) int {
 	return 3
 }
 
+func f14(p, q *int, a []int) {
+	// This crazy ordering usually gives i1 the lowest value ID,
+	// j the middle value ID, and i2 the highest value ID.
+	// That used to confuse CSE because it ordered the args
+	// of the two + ops below differently.
+	// That in turn foiled bounds check elimination.
+	i1 := *p
+	j := *q
+	i2 := *p
+	useInt(a[i1+j])
+	useInt(a[i2+j]) // ERROR "Proved boolean IsInBounds$"
+}
+
 //go:noinline
 func useInt(a int) {
 }