Re: [9fans] splitting the compiler

[forsyth@caldo.demon.co.uk]

>>We can make the first and the second not exclusive by having -O flags
>>so while developing (you want fast compiling and no new bugs generated
>>by the compiler) you don't use 2.  The issue here is the 3rd
>>constraint.  If you add a complex optimizer the code is less portable.

many (i'd have said nearly all) of the worthwhile fancier global optimisations are
perfectly portable, however much code they take to implement.   indeed, it's often
much easier to do them in a high-level intermediate representation
than a low-level machine-oriented one because there is much more context available.
arguably, some of the fancier optimisations are often compensating for
the low level of the programming language, and it's sometimes much
better to address that directly.   (very high-level languages can pose their
own different problems for compilation, of course.)

furthermore, the least buggy optimising compilers i've used
have had most of the optimiser on by default.  it's the rarely-invoked
things that tend to introduce bugs (in my experience, and that
of Linux, i've observed, with gcc).

as someone observed, for system implementation languages like C--and
come to think of it, it was even true of less system-y FORTRAN and Pascal, certainly
Ada--what the language definition actually guarantees is often a
significant subset of what programmers simply assume they can rely
upon.  readable language definitions that spell out these points
clearly would help, but that often conflicts with the desire for
(notional) precision or flexibility in implementation.  by contrast
with many users of a language, most compiler writers tend to know the
definition fairly well, except perhaps for enormous langauges,
but authors of compilers that are intended to
offer big code improvements (for particular classes of programs) are
even more like shyster lawyers with an eye for the fine print.