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