LLVM ERROR: Do not know how to expand the result of this operaton" for t13: i32 = lrint t12

[atrosinenko]

While compiling newlib, backend crashes on some files. One of them is libm/common/lrintl.c that can be transformed to the attached lrintl.ll.txt.

Bugpoint reduces it down to

$ ~/projects/llvm-project/build/bin/llvm-dis < bugpoint-reduced-named-md.bc
; ModuleID = '<stdin>'
source_filename = "lrintl-6541b9.c"
target datalayout = "e-m:e-p:16:16-i32:16-i64:16-f32:16-f64:16-a:8-n8:16-S16"
target triple = "msp430"

define dso_local i32 @lrintl(double %x) local_unnamed_addr #0 {
entry:
  %0 = tail call i32 @llvm.lrint.i32.f64(double %x)
  ret i32 %0
}

; Function Attrs: nounwind readnone speculatable willreturn
declare i32 @llvm.lrint.i32.f64(double) #1

attributes #0 = { "use-soft-float"="false" }
attributes #1 = { nounwind readnone speculatable willreturn }

!llvm.ident = !{!0}

!0 = !{!"clang version 11.0.0 (git@github.com:access-softek/llvm-project.git d33c7de8e11f2727ef5e325d931ae94af8619bf9)"}

I used the following command, if it does matter:

~/projects/llvm-project/build/bin/bugpoint -llc-safe lrintl.ll -tool-args --disable-symbolication

Meanwhile, mere loading of debug information can take several seconds. While it is useful (or at least tolerable) for usual debugging tasks, it seems ruining bugpoint performance. Wouldn't it be useful to pass --disable-symbolication argument to the tool under test, if appropriate. In case it can change bug reproducibility, bugpoint could show a suggestion at the beginning of its output, at least. The user would have much time to read it... Still, I can hardly imagine why disabling symbolizer could hinder "crashability" - and for that rare case, an option can be added to explicitly revert to the traditional behavior.

[atrosinenko]

Full output of llc:

$ LANG=C ~/projects/llvm-project/build/bin/llc bugpoint-reduced-named-md.bc
ExpandIntegerResult #0: t13: i32 = lrint t12

LLVM ERROR: Do not know how to expand the result of this operator!
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0.      Program arguments: /home/ast/projects/llvm-project/build/bin/llc bugpoint-reduced-named-md.bc 
1.      Running pass 'Function Pass Manager' on module 'bugpoint-reduced-named-md.bc'.
2.      Running pass 'MSP430 DAG->DAG Pattern Instruction Selection' on function '@lrintl'
 #0 0x000055db5eb2ec47 llvm::sys::PrintStackTrace(llvm::raw_ostream&) /home/ast/projects/llvm-project/llvm/lib/Support/Unix/Signals.inc:564:22
 #1 0x000055db5eb2ecde PrintStackTraceSignalHandler(void*) /home/ast/projects/llvm-project/llvm/lib/Support/Unix/Signals.inc:625:1
 #2 0x000055db5eb2ca27 llvm::sys::RunSignalHandlers() /home/ast/projects/llvm-project/llvm/lib/Support/Signals.cpp:68:20
 #3 0x000055db5eb2e58f SignalHandler(int) /home/ast/projects/llvm-project/llvm/lib/Support/Unix/Signals.inc:406:1
 #4 0x00007ff7a5f8c540 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x15540)
 #5 0x00007ff7a5a213eb raise /build/glibc-t7JzpG/glibc-2.30/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
 #6 0x00007ff7a5a00899 abort /build/glibc-t7JzpG/glibc-2.30/stdlib/abort.c:81:7
 #7 0x000055db5ea7a507 llvm::install_bad_alloc_error_handler(void (*)(void*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool), void*) /home/ast/projects/llvm-project/llvm/lib/Support/ErrorHandling.cpp:130:61
 #8 0x000055db5ea7a2b6 llvm::report_fatal_error(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool) /home/ast/projects/llvm-project/llvm/lib/Support/ErrorHandling.cpp:86:77
 #9 0x000055db5ea0bf87 llvm::DAGTypeLegalizer::ExpandIntegerResult(llvm::SDNode*, unsigned int) /home/ast/projects/llvm-project/llvm/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp:1893:48
#10 0x000055db5e9a3c1f llvm::DAGTypeLegalizer::run() /home/ast/projects/llvm-project/llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.cpp:257:17
#11 0x000055db5e9a8276 llvm::SelectionDAG::LegalizeTypes() /home/ast/projects/llvm-project/llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.cpp:1041:37
#12 0x000055db5e933c95 llvm::SelectionDAGISel::CodeGenAndEmitDAG() /home/ast/projects/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:837:36
#13 0x000055db5e933209 llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator<llvm::ilist_detail::node_options<llvm::Instruction, true, false, void>, false, true>, llvm::ilist_iterator<llvm::ilist_detail::node_options<llvm::Instruction, true, false, void>, false, true>, bool&) /home/ast/projects/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:737:1
#14 0x000055db5e937d94 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) /home/ast/projects/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1616:33
#15 0x000055db5e931ae4 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) /home/ast/projects/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:504:7
#16 0x000055db5dc2a261 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) /home/ast/projects/llvm-project/llvm/lib/CodeGen/MachineFunctionPass.cpp:73:33
#17 0x000055db5e1bbd98 llvm::FPPassManager::runOnFunction(llvm::Function&) /home/ast/projects/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1482:20
#18 0x000055db5e1bc059 llvm::FPPassManager::runOnModule(llvm::Module&) /home/ast/projects/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1518:13
#19 0x000055db5e1bc4cb (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) /home/ast/projects/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1583:20
#20 0x000055db5e1bccfc llvm::legacy::PassManagerImpl::run(llvm::Module&) /home/ast/projects/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1695:13
#21 0x000055db5e1bcf0d llvm::legacy::PassManager::run(llvm::Module&) /home/ast/projects/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1727:1
#22 0x000055db5d0f112e compileModule(char**, llvm::LLVMContext&) /home/ast/projects/llvm-project/llvm/tools/llc/llc.cpp:627:66
#23 0x000055db5d0ef56a main /home/ast/projects/llvm-project/llvm/tools/llc/llc.cpp:360:35
#24 0x00007ff7a5a021e3 __libc_start_main /build/glibc-t7JzpG/glibc-2.30/csu/../csu/libc-start.c:342:3
#25 0x000055db5d0ee81e _start (/home/ast/projects/llvm-project/build/bin/llc+0x11ad81e)

[asl]

I would not bother and simple strip debug info prior to bugpoint :)

[asl]

As for this particular issue – I would ignore it is for now. i32 is not a legal type on MSP430, so some additional care would be required.

[atrosinenko]

I expected to implelemt some hackish solution for this such as "use some LIBCALL that is not defined yet" at first, too. But it seems, I cannot just ignore it, because this (and possible other issues like this one) could prevent regular compilation of newlib (or other similar libraries).

I mean, I perfectly accept the case "A particular program that tries to use such function would not link". But I would prefer to defer this until the particular .o file would be extracted from libm.a and used (it would not, unless program explicitly uses this function, if I get this case right).

[atrosinenko]

Or do you mean re-configure newlib for 16-bit platform because fixing all issues that would probably arise is too complex?

[asl]

We are not interested in fixing all newlib problems (yet). Documenting them is fine, hacking out via external call is fine as well.