Bug 89759

These also fail on r600. This is probably a st/mesa-level or glsl ir-level issue. Haven't gotten any confirmation from anyone using i965, but I'm reassigning this to mesa core.

I suspect that the following is the cause of the trouble:

	b[1] = a[1];
	c[1] += d[1];
	a[1] += 1.0;

If the += 1 gets reordered to before the b[1] = a[1], then we're in trouble. I get cyan as the output, with 182 for the first component, which means that

	if(b[1] == 1.0) q += 2.0;

is failing. Haven't quite figured out how to convert these webgl tests into piglits quite yet, although this one should be easy since it's not input-dependent.

Connor just confirmed that these pass on i965, so most likely a st/mesa issue. [Which doesn't have its own component.]

Created attachment 114617 [details]
shader test

Confirmed that it's the

	a[1] += 1.0;

line causing the trouble. If I comment it out, I get the expected white output.

Looks like the st/mesa copy propagation pass fails... commenting out

v->copy_propagate();

makes the original shader work. Probably not the right forum, but why do we bother with the tgsi optimizations? All the backend drivers do the same things anyway (and in a way that works... :) )

FTR, the issue is that before the copy prop we have

DCL TEMP[1..4], ARRAY(1), LOCAL
DCL TEMP[5..8], ARRAY(2), LOCAL
DCL TEMP[9..12], ARRAY(3), LOCAL
DCL TEMP[13..16], ARRAY(4), LOCAL
DCL TEMP[17..20], ARRAY(5), LOCAL
DCL TEMP[21..24], ARRAY(6), LOCAL
DCL TEMP[25..26], LOCAL

 28: MOV TEMP[25].x, TEMP[14].xxxx
 30: ADD TEMP[14].x, TEMP[14].xxxx, IMM[0].yyyy
 46: FSEQ TEMP[26].x, TEMP[25].xxxx, IMM[0].yyyy

And the copy propagation pass decides to copy-prop TEMP[14] into TEMP[25] on line 46. This ends poorly. Perhaps because file == PROGRAM_ARRAY isn't properly supported by the pass? Not sure. Sent a patch to just remove.

Dave pushed a fix in commit 91e3533481. Thanks for reporting!