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.

Also we do devirtualize them just late, only turning indirect call to direct
call that has very little runtime effect on modern hardware.  Hopefully
ipa-prop infrastructure can be extended easilly to handle devirtualization
before inlining.

Honza