tanner@ki4pv.UUCP (04/02/87)
We have reason to be suspicious of re-writing constructs such as
((x*4) - 69) * 12 ==> (x*48) - (69*12)
The fear is that we could introduce overflows for some values of x,
4, 69, and 12. This is a reasonable fear.
One proposed solution is to forbid such things altogether. Lousy,
slow code -- especially from macros.
The other is to allow them, and have some unwary sucker come
complaining that his prog is giving him an APR trap or the local equiv.
It seems to me that we might want to consider explicitly specifying
that under some circumstances, conforming compilers might be able to
do these things, under user control. A compiler could claim to
support some (including improper) subset of the following OPT levels:
0 = don't do any opts; writes lousy code
1 = clean up code; don't do questionable re-writes
2 = do anything it can think of
A fair warning would be given: anyone using level 2 had better be
sure of himself. Any compiler is free to neglect to supply any of
the levels, but must specify which it does support. Any programmer
who writes and immediately compiles level 2 deserves what he gets.
Thus, the person who knows best what can safely be done (me: the guy
using the damned conforming compiler) gets to say what can be done to
my code. The reasons for using level 0 instead of 1: it takes longer
to compile level 1 and we're still in the debugging phase; vendor
only gives levels {0,2} and we don't trust 2.
(What do you mean, this reminds you of a certain ALGOL compiler? Oh,
\fBthat\fR algol compiler. Right.)
--
<std dsclm> {akgua!codas allegra decvax!ucf-cs ihnp4!hropus}!ki4pv!tannerflip@osu-cgrg.UUCP (04/03/87)
In article <6943@ki4pv.UUCP>, tanner@ki4pv.UUCP writes: > [...] > The other is to allow them, and have some unwary sucker come > complaining that his prog is giving him an APR trap or the local equiv. > > It seems to me that we might want to consider explicitly specifying > that under some circumstances, conforming compilers might be able to > do these things, under user control. A compiler could claim to > support some (including improper) subset of the following OPT levels: > 0 = don't do any opts; writes lousy code > 1 = clean up code; don't do questionable re-writes > 2 = do anything it can think of > > A fair warning would be given: anyone using level 2 had better be > sure of himself. Any compiler is free to neglect to supply any of > the levels, but must specify which it does support. Any programmer > who writes and immediately compiles level 2 deserves what he gets. > The Convex C-1 vectorizing compiler does such a thing. Since vectorization is a tricky thing and a compiler cant read your mind all of the time it allows a few things... 1. compiler directives placed in line with the code. This allows turning on and off certain optomizations, for example, /*$dir scalar */ for(x=0; x<256; x++ ) { ... doesnt let the compiler try to vectorize a loop. 2. the -O0, -O1, and -O2 flags allow no, local and global scalar and local and global vector and scalar optomization. This makes things nice in your makefile for saying things like OPT_LEVEL = 2 CFLAGS = -O$(OPT_LEVEL) ... 3. other flags such as the -F which performs "potentially unsafe optomization" The combination of these things allows alot more control over how your code is compiled. Possibly not the best approach, but it is most adequate for our uses around here. -- Flip Phillips {ucbvax,decvax}!cbosg!osu-cgrg!flip Computer Graphics Research Group, The Ohio State University USnail: 1501 Neil Ave., Columbus, OH 43201 "All I wanted was a Pepsi, and she wouldn't give it to me." -Suicidal Tendancies