Related articles |
---|
[4 earlier articles] |
Re: Register Allocation and Aliasing torbenm@diku.dk (1990-07-14) |
Re: Register Allocation and Aliasing mike@vlsivie.at (1990-07-15) |
Re: Register Allocation and Aliasing aglew@dwarfs.crhc.uiuc.edu (1990-07-16) |
Re: Register Allocation and Aliasing phorgan@cup.portal.com (Patrick Horgan) (1990-07-17) |
Re: Register Allocation and Aliasing heggy@cs.pitt.edu (1990-07-17) |
Re: Register Allocation and Aliasing aglew@oberon.crhc.uiuc.edu (1990-07-17) |
Re: Register Allocation and Aliasing lupine!rfg@uunet.UU.NET (1990-07-19) |
Re: Register Allocation and Aliasing lupine!rfg@uunet.UU.NET (1990-07-19) |
Re: Register Allocation and Aliasing vestal@src.honeywell.com (1990-07-19) |
Newsgroups: | comp.compilers |
From: | lupine!rfg@uunet.UU.NET (Ron Guilmette) |
Keywords: | code, optimize, analysis |
Organization: | Network Computing Devices, Inc., Mt. View, CA |
References: | <1990Jul14.222431.13761@esegue.segue.boston.ma.us> |
Date: | Thu, 19 Jul 90 18:20:14 GMT |
In article <1990Jul14.222431.13761@esegue.segue.boston.ma.us> Preston Briggs <preston@rice.edu> writes:
>Andy Glew writes:
>>> 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! ...
>And Ron Guilmette replied:
>>Actually, this sounds like a marvelous idea to me!
>...
>>Having a machine that did this stuff would effectively render alias analysis
>>(in compilers) "impotent and obsolete".
>I disagree. Alias analysis has many uses during optimization...
Who am I to disagree with sombody from Rice (especially Preston)? :-)
Preston's examples do in fact totally demolish my argument that clever
hardware could render alias analysis unnecessary.
Obviously, a good optimizing compiler will always need to do hefty analysis
of the code being compiled in order to understand which transformations can
and cannot be done (safely).
Nontheless, I think that there might still be a place for the hardware scheme
we were discussing. Although a compiler for such a machine would still need
to be pretty smart if it wanted to produce really good code, the hardware
scheme proposed for dealing with potential aliasing could still allow an
optimizing compiler to keep some values in registers over a larger range
than it could otherwise.
--
// Ron Guilmette (rfg@ncd.com)
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.