Vladimir N. Makarov wrote:
Vlad,
I think that different people can have different perspectives.
You have been working on improving the register allocation for several
years, but very little has come of it because the reload
infrastructure does not suit itself to being integrated with modern
Regs_ever_live is the poster child of this. In theory regs_ever_live is
easy, it is just the set of hard registers that are used. In practice
this is a disaster to keep track of because it was only updated
occasionally and its values are randomly changed by the backends in
totally
Richard Kenner wrote:
Regs_ever_live is the poster child of this. In theory regs_ever_live is
easy, it is just the set of hard registers that are used. In practice
this is a disaster to keep track of because it was only updated
occasionally and its values are randomly changed by the backends
On Sunday I had accidentally chat about the df infrastructure on
IIRC. I've got some thoughts which I'd like to share.
I like df infrastructure code from the day one for its clearness.
Unfortunately users don't see it and probably don't care about it.
With my point of view the df
Vlad,
I think that different people can have different perspectives.
You have been working on improving the register allocation for several
years, but very little has come of it because the reload
infrastructure does not suit itself to being integrated with modern
register allocators. You
On 2/13/07, Vladimir N. Makarov [EMAIL PROTECTED] wrote:
There are certainly performance issues here. There are limits on
how much I, and the others who have worked on this have been able to
change before we do our merge. So far, only those passes that were
directly hacked into flow, such
