[llvm-dev] Bug 20871 -- is there a fix or work around?

Craig Topper via llvm-dev llvm-dev at lists.llvm.org
Fri Oct 6 23:13:20 PDT 2017


That seems like a valid fix to me.

~Craig

On Fri, Oct 6, 2017 at 9:45 PM, Riyaz Puthiyapurayil via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Ignore the suggested fix in my earlier post. How about this?
>
>
>
> diff --git a/lib/Target/X86/X86ISelLowering.cpp b/lib/Target/X86/
> X86ISelLowering.cpp
>
> index 20c81c3..b8ebf42 100644
>
> --- a/lib/Target/X86/X86ISelLowering.cpp
>
> +++ b/lib/Target/X86/X86ISelLowering.cpp
>
> @@ -1632,10 +1632,11 @@ X86TargetLowering::X86TargetLowering(const
> X86TargetMachine &TM,
>
>    if (!Subtarget.is64Bit()) {
>
>      // These libcalls are not available in 32-bit.
>
>      setLibcallName(RTLIB::SHL_I128, nullptr);
>
>      setLibcallName(RTLIB::SRL_I128, nullptr);
>
>      setLibcallName(RTLIB::SRA_I128, nullptr);
>
> *+    setLibcallName(RTLIB::MUL_I128, nullptr);*
>
>    }
>
>    // Combine sin / cos into one node or libcall if possible.
>
>    if (Subtarget.hasSinCos()) {
>
>      setLibcallName(RTLIB::SINCOS_F32, "sincosf");
>
>
>
> *This will make the Legalizer choose the brute force approach below:*
>
>
>
> void DAGTypeLegalizer::ExpandIntRes_MUL(SDNode *N,
>
>                                         SDValue &Lo, SDValue &Hi) {
>
> ...
>
>
>
>   *if (LC == RTLIB::UNKNOWN_LIBCALL || !TLI.getLibcallName(LC)) {*
>
>     // We'll expand the multiplication by brute force because we have no
> other
>
>     // options. This is a trivially-generalized version of the code from
>
>     // Hacker's Delight (itself derived from Knuth's Algorithm M from
> section
>
>     // 4.3.1).
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171006/b51b2164/attachment.html>


More information about the llvm-dev mailing list