Re: thanks for the memory work

[Andrew MacLeod <amacleod at redhat dot com>]

On Tue, 2003-11-25 at 23:27, law@redhat.com wrote:
> In message <1069818411.22241.2204.camel@p4>, Andrew MacLeod writes:
>  >> Even if they come out of a single array, I don't see how that necessarily
>  >> helps the memory consumption problems -- since you've still got to
>  >> provide the operand walkers indices into that array.
>  >> 
>  >Well, you avoid the overhead of having an array for each one, and if you
>  >have 328,000 of them, that has to be something at least. the GC doesnt
>  >have to deal with them.
> But don't you still need a varrarys for the indices?
> 
> Or were you planning to have a single varray with all the operands and you
> have to walk the entire varray examining the type of each element to know
> if it's applicable?
> 

ummm, eh?

Initial plan is to have 1 varray of tree * for real operands over all
stmts. The annotation will then have an index into this array for defs
and one for uses. So when you want the uses(s), you have direct access
to them. Initially Id put the def/use count in the annotation as well
simply for speed. It'll be dead easy to change whe Im done tho. 
Initially Im trying to get rid of all those varrays.

What would I have to walk the entire array examining elements for? The
individual operand types are for the accessor routines to ensure
compliance, not the underlying data, if thats what you meant.

When I allocate a varray, because it grows, you can never be sure that
index [x] is always at the same memory location can you? varray memory
is always contiguous, and not segmented right? 
> 
>  >PLus, I was planning to do some thing about the 0
>  >and 1 DEF case, much like I did with immediate_uses, they oughtn't take
>  >much to deal with.
> I definitely think dealing with the 0/1 def cases will be worthwhile. 
> 
Perhaps. Im not as convinced it will be that big of a win, but perhaps.
I know one def is common, and we might very well be able to handle it
seemlessly... But you are only saving at most 1 or 2 words per stmt, I
wouldn't expect to see too much difference in the end relative to where
we are spending memory elsewhere. We'll see :-)


After sleeping on it, I think its probably worthwhile to have all 4
operand types be their own type. We may want to treat DEFs differently
than USES for the afore mentioned 0/1 case, (or some other reason) VUSEs
and VDEfs are different as well (VDEFS have 2 operands), etc. Its
probably just better to make them 4 different types.  You never know
when we might want to implement one of them quite differently. No point
in doing this exercise more than once :-) client code ought to  be a
little clearer to read as well.

I was thinking def_optype, use_optype, vdef_optype and vuse_optype. Some
of them may end up being exactly the same thing, soi they'd be different
in name only.

Andrew