Re: Speeding up ggc-simple on stage1

[Jeffrey A Law <law at cygnus dot com>]

  In message <orn1qgth5s.fsf@garnize.lsd.ic.unicamp.br>you write:
  > --=-=-=
  > 
  > stage1 is usually built without optimization (couldn't this change, at
  > least when the bootstrap compiler is gcc?).
Probably not.  We've already discussed this at length on this list.  The
primary problem is stage1 is 100% concerned with just getting something
working.  We don't want to add the concern about dealing with optimizer
bugs when trying to build the stage1 compiler.

  > Unfortunately, I've got a
  > slow powerpc running AIX 4.1 (it won't run GNU/Linux :-(, that takes
  > ages to build stage2 and, it seems that, whenever I attach gdb to cc1,
  > it's within running garbage collection code :-(
Presumably that host can't use gcc-page?

Yes, ggc-simple is painfully slow.  It took several days to bootstrap an m68k
box I've got access to using gcc-simple.

  > I believe reducing stack usage for garbage collection could help it
  > some, so I've tried to rewrite some (all?) of the recursive functions
  > in ggc-simple to try to avoid recursion as much as possible.  I can't
  > say that know it's fast, but it seems to have improved a bit.
I'd like to know that we're actually going to improve things before we
start making changes.

  > Is this ok to install?
Not without at least knowing it's an improvement.  I'm not talking about
a massive study of its performance.  Build cc1 with and without this
change and run a substantial file through the compiler.  combine.i,
reload.i or reload1.i are always good candidates for this kind of
test.


You also have some formatting problems.  We don't write

 for (;;) {
   code
 }

Instead write

  for (;;)
    {
      code
    }


jeff