On Wed, Nov 24, 2010 at 4:32 PM, Richard Guenther <richard.guent...@gmail.com> wrote: > 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.
Btw, I don't remember what your reason was for hookization, Joern. But I can't see why things like BITS_PER_UNIT cannot be part of the ABI/API between the middle-end and a possible target shared object. If the goal is to emit code for different targets from a single compilation (thus basically make the IL re-targetable) then hookization of BITS_PER_UNIT brings you exactly nothing as values derived from it are stored all over in the IL, so you'd need to fixup all types and decls and possibly re-layout things at the time you switch to a different target. So, Joern, maybe you can clarify what the benefit is in hookizing BITS_PER_UNIT? Thanks, Richard.
