Re: Reload patch to improve 386 code

[Bernd Schmidt <crux@pool.informatik.rwth-aachen.de>]

> 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. ]

Inheritance doesn't seem to cause problems with my patch; I've never touched
it and did not run into bugs.  I just think it's horribly complicated and
could be done somewhat cleaner, and more reliable.  Just a few days ago I ran
across a piece of code for which reload generated twice as many instructions
as necessary, just because the inheritance code didn't catch a particular
case.  The reload_cse_regs code and the inheritance code do some very similar
things, and I think it would be better to have only one piece of code that
handles everything in a general fashion.
The only major obstacle I see is that currently the MEMs made by reload for
spill slots in the stack frame don't get handled very well by the alias code.
If alias.c knew that these don't alias with other MEMs, reload_cse_regs would
immediately be much more powerful.

Bernd