Xref:	news2.mv.net comp.os.msdos.djgpp:6189
Newsgroups:	comp.os.msdos.djgpp
From:	tob AT world DOT std DOT com (Tom Breton)
Subject:	Re: c:\Compiling............ Zzzzz..... :)
Message-ID:	<Dupvr8.5vD@world.std.com>
Reply-To:	tob AT world DOT std DOT com
Organization:	BREnterprises
References:	<199607161225 DOT IAA19062 AT delorie DOT com>
Date:	Thu, 18 Jul 1996 02:18:44 GMT
Lines:	45
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

I apologize for continuing this thread here, but none of
gnu.gcc.announce, gnu.gcc.bug, gnu.gcc.help seemed to be right for it.

DJ Delorie <dj AT delorie DOT com> writes:
[Responding to someone else]
> Do you realize that gcc is about 30 Mb of source code?  Do you realize
> that there are thousands of people already working on gcc, including how
> to make it faster in general?
>
>
> Hey!  We've been improving the speed for about ten years now.  Compile
> speed is about par with Borland if your system is configured right.
>
> I'd also like to know which unixisms you'd like to throw away, and why
> you feel that they'd improve the compilation speed.

Now that you mention it, one thing I seriously wonder about gcc is why
it does not use sentinels for its rtx linked lists. (Or didn't when I
checked the 2.6.3 source)

Sentinels, of course, are do-nothing nodes on the ends of a list that
guarantee there will be no special cases when inserting and removing
nodes. They themselves are never inserted nor removed.

The lack of sentinels also causes the triplication in emit-rtl of

emit_insn_before        emit_insn_after         emit_insn
emit_jump_insn_before   emit_jump_insn_after    emit_jump_insn
emit_call_insn_before   emit_call_insn_after    emit_call_insn
emit_barrier_before     emit_barrier_after      emit_barrier
emit_note_before        emit_note_after         emit_note

Even if specializing these routines is faster (I'm not sure it is, in
any case it can't be much because they are almost identical), loading
the extra code takes time and memory.

gcc also points to the first and last node of its current rtx. I'm
probably mucking up the terms the source uses but you know what I mean.
If those pointers were replaced by two sentinels in static memory that
always were the first and last nodes of the current rtx, it would appear
to save dereferences all over the place, with some trivial overhead when
pushing/popping rtx's to swap 'em for dynamically allocated nodes.

        Tom

- Raw text -