This is an archive of the discontinued LLVM Phabricator instance.

[RISCVISelLowering] avoid emitting libcalls to __mulodi4() and __multi3()
ClosedPublic

Authored by nickdesaulniers on Aug 30 2021, 12:53 PM.

Details

Summary

Similar to D108842, D108844, D108926, D108928, and D108936.

__has_builtin(builtin_mul_overflow) returns true for 32b RISCV targets,
but Clang is deferring to compiler RT when encountering long long types.

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

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

Diff Detail

Event Timeline

nickdesaulniers requested review of this revision.Aug 30 2021, 12:53 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 30 2021, 12:53 PM
llvm/test/CodeGen/RISCV/mul.ll
1463

hmm...probably want to avoid MUL_I64, too?

nickdesaulniers planned changes to this revision.Aug 30 2021, 12:56 PM
jrtc27 added inline comments.Aug 30 2021, 1:05 PM
llvm/test/CodeGen/RISCV/mul.ll
1463

For the case you care about (RV32IM below) it is, and if you were to add MUL_I64 then it would just emit a libcall to __mulsi3, and I don't think you want to be inlining soft multiplication for every width of multiplication. That would make embedded people targeting small code size extremely unhappy.

craig.topper added inline comments.Aug 30 2021, 1:07 PM
llvm/test/CodeGen/RISCV/mul.ll
1463
nickdesaulniers requested review of this revision.Aug 30 2021, 1:31 PM
nickdesaulniers marked 2 inline comments as done.
This revision is now accepted and ready to land.Aug 30 2021, 2:32 PM
This revision was landed with ongoing or failed builds.Aug 31 2021, 11:24 AM
This revision was automatically updated to reflect the committed changes.