Potentially wrong SIMD opcode generation in 0.17.2

[postspectacular]

Hi all, I'm not sure if that's related to the recent Binaryen updates in 0.17.2, but the following code (which compiles just fine w/ all recent assemblyscript versions < 0.17.2) is now causing a validation error during compile and seemingly produces the wrong SIMD opcodes to begin with:

https://github.com/thi-ng/umbrella/blob/develop/packages/simd/assembly/abs.ts#L12

export function abs4_f32(
    out: usize,
    a: usize,
    num: usize,
    so: usize,
    sa: usize
): usize {
    so <<= 2;
    sa <<= 2;
    const res = out;
    for (; num-- > 0; ) {
        v128.store(out, f32x4.abs(v128.load(a)));
        out += so;
        a += sa;
    }
    return res;
}

[wasm-validator error in function assembly/abs/abs4_f32] i32 != v128: store value type must match, on 
[none] (v128.store
 [i32] (local.get $0)
 [i32] (i64x2.all_true
  [v128] (v128.load
   [i32] (local.get $1)
  )
 )
)
FAILURE validate error
    at Object.main (/Users/thing/umbrella/node_modules/assemblyscript/cli/asc.js:735:23)
    at /Users/thing/umbrella/node_modules/assemblyscript/bin/asc:21:47

Where is that i64x2.all_true op coming from here? Should be f32x4.abs...

[dcodeIO]

Indeed looks like another renumbering took place there and we missed to update the constants. cc @MaxGraey

[MaxGraey]

I think we should update constants every time after update binaryen. @dcodeIO could you remind me about this during review?

[dcodeIO]

I guess we could build a test case that compares the constants somehow :)

[postspectacular]

Thank you both! Is that maybe something which could be semi-automated via a little dev tool? I'm assuming those constants are retrieved from somewhere in the Binaryen codebase. Want me to look into it? If so, can you please provide some more pointers, i.e. which files & enums should be considered for syncing...

[dcodeIO]

The script responsible for updating the constants is https://github.com/AssemblyScript/assemblyscript/blob/master/scripts/update-constants.js

Perhaps it could provide a --check option that doesn't update, but just compares, yielding an error with a non zero exit code on mismatch. Would then be easy to integrate into CI :)