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>:
I think a proper implementation has the totality of the definition of the
interface for targets to define in just one place, i.e. the definition of
the target structure and its associated documentation. Targets providing
headers that target-independent code includes involves a hole in this
interface definition that makes it hard to tell quite what the interface
is (enumerating target macros is hard when any identifier could be a
macro).
You have a point there.
That is true for the actual target-provided include file(s).
However, defines from tm_defines could be screened for a list of interface
names, so that any other defines are only seen in tm.c .
Requiring every interface macro to be mentioned in a relevant .texi file is
probably a good idea; we should be able to grep @defmacx* from there.
Clarity and clear definition of internal interfaces is good in
itself, and avoiding macros where possible generally helps make interfaces
clearer and easier to analyze.
Certainly I'd consider that the function-like target macros, and others
that expand to code rather than constants, are the highest priority to
convert to hooks (and also less likely to have much performance impact;
the targets with more complicated expansions hopefully already use
function calls in the definitions of their macros).
Well, some expand to very little code, or on some targets, none at all.
So just because you have a function-like macro that expands to code does
not mean that it'll be cheap in terms of compiler performance to hookize
it.
This does not prevent tricks to build a file multiple times if that is
really felt to be necessary (you could build it with your namespaces and
with targetm defined to be a const target vector for a particular target,
so that LTO/WHOPR can separately optimize the functions for each target).
Yes, that sounds like a plan that can work.
But that means you'll have to wait for LTO/WHOPR to be mature enough before
you can remove performance-critical target macros.
And I'd also like to know what that does to our bootstrap speed.
Alternatively, we could impose rules on how interface macros can be defined
in tm.h, and sanitize the defines for all but tm.c so that only interface
macros are visible. And possibly helper macros in an agreed part of the
implementation namespace.
Admittedly that would be more of a hack, but it should be a hack that can
be put together over a long weekend - and it'll add very little to bootstrap
times.