RFD: hookizing BITS_PER_UNIT in tree optimizers / frontends

[Joseph S. Myers]

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
joseph@codesourcery.com