search for: udivrem

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 = -Quotient; Remainder = -Remainder; } else if (RHS.isNegative()) { APInt::udivrem(LHS, -RHS, Quotient, Remainder); Quotient = -Quotient; } else { APInt::udivre...

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 {

I need to lower a node into something in the machine that has side effects, i.e. needs a chain. Specifically it's actually UDIVREM. UDIVREM does not have a chain. I can custom lower UDIVREM into the nodes I want, with chain, I can even chain the new nodes and connect them to entry and root with token factors. But then the new nodes are not chained with respect to other nodes, or not chained with respect to each other, in case...

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.

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,

...now to be not supported by target's type legalization with a call to a function that implements given arithmetic operation. 3. The pass also injects these functions to the module with a weak linkage. 4. The pass requires a function generator (interface implementation) for mul and udivrem algorithms for integer types of sizes being powers of 2 (i.e. i128, i256, ...). Replacements for other instructions are created using these 2 algorithms. 5. A default implementation of the generator is provided. 6. A user is able to provide its own implementation of the generator wit...

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 GPR8:$lhs, GPR8:$rhs)) Which fails: Assertion failed: (Ops.size() >= NumSrcResults && "Didn't provide enough results"), function EmitR...

...p.northover at gmail.com> wrote: > On Thu, 16 Jul 2020 at 16:44, Hendrik Greving via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > But then the new nodes are not chained with respect to other nodes, or > not chained with respect to each other, in case there are several UDIVREM. > > Do they really need to be chained with each other or anything else? > The case I know of is when they get lowered to a libcall. That libcall > has effects that mean it needs a chain of some kind, but it doesn't > really matter in any other way where in the basic block it hap...

Hello List, I am on the hook to instrument a piece of legacy LLVM IR code, and then we are planning to feed to the SeaHorn framework for some model checking tasks. After the instrumentation, I tried to use llc (version 3.9) to compile the IR code, and it works fine. However, when I try to use llc (version 3.8.1, the default llvm version of SeaHorn) to compile the IR code, it shows the following

...e: > > 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 GPR8:$lhs, GPR8:$rhs)) > > > As far as I know, you cannot define a tablegen pattern with multiple > results, and need to use C++ match...

I did it by code preparing into an intrinsic that has side effects. Pseudo instruction would work as well. I'm not sure if glue would help, since the nodes A->B, C->D from example above are not necessarily adjacent. More hooks into the selection DAG builder may be an idea for a LLVM extension. For example in this case, custom allowing for a node to be built with an existing chain would

Hello, I am on the hook to instrument a piece of legacy LLVM IR code, and then we are planning to feed to the SeaHorn framework for some model checking tasks. After the instrumentation, I tried to use llc (version 3.9) to compile the IR code, and it works fine. However, when I try to use llc (version 3.8.1, the default llvm version of SeaHorn) to compile the IR code, it shows the following

...ructions > + // for them. > + setOperationAction(ISD::FCEIL, MVT::f32, Legal); > + setOperationAction(ISD::FEXP2, MVT::f32, Legal); > + setOperationAction(ISD::FRINT, MVT::f32, Legal); > + > + setOperationAction(ISD::UDIV, MVT::i32, Expand); > + setOperationAction(ISD::UDIVREM, MVT::i32, Custom); > + setOperationAction(ISD::UREM, MVT::i32, Expand); > +} > + > +SDValue AMDGPUTargetLowering::LowerOperation(SDValue Op, SelectionDAG &DAG) > + const > +{ > + switch (Op.getOpcode()) { > + default: return AMDILTargetLowering::LowerOperation(Op,...