On Tue, Feb 17, 2009 at 5:51 PM, Bernd Schmidt <bernds_...@t-online.de> wrote: > The conservative assessment is that all pseudos go on the stack. > However, this way you'll generate terrible code.
Yes. So make a not-too-optimistic estimate. And if it turns out your estimate is too small, then you roll back, update the estimate, and try again. This only works if you can make the "roll back" part work, but it's been done before (not for GCC, of course). > I don't really understand why people want to remove reload only to > implement the same thing elsewhere. I don't think "people" want to remove reload. Simplifying it, is probably a better description. Splitting out tasks not related to spilling. Trying to do the same things in a place where you can still create a pseudo, instead of trying really hard to find a register and change many choices of the register allocator while at it. > 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. There is at least one more major problem with reload: It performs instruction selection. A big issue with register allocation in GCC is that the register allocator doesn't even really know what instruction it is allocating registers for! Gr. Steven
