[comp.lang.c] unofficial X3J11 meeting notes

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.