This unfinished CL lowers away bitconverts between vector
types in the common case but exposes some hairy stackification issues
when v2i64 and v2f64 are not enabled.
Details
Diff Detail
- Repository
- rL LLVM
- Build Status
Buildable 22072 Build 22072: arc lint + arc unit
Event Timeline
lib/Target/WebAssembly/WebAssemblyRegStackify.cpp | ||
---|---|---|
569 | @aardappel This solution for the problem described in the comment fixes my own test, but causes crashes in the stackification tests. I assume this function is doing other work besides creating a TEE that cannot be skipped. Could you suggest a more robust way to fix this problem? |
lib/Target/WebAssembly/WebAssemblyRegStackify.cpp | ||
---|---|---|
569 | (We talked in person and I'm gonna summarize it here) |
lib/Target/WebAssembly/WebAssemblyRegStackify.cpp | ||
---|---|---|
569 | Yes, we'd really want to avoid checks like this, as disabling the explicit locals is something pretty hacky we only do to keep current tests happy. I think the easiest solution is to convert the affected test to work with explicit locals? |
lib/Target/WebAssembly/WebAssemblyRegStackify.cpp | ||
---|---|---|
569 | Would it be useful to convert the tests to work with explicit locals or is there some other benefit to disabling them? |
lib/Target/WebAssembly/WebAssemblyRegStackify.cpp | ||
---|---|---|
569 | Yes, that is generally useful, we'd like to move to a world where there is as little use of this flag (and --wasm-keep-registers) as possible, with the exception maybe of test that specifically are about the handling of locals and registers in IR. |
@aardappel This solution for the problem described in the comment fixes my own test, but causes crashes in the stackification tests. I assume this function is doing other work besides creating a TEE that cannot be skipped. Could you suggest a more robust way to fix this problem?