This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] Improve memory characteristics of VDEFs


On Sun, 2003-11-23 at 00:03, law@redhat.com wrote:
> In message <20031122152142.GA7238@atrey.karlin.mff.cuni.cz>, Jan Hubicka writes
> :
>  >> Now the code looks like
>  >> 
>  >> for (i = 0; i < VARRAY_ACTIVE_SIZE (vdefs) / 2; i++)
>  >>   {
>  >>     result = VARRAY_RESULT (vdefs, i);
>  >>     source = VARRAY_OP (vdefs, i);
>  >>   }
>  >> 
>  >
>  >This is nice (modulo the pasto:).  One weird idea I was playing around
>  >yesterday is that majority of non-virtual OP/DEFs are very trivial to
>  >find  (at least considering generic case of modify_expr with binary or
>  >unary operand), so perhaps we don't want to build varrays for these at
>  >all and instead re-discover them each time they are needed.

It would be an interesting timing experience, but I think it would be a
big loss.  RIght now, a traversal fo the entire IL looking at all the
regular USES and DEFs is very cheap. You can do it  many times and it
doesnt add much to the cost. And we do do it many times. If you start
special casing and checking, Im willing to be compile times on all
passes will increase noticably. You have to check TREE_CODE for
MODIFY_EXPR, and then each side for CONST vs. SSA_NAME. If you dont
cache this information, it will becomes more time consuming to count the
number of uses, or find use[0]. (Is the it LHS or the RHS if the
operands is a PLUS_EXPR.

However, that being said, the observation that the common case is no
more than 2 uses, we might be able to do something like I did in
immediate_uses, where we have 2 words we cache stuff into, and once we
go beyond 2 words, we allocate memory for them. I dont think that is
quite apropriate either here.

We have also considered allocating *all* off the uses and defs in one
big array, and just maintaining an index into that from the node rather
than a unique array for each one. I think this would be the best bet.
Maybe I'll give that a try the beginning of the week and see what the
results are...

Andrew


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]