[Mesa-dev] [glsl] indvar in ir_loop

Ian Romanick idr at freedesktop.org
Fri Oct 11 23:39:09 CEST 2013


On 10/10/2013 11:14 PM, Liu Xin wrote:
> Hi, Mesa developers,
> 
> According to glsl v1.0, we have loop construct:
> for (for-init-statement; condition(opt); expression)
> statement-no-new-scope
> 
> Variables declared in for-init-statement or condition are only in scope
> until the end of the
> statement-no-new-scope of the for loop.
> 
> let's assume I have a fragment shader:
> 
> ~/testbed$ cat indvar.frag
> void main(void)
> {
>         vec4 a[32];
>         for(int i=0; i<10; ++i) {
>                 if (i == 9)
>                     gl_FragColor = a[i];
>        }
> }
> 
> 
> I found current glsl compiler emits HIR like this:

The HIR loses all notions of scope.

> (function main
>   (signature void
>     (parameters
>     )
>     (
>       (declare () int i at 0x988eb84)
>       (declare () (array vec4 32) a at 0x988ec5c)
>       (declare (temporary ) int assignment_tmp at 0x988eaac)
>       (assign (constant bool (1)) (x) (var_ref
> assignment_tmp at 0x988eaac)  (constant int (0)) )
>       (assign (constant bool (1)) (x) (var_ref i at 0x988eb84)  (var_ref
> assignment_tmp at 0x988eaac) )
>       (loop () () () () (
>         (if (expression bool ! (expression bool < (var_ref i at 0x988eb84)
> (constant int (10)) ) ) (
>           break
>         )
>         ())
> 
>         (if (expression bool all_equal (var_ref i at 0x988eb84) (constant
> int (9)) ) (
>           (declare (temporary ) vec4 assignment_tmp at 0x987cee4)
>           (assign (constant bool (1)) (xyzw) (var_ref
> assignment_tmp at 0x987cee4)  (array_ref (var_ref a at 0x988ec5c) (var_ref
> i at 0x988eb84) ) )
>           (assign (constant bool (1)) (xyzw) (var_ref
> gl_FragColor at 0x96d8fc4)  (var_ref assignment_tmp at 0x987cee4) )
>         )
>         ())
> 
>         (declare (temporary ) int assignment_tmp at 0x987cb84)
>         (assign (constant bool (1)) (x) (var_ref
> assignment_tmp at 0x987cb84)  (expression int + (var_ref i at 0x988eb84)
> (constant int (1)) ) )
>         (assign (constant bool (1)) (x) (var_ref i at 0x988eb84)  (var_ref
> assignment_tmp at 0x987cb84) )
>       ))
> 
>     ))
> 
> )
> 
> I think glsl compiler translates AST like this
> 
> int i = 0;
> for (;;) {
>     if (i < 10) break;
>     if (i == 9) gl_FragColor = a [ i ] ;
>     i = i + 1;
> }
> 
> Is it correct?

I believe this block is implicitly surrounded by { and }.  I'm pretty
sure that we have test cases for the situation you're describing, but
I'd have to go dig around.

> Another question, for class ir_loop, why is ir_loop::counter ir_variable
> while from/to/increment are all ir_rvalue? I create an ir_variable for
> ir_loop counter, but hierarchical visitor won't access it. I don't think
> ir_loop::accept(ir_hierarchical_visitor *v)  will visit ir_loop::counter
> at all.

ir_loop::counter is the variable that hold the loop counter.
ir_loop::from is the initial value of the counter, ir_loop::to is the
end value, and ir_loop::increment is the value that ::counter is
modified by on each iteration.

> thanks,
> --lx
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev



More information about the mesa-dev mailing list