Path: utzoo!attcan!uunet!husc6!bloom-beacon!gatech!mcnc!uvaarpa!umd5!ncifcrf!nlm-mcs!brl-adm!adm!dsill@nswc-oas.arpa
From: dsill@nswc-oas.arpa (Dave Sill)
Newsgroups: comp.lang.c
Subject: Re: Noalias trivia question
Message-ID: <14522@brl-adm.ARPA>
Date: 24 May 88 15:04:41 GMT
Sender: news@brl-adm.ARPA
Lines: 32
Posted: Tue May 24 11:04:41 1988

From: "T. William Wells" <bill@proxftl.uucp>
>Noalias is bad for a number of reasons, which I do not care to
>discuss; however, you, terry@wsccs, seem to have an exaggerated
>notion of what is possible for an optimizer to do.  Noalias
>solves a problem which CANNOT be solved by an optimizer (yes,
>this is another problem which can be shown to be equivalent to a
>halting problem).

That's a new one on me.  I'd like to see that reduction.  However,
even if the "noalias", or value caching, problem is unsolvable in
general, that does not mean that an optimizer can never determine when
it is safe to cache.  

>Please, before you flame others for supporting
>things like this with comments like: "let the optimizer do it",
>why don't you find out whether it is actually possible for the
>compiler to do it?

You are implying that programmers can solve unsolvable problems but
that programs cannot, which is simply not true.  The algorithm the
programmer applies to determine when "noalias" can be used could be
used by an optimizer.  If this caching algorithm requires information
not available to the optimizer, such as the ranges of all pointers
(which may be limited by assumptions about the input to the program),
then it's not safe.  What happens when the input assumptions change?

=========
The opinions expressed above are mine.

"We must remove the TV-induced stupor that lies like a fog across the
 land."
					-- Ted Nelson