[llvm-bugs] [Bug 16404] __int128_t multiply with -fsanitize=undefined fails to link (undefined reference to __muloti4)

[via llvm-bugs]

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

Nick Desaulniers <ndesaulniers at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
                 CC|                            |craig.topper at gmail.com,
                   |                            |ndesaulniers at google.com
             Status|REOPENED                    |RESOLVED

--- Comment #30 from Nick Desaulniers <ndesaulniers at google.com> ---
I fixed the bug in the initial report in
d0eeb64be5848a7832d13db9d69904db281d02e8 / https://reviews.llvm.org/D108928 in
clang-14. So closing this as resolved/fixed.

That said, it's kind of tragic from a code size perspective that we can't use
these compiler-rt-only symbols.

It's also tragic IMO that clang doesn't use LLVM's own compiler runtime (or
linker for that matter) by default.  And because it doesn't, there's less
incentive to ever get those working for a platform; if we can just depend on
libgcc (or ld64), why put any effort into compiler-rt (or LLD) for those
platforms?

Part of me thinks it would be nice to still emit libcalls to mulodi/muloti and
friends for platforms that do currently link against compiler-rt.  To do that,
LLVM would need knowledge of which compiler runtime was being linked against. 
Clang knows this (ToolChain::GetRuntimeLibType and
ToolChain::GetDefaultRuntimeLibType are used to make code gen decisions in
clang), but LLVM doesn't AFAICT. Perhaps we should have module level IR for
this that clang can set? Then LLVM can make better code gen decisions?  The one
thing I haven't checked yet is whether one can specify something like `clang
-rtlib=compiler-rc -c foo.c` but then invoke the linker with a different
compiler library?  I assume that that's possible; otherwise I don't see how you
could build a shared object that could work with either runtimes.  So is clang
wrong to make such checks?

Should muloti/mulodi just be deleted from compiler-rt? At the least, we should
file a feature request for libgcc to add these.

Another part of me thinks it would be nice to switch the default compiler
runtime to compiler-rt for clang, and encourage platforms to get their compiler
runtimes working with compiler-rt.  Is having the compiler builtins separated
from the reset of compiler-rt interesting? Perhaps.  That feels orthogonal to
the above point about module level IR, and not a yak I intend to shave.

-- 
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/20211101/a17a8cac/attachment.html>