Print Register Liveness Information

Hi,

Is there a way to print the register liveness information into the assembly file or as some intermediate listing?

To be more precise, I am looking at figuring out the following information in an assembly file/listing.

Say, for simplicity, our register set is only { rsp, rbp, eax }

subq $16, %rsp // rsp is killed here, eax and rbp are live
movl $0, -4(%rbp) // rbp is killed here, rsp and eax are live
xorl %eax, %eax // eax is killed here, rsp and rbp are live
movl $1, %eax // eax is killed here, rsp and rbp are live

Is there a way LLVM stores this information somewhere before producing assembly?

I haven’t dug into the source code yet, but intuitively the information must be there and hence maybe some pass dumps that info?

Thanks!

Hi Anitha,

The liveness information is usually dropped after regalloc.
Therefore the short answer is no, this information is not available before producing assembly.

However, we have the live-ins and you can request the kill flag to be set. From both this information, you can recompute the liveness.
I’d suggest you use the LivePhysReg helper class and use its result to annotate your assembly (emitComment or something along those lines).

Cheers,
-Quentin

Note that this only works for targets that say TargetRegisterInfo::trackLivenessAfterRegAlloc()== true.

Good point!
Additionally this might gets invalidated by some passes (look for MachineRegisterInfo::invalidateLiveness)

Good point!
Additionally this might gets invalidated by some passes (look for MachineRegisterInfo::invalidateLiveness)

Thanks for the pointers! What is the rational behind invalidating
register liveness info? Does it consume lot of memory during compilation?

-Anitha

Good point!
Additionally this might gets invalidated by some passes (look for MachineRegisterInfo::invalidateLiveness)

Thanks for the pointers! What is the rational behind invalidating
register liveness info? Does it consume lot of memory during compilation?

There are mainly two reasons:

  1. If you don’t need it later, we don’t bother maintaining it to save compile time
  2. Some transformations may do complex transformations (e.g., on the CFG) and keeping the information up-to-date is too error-prone and we just bail

#2 is usually less common but it can happen.