search for: __multi3

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>

...ll) that when run through the optimizer produces 65bit integer math(fc_long-opt.ll). Now I understand that llvm can have any length integer, but I consider turning a 64bit mul into multiple 65 bit instructions to be a 'bad' optimization. This eventually expands to a 128bit multiply call(__multi3) which I have absolutely no interest in supporting. So I'm wondering what optimization might be the culprit here so I can disable it in this situation. Micah -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachm...

...oduces 65bit integer math(fc_long-opt.ll). >> >> >> >> Now I understand that llvm can have any length integer, but I consider >> turning a 64bit mul into multiple 65 bit instructions to be a ‘bad’ >> optimization. This eventually expands to a 128bit multiply call(__multi3) >> which I have absolutely no interest in supporting. So I’m wondering what >> optimization might be the culprit here so I can disable it in this >> situation. > > I'm pretty sure this is the fault of one of the loop passes (I forget > which one off the top of my hea...

...gh the > optimizer produces 65bit integer math(fc_long-opt.ll). > > > > Now I understand that llvm can have any length integer, but I consider > turning a 64bit mul into multiple 65 bit instructions to be a ‘bad’ > optimization. This eventually expands to a 128bit multiply call(__multi3) > which I have absolutely no interest in supporting. So I’m wondering what > optimization might be the culprit here so I can disable it in this > situation. I'm pretty sure this is the fault of one of the loop passes (I forget which one off the top of my head). It's worth noting...

...; >>> >>> >>> Now I understand that llvm can have any length integer, but I >>> consider >>> turning a 64bit mul into multiple 65 bit instructions to be a ‘bad’ >>> optimization. This eventually expands to a 128bit multiply call >>> (__multi3) >>> which I have absolutely no interest in supporting. So I’m >>> wondering what >>> optimization might be the culprit here so I can disable it in this >>> situation. >> >> I'm pretty sure this is the fault of one of the loop passes (I forget &...

On Monday 12 October 2009 22:22, Eli Friedman wrote: > > Now I understand that llvm can have any length integer, but I consider > > turning a 64bit mul into multiple 65 bit instructions to be a ‘bad’ > > optimization. This eventually expands to a 128bit multiply call(__multi3) > > which I have absolutely no interest in supporting. So I’m wondering what > > optimization might be the culprit here so I can disable it in this > > situation. > > I'm pretty sure this is the fault of one of the loop passes (I forget > which one off the top of my...

...t;> >>> >>> Now I understand that llvm can have any length integer, but I >>> consider >>> turning a 64bit mul into multiple 65 bit instructions to be a 'bad' >>> optimization. This eventually expands to a 128bit multiply call >>> (__multi3) >>> which I have absolutely no interest in supporting. So I'm >>> wondering what >>> optimization might be the culprit here so I can disable it in this >>> situation. >> >> I'm pretty sure this is the fault of one of the loop passes (I forg...

On 30 January 2018 at 14:12, Kito Cheng via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi all: > > I'm porting RISC-V[1] for compiler-rt recently, and I've got a problem > when adding soft float routine for rv32, RISC-V ABI required 128 bits > bits for long double, but it's implemented by int128_t, however rv32 > don't support __int128_t. > > Of

Hi all: I'm porting RISC-V[1] for compiler-rt recently, and I've got a problem when adding soft float routine for rv32, RISC-V ABI required 128 bits bits for long double, but it's implemented by int128_t, however rv32 don't support __int128_t. Of cause, it not hard thing to support __int128_t by overriding TargetInfo::hasInt128Type for LLVM, but its will cause some ABI

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