[Mesa-dev] Mesa (shader-work): glsl: teach loop analysis that array dereferences are bounds on the index

Eric Anholt eric at anholt.net
Thu Sep 9 14:58:54 PDT 2010


On Thu, 9 Sep 2010 03:26:45 +0200, Luca Barbieri <luca at luca-barbieri.com> wrote:
> Thanks!
> 
> But, does this mean that if I allocate using new(existing_ir) ir_foo()
> or opposed to new(talloc_parent(existing_ir)) ir_foo() then this new
> object will always remain alive as long as existing_ir is alive, even
> if it's no longer referenced?
> 
> If so, why would anyone do that, which seems to occur frequently in
> the codebase?

Because we were lazy.  Fixing would be good.

> And why is an hierarchical ownership model useful at all, instead of
> just doing a "mark-and-sweep" plus copying phase after all
> optimizations, or maybe after a given pass if the allocated memory
> grows too much?

When I free a shader, I just free the shader, and the ir list, the ir,
the constant storage associated with the ir_constants, the names,
etc. all get freed.  We've got stuff not taking advantage of this yet,
since we tried to avoid rewriting all of the outside-the-compiler Mesa
internals.

But yes, in terms of the ownership of the ir nodes themselves, we're
mark-and-sweeping except that sweep is "talloc_free()".

> Also, how about just keeping the context in a thread-local variable
> and using it automatically, possibly in a global way with a gc root
> registration mechanism?

Sounds like way more work than a function parameter to the do_* passes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20100909/91a24468/attachment.pgp>


More information about the mesa-dev mailing list