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? > To make sure that none of the other instructions are affected, we > temporarily replace the MOV with a NOP and then after the pass is over > remove all of the NOPs when it's safe to invalidate the live > intervals. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
