cmd/compile: elide sign-extend after zero-extend for wasm

Add rules to eliminate sign-extension of values that have already
been zero-extended from fewer bits via an I64And mask:

  (I64Extend32S x:(I64And _ (I64Const [c]))) && c >= 0 && int64(int32(c)) == c => x
  (I64Extend16S x:(I64And _ (I64Const [c]))) && c >= 0 && int64(int16(c)) == c => x
  (I64Extend8S  x:(I64And _ (I64Const [c]))) && c >= 0 && int64(int8(c))  == c => x

When a value has been masked to fit within the non-negative range of
the sign-extension width, the upper bits are already zero and sign-
extending is a no-op. For example, (I64Extend32S (I64And x 0xff))
can be elided because 0xff fits in a signed int32, so bit 31 is
guaranteed to be zero and sign-extending from 32 bits is identity.

Cq-Include-Trybots: luci.golang.try:gotip-wasip1-wasm_wasmtime,gotip-wasip1-wasm_wazero
Change-Id: Ia54d67358756e47ca7635a6a8ca4beadb003820a
Reviewed-on: https://go-review.googlesource.com/c/go/+/756320
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>

0 files changed, 0 insertions, 0 deletions