On Mon, 15 Nov 2010, Joern Rennecke wrote: > With 638 macros documented by @defmac, and 475 files that include tm.h , > our current approach to hookization is too slow to get the tree optimizers > and front ends independent of target macros in any useful timeframe.
I think it's perfectly feasible; I think the two-person year estimate I mentioned in <http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02675.html> for a project that would include a lot more than just eliminating target macros is realistic. A complete conversion of OPTIMIZATION_OPTIONS - a macro defined by lots of targets - took me about five hours' work. Many macros are defined by far fewer targets and would be much quicker to convert. Similarly, creating a wrapper in targhooks.c is much quicker than doing a complete conversion of a macro to a hook for all targets at one go. (Those macros that are referenced in libgcc or other target code, in the driver, etc., or in #if etc. conditionals, are of course harder.) > Therefore, I propose the following approach: > The target macros currently required by tree optimizers and frontends > get wrapper hooks, and these wrapper hooks get wrapper macros, to look By wrapper hooks you mean hooks in targhooks.c like the present transitional system? That seems reasonable, but I really don't see the benefit of the wrapper macros; they seem like needless complication. If the hook is defined to have the same semantics as the macro, changing the uses to use the hook directly is just search-and-replace (plus reformatting if lines go over 80 characters). > I'll create all the wrapper hooks initially as sub-members of a new > targetm.wrapper member; If people would like them somewhere else, we can > move them around later, but discussing individual placement of some > sixhundred hooks beforehand would just slow down things too much. I do not believe this is sensible. A key point of macro-to-hook conversion is to clean up the compiler's target interface, which means thinking individually about the correct hook form of each interface. A pile of automatically generated wrappers is hardly better than a pile of macros, and it is often the case that a one-to-one correspondence of macros and hooks is not appropriate. It's much better to work in thematic groups. I have previously considered the question of how you identify all target macros to know that a conversion is complete. My conclusion is: Define a target macro for this purpose to be a macro defined in a config/ header listed in tm_file and used in a source file outside of config/. This is not sufficient for a multi-target compiler of the form I was considering - there are macros such as HAVE_<insn> that are defined by generator programs and tested in front ends, and those such as DELAY_SLOTS and INSN_SCHEDULING that similarly are defined by generator programs (but at least those two are not tested in front ends). And there are also target macros that only get tested in other files in config/. But it is still a very useful step in cleaning up the target interfaces in the compiler. Then any target macro must have at least one of the following properties: * The macro is tested with #if/#ifdef/#ifndef/#elif in a source file outside of config/ (but including front-end subdirectories). Care is needed in identifying such macros through grep because of backslash-newline line continuations and because it's possible some macros are only tested in generated files not directly in source files. Of course lots of macros tested in preprocessor conditionals will not be target macros, but you need to check the definitions of such macros to find any cases such as: #define FOO TARGET_MACRO #if FOO * The macro is defined by every target. Such macros could be found by going through all the headers in tm_file for some single convenient target that does not have too much defined in the headers listed there. -- Joseph S. Myers jos...@codesourcery.com