🚀 go-pugleaf

In article <1913@cod.NOSC.MIL> bmarsh@cod.nosc.mil.UUCP (William C. Marsh) writes:
>In article <265861D7.3293@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>>Now, if the compiler determines on its own that no aliasing is
>>possible, and then does the optimization on its own, then more power
>>to it.  That's great, because it will work for the individual routines
>>in my code in which no aliasing occurs.  But MSC isn't that smart yet.
>
>I don't beleive *any* compiler could be that smart.  Any routine that was
>passed a pointer couldn't use any global or static data, for fear that it
>is being aliased by the pointer.  The compiler, unless it looks at all the
>code (and all the possible ways of calling that function) could not possibly
>do this kind of optimization on it's own.

Actually, it is possible to do a pretty decent job of alias analysis; it is
just very computationaly expensive.  We have been investigating some
possibilities as an outgrowth of our interprocedural optimization research and
have developed an algorithm we think will work. Unfortunately, it is order n
to the power you don't even want to think about. And assumes an underlying
full interprocedural analysis to boot.

For now I think we're stuck with some sort of 'relax aliasing' option for
those wanting to get the most out of their compiler and willing to cooperate a
little bit with it.

[Now Preston can give us his 'why I like Fortran' spiel ;-) ]

Mark Roberts
{uw-beaver|uunet}!microsoft!markro
-- 
Send compilers articles to compilers@esegue.segue.boston.ma.us
{spdcc | ima | lotus}!esegue.  Meta-mail to compilers-request@esegue.
Please send responses to the author of the message, not the poster.