Mark Roulo (nothanks@xxx.com) on 6/24/10 wrote:
---------------------------
>I suspect that one of the issues making GCC larger/more-complicated/harder-to-maintain
>is that the architectures that it supports are much more varied (weirder) as a group
>than any one is individually. The compiler internals have to handle the collective strangeness.

Yes but not only that. Admittedly the back-end design is quite old and convoluted but it is very solid, supports all kind of crazy architectures (*), is well documented and has a lot of implementations. Changing it has never been an option because it would require completely rewriting and re-testing *everything*. In spite of this it still gets some large, structural improvements from time to time (lately the register allocator was changed and significant improvements to the way conditions and branching were handled were made).

On top of that GCC has lots of front-ends too, many which also support significant extensions. What other compiler supports both very high level stuff like OpenMP or native compilation of Java on the front-end, polyhedral loop transformations in the architecture-independent optimizer as well as deeply embedded architectures like H8/300 in the back end? GCC code is as complex as the feature set is vast. I doubt that many other compilers would be much easier to maintain while still having the same feature set. In fact *no* other compiler compares with GCC in the breadth and depth of both language and target support.

>*) Unless you want a totally different instruction scheduler for each target architecture
>(and maybe you do ... maybe this is what GCC already does?), then you need some
>sort of super-set of all the constraints one can have when building instruction
>sequences (the branch-delay-slot is one example of this sort of constraint). The
>super-set is going to be more complicated than any one constraint set.

IIRC instruction scheduling is architecture independent but an architecture must provide its own model to make the scheduler do its work.

(*) When I say crazy architectures I mean real *crazy* stuff BTW. IA64 or old SPARC delay-slots are quite easy to handle. Supporting machines with sub-registers, a register bank that changes depending on the CPU status, accumulators or uneven pointer sizes (24-bit pointers anyone?) is much harder. GCC supports all of that stuff plus much more.