I had been assuming that give a LiveRange a, a.valno->def, if
valid, would be the same as a.start. But this is apparently not
always the case. For example:
Predecessors according to CFG: 0x839d130 (#3) 0x8462780 (#35)
308 %reg1051 = MOV64rr %reg1227<kill>
312 %reg1052 = MOV64rr %reg1228<kill>
316 %reg1053 = MOV64rr %reg1229<kill>
320 %reg1054 = MOV64rr %reg1230<kill>
324 %reg1055<dead> = LEA64r %reg1047, 1, %reg1053, 0
328 %reg1135 = MOVSX64rr32 %reg1025
332 %reg1136 = MOV64rr %reg1135<kill>
336 %reg1136 = ADD64ri32 %reg1136, -4, %EFLAGS<imp-def,dead>
340 TEST64rr %reg1136<kill>, %reg1136, %EFLAGS<imp-def>
344 JNS mbb<file solve.f, line 23, in loop at depth 1, bb16,0x83a2c70>,
Here we have the curious case of %reg1055 being defined and then immediately
killed. It's a dead assignment. Why it wasn't removed I don't know, but the
LiveInterval looks like this:
%reg1055,0 = [308,348:0 ) 0@326-(326 326)
The valno->def is 326, which is what I would expect given the instruction
So why does the live range extend throughout the entire basic block?
%reg1055 doesn't appear anywhere else in the program so it shouldn't be
live-in to the block.
A related question: LiveRange::valno is a single value, correct? In other
words it doesn't point to an array or anything, right?
If so, then isn't LiveInterval::Ranges and LiveInterval::VNInfoList redundant?
What's in VNInfoList that's not in the valno member of the Ranges elements,