Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!alice!dmr
From: dmr@alice.UUCP
Newsgroups: comp.lang.c
Subject: Re: no noalias not negligible
Message-ID: <7880@alice.UUCP>
Date: 22 May 88 08:53:50 GMT
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 58
Posted: Sun May 22 04:53:50 1988

Since the noalias issue has surfaced again, I offer a few thoughts on the
issue.

The comments of Hough, and the views of all the people on X3J11 who
wanted some way to express the "noalias" concept, are worth paying
attention to.  When a function with two pointer arguments is called,
the pointers are allowed to point to overlapping things, and this
inhibits otherwise plausible optimizations (vectorization especially)
in the function.  Other possibilities for pointers to overlapping
things occur, like externals vs. parameters, but in practice
Hough's example represents the problem that purveyors of vector
machines worry most about.

The problem with the noalias proposal, as embodied in the January
draft, was not at all that it attacked a nonexistent problem, but
that it did far too much.  If it had merely provided a way of
saying, "I promise that this pointer can be trusted not to point to
data accessed by another path," and if the scope of the promise
were limited reasonably, it would have been accepted without
any real quarrel; there might have been mutterings from mossbacks
like me about balancing the burden of language complexity against
the benefit, but no outcry.

Instead, the concept was illegitimately bound to the notion
of data type, and was made very dangerous; the rules as constituted
would have forced programmers into promises they didn't understand
and couldn't keep.  Some of the examples are in the screed I
posted some months ago.

I don't think there are easy answers to the problem.  As it
stands, C is hard to vectorize because of aliasing.  Fortran
is easier because of some global rules: for example, two parameters,
or a parameter and a COMMON, are not allowed to be aliased.
X3J11 was understandably unwilling to introduce Fortran-style
rules because it would represent a subtle and dangerous change
in the interpretation of existing programs.  Indeed, the Fortran
rules are subtle and to some extent dangerous even for Fortran.
Many years ago I was involved in a large system (Altran)
written in Fortran, and its most stubborn bugs owed to unsuspecting
violation of Fortran's aliasing (rather, noaliasing) rules.

I think there is little doubt that the best solution for C is to
use a #pragma, and that it would have been best for X3J11 to suggest one.
Because I thought it was absolutely essential to get rid of the
January version of noalias, and no variations on it worked any better,
I made a calculated decision not to propose an alternative; no idea
seemed attractive enough to avoid further controversy and consequent
distraction from the problems with the draft's version.  Gwyn,
by the way, seems to be correct in observing that the rules for #pragma,
as written, prohibit using it to make promises about aliasing.
Thus making a formal #pragma proposal would have opened up a wrangle about
#pragmas in general.  There was not enough time to do the job properly.
If all this had happened two years ago, something could have been worked
out, but it was too late for this standard.

	Dennis Ritchie
	research!dmr
	dmr@research.att.com