[WebAssembly] llc crashed at -O1/O2/O3 and triggered assertion "!WebAssembly::isArgument(MI.getOpcode())"

[XChy]

Reproducer: https://godbolt.org/z/5zY4esjsK
Testcase:

target datalayout = "e-m:e-p:32:32-p10:8:8-p20:8:8-i64:64-i128:128-n32:64-S128-ni:1:10:20"
target triple = "wasm32-unknown-wasi"

define i32 @func_70(ptr %spec.select) {
entry:
  br label %BS_LABEL_1

BS_LABEL_1:                                       ; preds = %BS_LABEL_1, %entry
  %l_127.0 = phi ptr [ undef, %entry ], [ %spec.select, %BS_LABEL_1 ]
  store i32 0, ptr %l_127.0, align 4
  callbr void asm sideeffect "", "!i"()
          to label %asm.fallthrough [label %BS_LABEL_1]

asm.fallthrough:                                  ; preds = %BS_LABEL_1
  ret i32 0
}

llc output:

llc: /root/llvm-project/llvm/lib/Target/WebAssembly/WebAssemblyExplicitLocals.cpp:288: virtual bool {anonymous}::WebAssemblyExplicitLocals::runOnMachineFunction(llvm::MachineFunction&): Assertion `!WebAssembly::isArgument(MI.getOpcode())' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace and instructions to reproduce the bug.
Stack dump:
0.	Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/llc -o /app/output.s -x86-asm-syntax=intel -O1 <source>
1.	Running pass 'Function Pass Manager' on module '<source>'.
2.	Running pass 'WebAssembly Explicit Locals' on function '@func_70'
 #0 0x00000000041966e8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x41966e8)
 #1 0x0000000004193594 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
 #2 0x000079e31e642520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
 #3 0x000079e31e6969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
 #4 0x000079e31e642476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
 #5 0x000079e31e6287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
 #6 0x000079e31e62871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
 #7 0x000079e31e639e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
 #8 0x0000000002166ac7 (anonymous namespace)::WebAssemblyExplicitLocals::runOnMachineFunction(llvm::MachineFunction&) WebAssemblyExplicitLocals.cpp:0:0
 #9 0x000000000307cb79 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0
#10 0x00000000036cac96 llvm::FPPassManager::runOnFunction(llvm::Function&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x36cac96)
#11 0x00000000036cb041 llvm::FPPassManager::runOnModule(llvm::Module&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x36cb041)
#12 0x00000000036cb8af llvm::legacy::PassManagerImpl::run(llvm::Module&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x36cb8af)
#13 0x00000000008f93c3 compileModule(char**, llvm::LLVMContext&) llc.cpp:0:0
#14 0x00000000007c6a16 main (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x7c6a16)
#15 0x000079e31e629d90 (/lib/x86_64-linux-gnu/libc.so.6+0x29d90)
#16 0x000079e31e629e40 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e40)
#17 0x00000000008ee805 _start (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x8ee805)
Program terminated with signal: SIGSEGV
Compiler returned: 139

[llvmbot]

@llvm/issue-subscribers-backend-webassembly

Author: Hongyu Chen (XChy)

Reproducer: https://godbolt.org/z/5zY4esjsK Testcase: ```llvm target datalayout = "e-m:e-p:32:32-p10:8:8-p20:8:8-i64:64-i128:128-n32:64-S128-ni:1:10:20" target triple = "wasm32-unknown-wasi"

define i32 @func_70(ptr %spec.select) {
entry:
br label %BS_LABEL_1

BS_LABEL_1: ; preds = %BS_LABEL_1, %entry
%l_127.0 = phi ptr [ undef, %entry ], [ %spec.select, %BS_LABEL_1 ]
store i32 0, ptr %l_127.0, align 4
callbr void asm sideeffect "", "!i"()
to label %asm.fallthrough [label %BS_LABEL_1]

asm.fallthrough: ; preds = %BS_LABEL_1
ret i32 0
}

llc output:

llc: /root/llvm-project/llvm/lib/Target/WebAssembly/WebAssemblyExplicitLocals.cpp:288: virtual bool {anonymous}::WebAssemblyExplicitLocals::runOnMachineFunction(llvm::MachineFunction&): Assertion `!WebAssembly::isArgument(MI.getOpcode())' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace and instructions to reproduce the bug.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/llc -o /app/output.s -x86-asm-syntax=intel -O1 <source>

1. Running pass 'Function Pass Manager' on module '<source>'.
2. Running pass 'WebAssembly Explicit Locals' on function '@func_70'
   #0 0x00000000041966e8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x41966e8)
   #1 0x0000000004193594 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
   #2 0x000079e31e642520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
   #3 0x000079e31e6969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
   #4 0x000079e31e642476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
   #5 0x000079e31e6287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
   #6 0x000079e31e62871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
   #7 0x000079e31e639e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
   #8 0x0000000002166ac7 (anonymous namespace)::WebAssemblyExplicitLocals::runOnMachineFunction(llvm::MachineFunction&) WebAssemblyExplicitLocals.cpp:0:0
   #9 0x000000000307cb79 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0
   #10 0x00000000036cac96 llvm::FPPassManager::runOnFunction(llvm::Function&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x36cac96)
   #11 0x00000000036cb041 llvm::FPPassManager::runOnModule(llvm::Module&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x36cb041)
   #12 0x00000000036cb8af llvm::legacy::PassManagerImpl::run(llvm::Module&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x36cb8af)
   #13 0x00000000008f93c3 compileModule(char**, llvm::LLVMContext&) llc.cpp:0:0
   #14 0x00000000007c6a16 main (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x7c6a16)
   #15 0x000079e31e629d90 (/lib/x86_64-linux-gnu/libc.so.6+0x29d90)
   #16 0x000079e31e629e40 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e40)
   #17 0x00000000008ee805 _start (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x8ee805)
   Program terminated with signal: SIGSEGV
   Compiler returned: 139

</details>

[dschuff]

The proximate cause here: after isel we have:

# *** IR Dump After WebAssembly Instruction Selection (wasm-isel) ***:
# Machine code for function func_70: IsSSA, TracksLiveness
Function Live Ins: $arguments
bb.0.entry:
  successors: %bb.1(0x80000000); %bb.1(100.00%)
  liveins: $arguments
  %2:i32 = IMPLICIT_DEF
  %1:i32 = ARGUMENT_i32 0, implicit $arguments

bb.1.BS_LABEL_1 (inlineasm-br-indirect-target):
; predecessors: %bb.0, %bb.1
  successors: %bb.2(0x80000000), %bb.1(0x00000000); %bb.2(100.00%), %bb.1(0.00%)

  %0:i32 = PHI %2:i32, %bb.0, %1:i32, %bb.1
  %3:i32 = CONST_I32 0, implicit-def dead $arguments
  STORE_I32_A32 0, 0, %0:i32, killed %3:i32, implicit-def dead $arguments :: (store (s32) into %ir.l_127.0)
  INLINEASM_BR &"" [sideeffect] [attdialect], $0:[imm], %bb.1
  BR %bb.2, implicit-def dead $arguments

bb.2.asm.fallthrough:
; predecessors: %bb.1

  %4:i32 = CONST_I32 0, implicit-def dead $arguments
  RETURN killed %4:i32, implicit-def dead $arguments

later the IMPLICIT_DEF is removed:

# *** IR Dump After Process Implicit Definitions (processimpdefs) ***:
# Machine code for function func_70: IsSSA, TracksLiveness
Function Live Ins: $arguments

bb.0.entry:
  successors: %bb.1(0x80000000); %bb.1(100.00%)
  liveins: $arguments
  %1:i32 = ARGUMENT_i32 0, implicit $arguments
...

But then later phi node elimination adds another:

# *** IR Dump After Eliminate PHI nodes for register allocation (phi-node-elimination) ***:
# Machine code for function func_70: NoPHIs, TracksLiveness
Function Live Ins: $arguments

bb.0.entry:
  successors: %bb.1(0x80000000); %bb.1(100.00%)
  liveins: $arguments
  %5:i32 = IMPLICIT_DEF
  %1:i32 = ARGUMENT_i32 0, implicit killed $arguments

WebAssemblyExplicitLocals removes the ARGUMENT pseudoinstructions before it runs. But it assumes that the ARGUMENTs are the first instructions in the entry block, and here we have the IMPLICIT_DEF first, so the loop bails out early, and then the later assertion that there are no ARGUMENTs fails.

It's not yet clear to me why phi elimination is adding implicit defs here when we have callbr and in no other existing cases.

But that does raise another deeper point: why callbr in the first place? That's only for implementing asm goto and I'm having trouble imagining what the use case would be for that in WebAssembly. I would not really expect it to "just work" given WebAssembly's structured control flow. Given that it looks like the control flow is explicitly modeled by callbr maybe it's something we could fix, but is it worth it? What are you trying to compile?

[XChy]

But that does raise another deeper point: why callbr in the first place? That's only for implementing asm goto and I'm having trouble imagining what the use case would be for that in WebAssembly. I would not really expect it to "just work" given WebAssembly's structured control flow. Given that it looks like the control flow is explicitly modeled by callbr maybe it's something we could fix, but is it worth it? What are you trying to compile?

Thanks for your effort and response. This reduced testcase is generated by a C fuzzer. AFAIK, asm goto is a common feature in embedded scenarios and exists in Linux kernel code. I understand that the WASM backend does not support asm goto, as WASM may not be used in these scenarios. As for callbr, it may not be only for asm goto, but also some selected intrinsics in the future, see also #133907.
Generally, I expect a valid C program can be correctly compiled or report an "unsupported" error in any backend, instead of just crashing. I hope this bug report doesn't make you uncomfortable. If you do not plan to support callbr in the future, I will disable the asm-goto feature in the fuzzer and stop reporting bugs related to callbr.

[dschuff]

Thanks for your effort and response. This reduced testcase is generated by a C fuzzer. AFAIK, asm goto is a common feature in embedded scenarios and exists in Linux kernel code. I understand that the WASM backend does not support asm goto, as WASM may not be used in these scenarios.

This is my understanding too, hence the pushback. My concern is that, while it might be easy enough to maybe fix the phase ordering problem or make WebAssemblyExplicitlLocals handle the case we see here, without a real use case we still wouldn't really know whether the feature actually works.

As for callbr, it may not be only for asm goto, but also some selected intrinsics in the future, see also #133907. Generally, I expect a valid C program can be correctly compiled or report an "unsupported" error in any backend, instead of just crashing.

I agree, and in this case if we aren't going to fix it in the near term we should at least surface an error rather than crashing. Although pedantically I would say that asm goto is not actually a "valid C program" but a C extension that Wasm doesn't currently support.

I hope this bug report doesn't make you uncomfortable. If you do not plan to support callbr in the future, I will disable the asm-goto feature in the fuzzer and stop reporting bugs related to callbr.

No discomfort :) But I also don't think it's worth putting in the effort to fully support callbr until we have a real use case that we can test. That could be some case where asm goto makes sense, or some intrinsic that we want to support. I think for now we should file a bug to track it that users could find and request callbr support, and we should report an error rather than crashing.

[dschuff]

I filed #166977. I'll keep this bug open until we add an error message.