Re: RFA: Fix other/44566

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

On Sun, 27 Jun 2010, Joern Rennecke wrote:

> Quoting "Joseph S. Myers" <joseph@codesourcery.com>:
> 
> > On Sun, 27 Jun 2010, Joern Rennecke wrote:
> > > As my work shows, having the hooks coded in the individual targets is not
> > > required - using the existing macros to provide hooks works just fine.
> > 
> > It is fragile, because you need a way to ensure that no patch causes a use
> > of a macro to be introduced in a file built once-only;
> 
> We can fix that: we can poison the macro for these files.  Or to express it
> more robustly: poison them for all files that don't need access to this
> class of target macros.  I.e. the compiler backend rtl files / targethooks.c
> are the only ones to see compiler backend macros, the gcc driver hook file
> is the only one to see the driver macros etc.

Yes, there are workarounds.  I by far prefer the cleaner and simpler 
approach:

* The target vectors define everything about a target; there is no tm.h 
file at all, and every former target macro is poisoned for the whole 
compiler.  Nor are the macros used to initialize the target vector defined 
in .h files as some are at present (to ease the transition from macros to 
hooks, for those hooks that depend a lot on the OS as well as the target 
architecture); for target architecture vectors, there is exactly one 
definition of each hook, as a function that might if necessary contain 
further conditionals (if, not #if) internally.  I explicitly admit the 
possibility that there are separate target vectors for things depending 
heavily on both architecture and OS (e.g. specs in the driver), with 
arch-OS pairs providing .c files in such cases.

* We eat our own dogfood and make sure LTO/WHOPR can devirtualize target 
vector references so that clean abstractions and avoidance of macros do 
not make a single-target compiler less efficient.

I'm not asking you to implement this.  I am saying that the transition 
that has been under way for some time from target macros to hooks, with 
the explicit aim that each hook is defined directly as a function by each 
relevant target and the macros (and associated implementations of hooks in 
targhooks.c using those macros) go away completely, is a sound one and 
should continue, and we should not let the existence of multi-target 
approches that do not depend on this transition obstruct the continuation 
of this transition.

-- 
Joseph S. Myers
joseph@codesourcery.com