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


> 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.

Because some of defs/uses are dificult to find, we may simply build the
lists only for these as we do now and mark the others as simple.

I have no data on how much the savings would be, but one thing that
seemed to make sense was to add iterator interface for these so we are
consistent with the STMT walks.

Also I was thinking that perhaps adding wrappers such as
FOR_EACH_STMT/FOR_EACH_OP/FOR_EACH_DEF would make code more readable
(even thought they are not very C).  At least when I want to use
iterators for stmt walk, I usually do cut&past as the names and calling
conventions are still not completely familiar to me.

This can be done on the top of your current API as well.  For iterators
we need temporary variable that is ugly, but we do that for bitmaps too,
so perhaps this is not very evil.

Does some of this appear as good ideas for others?
Honza


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