[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