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: Explicitly release memory used by varrays


On Mon, 2004-09-13 at 17:35, Jan Hubicka wrote:
> BTW next on my radar is DOM expense caused by reversing very many
> conditions.  This contribute roughtly to 5% of memory overhead.  Do you
> think there is way out of this?  (caching the expressions or just
> keeping the flag "reversed" around and not actually building the
> reversed tree?)
Before you start down this road, look very carefully at whether or
not we still need to call thread_across_edge as often as we do
now, which accounts for a notable amount of the duplication.  I
haven't investigated it yet, but I believe some of the cases
where we call thread_across_edge are no longer useful now that
we've fixed some buglets in get_eq_expr_value and/or its callers.

Beyond that, obviously I've thought about caching the reverse of
all the comparisons (possibly in the COND_EXPR's annotation).
I don't really like that.  What I think we need here is a better
way to do queries into the hash table so that we can reduce the
amount of things we need to enter into the tables.  ie, right
now when we encounter

 if (a > b)
   {
   }
 else
   {
   }


In the true arm we record
1 = (a > b)
0 = (a <= b)
0 = (a == b)  /* I think we record this, but I'm not absolutely
                 sure.  I'd have to verify in record_dominating_... */

In the false arm we record
1 = (a <= b)
0 = (a > b)

Note that we only reverse the comparison once to record all those
equivalences.  But if we had a better way to query the table, then
we might now have to record the comparison and its reverse every
time we hit a conditional.


jeff


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