Re: RFA: Fix other/44566

[Jan Hubicka <hubicka at ucw dot cz>]

> On Mon, 28 Jun 2010, Jan Hubicka wrote:
> 
> > Since we produce several binaries (one for each frontend, that is 6 binaries)
> > and since we compile each twice to get in the checksum needed for PCH, we get
> > backend build 13 times for stage2 and 13times for stage3.  So we speak about
> > building backend 27 times instead of 3 that is considerable build time hit.
> 
> A multi-front-end binary (that uses a --front-end= option in argv[1] to 
> decide which front end it is) shouldn't be hard to build, to save build 
> time and reduce the size of multi-language binary distributions.  You'd 
> lose devirtualization of langhooks - but since some langhooks are modified 
> at runtime anyway, I don't know if devirtualization of langhooks actually 
> works, and I expect devirtualization of target hooks to be much more 
> significant for performance.

There is also alternative of getting incremental whopr to work cross 
binaries - i.e. if frontend changes nothing in a partition, it can be
used to build other binary.
This is tricky, we probably would need server handling the known partitions
to allow parallelizm that is something I definitly do not plan for next release.

I did some testing how much the partitions changes and at moment they do,
there are still macros and things that get compiled into it. Especially
concerning EH.

We do not devirtualize calls thruough static structures unless they are
declared const.

Having multi frontend binary (at least as an option) seems like nice goal,
especially because it imply cleanups and interface improvements.
>From performance POV I am however affraid that increasing compiler binary
would lead to even longer startup time.  I am not sure how large percentage
of the backend binary frontends would occupy.  Perhaps not too large.

Honza