Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: `noalias' vs `register'
Message-ID: <6848@brl-smoke.ARPA>
Date: 16 Dec 87 20:24:11 GMT
References: <6829@brl-smoke.ARPA> <9753@mimsy.UUCP> <6830@brl-smoke.ARPA> <6845@brl-smoke.ARPA> <9807@mimsy.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) )
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 35

In article <9807@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>>>... `register' and `noalias' [can] really mean the same thing [me]
>>[but] "register" acts as a storage class while "noalias" is
>>a type qualifier. [Doug]
>Sure---but this is artificial; one could change this as easily as
>add `noalias'.  (Well, `int register *p' *would* look a bit odd.)

You're missing what is really going on here.

"register" was an aid to optimizer technology of the 70s;
"noalias" is an aid to optimizer technology of the 80s.
The type of optimizations these are supposed to help with
have entirely different natures.  "noalias" is intended to
allow data loaded into temporary registers to continue to
be used without having to reload it when some unrelated
pointer-dereference storage occurs; also, it permits
vectorization of operations on function array parameters,
because of the non-overlapping guarantee.  "register"
attempts something much simpler, namely to help allocate
limited fast storage to specified variables.  That is why
it is appropriate for "register" to be a storage class.
The constraint against & applied to a register variable
simply reflects the reality of common machine architecture
(fast storage not necessarily being addressable).  "noalias"
is by no means just "register" with the &-constraint removed.
It is a totally different concept with different semantic
content and (possibly, if the optimizer takes advantage
of it) different run-time effects on code behavior.

I don't know what the next C standard (after the 198x one)
will do to accommodate the optimizer technology of the 90s.
Personally, I have not had much luck with optimizers and
was glad that they aren't allowed to muck around much with
the code that I write unless I deliberate instruct them
to (by using appropriate keywords).