This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Reload patch to improve 386 code
- To: law at cygnus dot com
- Subject: Re: Reload patch to improve 386 code
- From: Mark Mitchell <mark at markmitchell dot com>
- Date: Sat, 5 Sep 1998 21:28:50 -0700
- CC: amylaar at cygnus dot co dot uk, crux at pool dot informatik dot rwth-aachen dot de, meissner at cygnus dot com, toon at moene dot indiv dot nluug dot nl, egcs at cygnus dot com
- References: <23417.905033646@hurl.cygnus.com>
- Reply-to: mark at markmitchell dot com
>>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes:
Jeffrey> In message <199809052204.XAA14607@phal.cygnus.co.uk>you
Jeffrey> write:
>> > We actually have most of the stuff to implement this now. We
>> just need > to set the alias set for such MEMs so that they
>> have a different set > than all the MEMs created before reload.
>>
>> It's not quite that simple. You also have to know that
>> different stack slots don't alias each other.
Jeffrey> By setting the alias set, we disambiguate all the spill
Jeffrey> slots from all the other pointers in the code.
Jeffrey> We then let the existing base address tracking code
Jeffrey> disambiguate the stack slots from each other.
I don't see why the base address tracking code should have to do
anything. My plan was just to use different alias sets for each spill
register (we have 2^32 of them, after all!). If you like, you could
reuse these from function to function, so the maximum number of alias
sets used up this was would be the number of spills in any one
function. My guess is that if that gets close to 4 billion, we have
worse problems.
I'd be happy (delighted, even) to implement this, but I'd like a test
case that someone things will benefit. (I am in *no* way doubting the
existence of such a thing, but having one would allow me to verify my
work.)
Jeffrey> jeff
--
Mark Mitchell mark@markmitchell.com
Mark Mitchell Consulting http://www.markmitchell.com