Re: [PATCH/RFC/PR28071]: New scheduler dependencies lists.

[Jan Hubicka <hubicka at ucw dot cz>]

> Jan Hubicka wrote:
> >Hi,
> >the memory tester jammed for last week, but looking at the results
> >on the PR28071 -O3 compilation at:
> 
> Did you mean -O2?
Yes, it is -O3, sorry.
> 
> >http://www.suse.de/~gcctest/memory/graphs/index.html
> >it looks like that while this patch sucesfully addressed the compilation
> >time issues, the overall memory consumption increased noticeably (100MB,
> >or 20%)
> >
> >I think it might be caused just by suboptimal allocation (as the lists
> >with extra pointer should not consume more memory just because RTL
> >containers did needed extra 64bits too).
> 
> I'm looking at this issue now but still don't fully understand why this 
> happening at -O2 and not at -O3.  Maybe it is the problem described in 
> the comment in sched-deps.c: init_dependency_caches ():

The testcase has different properties at -O2 and -O3.  At -O2 you are
having one gigantic basic block, while at -O3 there are sequence of many
if-then-else control flow constructs because -O3 inlines extra function
containing that.
> 
> ---
> Lifetime of this obstack is whole function scheduling (not single region
> scheduling) because some dependencies can be manually generated for
> outside regions.  See dont_calc_deps in sched-{rgn, ebb}.c
> 
> Possible solution would be to have two obstacks:
>   * the big one for regular dependencies with region scheduling lifetime,
>   * and the small one for manually generated dependencies with function
> scheduling lifetime.
> ---

So I guess the problem whether freeing is done at the end of region or
not is not too relevant since there is about 1 region (I am not 100%
sure but I believe so).

> Deps_lists are created in the beginning of scheduling and are being 
> deallocated during it.  The same applies to dep_nodes so there isn't 
> really a need for allocpools.

The advantage of allocpool is mainly the lower overhead for allocating
many small objects since memory is allocated in chunks.  malloc
implementations generally will align more and have some sort of header
for each blocks.  In your case they might cause bigger memory
consumption than the linked list itself.

But I also believe it would be cleaner to use allocpool on the place of
current obstack as it has more appropriate API and also has the "throw
away everything" feature.

Honza
> 
> Considering doubly linked lists - it's just a matter of taste.  I stick 
> to the rule: "If you can't use it - don't create it."  And the design of 
> such a single linked list is more simple.
> 
> 
> Thanks,
> 
> Maxim