[PATCH] Add a case to LiveIntervalAnalysis::HandleMoveUp

[Vincent Lejeune]

(btw I tested them with llvm-test-suite on x86, I have some  "execution_time" labeled tests failing,
but they also fail without these patches)




----- Mail original -----
> De : Vincent Lejeune <vljn at ovi.com>
> À : Jakob Stoklund Olesen <stoklund at 2pi.dk>
> Cc : Andrew Trick <atrick at apple.com>; Commit Messages and Patches for LLVM <llvm-commits at cs.uiuc.edu>
> Envoyé le : Mardi 12 mars 2013 15h26
> Objet : Re: [PATCH] Add a case to LiveIntervalAnalysis::HandleMoveUp
> 
> Hi Jacob and Andrw,
> 
> I reworked my patch so that now it does not change the value of a live out 
> value. It also keep live in value.
> The 2 others patches enable mov of instructions that access sub-register (needed 
> to test the feature).
> 
> I added some tests using -verify-misched in a previous patch : 
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130311/167949.html
> They come from piglit (the test suite we use for opengl) and failed often when I 
> was working on handlemove of subregs,
> I think they would be good candidate for unit testing the feature.
> 
> There are also 4 unit tests in the third patches, these are simple modules which 
> generated not optimal code
> without recomputing the schedule graph ; the tests check now that they do.
> 
> Thank for your help in getting these patches in a proper form (although I think 
> they need reviews) and for your patience.
> Vincent
> 
> 
> 
> 
> ----- Mail original -----
>>  De : Jakob Stoklund Olesen <stoklund at 2pi.dk>
>>  À : Vincent Lejeune <vljn at ovi.com>
>>  Cc : Andrew Trick <atrick at apple.com>; Commit Messages and Patches for 
> LLVM <llvm-commits at cs.uiuc.edu>
>>  Envoyé le : Mercredi 6 mars 2013 23h11
>>  Objet : Re: [PATCH] Add a case to LiveIntervalAnalysis::HandleMoveUp
>> 
>> 
>>  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
>> 
>