Re: Register Allocation and Aliasing

In article <1990Jul05.155937.13214@esegue.segue.boston.ma.us> you write:
>How often are quantities that *might* be allocated to registers *not*
>allocated to registers, because of the remote *possibility* of
>aliasing via some circuitous pointers?
>
> Hare brained idea: allocate quantities that *might* be aliased to
>registers anyway. Provide a register to contain the true memory
>address of the aliased quantity, which causes a trap when the address
>is accessed (or automagically forwards to/from the register). Not
>only are aliasing problems avoided, but you've got a set of data
>address breakpoint registers as well! (ie. this technique could be
>experimentally evaluated on machines that have data address
>breakpoints).


Actually, this sounds like a marvelous idea to me!


I guess that the only drawback would be the cost of the additional hardware
to support the data breakpoints, but (as you noted) some machines already
have such facilities, so it can't be THAT expensive.


Offhand, I'd say that this could potentially work really well, except that
I think that you would want (a) a set of data-breakpoint registers which
had a one-to-one relationship with the actual registers (but you probably
only need to cover about half of them for a typical 32 register RISC machine)
and (b) special load and store instructions for potentially aliased data
values.


The special load instruction would not only load the data value into the
specified data register, it would also force the address used for the load
into the (associated) data breakpoint register. Finally, it would set a
"valid" bit associated with the given data-breakpoint register.


The special store instruction would simply, unset the "valid" bit for the
specified data-breakpoint register (thus preventing further data acceses
to the address indicated in the given breakpoint-register from being treated
as if the data-value in the data-register were still the valid (and most
up-to-date one).


The idea of getting the hardware to automagically satisfy references to
temporarily "register resident" data values directly from the registers
would eliminate the overhead of the (software) handing of breakpoints,
and would make this idea even better.


As I said, I think that it would *not* be necessary to associate one data-
breakpoint register with each actual data register. Keep in mind that
registers often hold computational results as well as simple copies of
variable values. (And don't forget the registers like PC, SP, and FP.
These don't need the special treatment either.)


Having a machine that did this stuff would effectively render alias analysis
(in compilers) "impotent and obsolete".


> Given the amount of fuss (number of papers) about aliasing in compilers...


It is certainly a pain in the $#^%$$^$%$ to do good alias analysis statically
in software (as opposed to dynamically and in hardware) especially for
everybody's current favorite language, C. Further, I'd have to guess that
static (compile-time) mechanisms for dealing with (i.e. preventing) aliasing
problems could NEVER match the performance characteristics of the hardware-
based dynamic scheme you have proposed.


In short... I like it. Too bad I don't build chips! I just program the
suckers. :-)


--
// Ron Guilmette (rfg@ncd.com)
--

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