[Mesa-dev] GLSL compiler produces different code for the same source

[Vadim Girlin]

On Sat, 2012-03-31 at 06:46 -0400, Tom Stellard wrote:
> On Sat, Mar 31, 2012 at 06:25:08AM -0400, Tom Stellard wrote:
> > On Sat, Mar 31, 2012 at 12:02:42AM -0700, Kenneth Graunke wrote:
> > > On 03/30/2012 02:11 PM, Vadim Girlin wrote:
> > > > Hi,
> > > >
> > > > I noticed that GLSL compiler sometimes produces different code for the
> > > > same shader source, e.g.:
> > > >
> > > > Vertex shader source:
> > > >
> > > >> 	gl_Position = gl_Vertex;
> > > >> 	gl_FrontColor = gl_Vertex;
> > > >
> > > > GLSL IR:
> > > >
> > > >>        (assign  (xyzw) (var_ref gl_Position)  (var_ref gl_Vertex) )
> > > >>        (assign  (xyzw) (var_ref gl_FrontColor)  (var_ref gl_Vertex) )
> > > >>        (assign  (xyzw) (var_ref gl_Position at 2)  (var_ref gl_Position) )
> > > >>        (assign  (xyzw) (var_ref gl_FrontColor at 3)  (var_ref gl_FrontColor) )
> > > >
> > > > Another variant has another order of the last two assignments:
> > > >
> > > >>        (assign  (xyzw) (var_ref gl_FrontColor at 4)  (var_ref gl_FrontColor) )
> > > >>        (assign  (xyzw) (var_ref gl_Position at 5)  (var_ref gl_Position) )
> > > >
> > > > Both variants are correct, but it makes the debugging harder - e.g. one
> > > > of the variants uncovers the bug in my code, and it's hard to reproduce
> > > > it. I guess we might want to remove the dependency on the moon phase
> > > > etc, and maybe provide some way to control it for debugging.
> > > >
> > > > My knowledge of the GLSL compiler is still not good enough to fix it
> > > > quickly, so I'd be grateful if somebody could help.
> > > >
> > > > There is the reduced test program in the attachment that demonstrates
> > > > the problem. It compiles the shader every second, so running it with the
> > > > following command line usually shows both variants during the first 10
> > > > seconds:
> > > >
> > > >> MESA_GLSL=dump ./test | grep -A 20 linked
> > > >
> > > > Vadim
> > > 
> > > Weird...I have no idea why it would do that.
> > > 
> > > So far, I haven't been able to reproduce this locally, either with your 
> > > test program, glslparsertest, or the standalone compiler.  Valgrind 
> > > doesn't seem to have any complaints about uninitialized data, either...
> > > 
> > > Can anyone else reproduce this?
> > 
> > I was able to reproduce this with r300g.  Is it possible that one of the
> > shader CAPS is causing this?
> 
> Or maybe the ordering of keys in a hash?
> 

It seems you are right, the output_read_remover stores the mapping of
the output variables to the temps in the hash table, using the pointers
as the hash. Probably we need to use some other hash function to fix the
ordering, e.g. use hash of the variable name?

Vadim