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).