ICE: error in backend: unable to legalize instruction: %72:_(s32) = G_FCMP floatpred(ult)

[jseaton]

Hi, compiling this test kernel:

extern "C" {

float x = -0.1;
void uwu(float *a_in, float (*c_out)[1024]) {
  for (int i=0; i<1024; i++) {
    (*c_out)[i] = x;
    x += 0.001;
    if (x >= 0.1)
      x = -0.1;
  }
}

} // extern "C"

Results in this backtrace:

fatal error: error in backend: unable to legalize instruction: %72:_(s32) = G_FCMP floatpred(ult), %57:_(s64), %17:_ (in function: uwu)
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.	Program arguments: /home/jo/src/aie/mlir-aie/ironenv/lib/python3.13/site-packages/llvm-aie/bin/clang++ -O2 -std=c++20 --target=aie2-none-unknown-elf -c uwu.cc -o uwu.o
1.	<eof> parser at end of file
2.	Code generation
3.	Running pass 'Function Pass Manager' on module 'uwu.cc'.
4.	Running pass 'Legalizer' on function '@uwu'
 #0 0x000077289e7996bb llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/jo/src/aie/mlir-aie/ironenv/lib/python3.13/site-packages/llvm-aie/bin/../lib/libLLVM.so+0xb996bb)
 #1 0x000077289e796bc4 llvm::sys::CleanupOnSignal(unsigned long) (/home/jo/src/aie/mlir-aie/ironenv/lib/python3.13/site-packages/llvm-aie/bin/../lib/libLLVM.so+0xb96bc4)
 #2 0x000077289e68aad6 llvm::CrashRecoveryContext::HandleExit(int) (/home/jo/src/aie/mlir-aie/ironenv/lib/python3.13/site-packages/llvm-aie/bin/../lib/libLLVM.so+0xa8aad6)
 #3 0x000077289e78f95e llvm::sys::Process::Exit(int, bool) (/home/jo/src/aie/mlir-aie/ironenv/lib/python3.13/site-packages/llvm-aie/bin/../lib/libLLVM.so+0xb8f95e)
 #4 0x0000000000410225 LLVMErrorHandler(void*, char const*, bool) cc1_main.cpp:0:0
 #5 0x000077289e6a4a73 llvm::report_fatal_error(llvm::Twine const&, bool) (/home/jo/src/aie/mlir-aie/ironenv/lib/python3.13/site-packages/llvm-aie/bin/../lib/libLLVM.so+0xaa4a73)
 #6 0x000077289f792a7b llvm::reportGISelFailure(llvm::MachineFunction&, llvm::TargetPassConfig const&, llvm::MachineOptimizationRemarkEmitter&, char const*, llvm::StringRef, llvm::MachineInstr const&) (/home/jo/src/aie/mlir-aie/ironenv/lib/python3.13/site-packages/llvm-aie/bin/../lib/libLLVM.so+0x1b92a7b)
 #7 0x000077289f71354f llvm::Legalizer::runOnMachineFunction(llvm::MachineFunction&) (.part.0) Legalizer.cpp:0:0
 #8 0x000077289ed884ca llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0
 #9 0x000077289e98aa80 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/jo/src/aie/mlir-aie/ironenv/lib/python3.13/site-packages/llvm-aie/bin/../lib/libLLVM.so+0xd8aa80)
#10 0x000077289e98af51 llvm::FPPassManager::runOnModule(llvm::Module&) (/home/jo/src/aie/mlir-aie/ironenv/lib/python3.13/site-packages/llvm-aie/bin/../lib/libLLVM.so+0xd8af51)
#11 0x000077289e98b882 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/jo/src/aie/mlir-aie/ironenv/lib/python3.13/site-packages/llvm-aie/bin/../lib/libLLVM.so+0xd8b882)
#12 0x00007728a606a0e0 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr<llvm::vfs::FileSystem>, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream>>, clang::BackendConsumer*) (/home/jo/src/aie/mlir-aie/ironenv/lib/python3.13/site-packages/llvm-aie/bin/../lib/libclang-cpp.so+0x226a0e0)
#13 0x00007728a6543507 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/home/jo/src/aie/mlir-aie/ironenv/lib/python3.13/site-packages/llvm-aie/bin/../lib/libclang-cpp.so+0x2743507)
#14 0x00007728a4a24ebc clang::ParseAST(clang::Sema&, bool, bool) (/home/jo/src/aie/mlir-aie/ironenv/lib/python3.13/site-packages/llvm-aie/bin/../lib/libclang-cpp.so+0xc24ebc)
#15 0x00007728a70e2959 clang::FrontendAction::Execute() (/home/jo/src/aie/mlir-aie/ironenv/lib/python3.13/site-packages/llvm-aie/bin/../lib/libclang-cpp.so+0x32e2959)
#16 0x00007728a706323e clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/home/jo/src/aie/mlir-aie/ironenv/lib/python3.13/site-packages/llvm-aie/bin/../lib/libclang-cpp.so+0x326323e)
#17 0x00007728a717b398 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/home/jo/src/aie/mlir-aie/ironenv/lib/python3.13/site-packages/llvm-aie/bin/../lib/libclang-cpp.so+0x337b398)
#18 0x0000000000411f9a cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/home/jo/src/aie/mlir-aie/ironenv/lib/python3.13/site-packages/llvm-aie/bin/clang+++0x411f9a)
#19 0x000000000040b8ef ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&, llvm::ToolContext const&) driver.cpp:0:0
#20 0x00007728a6c147d9 void llvm::function_ref<void ()>::callback_fn<clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, bool*) const::'lambda'()>(long) Job.cpp:0:0
#21 0x000077289e68aa12 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (/home/jo/src/aie/mlir-aie/ironenv/lib/python3.13/site-packages/llvm-aie/bin/../lib/libLLVM.so+0xa8aa12)
#22 0x00007728a6c16bae clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, bool*) const (.part.0) Job.cpp:0:0
#23 0x00007728a6bd52fb clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const (/home/jo/src/aie/mlir-aie/ironenv/lib/python3.13/site-packages/llvm-aie/bin/../lib/libclang-cpp.so+0x2dd52fb)
#24 0x00007728a6bd5d5e clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&, bool) const (/home/jo/src/aie/mlir-aie/ironenv/lib/python3.13/site-packages/llvm-aie/bin/../lib/libclang-cpp.so+0x2dd5d5e)
#25 0x00007728a6be3664 clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&) (/home/jo/src/aie/mlir-aie/ironenv/lib/python3.13/site-packages/llvm-aie/bin/../lib/libclang-cpp.so+0x2de3664)
#26 0x000000000040f940 clang_main(int, char**, llvm::ToolContext const&) (/home/jo/src/aie/mlir-aie/ironenv/lib/python3.13/site-packages/llvm-aie/bin/clang+++0x40f940)
#27 0x000000000040aef3 main (/home/jo/src/aie/mlir-aie/ironenv/lib/python3.13/site-packages/llvm-aie/bin/clang+++0x40aef3)
#28 0x000077289d635488 (/usr/lib/libc.so.6+0x27488)
#29 0x000077289d63554c __libc_start_main (/usr/lib/libc.so.6+0x2754c)
#30 0x000000000040af3e _start (/home/jo/src/aie/mlir-aie/ironenv/lib/python3.13/site-packages/llvm-aie/bin/clang+++0x40af3e)
clang++: error: clang frontend command failed with exit code 70 (use -v to see invocation)
clang version 19.0.0 (https://github.com/Xilinx/llvm-aie 628b7e2035ffce0b9ece210e45061ffbd2566531)
Target: aie2-none-unknown-elf
Thread model: posix
InstalledDir: /home/jo/src/aie/mlir-aie/ironenv/lib/python3.13/site-packages/llvm-aie/bin
Build config: +assertions

This appears to be dependent on the value of x as the value 1.0 seems to be fine.

I'm aware this compiler is still very in development, are issues like this still useful?

uwu-31946e.cpp.txt
uwu-31946e.sh.txt

[jseaton]

I guess this is a consequence of G_FCMP not being implemented, and x = 1.0 gets turned into an integer compare.

[andcarminati]

Hi @jseaton, thank you for finding this issue. Actually, AIEs cannot support native 64bit fp operations. For some of them we can still use compiler_rt as libcall support. However, that is not the case for G_FCMP generic opcode (no libcall support in compiler_rt AFAIK). As a solution, I can recommend to cast all fp constants to float because they are handled as double internally, and this forces the other source operands to be extend to double as well. For example, considering the previous code, the following change should be enough:

extern "C" {

float x = -0.1;
void uwu(float *a_in, float (*c_out)[1024]) {
  for (int i=0; i<1024; i++) {
    (*c_out)[i] = x;
    x += 0.001;
    if (x >= (float) 0.1)
      x = -0.1;
  }
}

}

All 32bit support should work out-of-the-shelf.

If you see something more that deviates from the expected behavior, you are welcome to share!

[martien-de-jong]

Hi @jseaton, 1.0 is different since it can be represented exactly in both float and double, whereas .1 will lose precision when converted to float.
In general, floating point ops will frequently fall back to software emulation and will quickly exhaust program memory (16Kb per tile).

[jseaton]

Thank you both for your patience and explanations. I understand doubles are being quite expensively emulated, I have indeed been butting up against the instruction memory size!
That said, I think I have added support for this via the __ledf2 builtins and friends in comparedf2.c, if you are happy to have it (PR #439).

[martien-de-jong]

The mentioned PR solves the issues.