RFD: inline hooks

RFD: inline hooks

[Joern Rennecke]

For the rtl passes, architecture target macros are not much of an issue
with regards to executable code modularity: since the rtl passes are
deeply interwoven with the insn-*.c files, we might as well compile one
specialized copy of the rtl passes for each target architecture.

Another argument against leaving the macros are their often ill-defined
interface types and the call-by-name semantics that make all the identifiers
in scope at the call site a potential interface.

We could avoid the latter problems without sacrificing the speed that we
get from target-specific code by replacing the target macro with an
inline hook.  E.g. consider HARD_REGNO_MODE_OK.  We could have $tm_file
define TARGET_HARD_REGNO_MODE_OK as a static inline function, or #define it
as the name of a static inline function somewhere else in $tm_file.
The function's address will be in TARGET_INITIALIZER, and thus type
checking on the function definition will be done.

But a file that includes tm.h will be able to use the function
TARGET_HARD_REGNO_MODE_OK directly, which can then be inlined, thus
giving type safety without performance penalty.

Re: RFD: inline hooks

[Ian Lance Taylor]

Joern Rennecke <amylaar@spamcop.net> writes:

> For the rtl passes, architecture target macros are not much of an issue
> with regards to executable code modularity: since the rtl passes are
> deeply interwoven with the insn-*.c files, we might as well compile one
> specialized copy of the rtl passes for each target architecture.
>
> Another argument against leaving the macros are their often ill-defined
> interface types and the call-by-name semantics that make all the identifiers
> in scope at the call site a potential interface.
>
> We could avoid the latter problems without sacrificing the speed that we
> get from target-specific code by replacing the target macro with an
> inline hook.  E.g. consider HARD_REGNO_MODE_OK.  We could have $tm_file
> define TARGET_HARD_REGNO_MODE_OK as a static inline function, or #define it
> as the name of a static inline function somewhere else in $tm_file.
> The function's address will be in TARGET_INITIALIZER, and thus type
> checking on the function definition will be done.
>
> But a file that includes tm.h will be able to use the function
> TARGET_HARD_REGNO_MODE_OK directly, which can then be inlined, thus
> giving type safety without performance penalty.

I think that would be a plausible implementation technique which a
backend could choose to use.  I think it should definitely be a macro
which refers to a reasonable name.  We would then want to have
defaults.h, or some such header file, do something like

#ifndef TARGET_HARD_REGNO_MODE_OK
#define TARGET_HARD_REGNO_MODE_OK(REGNO, MODE) \
  targetm.hard_regno_mode_ok ((REGNO), (MODE))
#endif

Ian

Re: RFD: inline hooks

[Joseph S. Myers]

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

See <http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02244.html> for example 
on the direction of moving away from inline functions in headers.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: RFD: inline hooks

[Joern Rennecke]

Quoting "Joseph S. Myers" <joseph@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.

Re: RFD: inline hooks

[Joseph S. Myers]

On Thu, 2 Dec 2010, Joern Rennecke wrote:

> The intended use for inline hooks would be macros that we are currently
> reluctant to fully convert to hooks because of concerns about performance.

Those can clearly be low priority.  Convert the others, see after that 
what LTO is like for hook devirtualization and inlining, demonstrate with 
performance figures that some more complicated approach is justified in a 
particular case.

-- 
Joseph S. Myers
joseph@codesourcery.com