[all-commits] [llvm/llvm-project] 52431f: [WebAssembly] Remove threwValue comparison after _...

[Heejin Ahn via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 52431fdb1ab8d29be078edd55250e06381e4b6b0
      https://github.com/llvm/llvm-project/commit/52431fdb1ab8d29be078edd55250e06381e4b6b0
  Author: Heejin Ahn <aheejin at gmail.com>
  Date:   2024-03-27 (Wed, 27 Mar 2024)

  Changed paths:
    M llvm/lib/Target/WebAssembly/WebAssemblyLowerEmscriptenEHSjLj.cpp
    M llvm/test/CodeGen/WebAssembly/lower-em-ehsjlj.ll
    M llvm/test/CodeGen/WebAssembly/lower-em-sjlj.ll

  Log Message:
  -----------
  [WebAssembly] Remove threwValue comparison after __wasm_setjmp_test (#86633)

Currently the code thinks a `longjmp` occurred if both `__THREW__` and
`__threwValue` are nonzero. But `__threwValue` can be 0, and the
`longjmp` library function should change it to 1 in case it is 0:
https://en.cppreference.com/w/c/program/longjmp

Emscripten libraries were not consistent about that, but after
https://github.com/emscripten-core/emscripten/pull/21493 and
https://github.com/emscripten-core/emscripten/pull/21502, we correctly
pass 1 in case the input is 0. So there will be no case `__threwValue`
is 0. And regardless of what `longjmp` library function does, treating
`longjmp`'s 0 input to its second argument as "not longjmping" doesn't
seem right.

I'm not sure where that `__threwValue` checking came from, but probably
I was porting then fastcomp's implementation and moved this part just
verbatim:
https://github.com/emscripten-core/emscripten-fastcomp/blob/9bdc7bb4fc595fe05a021b06fe350e8494a741a1/lib/Target/JSBackend/CallHandlers.h#L274-L278

Just for the context, how this was discovered:
https://github.com/emscripten-core/emscripten/pull/21502#pullrequestreview-1942160300



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications