RFD: hookizing BITS_PER_UNIT in tree optimizers / frontends

[Joern Rennecke]

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

> On Wed, Nov 24, 2010 at 1:56 PM, Joern Rennecke <amylaar@spamcop.net> wrote:
>> So what are we going to do about all the tree optimizers and frontends that
>> use BITS_PER_UNIT?
>
> Tree optimizers are fine to use target macros/hooks, and I expect
> use will grow, not shrink.

Hooks are fine, as long as we can make the target vector type target
independent (see PR46500).  However, macro use means the tree
optimizer / frontend is compiled for a particular target.  That prevents
both mulit-target compilers and target-independent frontend plugins
from working properly.
>
>> Should they all include tm.h, with the hazard that more specific
>> macros creep in?
>> Or do we want to put this in a separate header file?
>
> I don't have a very clear picture of where we want to go with all the
> hookization.  And I've decided to postpone any investigation until
> more macros are converted (where it makes sense to).

I'm fine with the RTL optimizers to use target macros, but I'd like the
frontends and tree optimizers to cease to use tm.h .  That means
all macros uses there have to be converted.  That does not necessarily
involve target port code - a wrapper hook could be provided in targhooks.c
that uses the target macro.

target libraries should also not use tm.h, but predefined macros or  
built-in functions.  I'm not currently working on that, though.