Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: `noalias' vs `register' Message-ID: <6859@brl-smoke.ARPA> Date: 17 Dec 87 20:41:24 GMT References: <6829@brl-smoke.ARPA> <9753@mimsy.UUCP> <6830@brl-smoke.ARPA> <6845@brl-smoke.ARPA> <475@cresswell.quintus.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 34 In article <475@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >I don't understand this. In Doug Gwyn's example, *p HAS AN ALIAS! >That is, there are two ways (*p and *q) of getting at the same >location. If this isn't illegal, what is the point of 'noalias'? The point of my example was to show that the existence of an alias can affect the code behavior, assuming a highly-optimizing compiler takes the "noalias" qualifier seriously. Proper use of this would normally be not to do things like my example, but mostly to flag arguments to functions that are promised not to point to overlapping storage (although there are several other uses for "noalias"). "noalias" is sufficiently general that it is not feasible for all cases of run-time aliasing to be detected at compile time. And such aliasing would not be tested for at run time either, because the point is to permit otherwise "unsafe" optimizations, given that the programmer has (by using "noalias") promised that the code will only be used in ways that do not involve unsafe aliasing. The burden is on the programmer who specifies something as "noalias" to get it right, not on the compiler to check that he did. There are many things in C this way.. >Having the C compiler recognise that sin(x) or strlen(s) only needs to >be evaluated more than once in some complicated expression would >be more useful to me than making promises about pointers that >the compiler isn't apparently expected to check, and the 'noalias' >attribute on the arguments is not enough to allow that optimisation. True, "noalias" does not promise that a function has no side effects. It is rather rare that one encounters C code that could benefit from some such facility for flagging functions like that, but there is a lot of code that can take advantage of the new opportunity for optimization.