understanding DAG: node creation

Hi Dmitri,

If you have such a simple intrinsic which operates on a single register, just lower the intrinsic to a target specific node which is only implemented by a single instruction. Like you were doing before and by using a chain operand. Hard code the instruction to use and define the global register and only pass the instruction the actual variable argument.

Hope that helps,
Sam

Sam Parker
Research Student
Electronic Systems Design Group
School of Electronic, Electrical and Systems Engineering
Loughborough University

Sam, thanks for your answer.

That’s a great suggestion.

And excuse me for maybe dilettante question:

To hard-code use of the global register means to hard-code it in the ‘asm string’ argument of the instruction definition in the .td file?

Hi,

Yes, that's what I would do. If you want LLVM and the register allocator to also know that the instruction explicitly defines the register, I would designate the register into it's own register class and have your instruction write to that class (and there will be only a single option for RA).

cheers,
Sam

Sam Parker
Research Student
Electronic Systems Design Group
Loughborough University
UK

Before I wrote here, I tried both ways you decsribed, but none of them has worked out for me.

With yours sugesstions I was able to move a bit further with the first approach (when we don’t create regclass and just hard-code it in .td)

But I still receive strange errors. I received DAG which I happy with (DAG here: http://goo.gl/62tpkk), but everything goes broken on scheduling.

I had to chain mine nodes, because otherwise nodes xmac and srxacc got removed on first combine. But since they are chained, they have MVT::Other return type, and that causes strange crash inside func GetCostFor in ScheduleDAGRRList.cpp:

Def RegClass = TLI->getRepRegClassFor(VT)->getID();

When VT is MVT::Other it returns 0x0, what results crash.

It got me confused, because reading documentation on CodeGen gave me an idea, that chain edges are control flow edges, not data edges. So I don’t understand why scheduler tries to assign some register to it.

I’m struggling with this problem way to long for now, and I very appreciate yours help, Sam.

Hi,
I'm not sure. But in your lowered DAG the chain nodes are the first operands for you custom nodes, however for the other nodes the chain is the last operand. I seem to remember that during targetlowering the chain is the first operand and then it seems to switch over after ISelDAG, this confused me and may have something to do with the issue that you are seeing. I really don't know much about scheduling, do you want to post your instruction definitions again to see if someone else has some ideas,.

cheers,
sam

Sam Parker
Research Student
Electronic System Design Group
School of Electronic, Electrical and Systems Engineering
Loughborough University
UK

Yes, I’m going to provide it. I believe there must be no additional work on the scheduling phase. It’s just some mistake in the instruction definition or DAG.

I create Nodes inside SelectionDAGBuilder::visitIntrinicCall like that:

case Intrinsic::sparc_xmac: {
SDVTList nodeTys = DAG.getVTList(MVT::Other, MVT::i32);
SDValue Ops[3];
Ops[0] = getRoot();
Ops[1] = getValue(I.getArgOperand(0));
Ops[2] = getValue(I.getArgOperand(1));
SDValue xmacCall = DAG.getNode(ISD::XMAC, sdl, nodeTys, Ops);
DAG.setRoot(xmacCall.getValue(0));
return nullptr;
}
case Intrinsic::sparc_srxacc: {
SDVTList nodeTys = DAG.getVTList(MVT::Other, MVT::i32);
SDValue Ops[2];
Ops[0] = getRoot();
Ops[1] = getValue(I.getArgOperand(0));
SDValue srCall = DAG.getNode(ISD::SRXACC, sdl, nodeTys, Ops);
DAG.setRoot(srCall.getValue(0));
return nullptr;
}
case Intrinsic::sparc_lrxacc: {
SDVTList nodeTys = DAG.getVTList(MVT::Other,MVT::i32);
SDValue Ops[1];
Ops[0] = getRoot();
SDValue lrCall = DAG.getNode(ISD::LRXACC, sdl,
nodeTys, Ops);
DAG.setRoot(lrCall.getValue(0));
setValue(&I, lrCall.getValue(1));
return nullptr;
}

Then, lower them trivially.

setOperationAction(ISD::LRXACC, MVT::Other, Legal);
setOperationAction(ISD::SRXACC, MVT::Other, Legal);
setOperationAction(ISD::XMAC, MVT::Other, Legal);

Then, just set respective instr opcodes in SparcDAGToDAGISel::Select:

case ISD::SRXACC: {
SDVTList nodeTys = CurDAG->getVTList(MVT::Other);

SDValue Ops[2];
Ops[0] = N->getOperand(0);
Ops[1] = N->getOperand(1);

return CurDAG->SelectNodeTo(N, SP::SRXACC, nodeTys, Ops);
}
case ISD::XMAC: {
SDVTList nodeTys = CurDAG->getVTList(MVT::Other);

SDValue Ops[3];
Ops[0] = N->getOperand(0);
Ops[1] = N->getOperand(1);
Ops[2] = N->getOperand(2);
``
return CurDAG->SelectNodeTo(N, SP::XMAC, nodeTys, Ops);
}
case ISD::LRXACC: {
SDVTList nodeTys = CurDAG->getVTList(MVT::Other, MVT::i32);
SDValue Ops[1];
Ops[0] = N->getOperand(0);
return CurDAG->SelectNodeTo(N, SP::LRXACC, nodeTys, Ops);
}

They declared as:
def XMAC : F3_1<2, 0b111111,
(outs),
(ins IntRegs:$rs1, IntRegs:$rs2),
"xmac $rs1, $rs2, %xacc",
[]>;

let rs1 = 0, rd = 1, Uses=[XACC] in
def LRXACC : F3_1<2, 0b101110,
(outs IntRegs:$rd), (ins),
"lrxacc %xacc, $rd", []>;

let rd = 0, Defs=[XACC] in
def SRXACC : F3_1<2, 0b011101,
(outs), (ins IntRegs:$rs1),
"srxacc $rs1, %xacc", []>;

While my register is declared as:
def XACC : Ri<88, “XACC”>, DwarfRegNum<[88]>;

Please, note:

My problem is of self-educational and investigative nature.

This instruction srxacc and register xacc are not real.

Produced code aren’t supposed to work anywhere.

I just need llc to be able to output assembly file.

Thanks for your insights.

Hi,

I would still switch chain operands to be the last ones and ensure that lxacc result type is (MVT::i32, MVT::other) and not the other way around.

good luck,
sam

Sam Parker
Research Student
Electronic System Design Group
School of Electronic, Electrical and Systems Engineering
Loughborough University
UK

Sam, that helped. Thank you so much.