Ian Lance Taylor wrote:
Bernd Schmidt <bernds_...@t-online.de> writes:
Ian Lance Taylor wrote:
No, that makes no sense. What I'm suggesting is that we fix the stack
offsets of all local variables before register allocation, based on a
conservative assessment of how many registers will be saved on the
stack.
The conservative assessment is that all pseudos go on the stack.
However, this way you'll generate terrible code.
I think the number of pseudos on the stack is irrelevant. You put each
one farther down the stack at a known offset. The only interesting
number to choose is how many registers will need to be saved on the
stack.
Allocation of slots isn't that simple because you might be spilling
later, which in turn allocates a new stack slot. Note that you want the
new stack slot to actually be at a smaller address because it's likely
used far more often than the stack slots for pseudos that didn't get a
hard register.
You also can't make assumptions about stack/frame growth directions and
an address that is valid as fp+offset may not be valid as sp+offset'.
I think you're vastly over-simplifying the code in question.
I don't really understand why people want to remove reload only to
implement the same thing elsewhere. There are only two major problems
with reload IMO:
- the RELOAD_FOR_xxx mechanism of scheduling reload insns is terrible
- so is the inheritance code
Even so, the number of bugs in these seems to have dropped off over the
years.
The problem with reload is that it interferes with register allocation.
Even if gcc had a perfect register allocator, we would still generate
suboptimal code because reload would mess up the allocation. The key to
solving that problem is that we need to do instruction selection (in gcc
terms, picking which insn alternative to use) either before register
allocation or in conjunction with it.
I agree that instruction selection prior to or as part of allocation is
good. But until we're dealing with spills in the allocator as well,
we're still in a situation where reload can come along and muck things
up. Hence my desire to move more of the spill code generation into IRA.
Jeff
