On Wed, Nov 24, 2010 at 3:12 PM, Joern Rennecke <amyl...@spamcop.net> wrote: > Quoting Richard Guenther <richard.guent...@gmail.com>: > >> On Wed, Nov 24, 2010 at 1:56 PM, Joern Rennecke <amyl...@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.
I don't see why RTL optimizers should be different from tree optimizers. And we don't want to pay the overhead of hookization every target dependent constant just for the odd guys who want multi-target compilers that have those constants differing. Richard. > target libraries should also not use tm.h, but predefined macros or built-in > functions. I'm not currently working on that, though. >
