RFD: hookizing BITS_PER_UNIT in tree optimizers / frontends

[Joern Rennecke]

Quoting Richard Guenther <richard.guenther@gmail.com>:

> So, Joern, maybe you can clarify what the benefit is in hookizing
> BITS_PER_UNIT?

The point is that I want to eliminate all tm.h macro uses from the
tree optimizer and frontend files, so that they can stop including
tm.h .  When I first tried putting all patches to eliminate tm.h includes
from target.h, function.h and gimple.h together, a missing definition of
BITS_PER_UNIT was the first problem that popped up.  Also, even if the
count of files where BITS_PER_UNIT is the only tm.h macro is low right now,
if we don't have a strategy how to deal with it, it'll remain the last
macro standing and block all efforts to get rid of the tm.h includes.
With our current supported target set, we can actually
define BITS_PER_UNIT as constant 8 in system.h - that'd get it out
of the way.
If we actually actually get different different BITS_PER_UNIT values again,
we can generate a header file to define the appropriate value, but
with our current target set, there would be little point and little test
coverage for doing that.