search for: smul_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 LegalizeDAG.cpp. Here's a snipet of the relevant section. [Snipet] // See if multiply or divide can be lowered using two-result operations. // We just need...

...racked 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. This worked fin...

...-I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../libdecnumber -I/home/ksyim/workspace/compiler/llvm/llvm-2.3/objdir-sparc//include -I/scr/ksyim/workspace/compiler/llvm/llvm-2.3/include -DL_mulvsi3 -c ../../gcc/libgcc2.c -o libgcc/./_mulvsi3.o Cannot yet select: 0x8a92348: i32,i32 = smul_lohi 0x8aa5150, 0x8a925f8 ../../gcc/libgcc2.c:177: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://developer.apple.com/bugreporter> for instructions. make[3]: *** [libgcc/./_mulvsi3.o] Error 1 make[3]: Leaving directo...

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 would appreciate so...

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

...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 registers after use. > >...

If no i64 reg classes are registered, then type-legalization will expand a 32b x 32b = 64b multiply node into a 32-bit mult node with two i32 results (for example, SMUL_LOHI). The problem is that there isn't an easy way to have RA assign two consecutive hi/lo registers to the two i32 registers, once the 64-bit result is split into two 32-bit results. Is there a constraint I can use (something like register hints) to force RA to allocate consecutive registers? On...

Dan Gohman wrote: > There certainly are wishlist items for TableGen and TableGen-based > instruction descriptions, though I don't know of an official list. > Offhand, > a few things that come to mind are the ability to handle nodes with > multiple results, Is there an official workaround, BTW? - Volodya

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

...ication 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 to select ISD::SMUL_LOHI for UNSIGNED >> integers; isn't it? > > The LLVM mul instruction isn't fundamentally signed or unsigned. For a > 64 * 64 -> 64 multiply, it's perfectly legitimate to use 32 * 32 -> 64 > signed multiply as one of the components. > > -Eli

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

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

...oes the -view-*-dags output 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; > } >

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

On 5 sept. 2011, at 17:48, Duncan Sands wrote: > since the result of a multiply doesn't depend on the signedness, I find it > strange that your target differentiates between them. What I'm saying is > that if you have (say) two i32 numbers a and b and you do a signed multiply: > c = a *s b > and an unsigned multiply > d = a *u b > then c and d are the same number

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

On Sep 28, 2008, at 9:46 PM, 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 The Sparc backend has no active maintainer [1]. This

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

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 *current_thread_info_reg asm("g6"); Error Message: include/asm/thread_info.h:77: error: