On Nov 24, 2010, at 4:04 PM, Joern Rennecke wrote: > 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.
If BITS_PER_UNIT is all that's left, could you use some genxxx.c to extract that from tm.h and drop it into a tm-bits.h in the build directory? Then you could include that one instead of tm.h. paul