[m-dev.] [reuse] diff: remove --no-static-ground-terms constraint on reuse

[Peter Ross]

On Wed, Oct 18, 2000 at 05:35:39AM +1100, Fergus Henderson wrote:
> On 17-Oct-2000, Peter Ross <petdr at miscrit.be> wrote:
> > On Wed, Oct 18, 2000 at 04:23:04AM +1100, Fergus Henderson wrote:
> > > 
> > > Does this handle variables which are constructed statically
> > > in a procedure then reused in a different procedure?
> > > 
> > No it doesn't, aaargh!  You just need to mark which outputs of a
> > procedure are constructed statically.  Not to difficult to do.
> ...
> > you will need to introduce some sort of pragma which informs which
> > outputs of a call are constructed statically, and write that into the
> > trans_opt file.
> 
> I think it a different approach would be better:
> rather than changing reuse analysis to carefully avoid reusing
> anything that might be constructed statically,
> I think it would be better to change static ground term optimization
> so that it properly respects uniqueness declarations.
> 
Yes that will need to done, but just that change alone will not solve
all the problems,

        :- type f ---> f(int).

        :- pred foo(f::out).
        :- pragma no_inline(foo/1).
        foo(f(42)).

        :- pred bar(f::in, f::out).
        bar(Y, X) :-
                Y = f(A),
                X = f(A + 1).   % reuse Y

        :- pred baz(f::out).
        baz(Y) :-
                foo(X),
                bar(X, Y).

Note that the current reuse analysis would determine that X is local to
the goal baz, so it can be reused.  So we still need to do the analysis,
about whether or not X was constructed statically.

> If you leave static ground term optimization as is, i.e. not respecting
> the unique mode system, then you will need to make very conservative
> assumptions in reuse analysis in cases involving type classes,
> higher-order code, or the C interface, even if the procedures
> are declared with `di' and `uo' modes.  The reason is that
> reuse analysis will have no way of knowing what code is called
> in those cases, and it can't tell from the modes, since
> mode `di' will not necessary mean that the object is reusable.
> 

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------