similar to: [LLVMdev] Inserting nodes into SelectionDAG (X86)

Displaying 20 results from an estimated 5000 matches similar to: "[LLVMdev] Inserting nodes into SelectionDAG (X86)"

2009 Jun 26
2
[LLVMdev] Inserting nodes into SelectionDAG (X86)
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.
2009 Jun 25
0
[LLVMdev] Inserting nodes into SelectionDAG (X86)
On Jun 25, 2009, at 2:05 PM, Artjom K. wrote: > > Greetings, > > I am rather new to LLVM, so please excuse my limited knowledge about > it. > > Currently I am trying to modify the X86TargetLowering::LowerCALL > method by > inserting additional instructions before the call. > As far as I understand, nodes are created by calling the getNode > method on >
2009 Jul 01
3
[LLVMdev] Inserting nodes into SelectionDAG (X86)
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
2009 Jul 03
0
[LLVMdev] Inserting nodes into SelectionDAG (X86)
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 =
2009 Jun 29
2
[LLVMdev] Inserting nodes into SelectionDAG (X86)
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
2009 Jun 27
0
[LLVMdev] Inserting nodes into SelectionDAG (X86)
On Jun 26, 2009, at 4:49 AM, Artjom K. wrote: > > 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
2009 Jul 01
0
[LLVMdev] Inserting nodes into SelectionDAG (X86)
On Jun 29, 2009, at 9:00 AM, Artjom Kochtchi wrote: > > 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()); To read the
2007 Oct 05
0
[LLVMdev] RFC: Tail call optimization X86
Hi Evan, I incoporated the changes you request but to the following i have got a question: > Also, moving the option > there will allow us to change fastcc ABI (callee popping arguments) > only when this option is on. See Chris' email: I am not to sure on that. because that would make modules compiled with the flag on incompatible with ones compiled without the flag off as
2007 Oct 04
3
[LLVMdev] RFC: Tail call optimization X86
Comments: CheckDAGForTailCallsAndFixThem - 1. for (SelectionDAG::allnodes_iterator BE = DAG.allnodes_begin(), + BI = prior(DAG.allnodes_end()); BI != BE; BI--) { Please use pre-decrement instead of post-decrement. 2. The function is slower than it should be. You are scanning all the nodes in the DAG twice. You should just examine DAG.getRoot() to make determine whether it's a
2007 Jan 14
0
[LLVMdev] Inserting an assembly instruction in the calling sequence of the powerpc target
On Fri, 12 Jan 2007, Nicolas Geoffray wrote: > I'm currently implementing a linux/ppc target in llvm. The abis between cool > Darwin/ppc and linux/ppc are different and I'm running into problems > with vararg calls. ok > Before a variadic method is called, an extra instruction must be > executed (which is creqv 6, 6, 6). This instruction is not necessary in >
2008 Jul 10
2
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Cool, that worked. New patch attached... Cheers, Gary Evan Cheng wrote: > Just cast both values to const TargetRegisterClass*. > > Evan > > On Jul 10, 2008, at 7:36 AM, Gary Benson wrote: > > Evan Cheng wrote: > > > How about? > > > > > > const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : > > > &PPC:G8RCRegClass; >
2007 Oct 05
6
[LLVMdev] RFC: Tail call optimization X86
On Oct 5, 2007, at 2:42 AM, Arnold Schwaighofer wrote: > Hi Evan, > I incoporated the changes you request but to the following i have got > a question: > >> Also, moving the option >> there will allow us to change fastcc ABI (callee popping arguments) >> only when this option is on. See Chris' email: > > I am not to sure on that. because that would make
2008 Jul 08
0
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
PPCTargetLowering::EmitInstrWithCustomInserter has a reference to the current MachineFunction for other purposes. Can you use MachineFunction::getRegInfo instead? Dan On Jul 8, 2008, at 1:56 PM, Gary Benson wrote: > Would it be acceptable to change MachineInstr::getRegInfo from private > to public so I can use it from > PPCTargetLowering::EmitInstrWithCustomInserter? > >
2007 Jan 12
2
[LLVMdev] Inserting an assembly instruction in the calling sequence of the powerpc target
Hi all, I'm currently implementing a linux/ppc target in llvm. The abis between Darwin/ppc and linux/ppc are different and I'm running into problems with vararg calls. Before a variadic method is called, an extra instruction must be executed (which is creqv 6, 6, 6). This instruction is not necessary in Darwin/ppc. I looked into the PowerPC target implementation and the code generation
2008 Jul 10
0
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Just cast both values to const TargetRegisterClass*. Evan On Jul 10, 2008, at 7:36 AM, Gary Benson wrote: > Evan Cheng wrote: >> How about? >> >> const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : >> &PPC:G8RCRegClass; >> unsigned TmpReg = RegInfo.createVirtualRegister(RC); > > I tried something like that yesterday: > > const
2008 Jul 10
2
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Evan Cheng wrote: > How about? > > const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : > &PPC:G8RCRegClass; > unsigned TmpReg = RegInfo.createVirtualRegister(RC); I tried something like that yesterday: const TargetRegisterClass *RC = is64bit ? &PPC::GPRCRegClass : &PPC::G8RCRegClass; but I kept getting this error no matter how I arranged it:
2008 Jun 30
0
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
You need to insert new basic blocks and update CFG to accomplish this. There is a hackish way to do this right now. Add a pseudo instruction to represent this operation and mark it usesCustomDAGSchedInserter. This means the intrinsic is mapped to a single (pseudo) node. But it is then expanded into instructions that can span multiple basic blocks. See
2008 Jul 08
2
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Would it be acceptable to change MachineInstr::getRegInfo from private to public so I can use it from PPCTargetLowering::EmitInstrWithCustomInserter? Cheers, Gary Evan Cheng wrote: > Look for createVirtualRegister. These are examples in > PPCISelLowering.cpp. > > Evan > On Jul 8, 2008, at 8:24 AM, Gary Benson wrote: > > > Hi Evan, > > > > Evan Cheng wrote:
2008 Jun 30
2
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Chris Lattner wrote: > On Jun 27, 2008, at 8:27 AM, Gary Benson wrote: > > def CMP_UNRESw : Pseudo<(outs), (ins GPRC:$rA, GPRC:$rB, i32imm: > > $label), > > "cmpw $rA, $rB\n\tbne- La${label}_exit", > > [(PPCcmp_unres GPRC:$rA, GPRC:$rB, imm: > > $label)]>; > > } > > > > ...and
2006 Oct 15
2
[LLVMdev] Implicit defs
Hi Chris, Thanks for your response. > On Sat, 14 Oct 2006, Roman Levenstein wrote: > > Is it possible to dynamically define implicit defs for some > > instructions? > > Yes! This is what explicit operands are :). Specifically, if you > want to > vary on a per-opcode basis what registers are used/def'd by the > instruction, you can just add those registers