Re: thanks for the memory work

[Jan Hubicka <hubicka at ucw dot cz>]

> In message <200311260003.49376.s.bosscher@student.tudelft.nl>, Steven Bosscher 
> writes:
>  >Here's one statistic that disappointed me somewhat.  I expected that we were 
>  >creating millions of varrays for statement operands, but at least for 8361.ii
>  > 
>  >it's not so bad at all (numbers for -O2 -fno-tree-pre):
>  >
>  >             number of varrays
>  > use_ops        326058
>  > def_ops        327317
>  >vuse_ops        204200
>  >vdef_ops         88002
>  >TOTAL           945577
>  >
>  >Assuming that only the "name" and "type" fields of the varray_head_tag struct
>  > 
>  >are redundant our purpose, there's less than 8 MB overhead from this.
> Rather than focus on the waste within the varray, maybe the focus should
> be on not creating the varray in the first place.
> 
> The overwhelming majority of statements produce a single output -- the
> only reason def_ops is a varray is to handle those oddball cases like
> asms which can have multiple outputs.
> 
> So an interesting question then becomes can we _cleanly_ avoid use of the
> varray in the general case.   That would reduce the number of operand varrays

I think the iterator API + some magic to recognize most common cases
would do the job here.  I plan to look into this once I get my patches
queue shorter, but I won't mind anyone beating me :)

Honza
> by 33%, which is probably more significant than trying to eliminate fields
> within the varrays themselves.  That also has the advantage that there are
> fewer nodes for the GC system to manage.
> 
> 
> Jeff
>