This is the mail archive of the gcc@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: Faster compilation speed


On Sat, 10 Aug 2002, Richard Kenner wrote:
> 
> No, it doesn't.  As I said, it has to do with *correctness* issues.  For
> example, GCC assumes that there is exactly one copy of the RTL for each
> pseudo-register so that when the pseudo is forced to memory, only that
> RTL needs to be changed.
> 
> It also assumes that certain other RTL is *not* shared, so that it can
> be changed without affecting any others insns.
> 
> Nothing whatsoever to do with memory management.

But the above is _exactly_ what memory management is all about. 

Memory management has almost _nothing_ to do with "malloc()" and "free()".  

Those are the trivial parts. All the interesting stuff is knowing _when_
to call them, and that very much means (a) maintaining a count of users
(so you know when you can call free()) and (b) maintaining a "sharedness"  
of users (so you know when you need to copy and when you can just re-use). 

THAT is what memory management is all about. 

Let's take an example. In obstacks, the real memory management is not the
malloc that the internal obstack routines do when they need more memory.
No. The real MM is the decision to have a stack-based allocator, and the 
decision to say that all allocations get free'd when a previous one was 
freed. That's the _management_ part. 

(Admittedly it's _bad_ management, but hey, according to Dilbert that's a
most inherent part of management ;).

And when it comes to rtx's, gcc has no real memory management, and to me
that looks like a design mistake. And exactly _because_ gcc doesn't really
"manage" the rtx's, you end up having these ad-hoc "correctness" issues.

Now, I'm probably very biased, because in a kernel you really have to be 
very very careful indeed about never leaking memory, and about being able 
to reclaim stuff when new situations arise. So to me, memory management is 
the basis of anything working _at_all_. 

So my claim is that if you _were_ to have real rtx memory management, you
wouldn't need any of the ad-hoc rules. You could just mark the RTX as 
being shared (the same way you can mark a file mapping as being shared), 
and then that tells the copy-on-write routines that no copy is needed, 
exactly because everybody wants one single shared object. But even when it 
is shared, you still need to have a reference count - to know when there 
are no people interested in it any more.

(And yes, some objects stay around forever, like the atoms in lisp. They
should still have reference counts, it's just that they get created with
an implicit reference so the count never goes down to zero).

			Linus


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