On Tue, 23 Sep 2014, Andrew MacLeod wrote: > if() and target hooks arent exactly easy either..
Indeed - but I think the modularity goal is for the vast bulk of target macros to become hooks (not necessarily a one-to-one conversion, in some cases the right representation of the semantics may need to be rethought as part of the conversion to a hook). Among other things a hook has defined return type, defined argument type and uses all its arguments at the call site, so avoiding various cases of failure to build depending on the configured target because of warnings depending on the target macros in use. There are about 680 target macros at present. My most recent data indicates 154 of them are used in front ends (144 if you ignore front end drivers) - list appended (may have false positives and false negatives). If a few do not become hooks, the implication is that there are limited, well-defined parts of the compiler (RTL parts?) that need to be built separately for each target in a multi-target configuration. For proper front end and back end separation there would be other issues to deal with as well, such as how option handling presently expects all options to go in a single OPT_* enum and a single array of option data (and the generated options header has contents relating to all parts of the compiler visible everywhere). > if redefine the macro in terms of a target hook, but then you are pushing the > resolution out to run time... ie: Yes. In the bulk of cases this should not have significant performance impact (and there is always the option of getting LTO to devirtualize them). > maybe we can provide a fe-tm.h which is generated from tm.h and contains a > #define for each of macro that the front ends consume... > so during a build, we have a generator something like: > > #include "tm.h" > <...> > fprintf (fe_defaults, "#define NO_DOLLAR_IN_LABEL %s\n", > properly_reformat_macro_string (#NO_DOLLAR_IN_LABEL)); Target macros often use other macros that may be defined in tm.h; I don't think there's any ready way for a generator to extract macro definitions. > I've been struggling with exactly how to separate the front end in a practical > way. I'm currently experimenting with providing a fe-interface.[ch] files To a first approximation, 154 hook conversion patches. There are ways to reduce that number. I've been adding various target macro references to c-cppbuilting.c lately in order to predefine macros with -fbuilding-libgcc to reduce use of tm.h in code built for the target. It may well be possible for more of the predefined macros currently defined through c-cppbuiltin.c to move to cppbuiltin.c (this makes them visible when Fortran is being preprocessed, but at least for -fbuilding-libgcc that's harmless - no-one should actually use -fbuilding-libgcc for Fortran). In other cases, you may be able to avoid the target macro in the front end without changing it to a hook elsewhere. For example, if a front end refers to INT_TYPE_SIZE, this can change to TYPE_PRECISION (integer_type_node) unless it's in code that may execute before integer_type_node is set up. In other cases, many macros may convert to a single hook. That would be the case with stdint.h types, for example - you don't want separate hooks for each of INT_FAST8_TYPE, INT_LEAST32_TYPE, etc.; there have been some past discussions of appropriate hook design in such cases. Much easier than avoiding target macro use in front ends would be a clean separation of target macros used in the driver from those used elsewere. Of the 78 target macros use in the driver (mostly *_SPEC), only about 12 are used elsewhere. It would be quite plausible for the driver's target macros to go in driver/config/. To do that, you'd need refactoring code that understands the structure of .h files at the preprocessor level, so it can tell when a macro is being conditionally defined / undefined / redefined, copy the conditionals along with the definition, and also copy out other macros on which those conditionals depend. Some cleanup would no doubt be needed first - eliminating uses of a few macros in code built for the target, moving macros used in multiple places to hooks in targetm_common - but much less than for stopping front ends using target macros. (There would also be a need to ensure every target gets a set of driver/config headers used in the driver that corresponds appropriately to the set of config/ headers used elsewhere.) I think many (hundreds) of target macros could be converted to hooks through such a semi-automated refactoring process with tools understanding the preprocessor structure of .h files. The main obstructions I see to doing so are: (a) target macros used in code built for the target (which I've been working on lately; I'd welcome more people picking up pieces from the list at <https://gcc.gnu.org/wiki/Top-Level_Libgcc_Migration>, especially (i) libobjc (PR 24775), (ii) architecture-specific cases); (b) target macros used in the driver (but as noted above, a separate refactoring could separate most of those from the main tm.h, once those used in other places are dealt with separately); (c) target macros used in #if, directly or indirectly through being in the expansion of another macro used in #if (where many could readily be converted to the pattern of a single default definition in defaults.h, so that it's easy for the refactoring process to tell how to convert to a hook). ADA_LONG_TYPE_SIZE FrontEnd ADJUST_FIELD_ALIGN FrontEnd MiddleEnd Target ASM_COMMENT_START Defaults FrontEnd MiddleEnd ASM_FORMAT_PRIVATE_NAME Defaults FrontEnd MiddleEnd ASM_OUTPUT_DEF Defaults FrontEnd MiddleEnd ATTRIBUTE_ALIGNED_VALUE Defaults FrontEnd BIGGEST_ALIGNMENT Defaults FrontEnd MiddleEnd BIGGEST_FIELD_ALIGNMENT FrontEnd MiddleEnd Target BITS_BIG_ENDIAN FrontEnd MiddleEnd BITS_PER_WORD Defaults FrontEnd MiddleEnd Target BOOL_TYPE_SIZE Defaults FrontEnd MiddleEnd BYTES_BIG_ENDIAN Defaults FrontEnd MiddleEnd CHAR16_TYPE FrontEnd CHAR32_TYPE FrontEnd CHAR_TYPE_SIZE Defaults FrontEnd MiddleEnd CPLUSPLUS_CPP_SPEC Defaults FrontEndDriver CTORS_SECTION_ASM_OP FrontEnd MiddleEnd C_COMMON_OVERRIDE_OPTIONS FrontEnd DATA_ABI_ALIGNMENT FrontEnd MiddleEnd DEFAULT_ABI FrontEnd DOLLARS_IN_IDENTIFIERS FrontEnd DONT_USE_BUILTIN_SETJMP FrontEnd MiddleEnd DOUBLE_TYPE_SIZE Defaults FrontEnd MiddleEnd DTORS_SECTION_ASM_OP FrontEnd MiddleEnd DWARF2_UNWIND_INFO Defaults FrontEnd MiddleEnd Target DWARF_ALT_FRAME_RETURN_COLUMN FrontEnd MiddleEnd DWARF_FRAME_REGISTERS Defaults FrontEnd MiddleEnd EH_FRAME_SECTION_NAME Defaults FrontEnd MiddleEnd EH_RETURN_STACKADJ_RTX FrontEnd MiddleEnd EH_TABLES_CAN_BE_READ_ONLY Defaults FrontEnd MiddleEnd FLOAT_TYPE_SIZE Defaults FrontEnd MiddleEnd FLOAT_WORDS_BIG_ENDIAN Defaults FrontEnd MiddleEnd FUNCTION_BOUNDARY Defaults FrontEnd MiddleEnd HANDLE_PRAGMA_PACK_WITH_EXPANSION FrontEnd HAVE_sync_compare_and_swaphi FrontEnd HAVE_sync_compare_and_swapqi FrontEnd HAVE_sync_compare_and_swapsi FrontEnd INIT_ARRAY_SECTION_ASM_OP FrontEnd MiddleEnd INIT_SECTION_ASM_OP FrontEnd MiddleEnd INT16_TYPE Defaults FrontEnd INT32_TYPE Defaults FrontEnd INT64_TYPE Defaults FrontEnd INT8_TYPE Defaults FrontEnd INTMAX_TYPE Defaults FrontEnd INTPTR_TYPE Defaults FrontEnd INT_FAST16_TYPE Defaults FrontEnd INT_FAST32_TYPE Defaults FrontEnd INT_FAST64_TYPE Defaults FrontEnd INT_FAST8_TYPE Defaults FrontEnd INT_LEAST16_TYPE Defaults FrontEnd INT_LEAST32_TYPE Defaults FrontEnd INT_LEAST64_TYPE Defaults FrontEnd INT_LEAST8_TYPE Defaults FrontEnd INT_TYPE_SIZE Defaults FrontEnd MiddleEnd JCR_SECTION_NAME Defaults FrontEnd JMP_BUF_SIZE FrontEnd MiddleEnd LIBSTDCXX FrontEndDriver LIBSTDCXX_STATIC FrontEndDriver LONG_DOUBLE_TYPE_SIZE Defaults FrontEnd MiddleEnd Target LONG_LONG_TYPE_SIZE Defaults FrontEnd MiddleEnd Target LONG_TYPE_SIZE Defaults FrontEnd MiddleEnd MAIN_STACK_BOUNDARY FrontEnd MALLOC_ABI_ALIGNMENT Defaults FrontEnd MiddleEnd MATH_LIBRARY FrontEndDriver MATH_LIBRARY_PROFILE FrontEndDriver MAX_BITS_PER_WORD Defaults FrontEnd MiddleEnd MAX_FIXED_MODE_SIZE Defaults FrontEnd MiddleEnd MAX_OFILE_ALIGNMENT Defaults FrontEnd MiddleEnd MAX_STACK_ALIGNMENT Defaults FrontEnd MiddleEnd MINIMUM_ATOMIC_ALIGNMENT FrontEnd MODIFIED_WCHAR_TYPE FrontEnd MODIFY_JNI_METHOD_CALL FrontEnd MULTIPLE_SYMBOL_SPACES Defaults FrontEnd NO_DOLLAR_IN_LABEL Defaults Driver FrontEnd MiddleEnd NO_DOT_IN_LABEL Defaults Driver FrontEnd MiddleEnd NO_IMPLICIT_EXTERN_C FrontEnd OBJC_GEN_METHOD_LABEL FrontEnd OBJC_JBLEN FrontEnd OFFS_ASSIGNIVAR_FAST FrontEnd OFFS_MSGSEND_FAST FrontEnd PARM_BOUNDARY Defaults FrontEnd MiddleEnd PCC_BITFIELD_TYPE_MATTERS FrontEnd MiddleEnd Target PCC_STATIC_STRUCT_RETURN FrontEnd MiddleEnd PID_TYPE Defaults FrontEnd POINTER_SIZE Defaults FrontEnd MiddleEnd PREFERRED_STACK_BOUNDARY Defaults FrontEnd MiddleEnd PTRDIFF_TYPE Defaults FrontEnd PUSH_ARGS_REVERSED Defaults FrontEnd MiddleEnd Pmode Defaults FrontEnd MiddleEnd REGISTER_PREFIX FrontEnd MiddleEnd REGISTER_TARGET_PRAGMAS FrontEnd SHORT_TYPE_SIZE Defaults FrontEnd MiddleEnd SIG_ATOMIC_TYPE Defaults FrontEnd SIZE_TYPE Defaults FrontEnd MiddleEnd STACK_CHECK_MAX_VAR_SIZE Defaults FrontEnd MiddleEnd STACK_GROWS_DOWNWARD Defaults FrontEnd MiddleEnd STACK_POINTER_REGNUM FrontEnd MiddleEnd STDC_0_IN_SYSTEM_HEADERS FrontEnd STRICT_ALIGNMENT Defaults FrontEnd MiddleEnd SUPPORTS_INIT_PRIORITY Defaults FrontEnd SUPPORTS_ONE_ONLY Defaults FrontEnd MiddleEnd SUPPORTS_WEAK Defaults FrontEnd Target TARGET_64BIT Driver FrontEnd MiddleEnd Target TARGET_ALIGN_NATURAL FrontEnd Target TARGET_CAN_SPLIT_STACK FrontEndDriver TARGET_CPU_CPP_BUILTINS FrontEnd TARGET_DECLSPEC Defaults FrontEnd TARGET_DEC_EVAL_METHOD Defaults FrontEnd TARGET_DLLIMPORT_DECL_ATTRIBUTES Defaults FrontEnd MiddleEnd TARGET_EXECUTABLE_SUFFIX Driver FrontEnd Target TARGET_FLT_EVAL_METHOD Defaults FrontEnd MiddleEnd TARGET_FLT_EVAL_METHOD_NON_DEFAULT FrontEnd TARGET_FORMAT_TYPES FrontEnd TARGET_N_FORMAT_TYPES FrontEnd TARGET_OBJECT_SUFFIX Driver FrontEnd Target TARGET_OBJFMT_CPP_BUILTINS FrontEnd TARGET_OPTF FrontEnd TARGET_OS_CPP_BUILTINS FrontEnd TARGET_OVERRIDES_FORMAT_ATTRIBUTES FrontEnd TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT FrontEnd TARGET_OVERRIDES_FORMAT_INIT FrontEnd TARGET_PTRMEMFUNC_VBIT_LOCATION Defaults FrontEnd MiddleEnd TARGET_SOLARIS FrontEndDriver TARGET_USE_JCR_SECTION Defaults FrontEnd Target TARGET_USE_LOCAL_THUNK_ALIAS_P Defaults FrontEnd TARGET_VTABLE_DATA_ENTRY_DISTANCE Defaults FrontEnd TARGET_VTABLE_ENTRY_ALIGN Defaults FrontEnd TARGET_VTABLE_USES_DESCRIPTORS Defaults FrontEnd TARGET_VXWORKS_RTP FrontEndDriver TARGET_WEAK_NOT_IN_ARCHIVE_TOC Defaults FrontEnd TEXT_SECTION_ASM_OP FrontEnd MiddleEnd TIME_LIBRARY FrontEndDriver TRAMPOLINE_ALIGNMENT Defaults FrontEnd MiddleEnd TRAMPOLINE_SIZE FrontEnd MiddleEnd UINT16_TYPE Defaults FrontEnd UINT32_TYPE Defaults FrontEnd UINT64_TYPE Defaults FrontEnd UINT8_TYPE Defaults FrontEnd UINTMAX_TYPE Defaults FrontEnd UINTPTR_TYPE Defaults FrontEnd UINT_FAST16_TYPE Defaults FrontEnd UINT_FAST32_TYPE Defaults FrontEnd UINT_FAST64_TYPE Defaults FrontEnd UINT_FAST8_TYPE Defaults FrontEnd UINT_LEAST16_TYPE Defaults FrontEnd UINT_LEAST32_TYPE Defaults FrontEnd UINT_LEAST64_TYPE Defaults FrontEnd UINT_LEAST8_TYPE Defaults FrontEnd UNITS_PER_WORD Defaults FrontEnd MiddleEnd Target USE_GLD FrontEndDriver WCHAR_TYPE_SIZE Defaults FrontEnd WIDEST_HARDWARE_FP_SIZE FrontEnd Target WINT_TYPE Defaults FrontEnd WORDS_BIG_ENDIAN Defaults FrontEnd MiddleEnd -- Joseph S. Myers jos...@codesourcery.com