Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!hc!beta!unm-la!unmvax!nmtsun!hydrovax
From: hydrovax@nmtsun.nmt.edu (M. Warner Losh)
Newsgroups: comp.lang.c
Subject: Re: Pragmas
Summary: Sounds like a bad optimizer
Message-ID: <1227@nmtsun.nmt.edu>
Date: 14 Jan 88 05:55:11 GMT
References: <17196@topaz.rutgers.edu> <6920@brl-smoke.ARPA> <14460@think.UUCP> <3333@ihlpf.ATT.COM>
Organization: NMT Hydrology program
Lines: 58

In article <3333@ihlpf.ATT.COM>, nevin1@ihlpf.ATT.COM (00704A-Liber) writes:
>While I'm developing code, I don't turn the optimizing option of my compiler
>on.  I test it and find no problems.  I then turn the optimizer on.  Now I
>find problems.  (And will a debugger such as sdb be able to support 
>'noalias' so that I can find the bugs in my optimized code?)

   The whole purpose of optimization should be to produce equvalent programs
that execute either faster, or with less memory requirements.  The
noalias stuff sounds like it is agains the spirit of such an endevor,
because if used incorrectly, can cause bugs.  Hard to find bugs at that.
Overuse of the "register" class of variables doesn't break programs when
it is added (unless you happen to have a brain dead optimizer :-))  The
noalias stuff, however, can cause bugs that are a real b**** to find,
since ALMOST ALL DEBUGGERS don't support OPTIMIZED code, if the optimization
is reaaly extensive.  Having just finished a compiler's course, I know
that many optimization techniques lead to code that in no way resembles
the original code.  There are ways around these problems, however, since
if you are VERY VERY careful about how you traverse your data structures,
you can avoid MOST (but not all) of these bitfalls.

   Noalias, from a compiler writer's point of view, would be a wonderful
boon.  You could now make assumptions about when varaibles change (or
don't change) more easily than you could before.  I'm not sure that
these few advantages (in terms of a couple of instructions saved) would
be worth the pain it would put the USER of the compiler through when
he misuses this feature.

  I'm not necessarily talking about the initial writing of the
code.Most people who would use the noalias feature would know what is
going on.  The real problem occurs in the maintance cycle of the
program's life.  Most of the software gets maintained by the less
experienced, less knowladgeable programmers (especially after the
person who originally wrote it leaves the company).  These programmers
more than likely might make a fix that aliased somehting that was
declared as noalias (maybe a global in a .h file where the definition
is "hidden" from them.  Hidden in the sence that the definition is
not staring them in the face every time they pop into the editor to
work on the module.

   This feature, in my option, would be a dangerous one to have around.
If you need to produce highly optimized code for a small program
(<10k lines), then this would be great.  If you need to maintain a
large program (>1M lines), then noalias would lead to lots of time lost
to finding obscure bugs in only the OPTIMIZED version of the code.  In
fact, many people might just turn off all optimization when they discover
bugs like this, thus defeating the whole purpose of the noalias modifier
in the first place.

   One last note : the amount of existing code that this feature break
is probably very small.  I too would like to see some hard data to
support this claim.  And sorry to have rambled for so long.

-- 
bitnet:	lush@nmt.csnet			M. Warner Losh
csnet:	warner%hydrovax@nmtsun
uucp:	...{cmcl2, ihnp4}!lanl!unmvax!nmtsun!warner%hydrovax
	...{cmcl2, ihnp4}!lanl!unmvax!nmtsun!hydrovax
Warning:  Hydrovax is both a machine, and an account, so be careful.