Quoting "Joseph S. Myers" <jos...@codesourcery.com>:
I think we want to move *away* from inline functions in headers and
towards link-time inlining, in the interests of modularity: if one
component of GCC cannot see the internals of another component at compile
time, it cannot use them but must use the actual interface of that
component, but inline functions often require internals to be visible.
tm.h is a case in point of exposing internals, as it exports a great many
macros that are really part of the internals of a particular back end and
so should only be visible in that back end (including the generated
insn-*.c files) and not in the RTL passes, so tempting people to put e.g.
TARGET_64BIT conditionals outside of config/ (TARGET_64BIT should be
private to the individual back ends).
The intended use for inline hooks would be macros that we are currently
reluctant to fully convert to hooks because of concerns about performance.
As such, all the users currently must include tm.h anyway.
Moreover, I would like to restrict the use to files that are naturally
tightly coupled with the target, e.g. rtl passes.
E.g. BITS_PER_UNIT use in frontends would not be eligible, because that
would block us from removing tm.h includes where they currently cause the
most maintenance issues.
If LTO can be brought up to the level that we can let it do the inlining,
and the impact on bootstrap times is acceptable, great: As Ian pointed
out, we can have a fallback definition for the TARGET_xxx macros that
uses targetm, so we can seamlessly phase out the use of tm.h as LTO is
improved.
The TARGET_xxx fallback macros can be auto-generated from target.def, into
a new header file. During the build we can also compile a test program
to verify that for all inline hooks where a TARGET_xxx is visible from tm.h,
an [extern (otherwise $(outfile) will get warnings)] declaration or an
[inline (presumably)] definition is in scope.
Thus, switching to the fallback macros should be easy: the tm.h
include is swapped for an include of the generated TARGET_xxx fallback
macro header
file when we have determined that the price in performance is / has become
affordable; this can be done for individual source files or groups,
depending on the progress of LTO and our analysis / assessment of the
performance impact vs. the implementation hiding benefits.
We can even have a configure option to continue to use tm.h (indirectly)
for bootstrapping on targets that can't support LTO-dependent bootstrapping
because of either issues with the object file format / linker or because
of resource constraints (e.g. bootstrapping on a games console).
For a multi-target compiler, we have the issue that LTO can't inline
function calls that look up the function pointer from a member of a
struct gcc_target that is in turn pointed to by a pointer variable.
To mitigate the performance impact of this, in a multi-target compiler,
we can compile the rtl-passes per target and have targetm defined to
the target's target vector, while tree passes would be compiled once and
have targetm defined such that it dereferences the pointer that points
to the current target vector.
