This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFD: hookizing BITS_PER_UNIT in tree optimizers / frontends


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]