search for: mulh

...28> %mul, <i128 64, i128 64> %trunc = trunc <2 x i128> %shift to <2 x i64> ret <2 x i64> %trunc } On PPC, the legalizer will scalarize this since we do not have v2i128. Then the DAG combiner will produce the pattern I am referring to in this RFC: (v2i64 build_vector (mulhs (extractelt %a, 0), (extractelt %b, 0)), (mulhs (extractelt %a, 1), (extractelt %b, 1))) And if the target has mulhs legal for the vector type, this is strictly worse. So no matter what we do in InstCombine or the SLP vectorizer, we will end up with non-optimal code. If we al...

...operation on each element individually and then rebuilding the vector is likely more prevalent than that. At least I think that is the case, but I'll do some analysis to see if it is so or not. On Sat, Jan 11, 2020 at 6:15 PM Craig Topper <craig.topper at gmail.com> wrote: > For the MULHS example couldn’t that be fixed by adding a DAG combine to > create vector MULHS before type legalization? > > On Sat, Jan 11, 2020 at 3:08 PM Nemanja Ivanovic via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Thanks so much for your feedback Simon. >> >&g...

...are the same), then we can just convert this to (op %a [, %b]) Which is likely going to produce better code in all cases. Of course, things like this have a tendency to not be better in all cases, but I think we can probably account for any corner cases that arise. Example: (v2i64 build_vector (mulhs (extractelt %a, 0), (extractelt %b, 0)), (mulhs (extractelt %a, 1), (extractelt %b, 1))) Can be converted to the following on a target that has the operation available on vectors. (v2i64 mulhs %a, %b) A further improvement might be if the order of extracted elements doesn'...

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: i3...

...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

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);

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-e...

...Snipet] // See if multiply or divide can be lowered using two-result operations. // We just need the low half of the multiply; try both the signed // and unsigned forms. If the target supports both SMUL_LOHI and // UMUL_LOHI, form 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); un...

...) 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

Hello LLVM-Dev, Attached are: · The DAG after being built · The DAG before the legalization phase The DAG illustrated performs a signed division for type i32. As can be seen, the SDIV node was converted to a series of other nodes (which includes a MULHS node). In the target lowering class of our target, the SDIV has an operation action of custom. Does anybody know where in between the SelectionDAGBuilder and the Legalization phases the SDIV node got converted? I need the SDIV node to stay as an SDIV node until legalization phase (where it will be...

...sext to differentiate what containers the values are being 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...

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, >>

...> operands when defining some instructions such that some of the > > positional operands overlap with some of the named operands. I > > suspect this is not intentional; here's an example: > > > > AArch64 has the following instruction definition: > > > > SMULHxxx { > > field bits<32> Inst = { 1, 0, 0, 1, 1, 0, 1, 1, 0, 1, 0, Rm{4}, > > Rm{3}, Rm{2}, Rm{1}, Rm{0}, 0, Ra{4}, Ra{3}, Ra{2}, Ra{1}, > > Ra{0}, Rn{4}, Rn{3}, Rn{2}, Rn{1}, Rn{0}, Rd{4}, Rd{3}, Rd{2}, > > Rd{1}, Rd{0} }; > > ... > > dag OutOpe...

...Some of the backends seem to be combining positional and named operands when defining some instructions such that some of the positional operands overlap with some of the named operands. I suspect this is not intentional; here's an example: AArch64 has the following instruction definition: SMULHxxx { field bits<32> Inst = { 1, 0, 0, 1, 1, 0, 1, 1, 0, 1, 0, Rm{4}, Rm{3}, Rm{2}, Rm{1}, Rm{0}, 0, Ra{4}, Ra{3}, Ra{2}, Ra{1}, Ra{0}, Rn{4}, Rn{3}, Rn{2}, Rn{1}, Rn{0}, Rd{4}, Rd{3}, Rd{2}, Rd{1}, Rd{0} }; ... dag OutOperandList = (outs GPR64:$Rd); dag InOperandList = (ins GPR64:$Rn,...

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:

The sign information for binary operators is available in the llvm IR by the 'nsw' (no signed wrap) flag. Seems there is no use of this flag in the code generation phase. The sign information is no more available in the selection DAG. So how can I generate different instructions for binary operators with signed/unsigned operands in the assembler (e.g. mul/mulu)? -- View this message in

...EVT VT = Op.getValueType(); SDLoc dl(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...

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

...IR)/build/$@/$@.S $(RISCV_LLVM_OBJDUMP) --arch=rv32imac -D $(WORK_DIR)/build/$@/$@ > $(WORK_DIR)/build/$@/$@.ASM ``` gcc objdump result: ``` 4001168: 00052383 lw t2,0(a0) 400116c: 979a add a5,a5,t1 400116e: 439c lw a5,0(a5) 4001170: 0308a533 mulhsu a0,a7,a6 ``` llvm-objdump result: ``` 4001168: 83 23 05 00 lw t2, 0(a0) 400116c: 9a 97 add a5, a5, t1 400116e: 9c 43 lw a5, 0(a5) 4001170: 33 a5 08 03 <unknown> ``` Does anyone knows what is the probl...

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