Re: [patch] Fix behavior of TER on unrolled loops

[Andrew MacLeod <amacleod at redhat dot com>]

On Sat, 2005-08-20 at 22:03 +0200, Zdenek Dvorak wrote:
> Hello,
> 
> > > The patch fixes the problem 
> > 
> > You mean works around the problem, by basically disabling any form of
> > coalescing.
> > 
> > It should be clearly marked as something that should be removed when we
> > have a sane register allocator (IE FIXME)
> 
> it is not at all clear to me that this can be fixed by register
> allocator; at least not unless it performs quite extensive code motion.

I took a quick look, any decent rematerialization scheme would fix that
up quite nicely.  There is nothing killing the loads, so nothing
preventing them from being moved down to their uses.

> I am somewhat pessimistic about ever getting register allocator that is
> able to mysteriously fix all the problems with register pressure.

nothing will ever mysteriously fix all the problems, but we should be
able to get something which solves a lot of our problems, with some work
of course :-)
  
> Register allocation is unfortunately hard enough problem even without
> trying to make it to fix all the stupidities previous passes do.

Stupidity is in the eye of the beholder. As Dan said, RA's job is to fix
register pressure issues. symbolic IRs allow inifinte registers for a
reason.
> 
> Yes, it is a workaround in the sense that it does not really fix
> all the possible problems.  If you try hard enough, you are still able
> to persuade TER to cause this behavior.  This patch is just good enough to
> catch the common case coming from unrolling.


TER is simply a stopgap solution put in place to allow tree-ssa to
compete with the original code passed to the expanders.. the one true
solution is to rewrite the expanders and get code that has registers
where we have ssa names instead of this crappy "turn everything back
into a variables, mash it all together so we present large trees to our
complex expanders" scheme.  There wasn't time when tree-ssa was getting
into mainline, but we really ought to make the time rather than
continually hacking on top of the hack. 

Thats how we end up in these situations in the first place :-)


Andrew

PS. Im also not saying additional small hacks onto  TER to fix up
problems isnt acceptable either. I realize an expander rewrite is a real
project, not a quick evening hack. (  or is it?? :-)