Quoting "Joseph S. Myers" <jos...@codesourcery.com>:
On Thu, 18 Nov 2010, Joern Rennecke wrote:
1: At the end, target-def.h initalizes targetm, and whatever vectors we
might want to split out of it nor or in the future.
Disapprove, in the form in which you describe it. A key point of
splitting vectors is that different vectors are linked into different
programs and so need to be initialized in different places because each
vector references functions only present in certain programs.
At the moment I have to deal only with different pieces of the same program.
Adding support for multiple programs / DSOs should be straightforward.
But point 1 only really makes sense with the synergy of the following points,
so there is little point of doing only point 1.
FWIW, the existing infrastructure already allows you to change the place
where you include target-def.h , to avoid all these
#undef TARGET_FOO directives.
Moving of hooks should be infrequent enough - if you think about proper
placement in the first place
Maybe you should talk more with your colleagues. I had protested when
the CUMULATIVE_ARGS taking vectors were added to targetm, and I was
told they'd
be changed to taking void *, thus eliminating the problem.
Now people don't want void * because it lacks type safety. So these hooks
are really in the wrong place now. The target vector is a farce because
you can only use it if you include a header file that includes tm.h,
so target macro use can creep in undetected.
And target vectors of different targets are not type compatible, thus
a front end has to be compiled for a particular target for standards
compliance.
- that the need for mechanical search and
replace when you move them is not a problem.
That's only true if you get a timely patch review. (Probably not a problem
for codesourcery, with two global reviewers in house.)
Moving hooks around right now is painful because it creates huge patches
that can not be sensibly split up into easier to review chunks.
And the name of the target vector variable appears in every call site,
so it's also very awkward to change your mind on the exact naming.
Are you willing to do a review of:
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01813.html ?
