On Wed, Nov 24, 2010 at 4:22 PM, Joern Rennecke <amyl...@spamcop.net> wrote: > Quoting Richard Guenther <richard.guent...@gmail.com>: > >> On Wed, Nov 24, 2010 at 3:12 PM, Joern Rennecke <amyl...@spamcop.net> >> wrote: >>> >>> 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. > > RTL optimizers tend to have a lot of target dependencies; hookizing them > all is likely impractical, and also to have a performance impact. > > Also, by making the tree optimizers target independent, you can make > optimizations that consider more than one target. > > Because RTL optimizers work on highly target-dependent program > representations, the decision on what target's code to work on has already > been fixed by the time the RTL optimizers run.
As we are moving towards doing more target dependent optimizations on the tree level this doesn't sound like a sustainable opinion. GIMPLE is just a representation - whether it is target dependent or not isn't related to that it is GIMPLE or RTL. >> 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. > > As compared to... having a multi-year unfinished hookization process that > hasn't provided any new functinality yet. And hookizing BITS_PER_UNIT brings you closer exactly how much? Tackle the hard ones. Because if you can't solve those you won't succeed ever and there's no reason to pay the price for BITS_PER_UNIT then. > I don't think hookizing the frontends and tree optimizers will have a > noticable performance impact. > And if you must have the abolute fastest compiler, LTO should eventually be > able to inline the hooks if they are really only returning a constant. Not for a multi-target compiler where the hooks are in shared loadable modules like Diego envisions. Maybe we should at least have a way to specify indirect function calls are 'const' or 'pure', I don't know if that works right now, but I doubt it (decl vs. type attributes, etc.). > With regards to BITS_PER_UNIT, the issue is not so much that I really need > it hookized for a multi-target compiler - ultimately there have to be > consistent structure layout rules for an input program. > > The issue is that BITS_PER_UNIT is defined in tm.h, and if every > file that wants to know BITS_PER_UNIT includes tm.h for that purpose, > we'll continue to have hard-to-predict interactions between target, > midddle-end and front-end headers in the frontends and tree optimizers, > and other macros can creep in unnoticed which work on one target, but > not for some other target. > Hookizing and poisoning individual macros is only patchwork, and it > can actually give higher performance penalties when you hookize > the macro even in files that are tighly coupled with the target definitions > - > as many RTL optimizers are. > > The only watertight way to make sure frontends do not use macros from tm.h > is for them not to include that header, and and neither should any of the > headers they need include that header; make this a written policy, and > poison TM_H for IN_GCC_FRONTEND . Well, it was already said that maybe the FEs should use type-precision of char-type-node. I don't know if splitting tm.h into good-for-tree and not-good-for tree is a way to go, but it's certainly a possibility if your short-term goal is to avoid accidential use of target information. Richard.
