[LLVMdev] [RFC, ARM] expanding RET to CopyToReg;BRIND

Chris Lattner sabre at nondot.org
Wed May 31 14:07:02 PDT 2006

On Wed, 31 May 2006, [UTF-8] Rafael Esp?ndola wrote:
>> Right, the register allocator sees that.  The problem is the scheduler: we
>> have to represent the dependence between the copy and the shift in a way
>> that can be expressed in the dependence dag.  We do this with a flag edge.

> Sorry. I meant the scheduler. There is a data dependency already. One
> instruction defines CL. The other one uses it.

Right.  The problem is that there is no notion of "next to" and no strict 
ordering when building the scheduling graph, so data dependencies must be 
explicitly represented in the dag.

>> > In the first case, what do you think about making it possible for an
>> > instruction to optionally depend on a value? That is, make blr depend
>> > on R3 or R3/R4 depending on the type of the return value. Something
>> > like
>> > a = DAG.getNode(ISD::BRIND, MVT::Other, Copy, LR);
>> > a.addUse(PPC::R3)
>> You can play games like that, but I wouldn't suggest it.  It's better to
>> just force the copy to be inserted in the right place.  When the register
>> allocator runs, it does know about register lifetimes and other
>> constraints, and knows that R3/R4 are live out (as indicated by
>> MF.addLiveOut(...) ).
> I am going to use the Flag by now :-)
> I was just thinking that the imposed restriction is stronger then
> necessary. For example, it might be valid to reorder
> R3 = ...
> R4 = ...
> blr
> into
> R4 = ..
> R3 = ...
> blr

Right, but notice that "..." is just a virtual register.  Once the copies 
are coallesced away, this basically amounts to saying "R3 must have this 
value and R4 must have this value before the blr".  It doesn't constrain 
in which order R3/R4 as assigned.


>> -Chris
> Thanks once more,
> Rafael
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



More information about the llvm-dev mailing list