[llvm-bugs] [Bug 44353] New: LTO uses incomplete/inaccurate libcall list

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=44353

            Bug ID: 44353
           Summary: LTO uses incomplete/inaccurate libcall list
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: ELF
          Assignee: unassignedbugs at nondot.org
          Reporter: sbc at chromium.org
                CC: llvm-bugs at lists.llvm.org, peter.smith at linaro.org

I recently added support for handling libcalls generated at LTO time to
wasm-ld:https://reviews.llvm.org/D71738.

I noticed that LTO this relies on the static list of libcalls listed in 
llvm/include/llvm/IR/RuntimeLibcalls.def.

See lto::LTO::getRuntimeLibcallSymbols.

However as it says in the comments in RuntimeLibcalls.def:

```
Some libcalls have different names on particular OSes or architectures. 
These are set in InitLibcallNames() in TargetLoweringBase.cpp and/or by targets
using TargetLoweringBase::setLibcallName()
```

For example in WebAssembly backend has the following code which means that this
mechnism doesn't work for the FPROUND_F32_F16 libcall:

setLibcallName(RTLIB::FPROUND_F32_F16, "__truncsfhf2");

Possible solutions:

1. Create a hard-coded list of all libcall renames/aliases and add that to
lto::LTO::getRuntimeLibcallSymbols.  Would be fragile.

2. Extract the names after the renaming has been done. See 
TargetLoweringBase::InitLibcalls.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20191220/f60df8ae/attachment.html>