Path: utzoo!utgpu!jarvis.csri.toronto.edu!utcsri!norvell
From: norvell@utcsri.UUCP (Theodore Stevens Norvell)
Newsgroups: comp.lang.c
Subject: Re: Noalias trivia question
Message-ID: <5995@utcsri.UUCP>
Date: 1 May 88 00:31:00 GMT
Article-I.D.: utcsri.5995
Posted: Sat Apr 30 20:31:00 1988
References: <56@lakart.UUCP> <1164@maccs.UUCP>
Reply-To: norvell@utcsri.UUCP (Theodore Stevens Norvell)
Organization: CSRI, University of Toronto
Lines: 58
Summary: 

In article <1164@maccs.UUCP> gordan@maccs.UUCP () writes:
>Before we consign noalias to the dustbin of history... a question.
>
>In all the time noalias was discussed on comp.lang.c, just about no one
>spoke up in favor of it.  In the recent X3J11 meeting it was reportedly
>voted down by well over the required (2/3 ?) majority.
>
>And yet, it must have once gotten a similar majority in favor, not so
>very long ago (January?).
>
>So, like, who on X3J11 will admit to having voted for (or worse,
>proposed) noalias in the first place?  Why did it seem like a good idea
>at the time, and what were the reasons for dropping it (apart from
>universal opprobrium).  Enquiring minds &c.
>
Noalias was voted in last December.  As I recall, only 2 organizations
voted against it.  I don't trust my memory well enough to name them.
It was invented as an alternative to a rule proposed by Cray Research
that arguments to parameters which were pointers to const qualified
types could not point to aliased data (or something awful like
that).  The reason it seemed like a good idea at the time is that
it was a good idea at the time.  It is a clean way to convey useful
information to the compiler -- information that the compiler can
often not derive itself (short of inter-compilation-unit flow analysis).
This information is required to ensure that certain optimizations are
safe in the presence of pointer dereferences -- optimizations which
include: common subexpression elimination, instruction scheduling,
loop invariant removal, redundant instruction elimination, vectorization,
and lots of others.  Unlike other innovations of the ansi committee and
the proposal from Cray, it would have broken no existing code (except
that which used the word "noalias" as an identifier); unlike the
idea of using pragma it would have been portable.  I hope that
sensible vendors will agree on a semi-standard pragma for it.

As to why it was dropped, I do not know.  Perhaps companies which did not
offer optimizing compilers were scared that those that who did would
suddenly start producing code that ran twice as fast for programs using
noalias.  Perhaps the committee was awed by Ritchie's oration.  Perhaps
it can be blamed on the Russians.  Perhaps someone who knows could say.

As an aside: One idea that has been circulating about noalias is
particularly silly.  That is that the purpose of noalias is to
make the life of compiler writers easy.  This is bunk.  The more
you add to a language the more special cases and interactions the
compiler should handle in order to get the best code possible.
The purpose of noalias is to allow the user to get the best code
possible in a machine independent way by allowing the compiler
to optimize in the 99% of the cases where the optimization is
safe.

Another aside: Noalias had some drawbacks.  After the tremendous
number of articles pointing this out, I don't feel compelled to
repeat them.  That would really be kicking the thing when its down.

Theodore Norvell
BITNET,CSNET:   norvell@csri.toronto.edu
CDNNET:         norvell@csri.toronto.cdn
UUCP:           {alegra,cornell,decvax,linus,utzoo}!utcsri!norvell