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
> 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 und
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 wit
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,
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 ha
> 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
