Quoting Richard Guenther <richard.guent...@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.
