[PATCH] LiveRangeCalc: Don't start liveranges of PHI instruction at the block begin.

[Quentin Colombet]

> On Feb 20, 2015, at 11:49 AM, Matthias Braun <matze at braunis.de> wrote:
> 
>> 
>> On Feb 20, 2015, at 11:43 AM, Quentin Colombet <qcolombet at apple.com> wrote:
>> 
>> 
>>> On Feb 20, 2015, at 11:28 AM, Matthias Braun <matze at braunis.de> wrote:
>>> 
>>> I don't think it really matters one way or another. Given code that looks like this:
>>> 
>>> 100B   BB#XX ...
>>> 116B    %vreg1 = PHI %vreg8, %vreg42
>>> 132B    %vreg2 = PHI %vreg42, %vreg8
>>> ...
>>> 
>>> previously the liveranges for vreg1 and vreg2 would start at 100B, with my patch they start at 116B/132B.
>>> 
>>> * Starting the range at 100B is closer to the reality of values living into the block and PHIs not really being instructions.
>>> * Starting the range at 100B is contrary to the fact that the definition points of %vreg1/%vreg2 are at 116B/132B.
>>> * Either way %vreg1 and %vreg2 interfere so we should be fine in this regard.
>>> * The problem that motivated my change: We maintain an SSA representation for our liverange segments which have value numbers assigned. In case multiple value numbers reach a block we create a new one and let the live segment start at the block begin (you could call that an implicit PHI). This situation looks exactly the same as the case with PHI instructions, although it is not! The values that are picked in the predecessors are from %vreg8/%vreg42 which is in a different liveranges.
>>> 
>>> The last point would break the MachineVerifier (if it would actually run here) and breaks new code I am writing right now because I need a way to differentiate between "implicit PHIs" from live segment joins and live ranges started by PHI instructions. I could not think of a reason why letting live ranges start at the phi instructions would be bad, so I sent out the patch to get some opinions.
>> 
>> My concern is that, IIRC, it will introduce a bias in the spill cost of otherwise identical segments, since now some lengths will be artificially shorter.
> When we are spilling we are not in SSA form anymore, so this situation won't happen. This situation only happens for the few times when live intervals are calculated on the Machine-SSA form.

Indeed :).

LGTM then!

-Quentin

> 
> - Matthias
> 
>> 
>> -Quentin
>> 
>>> 
>>> - Matthias
>>> 
>>> PS: CC to Andy, maybe he has some comments for this.
>>> 
>>>> On Feb 20, 2015, at 10:56 AM, Quentin Colombet <qcolombet at apple.com> wrote:
>>>> 
>>>> Hi Matthias,
>>>> 
>>>> I am not sure this is the right thing to do.
>>>> Because of this change, we would have an order in phi definitions whereas there is in fact none.
>>>> 
>>>> That may make the machine verifier code more complicated, but I think this is what need to be fixed.
>>>> 
>>>> What do you think?
>>>> 
>>>> Thanks,
>>>> -Quentin
>>>> 
>>>> 
>>>> http://reviews.llvm.org/D7779
>>>> 
>>>> EMAIL PREFERENCES
>>>> http://reviews.llvm.org/settings/panel/emailpreferences/
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> llvm-commits mailing list
>>>> llvm-commits at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>> 
>> 
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150220/6c7ecce7/attachment.html>