This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: Fix other/44566
Quoting "Joseph S. Myers" <joseph@codesourcery.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 don't think it is merely a workaround; I think it is a proper
implementation.
Defining macros in config.in is an efficient way to specify target
dependencies. Requiring each port maintainer to replace 5 lines of
shell script with several pages of code is not a good use of developer's
time. Likewise, making developers jump through unnecessary hooks to
create a new port is not desirable.
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.
How long will single-target compilers be the main focus of GCC? It looks
like desktops are heading are heading into a CPU/GPU future, and
embedded systems are already commonly heterogeneous systems. My approach
allows to avoid hookization performance penalties for single as for
multi-targeted compilers, with the compiler technology we have available now.
And nothing would stop you from evolving this towards your scheme for
files that you can show can work without significant performance
penalty fully-hookized, compiled once.
You might want to see a stop to including tm.h in virtually every file,
but I don't see that anything is gained by abolishing tm.h altogether;
would you also argue against tm.c or the freedom of the port maintainer
to split tm.c into several files and include a common header file?
Well, if the target has a common header file, what is wrong if well-defined
set of files include it? The E.g. the hookization for insn-emit.c is the
optab table, so why would you stop it from including tm.h?
I'm not asking you to implement this.
Do you have an ETA for all that to fall into place? Will GCC still be
relevant then?
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.
But for the fully hookized / LTO / WHOPR future to make sense for a
multi-target compiler, you also have to make sure that you are not
lying to the compiler about the types that the hooks take.
So getting the hooks definitions to make sense when CUMULATIVE_ARGS,
enum reg_class, and HARD_REG_SET do not each refer to a unique type
is required no matter what path we take.