[LLVMdev] Implicit defs

[Roman Levenstein]

Hi Chris,

--- Chris Lattner <sabre at nondot.org> wrote:

> On Sat, 14 Oct 2006, Roman Levenstein wrote:
> > OK. I have not explained in my first email about DEFs everything I
> > wanted, the second one was a bit more specific ;) Of course, I
> realize
> > that I can add explicit DEFs to the machine instruction. But is it
> > possible to do it at the higher level, e.g. in the ISelLowering
> passes,
> > where no machine insns are generated yet. Basically, it is
> currently
> > possible at this level to do the mapping of virtual registers for
> > parameters to the physical registers, and this can be done without
> any
> > problems. It is usually done in  LowerCALL or something like that.
> I'd
> > like to do the same for return registers at the same place, to keep
> all
> > these related things together and because of certain symmetry of
> goals.
> > But if I would do it as you propose, I'll need to put somewhere
> else,
> > where we can operate at  the MI level, right? So the question is
> > actually about possibility of doing it in LowerCALL, where MIs are
> not
> > generated yet.
> 
> This is certainly possible, but requires some C++ code.  I assume you
> have 
> something like the PPC backend right now.  If so, you have this in
> your 
> lowering code:
> 
>    // Add argument registers to the end of the list so that they are
> known live
>    // into the call.
>    for (unsigned i = 0, e = RegsToPass.size(); i != e; ++i)
>      Ops.push_back(DAG.getRegister(RegsToPass[i].first,
>                                   
> RegsToPass[i].second.getValueType()));
>    if (InFlag.Val)
>      Ops.push_back(InFlag);
>    Chain = DAG.getNode(CallOpc, NodeTys, &Ops[0], Ops.size());
> 
> This creates a call node with a list of input registers, these are
> marked 
> as uses.  In the PPC backend, this is matched with this pattern:
> 
> ...
>    def BLA : IForm<18, 1, 1, (ops aaddr:$func, variable_ops),
>                              "bla $func", BrB, [(PPCcall (i32
> imm:$func))]>;
> ...
> 
> The "variable_ops" part of the operation list causes all those
> registers 
> to be added to the node when the isel turns the isel graph into the
> sched 
> graph.  Unfortunately, this will not work with extra definitions
> (call 
> clobbered regs in your case).
> 
> Perhaps the easiest way to handle this whole thing is to add an
> integer operand to the DAG call node that indicates the calling 
> convention used. 
> You can then use a 'usesCustomDAGSchedInserter' inserter to create
> the  machine instr any way you like based on this information.  
> See the PPC backend and how it inserts SELECT_CC_I4, for example.  
> In your case, you  would result in one machine instr (instead of the 
> many SELECT_CC_I4 produces).

Thanks for the hint. I did it as you describe. Well, almost. Instead of
using the calling convention as an additional argument, I directly put
the list of DEF regs into the list of operands.

Taking the code above as an example, I do something like:

// Put a list registers implicitly DEFined by this instruction
Ops.push_back(DAG.gettargetConstant(isDefReg1, MVT::i32); 
...
Ops.push_back(DAG.gettargetConstant(isDefRegN, MVT::i32); 
// Put a delimiter indicating the end of the list 
Ops.push_back(DAG.gettargetConstant(specialDelimiterValue, MVT::i32); 
// Here comes the usual ops.push_back(DAG.getRegister(...)) for USEed 
// registers

And then when processing the usesCustomDAGSchedInserter-marked CALL
insn, I basically create a CALL instruction by iterating over this list
and adding all of the regs from the DEF list as isDef operands of the
machine instruction. This works without any problems and enforces the
required register constraints.

Having done that, I'll concentrate now on the mapping of 64bit FP regs
2x32bit integer regs and register allocation of them.

Thanks again,
 Roman



 
____________________________________________________________________________________
Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates 
(http://voice.yahoo.com)