[LLVMdev] LiveInterval Questions

dag at cray.com dag at cray.com
Mon Oct 14 12:53:46 PDT 2013


I have never quite understood the "phi def" concept of LiveInterval.  I
understand that a phi def LiveRange originally came from a phi
instruction but I'm not sure how to use the information after phi
elimination.

For example, I have this LiveInterval:

[3472r,6688B:3)[6688B,8240B:2)[8240B,8976B:0)[8976B,12160B:1)[12160B,13744B:4)[13744B,14480B:5)[1448
0B,18048B:6)[18048B,19792B:7)[19792B,20192r:8)  0 at 8240B-phi 1 at 8976B-phi 2 at 6688B-phi 3 at 3472r 4 at 12160B
-phi 5 at 13744B-phi 6 at 14480B-phi 7 at 18048B-phi 8 at 19792B-phi

There is only one non-phi def.  The (one) instruction defining the
virtual register containing value #3 is at the top level of the
function, not in a loop nest and not under a condition:

3472B		%vreg637<def> = MOV64rm <fi#0>, 1, %noreg, 32, %noreg; mem:LD8[%37](align=32) GR64:%vreg637 dbg:file.c:46 [comments:

Because of the multiple value numbers resulting from the phi defs, what
appears at first to be a live interval that could be collapsed into one
LiveRange cannot be so collapsed.

The information I'm showing is after machine instruction scheduling,
immediately before register allocation.  Coalescing has already run.  I
am making a transformation which requires updating live interval
information and I am having trouble getting the updates correct.

I have several questions about this situation:

- Why are there any phi defs at all given that the register is only ever
  defined once at the top level of the function?  No defs of vreg637
  appear anywhere else.

- Am I correct about the multiple phi defs preventing merging of the
  LiveRanges into one?

- What do these phi defs mean semantically?  Should I assume all the phi
  defs eventually refer back to the original #3 value def?

- What if there were more than one non-phi def?  How do I know which phi
  defs associate with which non-phi defs?

I hope the questions make some sense.

                              -David



More information about the llvm-dev mailing list