A few observations: * You don't mention anything about separating host-side and target-side configuration, which are also entangled. A slightly out-of-date list of target macros used in target-side code is at <http://gcc.gnu.org/wiki/Top-Level_Libgcc_Migration> and a clean back-end class would involve eliminating those (so libgcc only includes libgcc_tm.h and not the host-side tm.h at all). (Various of the other things listed on that page were finished by Rainer, but not the target macros.)
* I don't see the advantages of separating out the host information into a different API. Any particular compiler binary can only meaningfully run on one host, whereas in principle it should be possible to have multiple instances of a target class in one process so separating out the target interface does make sense. * It's not clear to me what's supposed to be different about the target_info class compared to the existing target structure. We "just" need to convert several hundred more target macros into hooks; that's the major work rather than any change from a global object to C++ classes or similar. (The transitional conversion whereby targhooks.c contains a hook definition that uses a target macro is, to my mind, of very limited value as an end-point; such conversions need finishing by eliminating all direct users of the macro, then converting all back ends to define the hook directly, then poisoning the macro and allowing and documenting only the hook.) Target macros used in front ends are indeed a good priority for converting to hooks. See previous discussions (and in some cases old patches by Joern) of how to convert some particular cases, e.g. INT_TYPE_SIZE or SIZE_TYPE (roughly, it seems to make sense to have hooks covering groups of related macros rather than one hook per macro in all cases). (Yes, a clean separation needs some new hook structures as well, e.g. in the driver, where the approach for defining the hooks would probably be different from the present one given how they tend to depend on the target OS as much as the target architecture.) * Quite a lot of target interfaces would be used by the front ends specifically for defining macros for building target libraries only; see the "probably predefine macros if -fbuilding-libgcc in most cases" list on that wiki page. (Thus, given a clean separation of target-side and host-side configuration, c-cppbuiltin.c is inevitably going to use a lot of target macros / hooks.) * Various cases of front-end folding are to get better warnings, e.g. to detect that in a signed-to-unsigned conversion the converted value is in fact never negative. I don't see this issue mentioned in the document. But maybe the GIMPLE generated by the front end should contain some form of note "give this warning if that condition is satisfied" and then the warnings would get given after some GIMPLE optimizations. * Option handling uses a single OPT_* enumeration with options from all parts of the compiler; for a full clean separation, you can no longer just have one array of all the options generated when GCC is built, and each bit of the compiler would need to see just a subset of the options. -- Joseph S. Myers jos...@codesourcery.com
