This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFD: hookizing BITS_PER_UNIT in tree optimizers / frontends
On Nov 24, 2010, at 4:04 PM, Joern Rennecke wrote:
> 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.
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