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

[Luca Barbieri]

>> 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
(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.