Re: Register Allocation and Aliasing in C

bob.morgan@digital.com (Bob Morgan)
21 Jul 1998 11:08:17 -0400

          From comp.compilers

Related articles
Register Allocation and Aliasing in C rountev@cs.rutgers.edu (Atanas Rountev) (1998-07-20)
Re: Register Allocation and Aliasing in C bob.morgan@digital.com (1998-07-21)
| List of all articles for this month |

From: bob.morgan@digital.com (Bob Morgan)
Newsgroups: comp.compilers
Date: 21 Jul 1998 11:08:17 -0400
Organization: Digital Equipment Corporation
References: 98-07-139
Keywords: C, registers, analysis

On 20 Jul 1998 17:02:08 -0400, Atanas Rountev <rountev@cs.rutgers.edu>
wrote:
>I am trying to evaluate the benefits of precise and expensive alias
>analysis for C in terms of the impact it has on register allocation. I
>am having a hard time finding papers that describe how people deal
>with register allocation for C with its unrestricted use of pointers.
>Most of the papers I've seen are FORTRAN oriented and the aliasing
>issues there are different from the ones for C.


The answer to your question depends on the structure of your compiler.
Many optimizing compilers have decided which values are candidates for
allocation to registers earlier in the compiler. For example, a
compiler that creates quadruples (or some similar concept) is
implicitly saying "These are the things that can be placed in
registers". With this structure the alias information is used during
global optimization to decide on the position of instructions that
load and store values.


The register allocator does not move computations, it assigns the
registers and fixes up the problems when too many registers are
needed. It doesn't need the alias information.


If the compiler mixes some aspects of global optimization and register
allocation then alias information may be needed. This is not a
language related issue, except global optimization is harder with C
than with Fortran.


Bob Morgan
--


Post a followup to this message

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