chris@mimsy.UUCP (Chris Torek) (12/14/87)
In article <6829@brl-smoke.ARPA> gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: >A new keyword, "noalias", was added; it's a type-qualifier like const >and volatile. Its only function is to permit tighter optimization.... Aside from the obvious---that noalias can be applied to globals and aggregates, and that some dumb compilers still use the word `register' to decide what to put into registers---what is the difference between this and `register'? That is, why not simply allow register to be applied to globals and aggregates? >Pointers to the same object are now guaranteed to compare equal. >All types of null pointer compare equal. (char *) and (void *) >have the same representation. Is this temporary? That is, is this something that is noted to be liable to change in a future standard? >NULL and size_t are to be included in any header that references them >in the Standard.... Since size_t is presuably a typedef, not a #define, this sounds ugly. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
gwyn@brl-smoke.ARPA (Doug Gwyn ) (12/14/87)
In article <9753@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: -In article <6829@brl-smoke.ARPA> gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: ->A new keyword, "noalias", was added; it's a type-qualifier like const ->and volatile. Its only function is to permit tighter optimization.... ----what is the difference between this and `register'? "noalias" indicates that the object does not have an alias; i.e. it is modified via a single handle. This is a complicated point about which I'm sure much will be written in the near future. ->Pointers to the same object are now guaranteed to compare equal. ->All types of null pointer compare equal. (char *) and (void *) ->have the same representation. -Is this temporary? It wasn't meant to be. ->NULL and size_t are to be included in any header that references them ->in the Standard.... -Since size_t is presuably a typedef, not a #define, this sounds ugly. size_t is definitely a typedef, and it isn't too ugly. Implementations will have to encapsulate the typedef in the standard headers with a one-time lockout switch.
chris@mimsy.UUCP (Chris Torek) (12/15/87)
>>In article <6829@brl-smoke.ARPA> gwyn@brl-smoke.ARPA (Doug Gwyn) wrote: >>>A new keyword, "noalias", was added.... >In article <9753@mimsy.UUCP> I asked, essentially, >>why not just use `register'? ---and of course, the answer is obvious: you cannot take the address of a register. >>>(char *) and (void *) have the same representation. [Doug] >>Is this temporary? [me] >It wasn't meant to be. [Doug] Then why have (void *) at all? A simple typedef char *pointer_t; would suffice. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
hydrovax@nmtsun.nmt.edu (M. Warner Losh) (12/15/87)
In article <9753@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: + In article <6829@brl-smoke.ARPA> gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: + >A new keyword, "noalias", was added; it's a type-qualifier like const + >and volatile. Its only function is to permit tighter optimization.... + + Aside from the obvious---that noalias can be applied to globals and + aggregates, and that some dumb compilers still use the word `register' + to decide what to put into registers---what is the difference between + this and `register'? That is, why not simply allow register to be + applied to globals and aggregates? The new keyword noalias does more than the register vaiable. It will allow the compiler to do better global optimizations. Having just completed a compiler class here at NMTech, I can say that this is not an easy matter when aliasing (or refering to an object by several, nonobvious, handles) is included. When you have aliasing, most compilers simply throw up their hands and do a worst case code generation. The problem of aliasing, I believe (it has been a while since that lecture) is NP-complete (or maybe NP-HARD). ...!lanl!unm-la!unmvax!nmtsun!warner%hydrovax (Warner Losh) -- bitnet: lush@nmt.csnet M. Warner Losh csnet: warner%hydrovax@nmtsun uucp: ...{cmcl2, ihnp4}!lanl!unmvax!nmtsun!warner%hydrovax ...{cmcl2, ihnp4}!lanl!unmvax!nmtsun!hydrovax Warning: Hydrovax is both a machine, and an account, so be careful.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (12/15/87)
In article <9770@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
->>In article <6829@brl-smoke.ARPA> gwyn@brl-smoke.ARPA (Doug Gwyn) wrote:
->>>A new keyword, "noalias", was added....
->In article <9753@mimsy.UUCP> I asked, essentially,
->>why not just use `register'?
----and of course, the answer is obvious: you cannot take the address
-of a register.
That's not the answer!
The "noalias" type qualifier promises that the object can only be
modified by a single handle (as I said), thereby permitting the
optimizer to do things that are not safe otherwise; for example,
for pointers that could be used as aliases accessing the same
object, without "noalias" qualifying the object, every time it
was modified via one pointer the compiler would have to assume
that the modification might affect what is seen via the other
pointer. With "noalias", the compiler is entitled to treat the
two access paths as referring to non-overlapping objects, which
means that it can assume that the result of a previous dereference
(which may be in an active register) is not invalidated by a store
through another pointer, so it does not need to reload the value
already in the register just to be safe. The claim is that this
is a big win for some optimizers, particularly those that
vectorize operations. "Vanilla" use of C does not allow such
optimizations in most cases. This issue is important to many
people (mainly, those trying to optimize the dickens out of
the code). I personally don't care much for this new feature.
Fortunately, the typical programmer can just ignore it and
never use "noalias" in his code, so it only affects those who
like to fine-tune things.
->>>(char *) and (void *) have the same representation. [Doug]
->>Is this temporary? [me]
->It wasn't meant to be. [Doug]
-Then why have (void *) at all?
Type checking. Conversion between dissimilar pointer types
generates a diagnostic while conversion to/from (void *) is
silent.
george@mnetor.UUCP (George Hart) (12/15/87)
In article <6833@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >The "noalias" type qualifier promises that the object can only be >modified by a single handle (as I said), thereby permitting the >optimizer to do things that are not safe otherwise; for example, >for pointers that could be used as aliases accessing the same >object, without "noalias" qualifying the object, every time it >was modified via one pointer the compiler would have to assume >that the modification might affect what is seen via the other >pointer. With "noalias", the compiler is entitled to treat the >two access paths as referring to non-overlapping objects, which >means that it can assume that the result of a previous dereference >(which may be in an active register) is not invalidated by a store >through another pointer, so it does not need to reload the value >already in the register just to be safe. Will the standard also specify that attempts to create or use alternate handles for an object declared "noalias" are to generate compiler warnings/errors? -- Regards, George Hart, Computer X Canada Ltd. NOW REAL SOON NOW UUCP: utzoo UUCP: utzoo >!mnetor!george > cxhi!george uunet uunet BELL: (416)475-8980
gwyn@brl-smoke.ARPA (Doug Gwyn ) (12/17/87)
In article <4385@mnetor.UUCP> george@mnetor.UUCP (George Hart) writes: >Will the standard also specify that attempts to create or use alternate >handles for an object declared "noalias" are to generate compiler >warnings/errors? Only in certain contexts. It's "too hard" (to use a technical term) to determine whether this condition exists in general. One thing I'm pretty sure IS allowed is to use an explicit cast to copy a noalias pointer to a normal pointer. This is obviously risky stuff to be doing unless you have a firm grasp of just what this aliasing business is all about; I would suggest that the "typical programmer" (another technical term) avoid using "noalias", just to play safe.