Path: utzoo!attcan!uunet!husc6!bloom-beacon!mit-eddie!bu-cs!purdue!umd5!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.std.c
Subject: Re: Question about regrouping of operands
Message-ID: <7952@brl-smoke.ARPA>
Date: 21 May 88 15:17:18 GMT
References: <16490001@hpcllz2.HP.COM> <881@actnyc.UUCP> <19000@watmath.waterloo.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 28

In article <19000@watmath.waterloo.edu> rbutterworth@watmath.waterloo.edu (Ray Butterworth) writes:
>Now if integer overflow checking is enabled, the compiler is
>no longer free to do the additions in any order it wants.  It
>must do them in precisely the order that the programmer has
>requested, since the programmer might have specificly requested
>that order to prevent overflow.

This is correct.  However, it has not been demonstrated that a
serious loss of efficiency will necessarily result from removal
of this kind of optimization.  The only way I can imagine it being
significant would be for the hardware to provide extremely poor
data caching (for example, only a couple of data registers) so
that the compiler is forced to resort to more expensive caching
(for example, via push/pop).  My feeling is that people with
hardware like that already have much worse problems to worry about.

>With this change to the order of additions, the world will again
>lose out on compilers that help us to write more reliable code.

Overflow checking does not help in the writing of more reliable
code, but rather in the detection of unreliable code at a hard-to-
predict moment during actual execution.  There are certainly cases
in which I would prefer such an application to keep running even
with a slightly wrong behavior rather than simply fault.

>I'll never understand why they did it.

I can't help you there.