This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: Fix other/44566
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