This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: semi-automatic hookization
On Mon, 15 Nov 2010, Joern Rennecke wrote:
> With 638 macros documented by @defmac, and 475 files that include tm.h ,
> our current approach to hookization is too slow to get the tree optimizers
> and front ends independent of target macros in any useful timeframe.
I think it's perfectly feasible; I think the two-person year estimate I
mentioned in <http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02675.html> for
a project that would include a lot more than just eliminating target
macros is realistic.
A complete conversion of OPTIMIZATION_OPTIONS - a macro defined by lots of
targets - took me about five hours' work. Many macros are defined by far
fewer targets and would be much quicker to convert. Similarly, creating a
wrapper in targhooks.c is much quicker than doing a complete conversion of
a macro to a hook for all targets at one go.
(Those macros that are referenced in libgcc or other target code, in the
driver, etc., or in #if etc. conditionals, are of course harder.)
> Therefore, I propose the following approach:
> The target macros currently required by tree optimizers and frontends
> get wrapper hooks, and these wrapper hooks get wrapper macros, to look
By wrapper hooks you mean hooks in targhooks.c like the present
transitional system?
That seems reasonable, but I really don't see the benefit of the wrapper
macros; they seem like needless complication. If the hook is defined to
have the same semantics as the macro, changing the uses to use the hook
directly is just search-and-replace (plus reformatting if lines go over 80
characters).
> I'll create all the wrapper hooks initially as sub-members of a new
> targetm.wrapper member; If people would like them somewhere else, we can
> move them around later, but discussing individual placement of some
> sixhundred hooks beforehand would just slow down things too much.
I do not believe this is sensible. A key point of macro-to-hook
conversion is to clean up the compiler's target interface, which means
thinking individually about the correct hook form of each interface. A
pile of automatically generated wrappers is hardly better than a pile of
macros, and it is often the case that a one-to-one correspondence of
macros and hooks is not appropriate. It's much better to work in thematic
groups.
I have previously considered the question of how you identify all target
macros to know that a conversion is complete. My conclusion is:
Define a target macro for this purpose to be a macro defined in a config/
header listed in tm_file and used in a source file outside of config/.
This is not sufficient for a multi-target compiler of the form I was
considering - there are macros such as HAVE_<insn> that are defined by
generator programs and tested in front ends, and those such as DELAY_SLOTS
and INSN_SCHEDULING that similarly are defined by generator programs (but
at least those two are not tested in front ends). And there are also
target macros that only get tested in other files in config/. But it is
still a very useful step in cleaning up the target interfaces in the
compiler.
Then any target macro must have at least one of the following properties:
* The macro is tested with #if/#ifdef/#ifndef/#elif in a source file
outside of config/ (but including front-end subdirectories). Care is
needed in identifying such macros through grep because of
backslash-newline line continuations and because it's possible some macros
are only tested in generated files not directly in source files. Of
course lots of macros tested in preprocessor conditionals will not be
target macros, but you need to check the definitions of such macros to
find any cases such as:
#define FOO TARGET_MACRO
#if FOO
* The macro is defined by every target. Such macros could be found by
going through all the headers in tm_file for some single convenient target
that does not have too much defined in the headers listed there.
--
Joseph S. Myers
joseph@codesourcery.com