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

[Andrew MacLeod <amacleod at redhat dot com>]

On Mon, 2005-08-22 at 15:22 +0200, Zdenek Dvorak wrote:
> Hello,

> > 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.
> 
> depending on how the address of the loads is computed, moving a single
> one of them may actually increase the number of registers needed, so
> a straightforward greedy approach won't work.  I don't know about
> approach that would not suffer from this type of local optimum problem
> and in the same time would be fast enough to be usable for a compiler.

I will not go into a long detailed description, I did say decent
rematerialization, not simple or greedy. This involves knowing the
effects of what rematerializing a load or a subexpression involves at
the point of rematerialization. And your case would be resolved just
fine.

> I by no means want to tell that improving RA is not a good idea; any
> piece helps.  Just that completely ignoring register pressure in simple
> and easy to modify optimizations and hoping that a very difficult
> process of RA will solve it does not seem like a correct approach to me.
> 

I will state until at least the day I die that optimizations should
focus on what they are suppose to do, and nothing else.  Things like
code motion should never concern themselves with register pressure. You
have inifinite symbolic registers, use them. Worrying about things like
that makes the code more complex, bug prone, and hard to maintain. With
a real register allocation infrastructure, we should be able to take
care of these issues.  

> Of course, also taking things to the extreme and wanting middle-end to know
> every single bit of architecture features is wrong.  But knowing just enough
> so that it does not make changes that would make proper optimization in later,
> lower level optimizers impossible seems more correct to me.

 "knowing just enough" means something different to everyone, and 10
years later you have unmaintainable spagetti code that needs to be
rewritten.  "Knowing nothing" means the same thing to everyone.


> >
> > Thats how we end up in these situations in the first place :-)
> 
> Agreed.  Unfortunately, I don't have time to work on tree->rtl expansion
> in near future, so I am doomed to add hacks to TER :-)

And so was I forced to write it in the first polace  :-) the eternal
curse...


Andrew
-