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: Bernd Schmidt <crux at pool dot informatik dot rwth-aachen dot de>
- Subject: Re: Reload patch to improve 386 code
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Fri, 04 Sep 1998 03:08:23 -0600
- cc: meissner at cygnus dot com, toon at moene dot indiv dot nluug dot nl, egcs at cygnus dot com
- Reply-To: law at cygnus dot com
Another reply to an old message from Bernd...
In message <Pine.SOL.3.90.970819095143.291G-100000@starsky.informatik.rwth-aachen.de>you write:
> Then, there are some simplifications that could be done. I don't like the
> inheritance code, find_equiv_reg and all that. IMHO reload shouldn't try to
> be very clever about this sort of thing - the reload_cse_regs pass can be made
> more clever.
While reload_cse_regs can help this stuff, I'm not sure that it totally
eliminates the need for the reload inheritance stuff. In fact, I'm
sure Joern can show you lots of case where improving inheritance leads
to better code.
So, I'm not sure it's time to ditch the inheritance code yet. Given
the structure of the locally spilling reload code, I do see how reload
inheriting gets noticably more complicated.
One thing we should try is a cook off between the locally spilling reload
code (with inheritance disabled) and the existing reload code. If
the locally spilling reloader generally wins, I'll support disabling
inheritance to get the benefit of local spilling. Then we can go
back later and try to make inheritance work with your reload code.
[ Then again, if you've made inheritance work, then there's no need
for the cook off :-) I guess I'll find out when I start actually
looking at the code. ]
jeff