This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: What to do with new-ra for GCC 4.0

    I can't say I've really looked at new-ra, but I'm wondering whether this 
    is a sane idea.  Reload's purpose is to ensure that every instruction 
    matches its constraints, and its core algorithm is comprehensible enough 
    that you can know that it terminates and guarantees correct register 
    assignments.  If it is moved before register allocation, what happens to 
    these guarantees?  Or do you follow register allocation with another 
    pass of reload proper?

I've raised these issues as well and strongly agree with you that the original
purpose of reload (what you describe) is still needed.  However, reload has
become immensely complicated lately with all the register tracking it does
among the reloads and in trying to reuse old reloads.  This is indeed a
task more properly done by a register allocator and the fact that reload
will override the register allocator's work is also problematic.

However, how to do this in a more unified fashion is indeed a challenge.
Having the register allocator be responsible for all the spills and fills
might be a good thing, but basically means moving (or copying) a large chunk
of reload's code into the register allocator.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]