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

[Zoltan Somogyi]

On 17-Jan-2003, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> 	The debugger and the accurate garbage collector both rely on
> 	strong type-info liveness, I believe.  Changing them to only
> 	assume the weak type-info liveness invariant would be a lot of
> 	work, I think.  So I think we should stick with the strong
> 	type-info liveness invariant.  (Agreed?)

The situation is more subtle than that.

For a start, there are two application areas for typeinfo liveness: in
interfaces, and in procedure bodies. For procedures that are exported or
whose address is taken, we need interface typeinfo liveness, i.e.
there must be a typeinfo argument for every type variable in the signature.
In debugging and agc grades, we must ensure that as long as there is a live
variable whose type includes a type variable, there is a live typeinfo
variable for the type bound to that type variable. There are predicates
in hlds_pred.m that decide when each kind of typeinfo liveness is needed.

Optimizations such as unused args that can violate one or other form of
typeinfo liveness should be applied to a procedure only if that procedure
doesn't need that form of typeinfo liveness. For example, since debugging
requires typeinfo liveness on all procedures interfaces, unused args
optimization is turned off in debugging grades.

As for strong vs weak, the whole point of the typeinfo varmap is to
record the identity of the typeinfo variable describing the type bound
to a type variable. If we chose the weak invariant, we wouldn't need it.
All the code that generates RTTI depends on the strong invariant, so I
vote we keep it.

Zoltan.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------