[Mesa-dev] [glsl] indvar in ir_loop

[Liu Xin]

Ian,

I am sure I comes across trouble for the following code.

(function main
   (signature void
     (parameters
     )
     (
       (loop ((declare () int i at 0x8d19434)) ((constant int (0)) ) 
((constant int (32)) ) ((constant int (1)) ) (
         (call foo ((var_ref sampler2d at 0x8eef134) (var_ref 
myTexCoord at 0x8eef05c) ))

       ))

the loop is generated by hand, using the following code.

                     ir_loop * loop = new (ctx)ir_loop();

                     ir_variable * indvar = new (ctx) 
ir_variable(glsl_type::int_type, "i",ir_var_auto);
                     ir_dereference * idx = new (ctx) 
ir_dereference_variable(indvar);

                     loop->from = new(ctx) ir_constant(0);
                     loop->to = new(ctx) ir_constant(32);
                     loop->increment =  new (ctx) ir_constant(1);
                     loop->cmp = ir_binop_less;
                     loop->counter = indvar;

                     loop->body_instructions = sig->body;
                     sig->body.make_empty();

call_link_visitor(link_function.cpp) can not see the variable 
i at 0x8d19434. it's because call_link_visitor extends from 
ir_hierachical_visitor. ir_loop::accept(ir_hierarchical_visitor 
*v)**doesn't look at ir_loop::counter .

that is to say, it assumes the indvar is out of loop contruct, right?  
perhaps my usage is wrong.

my changeset makes it like breeze.

index be8b36a..4e4dd4c 100644*
*--- a/src/glsl/ir_hv_accept.cpp
+++ b/src/glsl/ir_hv_accept.cpp
@@ -71,6 +71,7 @@ ir_loop::accept(ir_hierarchical_visitor *v)
     if (s != visit_continue)
        return (s == visit_continue_with_parent) ? visit_continue : s;

+   if (this->counter) s = this->counter->accept(v);
     s = visit_list_elements(v, &this->body_instructions);
     if (s == visit_stop)
        return s;
*
*

thanks,
--lx

On 10/12/2013 05:39 AM, Ian Romanick wrote:
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131025/14489306/attachment.html>