| ;; Test that we handle multivalue + DWARF correctly. When we need to preserve | |
| ;; DWARF info, we don't do any local reordering and all newly added locals | |
| ;; during parsing/writing are added at the end of the local list. | |
| ;; Generated from this c file with the following command: | |
| ;; $ emcc -g -Xclang -target-abi -Xclang experimental-mv dwarf-multivalue.c -o dwarf-multivalue.wasm | |
| ;; | |
| ;; struct MyStruct { | |
| ;; int a; | |
| ;; float b; | |
| ;; }; | |
| ;; | |
| ;; struct MyStruct foo() { | |
| ;; struct MyStruct ret = {.a = 3, .b = 3.5}; | |
| ;; return ret; | |
| ;; } | |
| ;; | |
| ;; void test() { | |
| ;; struct MyStruct s = foo(); | |
| ;; } | |
| ;; | |
| ;; int main() { | |
| ;; test(); | |
| ;; return 0; | |
| ;; } | |
| ;; The original wasm file's $test function's locals are as follows: | |
| ;; (func $test | |
| ;; (local $0 i32) | |
| ;; (local $1 i32) | |
| ;; (local $2 i32) | |
| ;; (local $3 i32) | |
| ;; (local $4 f32) | |
| ;; (local $5 i32) | |
| ;; (local $6 i32) | |
| ;; (local $7 i32) | |
| ;; (local $8 f32) | |
| ;; (local $9 i32) | |
| ;; (local $10 f32) | |
| ;; If we parse this wasm file into Binaryen IR, two locals are added in the | |
| ;; 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) | |
| ;; ORIG-NEXT: (local $1 i32) | |
| ;; ORIG-NEXT: (local $2 i32) | |
| ;; ORIG-NEXT: (local $3 i32) | |
| ;; ORIG-NEXT: (local $4 f32) | |
| ;; ORIG-NEXT: (local $5 i32) | |
| ;; ORIG-NEXT: (local $6 i32) | |
| ;; ORIG-NEXT: (local $7 i32) | |
| ;; ORIG-NEXT: (local $8 f32) | |
| ;; ORIG-NEXT: (local $9 i32) | |
| ;; ORIG-NEXT: (local $10 f32) | |
| ;; 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 | |
| ;; reorder locals: | |
| ;; (func $test | |
| ;; (local $0 i32) | |
| ;; (local $1 i32) | |
| ;; (local $2 i32) | |
| ;; (local $3 i32) | |
| ;; (local $4 f32) | |
| ;; (local $5 i32) | |
| ;; (local $6 i32) | |
| ;; (local $7 i32) | |
| ;; (local $8 f32) | |
| ;; (local $9 i32) | |
| ;; (local $10 f32) | |
| ;; (local $11 i32) ;; Previous (local $11 (tuple i32 f32))'s first element | |
| ;; (local $12 f32) ;; Previous (local $11 (tuple i32 f32))'s second element | |
| ;; (local $13 i32) ;; Previous (local $12 i32) | |
| ;; We parse this binary again into Binaryen IR, roundtripping the original | |
| ;; binary. Locals $14 and $15 are added for stacky IR resolving during binary | |
| ;; reading process. | |
| ;; RUN: wasm-opt -all -g --roundtrip %s.wasm -S -o - | filecheck %s --check-prefix=ROUNDTRIP | |
| ;; ROUNDTRIP: (func $test | |
| ;; ROUNDTRIP-NEXT: (local $0 i32) | |
| ;; ROUNDTRIP-NEXT: (local $1 i32) | |
| ;; ROUNDTRIP-NEXT: (local $2 i32) | |
| ;; ROUNDTRIP-NEXT: (local $3 i32) | |
| ;; ROUNDTRIP-NEXT: (local $4 f32) | |
| ;; ROUNDTRIP-NEXT: (local $5 i32) | |
| ;; ROUNDTRIP-NEXT: (local $6 i32) | |
| ;; ROUNDTRIP-NEXT: (local $7 i32) | |
| ;; ROUNDTRIP-NEXT: (local $8 f32) | |
| ;; ROUNDTRIP-NEXT: (local $9 i32) | |
| ;; ROUNDTRIP-NEXT: (local $10 f32) | |
| ;; ROUNDTRIP-NEXT: (local $scratch i32) | |
| ;; ROUNDTRIP-NEXT: (local $12 f32) | |
| ;; 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 | |
| ;; info. |