thr3ads.net - llvm dev - [llvm-dev] Bug 20871 -- is there a fix or work around? [Oct 2017]

If this information is useful, please help other people find it:
Share via:

Riyaz Puthiyapurayil via llvm-dev

2017-Oct-07 04:45 UTC

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

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171007/90e43ae9/attachment.html>

Craig Topper via llvm-dev

2017-Oct-07 06:13 UTC

head link

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

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>

Riyaz Puthiyapurayil via llvm-dev

2017-Oct-07 17:41 UTC

head link

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

Thanks. Looks like we can do this for only __multi3. Other TImode functions
(e.g. __divti3, __modti3, etc.) are not defined on 32-bit. I am not sure if any
optimizations could cause those to be generated. AFAICT there is no fall back
support (like what is there for MUL) in the Legalizer for wide SDIV, etc. See
below:

void DAGTypeLegalizer::ExpandIntRes_SDIV(SDNode *N,
                                         SDValue &Lo, SDValue &Hi) {
  EVT VT = N->getValueType(0);
  SDLoc dl(N);
  SDValue Ops[2] = { N->getOperand(0), N->getOperand(1) };

  if (TLI.getOperationAction(ISD::SDIVREM, VT) == TargetLowering::Custom) {
    SDValue Res = DAG.getNode(ISD::SDIVREM, dl, DAG.getVTList(VT, VT), Ops);
    SplitInteger(Res.getValue(0), Lo, Hi);
    return;
  }

  RTLIB::Libcall LC = RTLIB::UNKNOWN_LIBCALL;
  if (VT == MVT::i16)
    LC = RTLIB::SDIV_I16;
  else if (VT == MVT::i32)
    LC = RTLIB::SDIV_I32;
  else if (VT == MVT::i64)
    LC = RTLIB::SDIV_I64;
  else if (VT == MVT::i128)
    LC = RTLIB::SDIV_I128;
  assert(LC != RTLIB::UNKNOWN_LIBCALL && "Unsupported SDIV!");

  SplitInteger(TLI.makeLibCall(DAG, LC, VT, Ops, true, dl).first, Lo, Hi);
}

From: Craig Topper [mailto:craig.topper at gmail.com]
Sent: Friday, October 6, 2017 11:13 PM
To: Riyaz Puthiyapurayil <Riyaz.Puthiyapurayil at synopsys.com>
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Bug 20871 -- is there a fix or work around?

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<mailto: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<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwMFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=mMZWMrEZcvPMLSsEQSah9FOTwza1UudSDkAneN47U9lD3qu6gt3kpnIb4MWV77cM&m=8ojUuM5qcLpXl5eKq90AnJ27_jlZl43gZ99CytdsKiU&s=cK36KWYg9rMAIdm1tYTT8PDuTUNGjzOZEdY8Z8K6dU0&e=>

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171007/5da8726e/attachment-0001.html>

llvm dev - Oct 2017 - Bug 20871 -- is there a fix or work around?

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

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

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