Use IRBuilder in the binary parser (#6963)

IRBuilder is a utility for turning arbitrary valid streams of Wasm
instructions into valid Binaryen IR. It is already used in the text
parser, so now use it in the binary parser as well. Since the IRBuilder
API for building each intruction requires only the information that the
binary and text formats include as immediates to that instruction, the
parser is now much simpler than before. In particular, it does not need
to manage a stack of instructions to figure out what the children of
each expression should be; IRBuilder handles this instead.

There are some differences between the IR constructed by IRBuilder and
the IR the binary parser constructed before this change. Most
importantly, IRBuilder generates better multivalue code because it
avoids eagerly breaking up multivalue results into individual components
that might need to be immediately reassembled into a tuple. It also
parses try-delegate more correctly, allowing the delegate to target
arbitrary labels, not just other `try`s. There are also a couple
superficial differences in the generated label and scratch local names.

As part of this change, add support for recording binary source
locations in IRBuilder.

1 files changed, 8 insertions, 8 deletions

diff --git a/test/lit/binary/dwarf-multivalue.test b/test/lit/binary/dwarf-multivalue.test
index c803dea14..250a861bf 100644
--- a/test/lit/binary/dwarf-multivalue.test
+++ b/test/lit/binary/dwarf-multivalue.test
@@ -39,8 +39,8 @@
 ;;  (local $10 f32)
 
 ;; If we parse this wasm file into Binaryen IR, two locals are added in the
-;; process. Here $11 is added for tuple parsing and $12 is added for stacky IR
-;; resolving during binary reading process.
+;; process. Here $scratch is added for tuple parsing and $scratch_12 is added
+;; for stacky IR resolving during binary reading process.
 ;; RUN: wasm-dis %s.wasm -o - | filecheck %s --check-prefix=ORIG
 ;; ORIG:      (func $test
 ;; ORIG-NEXT:  (local $0 i32)
@@ -54,8 +54,8 @@
 ;; ORIG-NEXT:  (local $8 f32)
 ;; ORIG-NEXT:  (local $9 i32)
 ;; ORIG-NEXT:  (local $10 f32)
-;; ORIG-NEXT:  (local $11 (tuple i32 f32))
-;; ORIG-NEXT:  (local $12 i32)
+;; ORIG-NEXT:  (local $scratch (tuple i32 f32))
+;; ORIG-NEXT:  (local $scratch_12 i32)
 
 ;; If we write this IR into binary, even if this cannot be displayed in the wast
 ;; format, the local order of $test will look like this, because we don't
@@ -92,11 +92,11 @@
 ;; ROUNDTRIP-NEXT:  (local $8 f32)
 ;; ROUNDTRIP-NEXT:  (local $9 i32)
 ;; ROUNDTRIP-NEXT:  (local $10 f32)
-;; ROUNDTRIP-NEXT:  (local $11 i32)
+;; ROUNDTRIP-NEXT:  (local $scratch i32)
 ;; ROUNDTRIP-NEXT:  (local $12 f32)
-;; ROUNDTRIP-NEXT:  (local $13 i32)
-;; ROUNDTRIP-NEXT:  (local $14 (tuple i32 f32))
-;; ROUNDTRIP-NEXT:  (local $15 i32)
+;; ROUNDTRIP-NEXT:  (local $scratch_12 i32)
+;; ROUNDTRIP-NEXT:  (local $scratch_14 (tuple i32 f32))
+;; ROUNDTRIP-NEXT:  (local $scratch_15 i32)
 
 ;; We can see that we don't reorder the locals during the process and the
 ;; original list of locals, local $0~$10, is untouched, to NOT invalidate DWARF