[m-rev.] diff: fix --optimize-higher-order bug

[Simon Taylor]

On 17-Jan-2003, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
>     Invariant 2.  "head variables scope left-to-right".
> 
> 	For the strong type-info liveness invariant (Invariant 1),
> 	each head variable is considered to scope over those to
> 	the right of it, but does not scope over those to its left.
> 
> 	That is, for each type variable T occurring in the procedure
> 	signature, the type-info specified for T in the type_info_varmap
> 	must come before any variables whose type contains T.
> 
> 	The corresponding invariant for the MLDS is that the scoping
> 	rules for the code in the mlds__maybe_gc_trace_code attached
> 	to each function parameter are just the usual (C,C++,Java,C#,etc.)
> 	scoping rules: variables declared to the left of that code are
> 	in scope, variables declared to the right of that code are not
> 	yet in scope.
> 
> 	The alternative to left-to-right scoping of head variables
> 	would be that all head variables in a procedure scope over
> 	each other for the purpose of Invariant 1 (strong type-info
> 	liveness).  However, this HLDS invariant would lead to a
> 	more complicated corresponding MLDS invariant, which would
> 	significantly complicate some parts of the MLDS back-end,
> 	such as ml_elim_nested.m.
> 
> 
> Fixing the MLDS back-end's implementation to not rely on these
> invariants looks to me like a difficult task.

I still don't understand how it's simpler to change multiple HLDS
optimization passes so that the MLDS code generator doesn't need to
work out the order in which variables should be declared and traced.
The MLDS code generator should have enough information to work that
out for itself.

In general, it's better (and more robust) if the HLDS has as few
restrictions as possible.  It's already very difficult to write
source-to-source transformations in the Mercury compiler, and every
extra unnecessary invariant makes it that much harder.

> Estimated hours taken: 8
> Branches: main
> 
> compiler/handle_options.m:
> 	Disable higher-order specialization if accurate GC is enabled,
> 	since the higher-order specialization pass doesn't preserve
> 	the invariants required by the implementation of accurate GC
> 	in the MLDS back-end; in particular it doesn't preserve
> 	strong type-info liveness with left-to-right parameter scoping.
> 	(For details, see mail in mercury-reviews for details.)

This is OK as a temporary fix.

Simon.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------