search for: mulhu

Eli Friedman wrote: > I haven't looked at the rest of the email carefully, but why aren't > you just implementing MULHU and MULHS? There's no point to > implementing the *MUL_LOHI variants if the processor doesn't have > them. I have implemented MULHU and MULHS. But if I take out my *MUL_LOHI stuff, the error I get is [~/ellcc/ellcc] main% ./nios2-elf-ecc -S test.c Cannot yet select: 0xaf93a34: i32...

...nington <rich at pennware.com> wrote: > I'm trying to implement *MUL_LOHI for my processor. > > My processor has mulxss (e.g.) that gives the 32 high bits of a 64 bit > multiply. I haven't looked at the rest of the email carefully, but why aren't you just implementing MULHU and MULHS? There's no point to implementing the *MUL_LOHI variants if the processor doesn't have them. -Eli

...) which is not simplified later on. this is quite expensive since the multiply is not pipelined and the div requires a libcall while the same could have been achieved with a (S|U)REM_I32 libcall. the problem is that the involved "magic" int TargetLowering has certain requirements such as MULHU support, which is not available on my architecture. i guess the best way is to check this conditions beforehand in the DAGCombiner, right? cheers, - dietmar

I'm trying to implement *MUL_LOHI for my processor. My processor has mulxss (e.g.) that gives the 32 high bits of a 64 bit multiply. I tried this in ios2ISelDAGToDAG.cpp: /// Mul/Div with two results case ISD::SMUL_LOHI: case ISD::UMUL_LOHI: { SDValue Op1 = Node->getOperand(0); SDValue Op2 = Node->getOperand(1); AddToISelQueue(Op1);

On Mon, 18 Jun 2007, Chris Lattner wrote: > On Thu, 14 Jun 2007, Dietmar Ebner wrote: >> currently, the DAGCombiner unconditionally converts >> (DAGCombiner::visit(U|S)REM) expressions of the form X % C for constants >> C into X-X/C*C. this makes sense in certain cases where the div/mul >> logic will simplify X/C*X but is counterproductive in general, >>

...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 MUL and a copy of the top half). - Split will always split an operation into several smaller, operations (such as 128-bit addition being split into a 64-bit addition and a 64-bit addition with carry) Full disclosure: I’m working on a backend on which the pointer type is i...

Richard Pennington wrote: > Eli Friedman wrote: > >> I haven't looked at the rest of the email carefully, but why aren't >> you just implementing MULHU and MULHS? There's no point to >> implementing the *MUL_LOHI variants if the processor doesn't have >> them. >> > > I have implemented MULHU and MULHS. But if I take out my *MUL_LOHI > stuff, the error I get is > > [~/ellcc/ellcc] main% ./nios2-elf-ec...

...rm a preference by checking which forms of plain // MULH it supports. bool HasSMUL_LOHI = TLI.isOperationLegalOrCustom(ISD::SMUL_LOHI, VT); bool HasUMUL_LOHI = TLI.isOperationLegalOrCustom(ISD::UMUL_LOHI, VT); bool HasMULHS = TLI.isOperationLegalOrCustom(ISD::MULHS, VT); bool HasMULHU = TLI.isOperationLegalOrCustom(ISD::MULHU, VT); unsigned OpToUse = 0; if (HasSMUL_LOHI && !HasMULHS) { OpToUse = ISD::SMUL_LOHI; } else if (HasUMUL_LOHI && !HasMULHU) { OpToUse = ISD::UMUL_LOHI; } else if (HasSMUL_LOHI) { OpToUse = ISD::SMUL_LOHI;...

...(Op); unsigned Opc = Op.getOpcode(); unsigned ResNo = Op.getResNo(); assert(Opc == ISD::UMUL_LOHI || Opc == ISD::SMUL_LOHI); assert(ResNo == 0 || ResNo == 1); SDValue Op0 = Op.getOperand(0); SDValue Op1 = Op.getOperand(1); unsigned MULHXOpcode = Opc == ISD::UMUL_LOHI ? ISD::MULHU : ISD::MULHS; SDValue res[2] = { // Seems wasteful to generate both of these twice per node DAG.getNode(ISD::MUL, dl, VT, Op0, Op1), LowerMULHX(DAG.getNode(MULHXOpcode, dl, VT, Op0, Op1), DAG), }; SDVTList VTs = DAG.getVTList(VT, VT); SDNode * N = DAG.getNode(ISD::MERGE_V...

...ng loaded into in the IR. Basically I'm trying to describe patterns for automatically selecting between various multiplication instructions: #define MULL(t,s1,s2) t = (s1) * INT16(s2) #define MULLU(t,s1,s2) t = (s1) * UINT16(s2) #define MULH(t,s1,s2) t = (s1) * INT16((s2) >> 16) #define MULHU(t,s1,s2) t = (s1) * UINT16((s2) >> 16) #define MULHS(t,s1,s2) t = ((s1) * UINT16((s2) >> 16)) << 16 #define MULLL(t,s1,s2) t = INT16(s1) * INT16(s2) #define MULLLU(t,s1,s2) t = UINT16(s1) * UINT16(s2) #define MULLH(t,s1,s2) t = INT16(s1) * INT16((s2) >> 16) #define MULLHU(...

...​ On Thu, Aug 13, 2015 at 2:14 PM, Matt Arsenault <arsenm2 at gmail.com> wrote: > > On Aug 12, 2015, at 10:25 AM, Dylan McKay via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > - Expand should always expand the node into a different pattern (such > as MULHU expanding to MUL and a copy of the top half). > - Split will always split an operation into several smaller, > operations (such as 128-bit addition being split into a 64-bit addition and > a 64-bit addition with carry) > > > Are you primarily trying to avoid Expand being...

...ults; > + > + // RCP = URECIP(Den) = 2^32 / Den + e > + // e is rounding error. > + SDValue RCP = DAG.getNode(AMDGPUISD::URECIP, DL, VT, Den); > + > + // RCP_LO = umulo(RCP, Den) */ > + SDValue RCP_LO = DAG.getNode(ISD::UMULO, DL, VT, RCP, Den); > + > + // RCP_HI = mulhu (RCP, Den) */ > + SDValue RCP_HI = DAG.getNode(ISD::MULHU, DL, VT, RCP, Den); > + > + // NEG_RCP_LO = -RCP_LO > + SDValue NEG_RCP_LO = DAG.getNode(ISD::SUB, DL, VT, DAG.getConstant(0, VT), > + RCP_LO); > + > + // ABS_RCP_L...

Hi Sam, I am not a MIPS expert by any means, so YMMV, but: MIPS addu only differs to "add" in its (non)setting of the overflow flag. Because LLVM doesn't provide a way via the IR to access the overflow flag, a special notation isn't required in the IR to distinguish the two operations. Do you have another example? Cheers, James -----Original Message----- From:

Thanks for the replies guys but I think I should have phrased my question better... looking at the Mips backend there are machine instructions that operate on signed and unsigned data, such as add and addu. And like Mips, I need to specify unsigned specific instructions, so how do these get chosen between if the LLVM IR does not carry type data? A very general point in the right direction is all i

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

...- if (TLI.getOperationAction(ISD::MUL, VT) == TargetLowering::Custom) { - SDValue New = TLI.LowerOperation(Op, DAG); - if (New.getNode()) { - ExpandOp(New, Lo, Hi); - break; - } - } - - bool HasMULHS = TLI.isOperationLegalOrCustom(ISD::MULHS, NVT); - bool HasMULHU = TLI.isOperationLegalOrCustom(ISD::MULHU, NVT); - bool HasSMUL_LOHI = TLI.isOperationLegalOrCustom(ISD::SMUL_LOHI, NVT); - bool HasUMUL_LOHI = TLI.isOperationLegalOrCustom(ISD::UMUL_LOHI, NVT); - if (HasMULHU || HasMULHS || HasUMUL_LOHI || HasSMUL_LOHI) { - SDValue LL, LH, RL, RH; -...