[LLVMdev] LiveIntervals::handlePhysicalRegisterDef, unreachable MBBs

Alkis Evlogimenos alkis at cs.uiuc.edu
Fri Jul 9 06:30:02 PDT 2004

On Fri, 2004-07-09 at 05:02, Vladimir Prus wrote:
> I've just spend some time looking at the above function, and while I 
> understood what it does, a comment would have helped a lot.

Thanks for bringing this to my attention!

> Maybe, something like:
> // Determine the end of the live interval for this register
> // For physical register, all internvals are within basic blocks so
> // we look for the instruction in this basic block which last uses it.
> The first loop might have a comment like:
> // If the register is dead at instruction which sets it (i.e. not used later)
> // the live interval ends at the next instruction

Actually it ends at the same instruction. Each instruction has 4 slots.
So instruction 0 spans interval indexes 0-3, instruction 1 4-7 and so
on. In the case above the interval added is:

[defSlot(instr), defSlot(instr)+1)

You may notice that this interval is "empty" in the interval indexes
discrete world (i.e. [13,14)). Indeed it is, and its only purpose is to
naturally express this clobbering of physical registers to the register
allocator. For example given [13,14) for some physical register A and a
live interval [0,27) for some virtual register Z, we cannot allocate A
to Z because of the overlap!

> The second loop might have a comment like:
> // If the register is not dead at the defining instruction, it must be used
> // and killed by some subsequent instruction. Find that instruction now, which
> // always exists

I added comments to the handlePhysicalRegisterDef. Let me know if it
makes more sense now.

> Finally, why I've started all this. I forgot to add machine CFG edge and got 
> misterious crash. I've applied the attached patch, which checks that all 
> basic blocks are reachable from function entry. Any comments on:
> - whether this check is reasonable?
> - what's the right place for the check? LiveVariables.cpp is the simplest I 
> could find, but does not seem right.

I am not sure about this change. I will let others comment on it.



More information about the llvm-dev mailing list