This is the mail archive of the gcc@gcc.gnu.org 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


    However, the part you've missed is that as it stands, because of how
    the compiler is structured, this would require moving a significant
    amount of reload to before register allocation.

No, I don't agree with that.  There are two areas of complexity in reload.
The largest is the mini-ra that it has in allocating registers for spills,
allocating them to reloads, and handling "inheritance".  This all goes away
and is, by far, the largest complexity and size in reload.

But the second reason for the complexity of reload is the fact that it
has to be 100% correct.  When it's done, *every* operand has to be precisely
correct.  That adds *significant* complexity: look at all the secondary and
tertiary reload stuff, for example.

But if an ra got it right, say, 80% of the time, that would be quite fine:
it's certainly OK for reload to have *something* to do and having it do
one fifth of what it used to do would significantly improve code quality.
But the "80/20 rule" says that it's 1/5 as much complexity to only get
something correct 80% of the time, so I disagree that a "significant" part
of reload is needed.  What would be needed is more like what we have in
constrain_operands and in the register preferencing code.


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