On Nov 24, 2010, at 6:45 AM, Richard Guenther wrote: > On Tue, Nov 23, 2010 at 9:09 PM, Joern Rennecke <amyl...@spamcop.net> wrote: >> If we changed BITS_PER_UNIT into an ordinary piece-of-data 'hook', this >> would not only cost a data load from the target vector, but would also >> inhibit optimizations that replace division / modulo / multiply with shift >> or mask operations. >> So maybe we should look into having a few functional hooks that do common >> operations, i.e. >> bits_in_units x / BITS_PER_UNIT >> bits_in_units_ceil (x + BITS_PER_UNIT - 1) / BITS_PER_UNIT >> bit_unit_remainder x % BITS_PER_UNIT >> units_in_bits x * BITS_PER_UNIT >> >> Although we currently have some HOST_WIDE_INT uses, I hope using >> unsigned HOST_WIDE_INT as the argument / return type will generally work. >> >> tree.h also defines BITS_PER_UNIT_LOG, which (or its hook equivalent) >> should probably be used in all the places that use >> exact_log_2 (BITS_PER_UNIT), and, if it could be relied upon to exist, we >> could also use it as a substitute for the above hooks. However, this seems >> a bit iffy - we'd permanently forgo the possibility to have 6 / 7 / 36 >> bit etc. units. >> >> Similar arrangements could be made for BITS_PER_WORD and UNITS_PER_WORD, >> although these macros seem not quite so prevalent in the tree optimizers. > > Well. Some things really ought to stay as macros. You can always > error out if a multi-target compiler would have conflicts there at > configure time.
That seems reasonable especially since BITS_PER_UNIT is likely to be consistent (and 8) in any multi-target compiler. paul