On Mon, 15 Nov 2010, Joern Rennecke wrote: > Quoting "Joseph S. Myers" <jos...@codesourcery.com>: > > > 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. > > I was more thinking of getting the frontend and tree optimizers weaned off > target macros within one to four weeks.
I don't see why that shouldn't be done *properly* in four person-weeks. I can't imagine a problem doing a targhooks.c-type conversion, without any wrapper macros, in that time; in four person-weeks it should be possible to convert *every single target macro that doesn't have #if-type difficulties* to use a properly named and located hook with a default in targhooks.c, not just the limited subset used in front ends and tree optimizers. Do you have a list of the macros in question and the targets for which they are defined, that together with figures for time-per-macro and time-per-macro-per-target makes you think proper conversions are infeasible? I should point out that it's generally better for changes to be done in more (and more reviewable and bisectable) incremental patches rather than fewer. Note how my ongoing options/multilibs patch series is at 76 logical patches so far with plenty more to come. > > 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. > > Still, there are so many of them, and we can't reap the benefits till we > have covered all the ones that are used outside of the rtl centric files. Important benefits include cleaner internal interfaces, and every macro you convert (or remove - sometimes removing a macro is the right approach instead of a direct conversion) improves the internal interfaces. > > By wrapper hooks you mean hooks in targhooks.c like the present > > transitional system? > > Yes, except that for most of the hooks, I expect to select only the > argument / return types, and let a new or extended generator program > write the hook code. Some types would nominally have an enum, but actually > use integers, and be casted in the relevant places. That, too, is supposed > to be handled by the autogeneration program. I'd advise making the generator a tools to help in editing targhooks.c and other existing source files (such as tm.texi.in), to make the existing form of transition easier, rather than something separate and not integrated into the existing transition process. > Yes, but search-and-replace and reformatting for so many macros is also a I really don't think it's "so many" - and at least I expect most macros used in those parts of the compiler are not used in many different places. > lot of work (if you think ident can do the job, I'd like to see a patch I'd imagine at most a few seconds per call site. > submission to indent to do correct and conservative reformatting of > GCC sources). Plus, it generates a lot of repository churn. Repository churn is inevitable in cleanups - and as I said, lots of incremental patches is much better than one big one (minimal incremental patches is also GCC policy). > And the target hook names will probably not be final, so you'd have to > search-and-replace after each hook name or site (targetm sub-struct) > change. You need to work with relevant maintainers. Post the list of macro names - and where they are used - and ask relevant maintainers what they want the hooks to look like, so as to get the desired names and positions in the structure in advance of making the changes. (And make the program you use for the conversion process support inserting things in the places people specify, with the names they specify.) Posting lists will also make it easy for maintainers to do their own conversions if they wish. What front ends use what target macros? What tree optimizers use what target macros? Also make sure to work well with existing ongoing work and pay attention to already expressed views about what certain hook conversions should look like. Avoid causing problems with the work to make the preprocessor predefine the right macros for Fortran. Note my classification of target configuration information in <http://gcc.gnu.org/ml/gcc/2010-10/msg00294.html>. Note what I said in <http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01874.html> about how macros such as SIZE_TYPE should be converted to hooks, not a one-to-one conversion. Similarly, *_TYPE_SIZE should not be converted one-to-one either; I'd suggest having a hook that takes an enum integer_type_kind and returns the size, rather than a separate hook for each type - and WCHAR_TYPE_SIZE is a target macro that should go away completely without being replaced by a hook (it's derivative of information in WCHAR_TYPE, and is only now used by Ada). > That is true. We probably want a bitmap of the named patterns for which > the frontends want to test HAVE_xxx, unless the use can be easily replaced > with an optabs query - the latter might work if the frontend wants to know We recently noted that optabs don't work for defining preprocessor macros because they aren't set up when just preprocessing (as opposed to when cc1 is actually compiling). > > * 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. > > This is not a very useful criterion, because it covers so many macros that > are not used outside the rtl passes. It'd have to be filtered against My point was how to identify *all* target macros, which I consider a useful thing to do. You can then filter out those you care about. Or produce a list of undocumented target macros (cf. bug 3386 and my old message linked from there) so we can move towards tm.texi.in really documenting all target macros. (Personally I think a complete list of target macros that are used in code compiled for the target - including various C files in ada/ - would be very interesting - those macros are both ones to be careful about in hook conversions, if they are also used for the host, and ones that need dealing with as part of completing the toplevel libgcc transition.) -- Joseph S. Myers jos...@codesourcery.com
