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.

Richard.

Reply via email to