Joern Rennecke <amyl...@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
