[PATCH] Add a case to LiveIntervalAnalysis::HandleMoveUp

[Jakob Stoklund Olesen]

On Mar 6, 2013, at 2:01 PM, Vincent Lejeune <vljn at ovi.com> wrote:

> Hi Jakob,
> 
>> 
>> Did you read my previous mail about the problem with live-out values? You 
>> didn't address the problem.
> 
> I actually don't understand what should be done for live out values.
> For instance if I have the following LiveInterval :
> 
> [48r,64r:2)[64r,80r:3)[80r,96B:4)[96B,336r:0)[448B,640r:0)[640r,672r:1)[672r,688r:5)[688r,704r:6)[704r,816B:7)
> With block boundaries :
> [0B;80B][96B;240B][256B;432B][448B;800B]
> My reasoning is the following :
> LiveRange that represents live-out value in the first bloc is [80r;96B] ;
> If I move 80r to 8B for instance, I'm expecting the the first three LiveRange to be :
> [8r,48r:4)[48r,64r:2)[64r,96B:3)
> ie val 3 is becoming the new live-out value, that ends where value 4 ended before.

The point is that the LiveInterval representation of liveness is just a compression method. A single LiveRange object can span multiple basic blocks, but for values that are live in more than one basic block, there is no guarantee that it only appears in a single LiveRange object. That depends on the block layout which you can't make assumptions about.

To avoid scanning the whole LiveInterval looking for instances of the escaped value, I would suggest that you change your code so the value number escaping the basic block doesn't change.

That would mean that the escaping value number is now defined by a different instruction - the one that is now the last def in the block.

/jakob