Re: GCC internal re-architecture proposal

[Andrew MacLeod <amacleod at redhat dot com>]

On 06/21/2013 12:16 PM, Joseph S. Myers wrote:
> 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.)
yeah, I didn't go into any configuration stuff... I don't understand it 
well enough (and avoid it like the plague :-)  so that will require some 
outside assistance :-)

Thats something that can be flushed out better in the future for sure.


> * 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.
That has been brought up, and It may not be worth any effort at all.   I 
added it more for completeness and consideration for getting that 
information "all in one place".  It may well come to nothing.
> * 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"

There may not be any difference.  The term target_info was just taken 
out of my hat. It may well be that we just extend the existing 
structure.   It just need to be flushed out fully and completed. Im not 
terribly familiar with those bits, so i didn't give it much detail :-)
> 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.)
I think that sounds like a most reasonable way to proceed.
> 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).
indeed, thats exactly the sort of low-hanging simplifications I was 
thinking about, and I'm sure there will be others
> * 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.)
If thats where most of it lies, maybe there is some way to "push" some 
of that activity into the backend?...   I'll investigate c-cppbuiltin.c 
at some point when I get some time.   "Heavy" consumers like that would 
show up after the initial conversion stages and we can consider how to 
improve it.

> * 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.

Indeed, a previous incarnation of the document took that idea to further 
extremes, but that also sounds highly reasonable.   The gimple fodler 
may be able to issue those sorts of warnings as it "optimizes" by 
folding.   I'll add something back in about that.
> * 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.
Good observation, I'll add something about that too.

Thanks!

Andrew