search for: getconstants

Richard Pennington wrote: > My target doesn't support 64 bit arithmetic, so I'd like to supply > definitions for adde/addc. The problem is I can't seem to figure out the > magic. Here's an example of what I need to generate: > > # two i64s in r5/r6 and r7/r8 > # result in r1/r2, carry in r3 > > # adde > add r2, r6, r8 > cmpltu r3, r2, r6 #

My target doesn't support 64 bit arithmetic, so I'd like to supply definitions for adde/addc. The problem is I can't seem to figure out the magic. Here's an example of what I need to generate: # two i64s in r5/r6 and r7/r8 # result in r1/r2, carry in r3 # adde add r2, r6, r8 cmpltu r3, r2, r6 # compute carry # addc add r1, r5, r7 add r1, zero, r3 Is this

On Jul 1, 2009, at 2:22 PMPDT, Dan Gohman wrote: >> Ops.push_back(DAG.getConstant(1, MVT::i32)); >> Chain = DAG.getNode(ISD::ADD, DAG.getVTList(MVT::Other, MVT::i32), >> &Ops[0], Ops.size()); >> >> Isn't that the way how it is supposed to work? > > ADD does not use a chain, so there's no chain operand, or > MVT::Other result for it in an ADD

Hello, I'm working in adding support for 64-bit integers to my target. I'm using LLVM to decompose the 64-bit integer operations by using 32-bit registers wherever possible and emulating support where not. When looking at the bit shift decomposition I saw what seems to be a bug in the implementation. The affected function is ExpandShiftWithUnknownAmountBit in LegalizeIntegerTypes.cpp.

Thanks to your help I've actually made some progress... Especially the SelectionDAGNodes.h was a good hint. But there are still some things that I can't figure out: // 'mov eax, 41' Chain = DAG.getCopyToReg(Chain, DAG.getRegister(X86::EAX, MVT::i32), DAG.getConstant(41, MVT::i32), InFlag); InFlag = Chain.getValue(1); // 'inc eax' SDValue eaxVal =

I found a bug in the expansion code for SUB going back to at least LLVM 2.6 and still shows up in trunk. case ISD::SUB: { EVT VT = Node->getValueType(0); assert(TLI.isOperationLegalOrCustom(ISD::ADD, VT) && TLI.isOperationLegalOrCustom(ISD::XOR, VT) && "Don't know how to expand this subtraction!"); Tmp1 = DAG.getNode(ISD::XOR, dl,

Sorry to ask again, but I still can't get it right. The following code compiles and runs, but produces no instructions: Ops.push_back(DAG.getRegister(X86::EAX, MVT::i32)); Ops.push_back(DAG.getConstant(1, MVT::i32)); DAG.getNode(ISD::ADD, DAG.getVTList(MVT::i32), &Ops[0], Ops.size()); I reckon that has something to do with the fact that I am not using the Chain object. But as soon

Hi Javier, > The problem is the implementation of the expansion. Perhaps an example > can help illustrate better. Take the case of a 64-bit integer shifted > left by say 6 bits and is decomposed using 32-bit registers. Because 6 > is less than the 32 (the register size) the resulting low part should be > equal to the source low part shifted left by 6 bits. The current >

On Mon, Nov 30, 2009 at 7:22 PM, Javier Martinez <javier at jmartinez.org> wrote: > Hello, > > I'm working in adding support for 64-bit integers to my target. I'm using > LLVM to decompose the 64-bit integer operations by using 32-bit registers > wherever possible and emulating support where not. When looking at the bit > shift decomposition I saw what seems to be a

Hello LLVM, A recent commit creates the isIntDivCheap() target query. http://reviews.llvm.org/D12082 The current approach has a couple shortcomings. First, when targets decide divide is cheap, the DAGCombiner ignores obvious power-of-2 optimizations. In the targets I know, shifts are cheaper than divides in both speed and size. The target cannot see the value in the isIntDivCheap() call, so

Hi list: I have been trying to get my feet wet with the ARM backend. As a warmup exercise I wanted to be able to move jumptables especially large ones out of the code section. Currently the idiom for jump tables loooks like this // .set PCRELV0, (.LJTI9_0_0-(.LPCRELL0+8)) // .LPCRELL0: // add r3, pc, #PCRELV0 // ldr pc, [r3, +r0, lsl #2] // .LJTI9_0_0: //

On 03/14/2017 07:16 AM, vivek pandya wrote: > Hello Hal, > setCondCodeAction(expand) for un ordered comparison generates > semantically wrong code for me for example SETUNE gets converted to > SETOE that causes infinite loops. Can you please explain what is happening? It sounds like a bug we should fix. > > What is ideal place where I can convert unordered comparison to un

On Thu, Mar 9, 2017 at 9:35 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 02/25/2017 03:06 AM, vivek pandya via llvm-dev wrote: > > Note: Question is written after describing what I have coded. > > Hello LLVMDevs, > > I am trying to impliment floating point comparsion for an architecture > which > supports following type of floating point comparision if FPU

Thank you for your help. I think I managed to create the instruction I wanted: // mov eax, 41 Chain = DAG.getCopyToReg(Chain, DAG.getRegister(X86::EAX, MVT::i32), DAG.getConstant(41, MVT::i32), InFlag); InFlag = Chain.getValue(1); I don't understand though what InFlag is for. As I read the code, it even remains uninitialized when first passed to some node creation method.

Hi Duncan, The problem is the implementation of the expansion. Perhaps an example can help illustrate better. Take the case of a 64-bit integer shifted left by say 6 bits and is decomposed using 32-bit registers. Because 6 is less than the 32 (the register size) the resulting low part should be equal to the source low part shifted left by 6 bits. The current implementation places a zero

Note: Question is written after describing what I have coded. Hello LLVMDevs, I am trying to impliment floating point comparsion for an architecture which supports following type of floating point comparision if FPU is available: fcmp.un --> true if one of the operand is NaN fcmp.lt --> ordered less than, if any input NaN then return false fcmp.eq --> ordered equal, if any input NaN

On May 21, 2012, at 11:21 AM, Villmow, Micah wrote: > I found a bug in the expansion code for SUB going back to at least LLVM 2.6 and still shows up in trunk. > case ISD::SUB: { > EVT VT = Node->getValueType(0); > assert(TLI.isOperationLegalOrCustom(ISD::ADD, VT) && > TLI.isOperationLegalOrCustom(ISD::XOR, VT) && > "Don't

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

On Wed, May 20, 2009 at 5:26 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > 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