Re: behavior-preserving optimization in C, was compiler bugs

Anton Ertl wrote:


> The funny thing is that such weaknesses in language standards
> typically come around because two different implementations do it
> differently. And since the implementors know that the existing
> programs for their compilers rely on the order, they won't change the
> way their compilers work, and as a compromise this particular aspect
> is not standardized. Then a few years down the road the apologists
> (or, if you want, formalists, or language lawyers) say that programs
> that rely on the order like the ones that were the reason for the
> weakness are not just non-standard, but "incorrect" and ignore any
> bugs in the optimizer that occur in these programs. (I don't know if
> that's what happened in Scheme).


In fact, different implementations do it differently. But that's not
the reason why order of evaluation was left unspecified. I was the
coordinator of the committee that made the last IEEE standard for
Scheme, and I remember the arguments.


The fact is that side effects other than I/O are hardly ever actually
necessary in a scheme program, and using them is widely regarded as
bad style anyway. All variables are allocated in an initialized
state, so the condition of the stack or choice of register assignments
never affect variable contents. The vast majority of Scheme programs,
including programs written for implementations that have a constant
evaluation order, run just fine if the evaluation order is changed.


The order of evaluation was left unspecified mainly because academic
papers showed, and practical implemented systems demonstrated, that an
optimizing compiler, by picking an order of evaluation to minimize
register usage and the need to store intermediate results, could add
about ten percent to the speed of compiled programs.


Since the scheme community regards side-effects as mostly bad style
anyway, and existing systems had all kinds of evaluation orders, and
most code was portable between those systems anyway, and specifying an
evaluation order would have broken semantics on which some very good
optimizing compilers relied upon for their performance, we left
argument order unspecified. There were passionate partisans on both
sides of the question - some of whom felt as you do.


But - I think you are wrong about what an optimizer is for. An
optimizer is supposed to make programs run as fast as possible while
consuming the least other resources possible, within the language
spec. Programs that rely on something the language doesn't specify
already have varying behavior on different systems and an optimizer
has to regard *all* of those behaviors as correct. Picking one over
another is something it does (and _MUST_ do) for performance reasons.


                                                                Bear

Return to the comp.compilers page.
Search the comp.compilers archives again.