Re: thanks for the memory work

[Andrew MacLeod <amacleod at redhat dot com>]

On Tue, 2003-11-25 at 22:02, law@redhat.com wrote:
> In message <1069809446.22241.2045.camel@p4>, Andrew MacLeod writes:
 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 :)
>  >> 
>  >
>  >I think we'll pay a penalty if we don't cache the information and
>  >instead try to recreate it each time, even for the common cases. Too
>  >many ifs executed all the time. I certainly write code assuming that use
>  >and def access is quick.
> That is certainly a concern.  In fact that's one of the reasons why I
> wasn't even going to consider special casing uses, vdefs or vuses.  
> defs is the only one I thought that it might make sense to consider.
> 
> 
>  >As I discussed earlier, I plan to make all the real USE and DEF ops for
>  >all the stmt's come out of a single array, or be cached in the
>  >annotation for the common case like immediate_uses works now. Whichever
>  >works out best.  
> 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.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.

Anyway, once its abstracted out, we can fool around with lots of
different possibilities quite easily. I was originally only going to
abstract out the real uses, but Im thinking I might as well do virtual
uses at the same time.

I was thinking about breaking them into realop_type and virtual_type
instead of the current varray_type for all four. It seemed like having
defop_type, useop_type, vuseop_type and vdefop_type was a little too
granular...  What do y'all think? It only matters much when you have a
function that looks at all of them, the you cant share the same 'op'
variable. But maybe thats a good thing anyway....

Andrew