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

Looks like I have run into the same issue reported in:

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

Is there a fix or work-around for it? The bug report seems to be still open.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171005/46c1282d/attachment.html>

Is there a switch (other than -O0) that can be used to work around this?
Currently, our 32-bit compilation is broken with clang (undefined reference to
__multi3) when we changed the type of some variables from unsigned to uint64_t.
There are some loops in the code that are getting optimized by clang and ending
up with calls to __multi3. Somebody wrote in the existing bug report that
indvars is responsible for this. Is there a way to turn it off?

From: Riyaz Puthiyapurayil via llvm-dev [mailto:llvm-dev at lists.llvm.org]
Sent: Wednesday, October 4, 2017 7:04 PM
To: llvm-dev at lists.llvm.org
Subject: [llvm-dev] Bug 20871 -- is there a fix or work around?

Looks like I have run into the same issue reported in:

https://bugs.llvm.org/show_bug.cgi?id=20871<https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D20871&d=DwMFAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=mMZWMrEZcvPMLSsEQSah9FOTwza1UudSDkAneN47U9lD3qu6gt3kpnIb4MWV77cM&m=NLVJvRs7gxWXdTlf0AqaZwiKUVL5bOkLiuQT9ROMxsc&s=oqlif07O6_1z_DqqI7ZpFHwvL6Zr0TRl4BJDdUn-o0w&e=>

Is there a fix or work-around for it? The bug report seems to be still open.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171005/56b36d59/attachment.html>

I got no responses to my earlier emails. Since I was stuck, I looked into this
further and I tried the following change in my LLVM (4.0.1) sandbox and it seems
to address the problem.
I handled only __multi3 for now but a complete fix would handle other 128-bit
functions as well. Further, the guard that I am using (isArch32Bit)... is it
appropriate? Should
I check for something else instead?

diff --git a/lib/CodeGen/TargetLoweringBase.cpp
b/lib/CodeGen/TargetLoweringBase.cpp
index 003311b..05582fe 100644
--- a/lib/CodeGen/TargetLoweringBase.cpp
+++ b/lib/CodeGen/TargetLoweringBase.cpp
@@ -83,7 +83,9 @@ static void InitLibcallNames(const char **Names, const Triple
&TT) {
   Names[RTLIB::MUL_I16] = "__mulhi3";
   Names[RTLIB::MUL_I32] = "__mulsi3";
   Names[RTLIB::MUL_I64] = "__muldi3";
-  Names[RTLIB::MUL_I128] = "__multi3";
+  if (!TT.isArch32Bit()) {
+    Names[RTLIB::MUL_I128] = "__multi3";
+  }
   Names[RTLIB::MULO_I32] = "__mulosi4";
   Names[RTLIB::MULO_I64] = "__mulodi4";
   Names[RTLIB::MULO_I128] = "__muloti4";

Anyone familiar with this stuff, please comment. I know the above code has
changed in the master and I may have to add the following instead:

+  if (TT.isArch32Bit()) {
+    Names[RTLIB::MUL_I128] = nullptr;
+  }

Thx.
/RVP

From: Riyaz Puthiyapurayil via llvm-dev [mailto:llvm-dev at lists.llvm.org]
Sent: Thursday, October 5, 2017 3:37 PM
To: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Bug 20871 -- is there a fix or work around?

Is there a switch (other than -O0) that can be used to work around this?
Currently, our 32-bit compilation is broken with clang (undefined reference to
__multi3) when we changed the type of some variables from unsigned to uint64_t.
There are some loops in the code that are getting optimized by clang and ending
up with calls to __multi3. Somebody wrote in the existing bug report that
indvars is responsible for this. Is there a way to turn it off?

From: Riyaz Puthiyapurayil via llvm-dev [mailto:llvm-dev at lists.llvm.org]
Sent: Wednesday, October 4, 2017 7:04 PM
To: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
Subject: [llvm-dev] Bug 20871 -- is there a fix or work around?

Looks like I have run into the same issue reported in:

https://bugs.llvm.org/show_bug.cgi?id=20871<https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D20871&d=DwMFAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=mMZWMrEZcvPMLSsEQSah9FOTwza1UudSDkAneN47U9lD3qu6gt3kpnIb4MWV77cM&m=NLVJvRs7gxWXdTlf0AqaZwiKUVL5bOkLiuQT9ROMxsc&s=oqlif07O6_1z_DqqI7ZpFHwvL6Zr0TRl4BJDdUn-o0w&e=>

Is there a fix or work-around for it? The bug report seems to be still open.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171006/4828335f/attachment.html>

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>