Path: utzoo!utgpu!water!watmath!clyde!rutgers!sunybcs!boulder!hao!gatech!mcnc!decvax!decwrl!sun!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: a couple quickies / foo(&i)
Message-ID: <517@cresswell.quintus.UUCP>
Date: 10 Jan 88 03:15:54 GMT
References: <11189@brl-adm.ARPA>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 41

In article <11189@brl-adm.ARPA>, TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU writes:
> noalias int i;
> for (i=0; i<100; i++) {...anything...}
> the default is the "safe" method.  But look at what a 1990's compiler
> could do here.  If the compiler notices that I don't modify i in the loop
		  ***********************
> There you have it folks.  A real purpose for noalias that most people
> didn't even think of.
If the compiler is smart enough to notice that the loop body does not
change 'i', why do you need to tell it 'noalias'?  A *local* variable
whose address is never taken cannot possibly be aliased, because there
is no other *legal* way to get at it.  (If you are going to count the
possibility of poking around in the stack or being changed with a
debugger, everything is aliased.)

Just how much of a problem do we really have here, anyway?
The problem of aliasing is a problem of having multiple legal access
paths to the same variable.  How often is the controlled variable of
a loop global?  How often does it have its address taken?

Where 'noalias' is going to pay off (*if* it does) is with compilers
which put a great deal of work into optimisation, so presumably can
spare the effort to do a trivial data flow analysis, so all the XX%
of easy cases will be spotted anyway.  So 'noalias' is going to be
useful for the 100-XX% of cases where the variable is global, or has
its address passed to an unanalysed function or stored in memory.
I don't think that is enough cases, or that the benefit obtained in
those cases will be great enough, to warrant the change.  But what
do I know?

    REQUEST:	will one of the people who argued *for* the change
		tell us about their data base of C programs and
		the measurements they made which showed that the
		payoff (over and above the trivial data flow analysis)
		would be great.  A reference to published work would
		be ideal.

Frankly, I think some assistance for locating uninitialised variables
would be more use to more people.  (Requiring *0 to be a run time
fault would be a *wonderful* start.  Certainly an explicit recommendation
that a mode be provided which makes such a check could do no harm.)