EM_ASM in gl.c loses its argument when compiling with LLVM wasm backend

[dschuff]

system/lib/gl.c has an EM_ASM at the end: https://github.com/kripken/emscripten/blob/6dc4ac5f9e4d8484e273e4dcc554f809738cedd6/system/lib/gl.c#L1731
When building with upstream clang with the wasm backend, it doesn't work properly (when tested with BananaBread) and needs to be commented out.
Previously @jgravelle-google said it wasn't getting the correct IR in clang.

[dschuff]

When I compile with
src/work/wasm-install/emscripten/emcc --em-config src/work/wasm-install/emscripten_config_vanilla src/work/emscripten/system/lib/gl.c -c -emit-llvm -o glc.ll -S
I get the following IR:

if.end877:                                        ; preds = %if.end876
  %188 = load i8*, i8** %name_.addr, align 4
  %189 = load i8*, i8** %name, align 4
  %call878 = call i32 bitcast (i32 (...)* @emscripten_asm_const_int to i32 (i8*, i8*, i8*)*)(i8* getelementptr inbounds ([102 x i8], [102 x i8]* @.str.177, i32 0, i32 0), i8* %188, i8* %189)
  store i8* null, i8** %retval, align 4
  br label %return

[juj]

I saw a similar thing when I recently had to expand the family of EM_ASM functions in order to allow specifying a thread context to run the JS code block in. The change looks like this: juj/emscripten-fastcomp@5a4f21c. See the whole PR here: emscripten-core/emscripten-fastcomp#196. Not sure if that's at all related, but the effect I saw without the above commit was that the function parameters to EM_ASM functions were not getting through. Perhaps there is that kind of NaCl fork specific change that the wasm upstream also needs?

[jgravelle-google]

I was wrong earlier about it being wrong IR from clang, turns out it's due to Wasm's FastISel turning this call(bitcast) pattern into a call_indirect, which bewilders s2wasm's EM_ASM handling, causing asserts and sadness.

The problem isn't related to gl.c, but is triggered by it by being a .c file (so it uses function bitcasting of a single emscripten_asm_const_int function, instead of C++'s template overloading, see https://github.com/kripken/emscripten/blob/4f5676132be06d56dd908c4c356887eb9aaa9c05/system/include/emscripten/em_asm.h), compiled with -O0

A related question is why we build the GL library as -O0?

[jgravelle-google]

Fixed in https://reviews.llvm.org/D37073