On Fri, Jan 10, 2014 at 6:42 PM, Jordan Justen <jljus...@gmail.com> wrote:
> On Fri, Jan 10, 2014 at 5:59 PM, Matt Turner <matts...@gmail.com> wrote:
>> On Fri, Jan 10, 2014 at 5:19 PM, Jordan Justen <jljus...@gmail.com> wrote:
>>> On Thu, Dec 19, 2013 at 1:40 PM, Matt Turner <matts...@gmail.com> wrote:
>>>> + live_intervals->start[var_to] =
>>>> MIN2(live_intervals->start[var_to],
>>>> +
>>>> live_intervals->start[var_from]);
>>>> + live_intervals->end[var_to] = MAX2(live_intervals->end[var_to],
>>>> +
>>>> live_intervals->end[var_from]);
>>>> + reg_from = -1;
>>>
>>> Do you think these are what lead to the lost programs?
>>
>> I don't think so.
>>
>>> I haven't been able to determine why they are needed starting with this
>>> patch...
>>
>> Consider
>>
>> add vgrf3:F, vgrf1:F, vgrf2:F
>> mov vgrf4:F, vgrf3:F
>> mul vgrf5:F, vgrf5:F, vgrf4:F
>>
>> register coalescing turns this into
>>
>> add vgrf4:F, vgrf1:F, vgrf2:F
>> mul vgrf5:F, vgrf5:F, vgrf4:F
>>
>> and now our live intervals are wrong, and calculating live intervals
>> is expensive. Instead of recalculating live intervals after each
>> successful iteration, we just fix var_to's start and end to keep them
>> valid.
>
> Wasn't this also the case before this patch?
Good question. Before this change the live intervals were indeed wrong
after coalescing a register, but their relative ordering is never
changed, so it didn't affect the outcome of the live interval
comparison (->vars_interfere()).
The specific bit of this patch that necessitates the live interval fix
up is the comparisons against scan_ip, which is based on us tracking
where we are in the instruction list.
if (scan_ip <= live_intervals->start[var_to])
continue;
if (scan_ip > live_intervals->end[var_to])
break;
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
