[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