[m-rev.] for post-commit review: limit stack layout compression

[Paul Bone]

On Tue, May 24, 2011 at 07:13:05PM +1000, Zoltan Somogyi wrote:
> 
> compiler/mercury_compile_llds_back_end.m:
> 	Add progress messages that say when the compiler is converting the
> 	information it gathered for the construction of layout structures
> 	into the actual layout structures. In some cases (such as zm_enums.m),
> 	these could take a very long time.
> 
> compiler/stack_layout.m:
> 	Impose limits on how aggressive we want the compression of layout
> 	structures to be. This is because in the absence of those limits,
> 	the compression of the layout structures for zm_enums.m can literally
> 	take an hour.
> 
> compiler/options.m:
> 	Implement a new option controlling the limit to be applied by
> 	stack_layout.m.
> 
> doc/user_guide.texi.m:
> 	Document the new option.
> 
> tools/speedtest:
> 	More changes to allow this diff to be tested for its performance
> 	effects. With the default limit, the compiler compiles the 16 largest
> 	modules in a debug grade 10% faster, but generates .c files that total
> 	about 8.4% bigger. Both effects should be smaller for smaller modules;
> 	small modules won't see any change at all.
> 

The patch looks fine.

However, I wonder if we can compress these structures even when they're large
by compressing only some part of them at a time.  Say the limit is set to 1000,
and there are 2000 structures in a module.  Compress the first 1000, then
compress the next 1000 separately.  I'm not familiar enough with the problem to
be able to propose anything with any more detail.

Thanks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20110727/13a8912a/attachment.sig>