Re: aliased/non aliased parameters

Nathan Sidwell <nathan@pact.srf.ac.uk> wrote:
> I'm trying to locate information about compiling two versions of
> functions where parameters can be passed by possibly aliased
> references (like in C++). The technique is where the compiler
> generates two function bodies, one assuming no aliased and the other
> not assuming aliases. Then at the point of the call the unaliased
> version is called if the compiler can prove the objects are unaliased.


This's not exactly what you want, but it's close enough. A lot of
work has been done on 'linear'/'unique' types, and any parameters of
these types are guaranteed by the type system to be non-aliased. Some
languages may have _generic_ type classes that can be instantiated
with either a non-linear or a linear type, and I think that such a
system would compile a different implementation for the different
kinds of types.


The distinction between the two kinds of types is vital, as passing a
linear type to a function also passes the responsibility of its
storage management. Thus, if I have a multiple-precision integer
multiplication package, one of whose parameters is linear and the
other non-linear, then I can _reuse_ the storage of the linear
parameter in constructing the answer. Indeed, if I don't reuse it,
then I must make sure that it is safely returned to free storage.
----
I believe that some super and minisuper Fortrans used your technique.
You might check out how the Multiflow Fortran compiler worked.
[The old HP 3000 APL compiler did something similar. The first time it
compiled a function, it generated tight code that assumed that the size
and shape of the argument arrays would always be the same, if on subsequent
calls it turned out that assumption wasn't right, it recompiled the function
to slower but more general code. -John]


--

Return to the comp.compilers page.
Search the comp.compilers archives again.