[m-dev.] for review: layouts in all closures
Fergus Henderson
fjh at cs.mu.OZ.AU
Wed Aug 11 16:13:39 AEST 1999
On 09-Aug-1999, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
>
> compiler/continuation_info.m:
> compiler/stack_layout.m:
> compiler/unify_gen.m:
> Modify the predicates that record and use layout information about
> closures to always do so, since the necessary information is now
> always available about the interfaces of procedures whcih can be
> put into closures. Previously, they only did so if typeinfo_liveness
> was set.
s/whcih/which/
> --- handle_options.m 1999/06/01 09:43:45 1.76
> +++ handle_options.m 1999/06/01 10:54:19
> % XXX middle_rec doesn't work with --typeinfo-liveness,
> % because --typeinfo-liveness causes the stack to be used
> % in places where middle_rec is not expecting it and has
> % hence not set up a stack frame.
> - option_implies(typeinfo_liveness, middle_rec, bool(no)),
> + option_implies(typeinfo_liveness_hidden, middle_rec, bool(no)),
Shouldn't that bit be deleted now?
With your change to middle_rec.m, middle_rec will handle those cases OK,
won't it?
> compiler/options.m:
> compiler/handle_options.m:
> Rename the typeinfo_liveness option as typeinfo_liveness_hidden,
> to discourage its direct use.
...
> +++ options.m 1999/07/06 01:21:55
> @@ -180,7 +180,21 @@
> % Use an alternate calculation of liveness
> % where typeinfos are live for any live data
> % the includes that type variable.
> + %
> + % This option is hidden because we must not
> + % pay attention to it for any procedure whose
> + % address is taken; those must always be
> + % treated with typeinfo liveness (otherwise,
> + % the layout structure we include in closures
> + % using that procedure may not have all the
> + % information required to reconstruct the
> + % types of all the values inside the closure).
> + %
> + % The only place in the compiler that should
> + % look at this option is the predicate
> + % should_use_typeinfo_liveness in hlds_pred.m;
> + % everything else should go through there.
> + ; typeinfo_liveness_hidden
The name `typeinfo_liveness_hidden' is not very meaningful or mnemonic, IMHO.
I think "always_use_typeinfo_liveness" or `typeinfo_liveness_always'
or something along those lines would be much better.
options.m:
> @@ -850,7 +864,7 @@
> long_option("basic-stack-layout", basic_stack_layout).
> long_option("procid-stack-layout", procid_stack_layout).
> long_option("trace-stack-layout", trace_stack_layout).
> -long_option("typeinfo-liveness", typeinfo_liveness).
> +long_option("typeinfo-liveness", typeinfo_liveness_hidden).
The internal and external option names should match, IMHO.
So if you change the internal name, then you should change the
external name to reflect this.
Apart from that, your change looks fine to me.
--
Fergus Henderson <fjh at cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3 | -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------
More information about the developers
mailing list