TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU (01/09/88)
A while ago I wrote:
> for (i=0; i==100; i++) foo(&i);
Yes, I did mean:
for (i=0; i<100; i++) foo(&i);
Sorry for the typo and thanks for the answers (and interesting insights
to what both would do.
I must have posted that one late at night because I totally forgot that
for() is expanded to while() and that made the answer obvious.
Now, let's look at a not-so-obvious use of noalias:
noalias int i;
for (i=0; i<100; i++) {...anything...}
Because I told the compiler noalias it knows that I will not be doing
anything funny to i. A compiler can rightly ignore "noalias" since
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
and if the target machine has a compare_to_zero function
that is many times faster than compare_to_an_integer the code can
be re-written to be:
noalias int i, _hidden_i;
i=0;
_hidden_i=100;
while (_hidden_i) {...anything...; i++; --_hidden_i;}
...which could be very-much faster on the target. This level of
optimization is something that has never before been do-able until
now. Of course, with a _lot_ of extra programming (motion tracing, etc)
the compiler may have surmised that this was possible.
(I bet that a good motion tracer could find huge numbers of
variables that could be ALSO go as noalias as the programmer
didn't recognize. ...but a good motion tracer will not be
seen in many compilers until the late (?) 1990's)
There you have it folks. A real purpose for noalias that most people
didn't even think of.
T. Limoncelli
Drew U/Box 1060/Madison NJ 07940 Bitnet: tlimonce@drew.BITNET
Disclaimer: These are my views, not my employer or Drew Univesity.
"Any typos should be reported to my mother, who checked
all my papers until I got a spelling checker in 8th grade."
--------------------------------------------------------------------------ok@quintus.UUCP (Richard A. O'Keefe) (01/10/88)
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.)