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.
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.
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.
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. Long term. Hookizing constants is easy - before proceeding
with those (seemingly expensive) ones I'd like to see all the _hard_
target macros converted into hooks. If there are only things like
BITS_PER_UNIT left we can talk again.
The hard parts certainly include target.h and function.h .
But these are necessary to get a proper overview on the actual
problem, and stopping us from sliding back.
When I fix these, a number of files suddenly become exposed as using
tm.h without including it themselves.
Should I change all these files to explicitly include "tm.h" then,
even if it's only for BITS_PER_UNIT?
