Reducing compilation memory usage

[Alejandro Pulver]

On Fri, 18 Jan 2008 10:35:09 +0000
Andrew Haley <aph@redhat.com> wrote:

> > I really don't know if I could split it, as it's inside the same
> > function (all the ~8000 labels with very short code), and it uses
> > computed gotos (like the ones generated by a switch statement, with a
> > "jump table" so there is no comparison of the cases), so this may not
> > work in different files (at least 2 jump tables are used instead of 1,
> > using a dictionary-like setup, see below).
> >
> > For example, I've seen a Motorola 68K emulator (included in Generator,
> > a SEGA Genesis emulator) generating 16 C files, each one containing the
> > code for instructions starting with 0 to F (in hexadecimal). It uses
> > switch and case statements for the jump table (not computed gotos),
> > which is more or less the same in practice. I haven't fully read the
> > source, but it seems that has 2 jump tables to avoid this problem.
> >

I was wrong, generator uses one function for every instruction.

> > I'll see if they can be split, but I just was surprised when I tried
> > with GCC 4.x and actually compiled it (without optimizations). So I
> > thought there could be a way to optimize it by telling GCC specific
> > information about how to do it (as optimizing each block independently
> > should work fine).
> >   
> 
> Yeah, but that's not what gcc does -- we hold an entire function as 
> trees and a data-flow graph, and then we optimize the whole thing.

I thought that -fno-unit-at-a-time avoided it (and
max-pending-list-length could help). Maybe I misunderstood their
meaning.

Is there a way to estimate the memory usage of the compilation process?

> In your case the behaviour of gcc is not
> at all surprising, and the obvious way to solve your problem is to go 
> out and buy more
> RAM!  Of course we could make gcc more economical, and we could somewhat
> reduce memory usage, but you're asking for something really hard.
> 

I wasn't asking to change the program, I was just asking if there is an
already existing option. Even if I add more RAM, most users won't be
able to build it (and I'm looking for a general solution).

But I guess it's fine enough that GCC 4.x can build it (version 3.x
couldn't).

So far I have 2 alternatives in mind, do you have others (in addition
to adding RAM)?

1. Use 8 functions and files, with only 1000 cases each.
2. Use 2 or more jump tables in the same file, reducing the total
   number of cases (if possible, have to check).

Note that this program is focused on speed (currently the fastest MARS
simulator).

Thanks and Best Regards,
Ale
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-help/attachments/20080120/06634af6/attachment.sig>