This is an archive of the discontinued LLVM Phabricator instance.

[MipsISelLowering] avoid emitting libcalls to __multi3
ClosedPublic

Authored by nickdesaulniers on Aug 30 2021, 10:40 AM.

Details

Summary

Similar to D108842 and D108844.

has_builtin(builtin_mul_overflow) returns true for 32b MIPS targets,
but Clang is deferring to compiler RT when encountering long long types.
This breaks MIPS malta_defconfig builds of the Linux kernel that are
using
builtin_mul_overflow with these types for these targets.

If the semantics of __has_builtin mean "the compiler resolves these,
always" then we shouldn't conditionally emit a libcall.

This will still need to be worked around in the Linux kernel in order to
continue to support malta_defconfig builds of the Linux kernel for this
target with older releases of clang.

Link: https://bugs.llvm.org/show_bug.cgi?id=28629
Link: https://github.com/ClangBuiltLinux/linux/issues/1438

Diff Detail

Event Timeline

nickdesaulniers requested review of this revision.Aug 30 2021, 10:40 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 30 2021, 10:40 AM
nickdesaulniers edited the summary of this revision. (Show Details)Aug 30 2021, 10:51 AM

Why is multi3 a problem for MIPS but not Arm or x64_32?

Why is multi3 a problem for MIPS but not Arm or x64_32?

Both ARM and 32-bit x86 have this line already

setLibcallName(RTLIB::MUL_I128, nullptr);
nickdesaulniers planned changes to this revision.Aug 30 2021, 11:35 AM

I need to update llvm/tests/CodeGen/Mips/llvm-ir/mul.ll and llvm/tests/CodeGen/Mips/urem-seteq-illegal-types.ll.

nickdesaulniers edited the summary of this revision. (Show Details)
  • fix up tests
llvm/test/CodeGen/Mips/llvm-ir/mul.ll
252

perhaps it's more interesting to encode what the code actually being generated is, but I found it to be a tangly mess of spaghetti for this test in particular. GP32 and MM32 refer to multiple targets respectively; each have divergent code implementing 128b multiplication (and a lot of it).

rengolin accepted this revision.Sep 2 2021, 10:25 AM

LGTM, thanks!

This revision is now accepted and ready to land.Sep 2 2021, 10:25 AM
This revision was landed with ongoing or failed builds.Sep 2 2021, 10:41 AM
This revision was automatically updated to reflect the committed changes.