On Wed, Nov 24, 2010 at 10:04 PM, Joern Rennecke <amyl...@spamcop.net> 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.
What's the benefit of not including tm.h in the tree optimizers and frontend files to our users? Richard.
