[LLVMdev] [RFC, ARM] expanding RET to CopyToReg;BRIND
Chris Lattner
sabre at nondot.org
Wed May 31 12:57:14 PDT 2006
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.
> 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(...) ).
-Chris
--
http://nondot.org/sabre/
http://llvm.org/
More information about the llvm-dev
mailing list