On Wed, 24 Nov 2010, Richard Guenther wrote: > Well. Long term. Hookizing constants is easy - before proceeding > with those (seemingly expensive) ones I'd like to see all the _hard_ > target macros converted into hooks. If there are only things like > BITS_PER_UNIT left we can talk again.
I think doing easy ones first is natural - the hard ones are those affecting enum values, #if conditionals etc. (which includes a lot of constants), and if you convert the easy ones you can then see what's left. I think good priorities for moving away from target macros include: * Anything in code built for the target (use predefined macros, built-in functions or if appropriate macros defined in headers under libgcc/config/). * Anything that may expand to a function call for some targets and so requires tm_p.h to be included. * Anything clearly not performance-critical - for example, things used only at startup. But Joern has a different set of priorities: * Anything used in front ends. * Anything used in tree optimizers. And that's also fine. What's important is: * Do the conversion rather than spending ages talking about it. * *Think* about the appropriate conversion for a macro or set of macros rather than blindly mirroring the macro semantics in a hook. See for example my recent elimination of HANDLE_SYSV_PRAGMA and HANDLE_PRAGMA_PACK_PUSH_POP by enabling features unconditionally - not everything that is presently configurable by a target necessarily has a good reason for being configurable by a target, and sometimes the existing set of macros may not be a good way of describing what actually does need to be configured in a particular area. Or, in the BITS_PER_UNIT case, making sure to use TYPE_PRECISION (char_type_node) where that seems more appropriate. -- Joseph S. Myers jos...@codesourcery.com
