Hi, Thanks very much. I still have doubts on your suggestion:
AFAIK, the back-end pass consists of (in order) : reg move -> insn sched -> reg class -> local alloc -> global alloc -> reload -> post-reload. There are edges from reg move to reg class and reload back to global alloc. In case I want to implement a linear scan which may split live ranges (pseudos) into live intervals(smaller pseudos) and allocate different registers for each of them. This process would break the whole loop. So, what did you mean by --- "run this pass in between the register allocator and reload, that would probably be doable."? regards, Raj Ian Lance Taylor <[EMAIL PROTECTED]> wrote on 12/21/2006 09:02:04 PM: > Rajkishore Barik <[EMAIL PROTECTED]> writes: > > > Does anyone know of any document describing (in details) the reload phase > > of GCC? > > There isn't one. The closest such document is > http://gcc.gnu.org/wiki/reload > which is accurate despite, or perhaps because of, starting out by > equating reload with Satan. > > > I am planning to write a linear scan reload for GCC (one that does not > > take reg_renumber > > but takes instruction specific register allocation and move information). > > Can anyone point me > > to some existing code/literature for this in GCC? > > There is none. > > If you expect this pass to actually replace reload, then I advise you > to reconsider. That would be a hopeless task. Well, maybe you could > do it if you restrict yourself to a single architecture. > > If you want to run this pass in between the register allocator and > reload, that would probably be doable. Of course, reload will then > muck up your decisions, and the resulting code will sometimes be worse > than what you get today. But it might be an interesting experiment. > > Ian
