[llvm-commits] [llvm] r78650 - in /llvm/trunk: include/llvm/CodeGen/RegisterScavenging.h lib/CodeGen/RegisterScavenging.cpp test/CodeGen/Blackfin/2009-08-11-RegScavenger-CSR.ll

Jakob Stoklund Olesen stoklund at chora.dk
Wed Aug 12 01:26:23 PDT 2009


Here is another way of slicing it. Look at a CSR on entry to an MBB. We
have the folowing scenarios:

1. We are before PEI.
2. CSR has been spilled in an MBB upstream in the CFG.
3. CSR is pristine and will be spilled in this MBB.
4. CSR is pristine and will not be used in this MBB.

Cases 1. and 2. are easy - we treat the CSR like any other register. It
can be live-in or dead-in depending on how it has been used before.

In case 3. the CSR has been marked as live-in by PEI.

In case 4. the CSR is not marked live-in.

In any case, the register scavenger will need a list of pristine CSRs on
entry to each MBB. It needs to track them as unavailable. This list
should be provided by PEI because it can be tricky to calculate under
shrink wrap.

The machine code verifier also wants access to this info.

The question is, do we need to implement a separate mechanism for
tracking pristine CSRs, or can we just stick them in the live-in lists?

If we track pristine CSRs separately, the regscavenger will be able to
ask the target to fix the prologue/epilogue only when needed.

If we treat pristine CSRs as any other live register, the target must be
able to determine if a CSR has already been spilled in the prologue. The
regscavenger won't know.

/jakob




More information about the llvm-commits mailing list