Path: utzoo!utgpu!water!watmath!clyde!burl!codas!novavax!hcx1!hcx2!tom
From: tom@hcx2.SSD.HARRIS.COM
Newsgroups: comp.lang.c
Subject: Re: noalias comments to X3J11
Message-ID: <44100008@hcx2>
Date: 25 Mar 88 15:53:00 GMT
References: <7753@alice.UUCP>
Lines: 60
Nf-ID: #R:alice.UUCP:7753:hcx2:44100008:000:2766
Nf-From: hcx2.SSD.HARRIS.COM!tom    Mar 25 10:53:00 1988


>     Const has two virtues: putting things in read-only
>memory, and expressing interface restrictions.  For example,
>saying
>
>        char *strchr(const char *s, int c);
>
>is a reasonable way of expressing that the routine cannot
>change the object referred to by its first argument.  I
>think that minor changes in wording preserve the virtues,
>yet eliminate the contradictions in the current scheme.

You bet!, That would be a very reasonable thing for const to do,
and that's what I thought it did until I talked to my friend on
the committee. It is obvious to the casual observer what something
being constant means, right? But no, the obvious meaning of const
is not acceptable to some committee members, so what happens, `noalias'
is invented just so `noalias const' can mean what just `const'
should obviously have meant all along.

I agree with dmr, noalias must go! But I have another even more
pressing reason for getting rid of it. Working for a compiler
vendor, this is the nightmare scenario I see:

   1) User with non-optimizing compiler sees noalias and says
      `This is neat! I can get my code really optimized with this!'
      and proceeds to use it liberally throughout the 40,000,000
      lines of code he develops with his nonoptimizing compiler
      that is toatlly bored by `noalias'.

   2) User switches to our highly optimizing compiler which immediately
      deletes 30,000,000 lines of apparently dead code. And does
      nastly transformations to the rest of it.

   3) User screams, yells, and generally makes life totally
      miserable complaining about how our compiler is broken.

Repeat this over and over for an endless series of users who won't
believe they can't write code. Not to mention that some of the
problems might be actual bugs in the optimizer, but it could
take weeks to track them down and sort them out.

For this reason alone, I can't believe that any vendor is likely to
actually take advantage of any optimizations that noalias might allow.
Similar situations already exist for FORTRAN. There are all sorts
of optimizations allowed according to the strict letter of the
FORTRAN standard, but very few compilers will do them by default because too
much user code will break. You generally have to specifically request
the highest level of optimization.

This is an important point. Real vendors have to develop compilers
for real users. Neither users or compilers are perfect, and `noalias'
will just emphasize those imperfections.

The correct way to aggressively optimize programs is via a global
program database that gathers the information for the whole
program and *knows* what is aliased and what is not, but thats
another story....
================================
tahorsley@ssd.harris.com