search for: sdivrems

I wrote the following bit of code static APInt FloorOfQuotient(APInt a, APInt b) { unsigned bits = a.getBitWidth(); APInt q(bits, 1), r(bits, 1); APInt::sdivrem(a, b, q, r); * errs() << "sdivrem(" << a << ", " << b << ") = (" << q << ", " << r << ")\n"; * if (r == 0) return q; else {

OK, the code for sdivrem in APInt.h is wrong. Here's what's written: static void sdivrem(const APInt &LHS, const APInt &RHS, APInt &Quotient, APInt &Remainder) { if (LHS.isNegative()) { if (RHS.isNegative()) APInt::udivrem(-LHS, -RHS, Quotient, Remainder); else APInt::udivrem(-LHS, RHS, Quotient, Remainder); Quotient =

"Caldarale, Charles R" <Chuck.Caldarale at unisys.com> wrote: > > APInt q(bits, 1), r(bits, 1); > > The APInt constructor has three arguments, the last one being whether or not the value is to be treated as signed. > It defaults to false, as you appear to have just verified. The initial values of q and r shouldn't make a difference (note that several of the

Hi Renato, > * Have some call-back mechanism, possibly upon a flag > (HasSpecialDivRemLowering), and update the remainder result If you setOperationAction on SDIVREM and UDIVREM to Custom you can expand the rtlib call appropriately yourself. There's precedent for sincos on Darwin systems (both ARM and x86) and in AArch64 for basically every operation on fp128. Cheers. Tim.

...will be split into several equivalent smaller operations (i.e. 64-bit mul => two 32-bit multiplications), or it will be expanded into a different operation(s) (i.e. SDIVREM => SDIV + SREM or a runtime library call). This can be ambiguous - should a 128-bit SDIVREM be expanded into two 64-bit SDIVREMs or a 128-bit libcall. It would be useful for LLVM to distinguish between these two operations - i.e. instead of LegalizeAction::Expand, we have LegalizeAction::Expand and LegalizeAction::Split. - Expand should always expand the node into a different pattern (such as MULHU expanding to M...

Folks, I'm working on bug 16387: "clang doesn't produce ARM EABI-compliant modulo runtime function" http://llvm.org/bugs/show_bug.cgi?id=16387 And I need some pointers. I've changed ARMISelLowering::ARMTargetLowering::ARMTargetLowering() to associate __aeabi_idivmod variants to RTLIB::{U,S}DIVREM_* library calls, but now I need to teach the expansion that on AEABI case,

I’m hitting TableGen errors trying to match the smullohi <lhs> <rhs> node in TableGen. smullohi returns two results, which is the problem. I am not sure how to match against multiple results. The only other nodes to return two operands are umullohi, udivrem, and sdivrem. There are no examples of these in TableGen in tree. The closest I can get is this: set (R1, R0, (umullohi

Hi, Pondering the code for StrongSIV and trying to write my own, I find I have many questions. In this code, for example, * if (isa<SCEVConstant>(delta) && isa<SCEVConstant>(srcCoeff)) { const SCEVConstant *constDelta = cast<SCEVConstant>(delta); const SCEVConstant *constCoeff = cast<SCEVConstant>(srcCoeff); APInt distance, remainder;

I'm trying to replace SDIvRem (whch returns two i16 types) with a custom that returns i32 or i16. I am getting the Assertion (!Node || ResNo < Node->getNumValues() && "Invalid result number for the given node!") Seems that it doesn't like returning one value but how do you return more than one value? I am doing this in the LowerOperation for the case SDIVREM and a

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

> As far as I know, you cannot define a tablegen pattern with multiple results, and need to use C++ matching. I’m kind of surprised there are defined td nodes for these. Yes they were added a while ago, but never used. If I write a C++ matcher, will the register allocator work correctly? The multiplication instruction I'm working with always writes the result to registers `R1` and `R0`,