Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!MIZAR.DOCS.UU.SE!ewerlid
From: ewerlid@MIZAR.DOCS.UU.SE (Ove Ewerlid)
Newsgroups: gnu.gcc.bug
Subject: Re: Gnu C Bug (sorta)
Message-ID: <8908062231.AA22894@mizar.DoCS.UU.SE>
Date: 6 Aug 89 22:31:33 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 59



In a recent posting to bug-gcc Dirk Grunwald writes:

> some programs (e.g. the inner loop of a parallel prolog byte
> interpreter that was all one switch statement), the greenhills


> Gnu C (on the Encore) managed to compile it, although it *did* take
> about 20Mb of swap to do it.

I ran into the same problem when I compiled straight-line-coded DFA:s.
One particular program contained approx 1000 switches and 60000 cases.

Investigating the problem it turned out that every case consumed quite some
amount of memory due to the fact that every case was treated as a label.

ie:
	case 1:
	case 2:
	case 3:
	case 4: action

will produce 4 labels in the parsing phase.  No lookahead is done to 
determine that the above is a range.  It could be done by a right associative
rule in the parsing grammar.  I did not do that :-(

Instead I did it in a hackish way:

ie:	case 1: goto action
	case 2: goto action
	case 3: goto action
	case 4: goto action

which is the redundant output generated by the DFA-converter.  This is
easier to parse (a simple rule addition) and connect to the C backend
(simply do not create a unique case label, give it the action label instead).

So, while the source is bigger the VM consumption is much lower.
The program above compiled with a mere 9Mb of VM instead of an unknown amount
of 24Mb+. (The program itself was 2Mb, one function)

The (ideal?) solution is to hack the parsing grammar according to the first
of the above hacks.  Fortunately the design of GCC is a very clean ditto
and hacks of the above character is quite easy to do.  Still it always takes
time........

Your problem may ofcourse not be due to a very large percentage of cases in one
function.  The machine you are using may be a real VM killer or your switch
may contain large chunks of solid code etc.

Sorry, folks, to mention a solution to a problem without a patch.

(To be fair, I must say that the sun4-cc eventually aborted with a bunch of
 bogus warnings when compiling the above 2Mb program!
 Question: How far away was the bug fix?)


Ove