search for: umul_lohi

Hello, I'm having trouble getting LLVM to use UMUL_LOHI instead of MUL for unsigned integers. In the TargetLowering constructor I have: setOperationAction(ISD::MUL, MVT::i32, Expand); setOperationAction(ISD::SMUL_LOHI, MVT::i32, Legal); setOperationAction(ISD::UMUL_LOHI, MVT::i32, Legal); The problem seems to be with the code in LegalizeOp() in L...

Hi, When expanding multiply operation in LegalizeTypes LLVM generates some nodes such as UMUL_LOHI (please refer file LegalizeIntegerTypes.cpp - function - ExpandIntegerResult). However while lowering this operation in LegalizeDAG (please refer file LegalizeDAG.cpp - function - LegalizeOp) the comment says "These nodes will only be produced by target-specific lowering....."....

On Wed, Dec 17, 2008 at 11:49 PM, <Sachin.Punyani at microchip.com> wrote: > 2) Why is custom legalization of this node not allowed? No target has needed it so far. Why do you need it? > 3) My target does not have any instruction directly matching to this > operation. How should this node be legalized? If your target doesn't have this operation, you should mark

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); AddToISelQueue(Op2); unsigned Op; Op = (Opcode == ISD::UMUL_LOHI ? Nios2::MULxu : Nios2::MULx); SDNode *Hi = CurDAG->getTargetNode(Op, MVT::Flag,...

Thanks Eli. I didn't know that the operand sign didn't affect the operation as I've never done multiplication at the bit level. Javier On Tue, 8 Dec 2009 20:16:23 -0800, Eli Friedman <eli.friedman at gmail.com> wrote: > On Tue, Dec 8, 2009 at 7:16 PM, Javier Martinez <javier at jmartinez.org> > wrote: >> Eli, >> >> I think it is an error for LLVM

...LHS? 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,i32 = umul_lohi 0xaf9345c, 0xaf93924 What could I be doing to make the code generator think that umul_lohi is legal? -Rich

Hey, I’ve been working on custom lowering ISD::UMUL_LOHI and ISD::SMUL_LOHI. Our target has some legal vector types but no support for these so would like to mark them as Expand. This yields “Cannot unroll a vector with multiple results!” from the default case in VectorLegalizer::Expand. Hence custom lowering. All the types are legal at this stage. I...

On Thu, Sep 11, 2008 at 6:09 PM, Richard Pennington <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

...g 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,i32 = umul_lohi 0xaf9345c, 0xaf93924 > > What could I be doing to make the code generator think that umul_lohi is > legal? > > -Rich > In your target lowering you need to set the operation action for ISD::*MUL_LOHI to expand otherwise it will be assumed to be legal. Richard

On Thu, Sep 11, 2008 at 4:31 PM, Arnold Schwaighofer <arnold.schwaighofer at gmail.com> wrote: > Tail calls through function pointers should work.If not please send a testcase. > > I just added the two examples from the bug (1392) that calls for true > tail call support. They work on my machine (-tailcallopt needs to be > enabled) ;) > > That would be commit 56127. >

...hints on how to do this. It's not easy for the signed case, >> but is do-able. > > It can be lowered to a division + a branch, so it would be > inefficient, plus it would > be a lot of work to implement it correctly (for me at least). If you can get the relevant high product (UMUL_LOHI and friends), it's a relatively straightforward comparison. Otherwise, yes, the general case is quite tricky; inserting a division here is non-trivial. There's also the special-case of multiplication by a constant: here, the computation can be done with a single straightforward comparison...

...a computation and place the result in the destination register Rd. > The mul instructions implicitly use r0 and r1 to store the results. This > makes it quite hard to fit into TableGen and so we perform custom lowering > for these nodes. > > We expand the MUL DAG node into 'ISD::UMUL_LOHI' or 'ISD::SMUL_LOHI'. We > see these in AVRISelDAGToDAG.cpp and custom lower them (see > AVRISelDAGToDAG::selectMultiplication) into MULSRdRr or MULRdRr, > depending on signedness. Later on we have a custom inserter which inserts > instructions to clear the r1,r0 scratch reg...

Tail calls through function pointers should work.If not please send a testcase. I just added the two examples from the bug (1392) that calls for true tail call support. They work on my machine (-tailcallopt needs to be enabled) ;) That would be commit 56127. regards On Thu, Sep 11, 2008 at 11:21 PM, Evan Cheng <evan.cheng at apple.com> wrote: > Arnold implemented tail call. We

..., and having tracked down the cause, I'm now confused about the DAG legalization and optimization process which I thought I understood. I'd be really grateful for advice on whether I've misunderstood how legalization works. The target doesn't support MUL but does support i8 and i16 UMUL_LOHI and SMUL_LOHI. I custom lower i16 MUL because it's possible to use i8 UMUL_LOHI if the operands meet certain criteria. If this isn't possible, my custom-lowering returns SDValue() and so falls back onto the default expansion, which is to generate i16 SMUL_LOHI and use only the low result. T...

Hello LLVMDevs, I am looking for an example for how to lower LLVM IR to mulsu kind of instruction. I found that AVR back end have such instruction but AVRInstrInfo.td does not define any DAG pattern for which this instruction gets emitted. def MULSURdRr : FMUL2RdRr<1, (outs), (ins GPR8:$lhs, GPR8:$rhs), "mulsu\t$lhs, $rhs", []>, Requires<[SupportsMultiplication]>; Also

Hi, Here is the next iteration of the patch. The only comment not addressed is this one: > It would be better to implement a target-independent check for > overflow for the "Legal" case (like how SADDO does). Hacker's > Delight > has some hints on how to do this. It's not easy for the signed case, > but is do-able. It can be lowered to a division + a branch,

...ut look correct? They do look correct, there are three Xmul_lohi blocks, one returns the low part copied into R14 and the rest of combinations get added and merged into R15. Here is my selectionDAG code, i used X86's MUL code and adapted it to my target: case ISD::SMUL_LOHI: case ISD::UMUL_LOHI: { SDValue Op1 = N->getOperand(0); SDValue Op2 = N->getOperand(1); unsigned LoReg = R0, HiReg = R1; unsigned Opc = MULRdRr; SDValue InFlag = SDValue(CurDAG->getMachineNode(Opc,...

On Sep 9, 2010, at 12:59 PM, Borja Ferrer wrote: > Hello, i've noticed a new possible missed optimization while testing more trivial code. > This time it's not a with a xor but with a multiplication instruction and the example is little bit more involved. > > C code: > > typedef short t; > t foo(t a, t b) > { > t a4 = a*b; > return a4; > } >

...and an unsigned multiply >> d = a *u b >> then c and d are the same number (exactly the same bits set). > > At least two architectures I know about have size-extending multiplication, for which your statement is not true: yup, and that's why LLVM codegen has the SMUL_LOHI/UMUL_LOHI etc nodes. However that's not relevant to ordinary multiplication (codegen MUL node) which is what I understand the question to be about. Ciao, Duncan. > > - Motorola MC68K has i16 x 16 -> i32 instructions in signed and unsigned forms > > - Itanium has signed and unsigned mul...

On 2008-09-29 07:46, Keun Soo Yim wrote: > Does anyone succeed at compiling Linux kernel for Sparc v8 architecture? > I am currently trying to expand the regime of LLVM to Sparc kernel codes. > The following is the initial error messages. Any comment is welcomed. > > #1. Inline Assembly > > > > Code: > > register struct thread_info