[Mesa-dev] glsl_to_tgsi error in register renumbering or merging?

[Ilia Mirkin]

This appears to be a shortcoming that expects DCE to do a bunch of
work :( It doesn't treat a write as a read, so the live range is
determined by (first_write, last_read). So if there's a write without
a later read, it won't count that as part of its live range. (And
indeed turning DCE back on makes the merging stuff work properly
again.)

On Fri, Jan 29, 2016 at 1:24 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> Hello,
>
> I've been looking at removing some of the optimization passes ahead of
> nouveau's codegen, and noticed a huge increase in instructions for
> some shaders. Upon further investigation, I think there's an error in
> the renumbering pass, which causes a bunch of values to be overwritten
> and thus dead (which nouveau then dutifully eliminates).
>
> Here's a TGSI sequence without renumbering:
>
>  94: MUL TEMP[56].xyz, TEMP[34].xxxx, TEMP[55].xyzz
>  95: MOV TEMP[32].yzw, TEMP[56].yxyz
>  96: FSGE TEMP[57].x, TEMP[48].xxxx, IMM[3].zzzz
>  97: UIF TEMP[57].xxxx :0
>  98:   MOV TEMP[58].xyz, TEMP[56].xyzx
>  99: ELSE :0
> 100:   MOV TEMP[58].xyz, IMM[3].zzzz
> 101: ENDIF
> 102: MOV TEMP[59].xyz, TEMP[58].xyzx
> 103: MOV TEMP[32].xyz, TEMP[58].xyzx
>
> And here's the same sequence with merging and renumbering enabled:
>
>  94: MUL TEMP[5].xyz, TEMP[7].xxxx, TEMP[5].xyzz
>  95: MOV TEMP[5].yzw, TEMP[5].yxyz
>  96: FSGE TEMP[7].x, TEMP[13].xxxx, IMM[3].zzzz
>  97: UIF TEMP[7].xxxx :0
>  98:   MOV TEMP[5].xyz, TEMP[5].xyzx
>  99: ELSE :0
> 100:   MOV TEMP[5].xyz, IMM[3].zzzz
> 101: ENDIF
> 102: MOV TEMP[16].xyz, TEMP[5].xyzx
> 103: MOV TEMP[5].xyz, TEMP[5].xyzx
>
> Note that the IF selects between TEMP[56].xyz and some immediate,
> where TEMP[56].xyz is the output of the MUL at label 94.
>
> However in the merged/renumbered version, it immediately overwrites
> TEMP[5].yzw with TEMP[5].xyz. If things had been adjusted to then use
> TEMP[5].yzw instead of .xyz, then it would make sense, but it doesn't
> seem like such an adjustment was made.
>
> Mainly my question is... does my analysis appear to be correct? I
> guess it should avoid merges (or renumbers?) when it does a MOV with a
> non-identity swizzle?
>
> Thanks,
>
>   -ilia
>
> P.S. FTR, this particular shader is from "Dungeon Defenders", but it's
> hardly the only example.