Re: GCC internal re-architecture proposal

["Joseph S. Myers" <joseph at codesourcery dot com>]

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
joseph@codesourcery.com