[m-rev.] diff: removal of a frameopt limitation

[Ralph Becket]

Zoltan Somogyi, Thursday, 25 August 2005:
> Significantly improve the capabilities of the LLDS optimization that tries
> to delay the creation of the stack frame, in the hope that on some computation
> paths the frame won't need to be created at all. Previously, the delayed
> setup of the stack frame could take place only when a block without a stack
> frame fell through to a block that needed a stack frame. If block B1 jumped
> to another block B2 that needed a frame, this was taken as meaning that B1
> also had to have a frame. This was a problem, because if B1 ends with a
> computed goto, some of whose targets need stack frames and some do not,
> this limitation effectively gave all of them a stack frame, whether they
> wanted it or not, and thus required them to execute the stack frame teardown
> code.
> 
> This diff removes the limitation, optimization allows B1 in this case to not
> have a stack frame. Instead of jumping to B2, B1 will not jump to a label B3

s/will not/will/?

> it inserts immediately before B2, the code at B3 setting up the stack frame
> and falling through to B2. (We also insert code to jump around B3 if the
> code immediately preceding it could fall into it accidentally.)
> 
> The new code in frameopt is conceptually cleaner than it was before, because
> we now handle transitions from blocks that don't have a stack stack to blocks

s/stack stack/stack frame/?

> that do in a much more uniform manner.
> 
> Most of the changes to other modules are to make the change to frameopt.m
> easier to debug.
> 
> The motivation for the change was that we were beaten by YAP (Yet Another
> Prolog) on the deriv benchmark due to the limitation of frameopt. I haven't
> measured against YAP yet, but the runtime for 1.5 million iterations has been
> reduced from about 20 seconds to about 13.
> 
> Since the compiler doesn't have any predicates that are both frequently used
> and can benefit from the removal of that old limitation (which is why the
> limitation wasn't really noticed before), there is no measurable effect
> on the speed of the compiler itself.

I haven't had time to look at the code yet.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------