>> 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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev