Rename __invoke_* functions in wasm backend?

[kripken]

Currently wasm-emscripten-finalize finds functions starting with __invoke_ and renames them. This is for asm.js-style C++ exceptions and longjmp support. The renaming is important because the type in the wasm is the LLVM IR type, as this comment from wasm-emscripten.cpp says:

  // LLVM backend lowers
  //   invoke @func(arg1, arg2) to label %invoke.cont unwind label %lpad
  // into
  // ... (some code)
  //   call @invoke_SIG(func, arg1, arg2)
  // ... (some code)
  // SIG is a mangled string generated based on the LLVM IR-level function
  // signature. In LLVM IR, types are not lowered yet, so this mangling scheme
  // simply takes LLVM's string representtion of parameter types and concatenate
  // them with '_'. For example, the name of an invoke wrapper for function
  // void foo(struct mystruct*, int) will be
  // "__invoke_void_%struct.mystruct*_int".
  // This function converts the names of invoke wrappers based on their lowered
  // argument types and a return type. In the example above, the resulting new
  // wrapper name becomes "invoke_vii".

So there can be many invokes with different IR names that turn into the same invoke on wasm types. The ratio can be very large, for example all LLVM IR pointers (i32*, mystruct*, etc.) would get a different name in IR, but all we need in wasm is an i32 for them.

In #3043 we are working to remove the work done in wasm-emscripten-finalize, so we'd like to remove this. We could support all the invokes in emscripten directly, but the large number would be a significant regression in debug builds (where we don't do anything after link). Instead, could we rename them in the wasm backend? That is, I think I understand what that comment says about using LLVM IR types, as the emscripten-exceptions and -longjmp passes are on LLVM IR. But could we add a backend pass that renames them?

(The names don't need to match anything - it can be any naming scheme whatsoever. The only goal is to avoid one invoke per LLVM IR type, it's that amount that is the problem.)

cc @aheejin @tlively

[tlively]

Yes, I think this should be possible. What does wasm-emscripten-finalize rename them to? And what motivates the renaming?

[kripken]

The motivation is just the numbers issue - to have as few as possible. The number can get really out of hand, e.g. hello world with c++ iostreams with exceptions enabled has 177 invokes (many with long names like __invoke_%"class.std::runtime_error"*_%"class.std::runtime_error"*_%"class.std::__2::basic_string"* that bloat the binary), but after wasm-emscripten-finalize it's just 22.

The concrete renaming used atm is vii, ijdi etc. as in emscripten in general, where the first is v=void or the return type, and the others are i=i32, j=i64, f=f32, d=f64. It might be nice to do the same in the backend just to avoid confusion (but if there's something easier, any naming scheme would be fine, we'll be looking at the types and not the name).

[tlively]

I see thanks. This would probably be a good time to switch to a naming convention that can handle multivalue functions as well. Although my guess is that actually supporting multivalue would require additional upstream changes.

[aheejin]

Those names are generated in LowerEmscriptenEHSjLj pass in LLVM, but that pass is an IR pass and we don't know the final lowered types yet, so I guess as @kripken said we need a new backend pass.

The current naming scheme assumes the first character to be a return type, but this might have to change in the presence of multivalue. I guess we can delimit the return type and param types with an additional _. For example, if a function takes a multivalue type (i32, i32) and returns i32 and i64, the function name can be something like __invoke_ii_ij.

@tlively, what additional upstream change do you think needs to happen?

(I rewrote this comment. Please ignore the comment I posted and deleted 10 mins ago)

[kripken]

Note that this itself could maybe be a backend pass that assumes multivalue is not enabled, since we could just say that fastcomp-style exceptions and longjmp don't support multivalue (but new wasm exceptions support would work with multivalue - and not need this pass).

[tlively]

@aheejin, I don't know of any particular upstream changes that would be necessary, but I also don't know that it would already work with multivalue, so I was just being cautious. I think @kripken is right though that we probably don't need to support multivalue here.

[kripken]

It looks like this LLVM change will soon be the last item blocking #3043, which blocks wasm debugging. We were hoping to get that done by the end of September. There's almost a whole month left, so no rush, but please let me know if that's not realistic.

[aheejin]

Closed by

• llvm/llvm-project@3bba91f
• llvm/llvm-project@750b3dd
• Rename Emscripten EHSjLj functions in wasm backend #3191
• Let GenerateDynCalls generate dynCalls for invokes #3192
• Don't run binaryen postprocessing for Emscripten EH/SjLj emscripten-core/emscripten#12399
• Add deps info for emscripten_longjmp emscripten-core/emscripten#12456