Quoting "Joseph S. Myers" <jos...@codesourcery.com>:
I think the cleanups involved in using the target vector / class more, and
other cleanups involved in the natural approach to multi-target GCC of
which the target vector is a part, are more useful than the end result
(for which compiling large parts of the compiler multiple times is an
interesting approach - I'd always thought of the aim as being a
multi-target compiler without target-independent files being built more
than once).

I remembered the reports of GCC getting slower due to the target macros
introduced so far (was it some 5% ?).
Therefore, tying a multi-targeted gcc to the previous elimination of all
non-target-vector target specifics seemed like a bad idea.

My approach still allows rtl passes that are present only once - all you have
to do is remove it from / not place it in the list of files that are
compiled for each target, and change the header files so that the declarations
for functions defined in this file are not put in the target namespace.

It might well be that slowdown when going all target-vector can be avoided
by using different abstractions, or using them in different ways.
But that'll be a gargantuous task; I am at more than a hundred target
specific files now.

Something also to consider is that it is quite common in C++ to compile the
same code multiple times.  I fact I toyed with the idea to drive the
support for multiple targets using templates but I gave up on that because:
- It's harder to transform the existing code to be encapsulated into template
  than to encapsulate it into a namespace.
- Mangled names would be more complex, casing debugging nightmares.
- It would probably result in ferrying around a this pointer, plus unknown
  abstraction penalties.

- Keeping to a minimal set of one simple C++ feature makes the code easier
  to understand.

Reply via email to