Riyaz Puthiyapurayil via llvm-dev
2017-Oct-05 02:03 UTC
[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 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>
Riyaz Puthiyapurayil via llvm-dev
2017-Oct-05 22:36 UTC
[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 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>
Riyaz Puthiyapurayil via llvm-dev
2017-Oct-06 19:40 UTC
[llvm-dev] Bug 20871 -- is there a fix or work around?
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>
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>