[Mesa-dev] [PATCH 2/3] glsl: add continue/break/return unification/elimination pass

[Christoph Bumiller]

On 09/07/2010 03:10 PM, Luca Barbieri wrote:
>>> 2. Remove all "continue"s, replacing them with an "execute flag"
>>
>> This essentially wraps the rest of the code in the loop with
>> if-statements, right?  I had been thinking about adding a pass to do
>> this as well.
> Yes.
> 
>>> 3. Replace all "break" with a single conditional one at the end of the loop
>>
>> Hmm... I keep forgetting about conditional breaks.  We don't have much
>> support for them throughout the compiler.  We should probably fix that.
>>  Generating loop controls as conditional breaks (instead of 'if (cond)
>> break;') would be a good first step.  A pass that lowers other
>> if-statements that contain breaks to conditional breaks would be a good
>> second step.
> Yes, or perhaps adding a condition in ir_loop.
> 
>>> Note that for full effect we should also teach the unroller to unroll
>>> loops with a fixed maximum number of iterations but with the canonical
>>> conditional "break" that this pass will insert if asked to.
>>
>> Could you elaborate on this a bit?
> 
> Currently the unroller refuses to unroll anything containing break or continue.
> 
> However, we should unroll:
> for(i=0; i < 3; ++i)
> {
>   do_stuff(i)
>   if(stop(i))
>     break;
> }
> 
> into:
> do_stuff(0)
> if(!stop(0)
> {
>   do_stuff(1);
>   if(!stop(1))
>   {
>     do_stuff(2);
>     if(!stop(2))
>     {
>        do_stuff(3);
>        stop(3);
>     }
>   }
> }
> 
> at least for chips with no control flow support like nv30 and i915
s/at least/only
This doesn't reduce divergence, only increases code size.
> (and then apply if-conversion to kill the ifs as well).
> 
> This pass should always put the loop in this form if asked to.
> 
>>> Note that "continue" and "return" can also be implemented by adding
>>> a dummy loop and using break.
>>> However, this is bad for hardware with limited nesting depth, and
>>> prevents further optimization, and thus is not currently performed.
>>
>> On which hardware will this make a difference?  It seems that any
>> hardware that has loops also has returns.  Or is this another case where
>> VS and FS hardware differs?
> 
> Before DirectX 10, continue is not guaranteed to be supported.
> For instance, on nv40 FS it is not supported, even though loop/break
> are supported.
> 
> Also, we want to remove returns anyway so that we can inline the function.
> 
>> I haven't fully reviewed the code yet, I'll get to that tomorrow.  I do
>> have a couple code style comments.  About a month into things, we
>> started explicitly using 'this' in all methods.  For C programmers,
>> we've found that this makes things a lot more clear.  We've also been
>> trying to avoid initialization lists for the same reason.  I don't find
>> the argument in the C++ FAQ
>> (http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.6) very compelling.
>>
>> We've also been using FINISHME instead of TODO in comments.
> OK.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev