RFD: inline hooks

Ian Lance Taylor iant@google.com
Thu Dec 2 02:00:00 GMT 2010


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



More information about the Gcc mailing list