This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Beginner's question:Are there any inter-procedural optimizationin GCC backend ?
Daniel Berlin <dberlin@dberlin.org> writes:
>> 2) The RTL inliner is a major obstacle to making all RTL be
>> transiently allocated, and therefore to removing RTL from the
>> purview of the garbage collector. Daniel Berlin has numbers
>> indicating that allocation of RTL from the GC heap causes huge
>> amounts of memory to be wasted, with consequent compile-time
>> performance hit.
>>
>
> Note that this is mainly due to the extremely variant lifetimes of
> RTL. Some of it lives long time, some of it lives very short time.
> Since we have no idea which is which, we end up with pages that would
> be freed, except for some small number of pieces of RTL on them (ie
> 100-200 bytes out of 4096). This happens quite frequently. Trees
> have variant lifetimes, but nowhere near the variation you see with
> RTL.
Right. The idea is to use a strict policy of "live from allocation
until the end of rest_of_compilation" for _all_ RTL (perhaps with a
handful of exceptions of the form "live from allocation until process
exit" which I am hoping to minimize, since they will accumulate
undesirably in a multi-translation-unit compilation). If this can be
done, then RTL can be shoved on a single obstack (or similar) which is
recycled en masse at the end of rest_of_compilation. The GC never
sees it, PCH never sees it, it doesn't suffer internal fragmentation,
and the odds are the same chunk of memory will be used repeatedly for
successive functions.
It's basically your zone concept but taken even farther.
zw