Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!rochester!pt.cs.cmu.edu!sei!sei.cmu.edu!firth
From: firth@sei.cmu.edu (Robert Firth)
Newsgroups: comp.arch
Subject: Re: "interprocedural analysis useless for code optmization"
Message-ID: <7462@aw.sei.cmu.edu>
Date: 24 Oct 88 13:00:36 GMT
References: <371@babbage.acc.virginia.edu> <2982@uklirb.UUCP>
Sender: netnews@sei.cmu.edu
Reply-To: firth@bd.sei.cmu.edu (Robert Firth)
Organization: Carnegie-Mellon University, SEI, Pgh, Pa
Lines: 36

In article <2982@uklirb.UUCP> kirchner@uklirb.UUCP (Reinhard Kirchner) writes:

>Also Pascal has some difficult to detect aliases. Among them are:
>
>- VAR-Parameters and global variables
>- VAR-Parameters and heap objects
>- WITH-accessed parts of structures and direct accessed ones
>- VAR-ARRAYs and VAR-Scalars
>
>The VAR-Parameters are the main problem, because many objects which are
>accessible as VAR-Parameter may also be accessed directly. So each access
>to a VAR kills globals held in Registers and vice versa...

These are valid points, but I don't think the situation is quite that
bad.  (I've said this before, so will be brief)

a. Pascal is strongly typed. Therefore, a VAR of one type cannot alias
   an object of a different type (minor exception is when one type is
   composed from the other).  This in my experience means that one store
   to a VAR kills less than 20% of known tracked globals

b. Heap objects cannot be aliased with non-heap objects.  Usually, the
   programmer passes a pointer by value rather than the designated object
   by reference, in which case no alias is possible.

c. The language definition prohibits threatening access to a structure
   that has been bound in a WITH statement, so the codegenerator may
   legally assume no aliasing.

Things are even better if you are using an extended Pascal with separate
compilation facilities.  The "globals" are then partitioned into disjoint
sets; a routine defined in one module can directly access a global defined
in another only if there is an explicit IMPORT dependency.  This information
should be kept with each compiled module ("modules threatened list"), and
can be used to filter potential aliases (" a call of M1.ALPHA cannot threaten
globals declared in M2 so I can slave their values across this call").