Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rice!news
From: preston@ariel.rice.edu (Preston Briggs)
Newsgroups: comp.lang.misc
Subject: Re: Register Count
Message-ID: <1991Jan13.202053.22021@rice.edu>
Date: 13 Jan 91 20:20:53 GMT
References: <PCG.91Jan10162301@odin.cs.aber.ac.uk> <PCG.91Jan10194401@odin.cs.aber.ac.uk> <PCG.91Jan12152311@teachk.cs.aber.ac.uk>
Sender: news@rice.edu (News)
Organization: Rice University, Houston
Lines: 45

pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:

>    a[i], a[j] := a[m], a[n];

> it involves *both* value, as maybe "i = j" but "a[m] /=
>a[n]", and lvalue (if "j = m" or "i = n", ...) aliasing.
>
>Three "solutions" are possible:

>1)

Conservative implementation.

>2)

Non-deterministic implementation; force the programmer to be specific.
I'd say this is similar to C.

>3) A far more interesting solution is to add some cleverness to the
>compiler. I mean, real cleverness, not like current "optimizers".

and shows a solution that involves generating multiple versions
of the assignment, with tests of i, j, m, and n to distinguish
between the various versions.

I don't like this for a several reasons.

a) Where's the profit?  We save a register at best over the conservative
   solution in (1).  The cost though, is 1 or 2 tests at run-time.
   A branch or 2 per register saved is no deal.

b) Tools already exist to help disambiguate array references,
   e.g., dependence analysis.  While dependence analysis is not always
   precise, it is conservative (safe) and the technology is improving
   all the time.  Further, if you've taken the time to build a dependence
   analyzer, you can use it to support more extensive and more profitable
   transformations.

and finally

c) I don't like so much special-purpose machinery (compiler code)
   devoted to one programming language construct.  I'm much prefer
   general-purpose optimizations that help over the entire language.

Preston Briggs