------- Comment #8 from hutchinsonandy at gcc dot gnu dot org 2008-05-05 01:15 ------- The following information from Kenny Zadeck, shows why the solution does not work. This limitation is not avoidable at the present time without causing compilation time/memory regressions on other targets. So we will have to live with the overly cautious saving of registers.
> The target computes offset (INITIAL_ELIMINATION_OFFSET). This is called > several times during register allocation (no doubt because something > changes). Offset is a function of the number of registers saved. So I used > DF_REG_DEF_CHAIN to work out precisely saved registers. But this information > is out of date and so the offset is wrong. > However, info provided by df_regs_ever_live_p, is updated. > > So I think the live info is updated in global.c but not the chains. Is there > a sane way around this or should I put this one on "too difficult list"? > > best regards > There are a three things to consider: 1) Incremental updating is turned off during global. This was perhaps a mistake, but what I did not want to get into was rescanning each insn that uses/defines a register whenever that register gets assigned. By turning off rescanning, each insn is only rescanned once, after all of its operands have had their registers assigned. 2) Turning this off is most likely the cause of your grief. It is possible that you could move the call to turn off scanning until later, after your bit of foolishness happens but before the actual registers are assigned, but the truth is that i really do not really understand the information flow within global/reload so i did not consider something like this. 3) Incremental scanning could be turned back on, but the cost is quite high because most insns have many operands and because reload can change the assignment of registers after global gets finished. Kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32871
