> > > 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.
does anything like that exist? All the RA algorithms I have seen so far
were pretty simple greedy approaches. Could you please provide some
reference so that I may check what you mean?
> 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
I did not tell that this one will not; I said that for each of them, it
would not be hard to create a natural example that would not. Whatever
approach you use, you are forced to very simple heuristics (by the
complexity of the problem and compile time limitations).
> > 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.
... and actually useful.
> With a real register allocation infrastructure, we should be able to
> take care of these issues.
When I see it, I will believe; seeing just our two attempts at RA and
the loads of work Vladimir, Daniel, and other people invested into
improving it for a very limited gain so far, I remain sceptical.