RFA: Fix other/44566

[Joseph S. Myers]

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.

To build a multi-front-end binary you'd need to:

* Finish eliminating calls to "convert" from non-front-end code.  Either 
change them to fold_convert, or if front-end conversions are needed then 
make it a langhook.  I think this is the last front-end function called 
directly from non-front-end code with no hook at all.

* Eliminate cases where langhooks-def.h defines a default name for a hook 
and multiple front ends define functions with that name: change front ends 
to use front-end-specific names for those hooks and remove the defaults.  
This is cases such as LANG_HOOKS_PUSHDECL defined to pushdecl.

* Make each front end use its own namespace for non-static functions 
internal to that front end.  This can be done with C++ namespaces, or 
simply by naming conventions such as c_* for non-static functions in the C 
front end.

* Where c-family code calls functions that both C and C++ define with the 
same name but different implementations, convert those to some form of 
hook.

* Where C code can call objc_* functions for C, getting the stub-objc.c 
implementations for C and real ones for ObjC, make either the C code or 
the real ObjC implementations include appropriate conditionals checking 
whether the compiler is in ObjC mode and acting like the stub versions if 
not.  (That is, eliminate stub-objc.c and just make ObjC a mode of the C 
front end that is selected at runtime.)

* Do something about ObjC++ (remove it, arrange for objc-act.c to need 
building only once like the c-family code or give functions different 
names for ObjC++ from those for ObjC); if it is kept, make it a runtime 
mode of the C++ front end.

* Check for any issues with any target's c_target_objs and cxx_target_objs 
being linked together.

* Actually link everything together and implement runtime language 
selection.

-- 
Joseph S. Myers
joseph@codesourcery.com