[comp.lang.c] noalias, ordinary, volatile

ksb@j.cc.purdue.edu (Kevin Braunsdorf) (12/19/87)

I have been working on an optimizer that would take advantage of the
"noalias" concept (here we call it "exclusive" access, rather than
"noalias" data).

We are interested in three access restriction: exclusive, volatile,
and ordinary.  The "exclusive" access restriction tells the optimizer
something very strong: no reference through any handle other than this
one leads to this data.  The "volatile" access restriction tells the
optimizer the opposite: there are data references that you cannot see
that change this data.  The "ordinary" access restriction states that:
only references to this type may effect this data; it is the default.

Looking at the ordinary case first
	char *pch;
	int *pi;
				....
	*pi = 0;
	*pch = 'a';
	<read *pi>

one would expect *pi to contain a zero.  However if we change
	char *pch;
to
	int *pch;		/* broken name, example only		*/

then we can clearly see that *pi could be (int)'a'.

If we change
	int *pi;
to
	volatile int *pi;

then we also can see that *pi could have changed (asynchronously even).

Consider:
	#define exclusive noalias	/* so we all see the same thing */

	exclusive int *pi1;
	int *pi2;
				....
	*pi1 = 100;
	*pi2 = 200;
	<read *pi1>

Here we know that *pi1 has to be 100, *pi2 must refer to a distinct int
from *pi1 because the int is exclusive.

Look at the loop
	/* ??? */ int i;

	i = 1;
	while (i)
		/*empty*/;

Tell me, what happens if i is access restricted to
	volatile --
	ordinary --
	exclusive --

volatile:
	We loop reading i, until an asynchronous event changes it.

ordinary:
	We see no side effect that could change i, we bitch a little but
	generate code that does the volatile thing.

exclusive:
	We scream and die, i cannot change in the loop (if you
	want to loop forever you have to use
		spin();
	for our flow analysis to pass your code.).


Is that clear enough?  What if we wanted a pointer to be exclusive?

	typedef char *char_pointer;
	exclusive char_pointer ep;
or
	exclusive (char *) ep;

maybe...  I'm not telling.

Think about that pointer type you should get when you have:
	typedef union {
		int i;
		float f;
		char ch;
	} dummy;

	/* ??? */ int *pi = & dummy.i;

Shouldn't this be volatile?  How stringly should the compiler "feel"
about this?

KLANG!!
Kevin Braunsdorf			ksb@j.cc.purdue.edu
K Project				<most-places> pur-ee!gawk!klang

gwyn@brl-smoke.ARPA (Doug Gwyn ) (12/19/87)

In article <6006@j.cc.purdue.edu> ksb@j.cc.purdue.edu.UUCP (Kevin Braunsdorf) writes:
>Think about that pointer type you should get when you have:
>	typedef union {
>		int i;
>		float f;
>		char ch;
>	} dummy;
>	/* ??? */ int *pi = & dummy.i;
>Shouldn't this be volatile?  How stringly should the compiler "feel"
>about this?

The compiler in general won't be able to tell if at run time a union
is involved (consider function parameters).  It is certainly unsafe
to stash one type of data in a union member then use another member,
and as I recall ANSI C expressly says that such use is "undefined".
Again the burden is on the programmer to get it right, but then there
are other, simpler, ways to try to use garbage than that, many of
which the compiler can't feasibly detect in advance.

levy@ttrdc.UUCP (Daniel R. Levy) (12/20/87)

In article <6006@j.cc.purdue.edu>, ksb@j.cc.purdue.edu (Kevin Braunsdorf) writes:
> I have been working on an optimizer that would take advantage of the
> "noalias" concept (here we call it "exclusive" access, rather than
> "noalias" data)....

> 	i = 1;
> 	while (i)
> 		/*empty*/;

> [if i is declared as]
> exclusive:
> 	We scream and die, i cannot change in the loop (if you
> 	want to loop forever you have to use
> 		spin();
> 	for our flow analysis to pass your code.).

UGH.  I can see putting out a WARNING about the infinite loop, and it is poor
practice to just busy-wait (for something like a signal) but why DISALLOW
it unless the code uses your non-portable spin() call?

i
n
e
w
s

f
o
d
d
e
r
-- 
|------------Dan Levy------------|  Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
|         an Engihacker @        |  	<most AT&T machines>}!ttrdc!ttrda!levy
| AT&T Computer Systems Division |  Disclaimer?  Huh?  What disclaimer???
|--------Skokie, Illinois--------|