Issue |
81575
|
Summary |
[WebAssembly] Problems of forcing mem2reg in reference-types
|
Labels |
new issue
|
Assignees |
|
Reporter |
aheejin
|
I recently noticed that we force mem2reg optimization to run unconditionally, even in `-O0`, when reference-types feature is enabled:
https://github.com/llvm/llvm-project/blob/2dd52046816ac706a25d588efac77705793d8778/llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp#L479-L482
This was added in https://github.com/llvm/llvm-project/commit/890146b19206827bc48ee1ae1dc1534ff2ff18d7.
I think this can have some problems:
1. This means we run some optimizations even when we are not supposed to. We will handle debug value differently and debug info can be lost even in `-O0`, if reference-types is enabled. And the newest EH spec requires reference-types to be enabled, so this means enabling EH means running some optimizations even in `-O0`. Also, as it happens, we've been even discussing enabling reference-types by default. (#80923) It'd be good if there's a way to promote only reference type values to registers.
2. When Wasm EH is used, we [demote](https://github.com/llvm/llvm-project/blob/85e6e71eb09cb9e75bbd475e5f54f876653c3f16/llvm/lib/CodeGen/WinEHPrepare.cpp#L858-L887) certain PHIs from registers to memory in `WinEHPrepare`. (Wasm EH uses WinEHPrepare pass, because it uses WinEH IR) Specifically, we cannot have a PHI before a `catchswitch`. PHIs in `catchswitch` BBs have to be removed (= demoted) because `catchswitch`s are removed in ISel and `catchswitch` BBs are removed as well, so they can't have other instructions. But when reference-types is enabled, we [force](https://github.com/llvm/llvm-project/blob/2dd52046816ac706a25d588efac77705793d8778/llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp#L479-L482) to run mem2reg in `addISelPrepare`, which runs after `WinEHPrepare`, re-promoting the demoted PHIs in `WinEHPrepare`, which crashes the compiler. This is a problem even if we have a way to promote only reference types because they can be before a `catchswitch` too.
Any thoughts or ideas?
cc @pmatos
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs