executable file size

[Jim Wilson]

	> At the other hand file size increased from 320kb(from previous egcs) to 460
	> But maybe you should take resulting file size into account too. I
	> think that 1% of speed don't worth 1/3 of size.

	We need a -Ospacen flag, where n is a number, were higher numbers mean
	make is smaller, and -Ospace99 means make it run slowly if you have
	to, but make it fit.

This doesn't help with the reported problem.  The actual problem here
is that the dwarf2 debug info emitted for exception handling support (a new
feature as of the last snapshot) is large enough that many people are noticing
it.  One way to fix that is to use -fno-exceptions.  There are other
possibilities.

Otherwise, -Ospace is certainly useful for embedded systems work, and is
already on my wishlist for EGCS.  However, I think your suggestion of having
-OspaceN where N ranges from 0 to 99 is unimplementable.  There are lots
of different ways to trade code size for speed, but trying to figure out where
they go on a scale from 0 to 99 is not practical.  How much of a code size
decrease each one gives depends of the program and the target.  If we split
them into 100 different cases, then we will get varying and unpredictable
results for each of the 100 different options, and this will just confuse
users.  I think it is better to have just one option, and only add more if
absolutely necessary.

If people need tradeoffs between space and speed, then they can easily get
this by changing how much of the program is compiled with -Ospace vs how
much is compiled with -O2.

Jim