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

[Rafael Espíndola]

On 5/31/06, Chris Lattner <sabre at nondot.org> wrote:
> On Wed, 31 May 2006, [UTF-8] Rafael Esp?ndola wrote:
> >> We don't want the copy and shift to wander apart from each other (e.g. we
> >> don't want another shift to get scheduled in between them), so we flag
> >> them together.  In practice, these copies usually get coallesced away.
> > In the second case shl explicitly uses CL. Shouldn't the register
> > allocator be smart enough to avoid scheduling an instruction that
> > destroys CL in between them?
>
> 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.

> > 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

> -Chris

Thanks once more,
Rafael