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: 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 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