[Piglit] [PATCH] Add GLSL tests for loops with function calls that have side-effects.

[Paul Berry]

On 23 March 2012 14:16, Jose Fonseca <jfonseca at vmware.com> wrote:

> ----- Original Message -----
> > On 03/23/2012 03:49 AM, Kenneth Graunke wrote:
> > > On 03/23/2012 12:03 AM, Jose Fonseca wrote:
> > > [snip]
> > >>> Ian,
> > >>>
> > >>> The loop analysis code currently doesn't take calls into account
> > >>> whatsoever, which is clearly wrong. Any ideas on the best way to
> > >>> fix
> > >>> it?
> > >>
> > >> I think that, before a loop is unrolled, any inner calls should be
> > >> inlined. I don't any correctness/performance reason to do any
> > >> differently.
> > >>
> > >> Jose
> > >
> > > Yeah, I think "don't unroll if there are function calls" is the
> > > right
> > > answer. Inlining first would make unrolling happen in most cases.
> > > We can
> > > always improve on that later.
> >
> > I don't think we have to go that far.  I think:
> >
> > 1. Mark any out or inout parameter as being assigned (in the loop).
> > 2. Mark any globals as being assigned.
> >
> > That should put a bandaid on it.
>
> Sounds a perfectly good bandaid.
>
> But I guess I still don't understand why we'd ever want to unroll a loop
> that contain function calls. If the call is not worth to inline, then
> what's the point of unrolling the loop?
>

Yeah, I agree.  In any case, it's a moot point for now because Mesa
currently inlines everything no matter what.

As for the bandaid, is there a benefit of doing it rather than the "proper
fix" of disabling loop unrolling for loops containing function calls?  In
this case the proper fix seems easier, so I'm not sure why we're
considering a bandaid.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20120323/1340281d/attachment.html>