C optimizer

[Jeff A. Bowles]

>>> In article <1028 at frog.UUCP> john at frog.UUCP (John Woods) writes:
>>>> (getpid() != getpid())  [should always be 1]
>>> Well, how about
>>> (pid = getpid(), (void) fork(), pid != getpid())
>> True - but I don't see any references to fork() in Mr.Woods' posting.
>> What he is stating is that _IN THE ABSENCE_ of fork() calls, getpid()
>> had better return an unchanging value.
>
>Sure - and in the absence of assignments, variables are constant and
>can be optimized away.  The whole point of this was to find a pure
>syscall, and a routine isn't pure if calling another routine can cause
>it to change its return value for a given set of argument values.
>Thus, fork()'s changing the return value of getpid() means that
>getpid() can't be considered pure.

Are we still on this topic? By the bogosity above, nothing is "pure",
because you might write a function that changes the behaviour of another
function - for example,
	ftell(3S)	(tell you where your file pointer is, in file)
is pure, unless there's an fread/fwrite/fseek/fclose/freopen in the vicinity.
Now, those named functions are obviously impure, but aren't you pushing it
a little far? How about:

1. These functions are pure, i.e. the values returned will not change from
   one invocation to the next, given that the arguments didn't change:

    a function that returns the process's pid
    a function that returns the byte offset of a file pointer
    a function that returns the file descriptor corresponding to a file pointer
    (and so on)
    any function that performs arithmetic operations on its arguments and on
		the results of "pure" functions it invokes.

2. Any function that deviates by invoking an "impure" function, anywhere
   along the way, is an "impure" function. (Certain basic blocks might still
   be "pure" but the function itself isn't.

3. Any function that dereferences a pointer is best though of as "inpure"
   unless you decide how to describe "the argument passed didn't change
   in the second invocation of that function" - even if you passed a pointer
   to the same object, the pointer might be the same, but the object might
   not. This obviously limits the power within C, and makes a good argument
   for "const" and the like....


As a result,
	for (i = 0; i < 100000; i++)
		pid = getpid();

is a reasonable thing to compress to the single assignment "pid = getpid();"

	Jeff Bowles