[m-rev.] for review: optimize successive field updates

[Julien Fischer]

On Tue, 17 May 2005, Zoltan Somogyi wrote:

> For review by Julien.
>
> Zoltan.
>
> Fix a problem reported by Michael Day. When a piece of code had several updates
> to the fields of a cell in a row, we were constructing all the intermediate
> versions of the cell. With this change, we now construct only the final one.
>
Are you planning to merge this onto the release branch?  If not, can you
let me know and I'll do it as this is something that should definitely
be included.

> compiler/simplify.m:
> 	The cause of the problem was simplify's use of the cannot_flush
> 	predicate from goal_form.m. Each field update consists of a pair of
> 	deconstruct/construct unifications inside a removable barrier scope,
> 	but cannot_flush assumed that any goal not on its small approved list
> 	may cause a stack flush. Simplify therefore told common.m to throw away
> 	its list of known cells when emerging from the scope.
>
> 	The fix is to replace the use of cannot_flush with a new predicate
> 	that is explicitly written for the needs of simplify, which is not
> 	too conservative. The concern about increasing the set of output
> 	variables of an existentially quantified scope is now addressed
> 	only when simplify__goal_2 when processing scope goals, not in two
> 	places (redundantly) as before.
>
That last sentence doesn't parse well.

> 	Simplify the logic of simplify_info_maybe_clear_structs.
>
> 	Simplify the mechanism for initializing simplify_infos.
>
> 	Use more descriptive variables names in simplify__pred.
>
> 	Switch to four-space indentation to reduce the number of bad line
> 	breaks.
>
> compiler/pd_util.m:
> 	Conform to the new mechanism for initializing simplify_infos.
>
> compiler/goal_form.m:
> 	Delete the cannot_flush predicate, since it now has no users.
>
> compiler/common.m:
> 	Clean up some code. Break up an excessively large predicate, factor
> 	out some common code, and make comments conform to our conventions.
>

That looks fine.  Do you know if fixing this problem has had any impact
on the performance of the compiler itself?

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