Path: utzoo!attcan!uunet!cs.utexas.edu!rice!news From: preston@ariel.rice.edu (Preston Briggs) Newsgroups: comp.arch Subject: Re: Register Count Message-ID: <1991Jan14.143945.8482@rice.edu> Date: 14 Jan 91 14:39:45 GMT References: Sender: news@rice.edu (News) Organization: Rice University, Houston Lines: 50 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. In the case of multiple-assignment, I'd go for an instruction schedule that attempts to minimize register usage (similar to the work of Steve Johnson. That way, we'd gain the benefits on all sorts of expressions. Preston Briggs