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.