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

Julien Fischer juliensf at cs.mu.OZ.AU
Tue May 17 17:01:44 AEST 2005

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?

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

More information about the reviews mailing list