This is the mail archive of the
mailing list for the GCC project.
Re: What to do with new-ra for GCC 4.0
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: dberlin at dberlin dot org
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 6 Jan 05 23:15:03 EST
- Subject: 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.